[Design] [Scooby] First draft of the 0.3 spec

[Mimi Yin]

Hi Priss,

What a doozy of a spec. I just have a few questions below. Mostly  
having to do with fleshing out some of the use cases and user  
motivations...just so we have it all documented. :o) Mimi

> Overview
> Scooby is the next generation web calendar application.
Should we update this sentence?

> This document details the features for Scooby 0.3. The features are  
> based on the 0.3 target user. An OSAF employee who is tasked to use  
> Scooby to put in their paid time off (PTO) on the office calendar.
I wonder if the passive voice: 'tasked to use' puts a top-down slant  
on the use case in a way that doesn't accurately reflect the  
unstructured nature of small group interactions, which in turn is the  
foundation for the proposed designs. 'An OSAF employee needs to send  
out a PTO (paid time-off) announcement and has been asked to update  
the shared office calendar as well.

> We’ve selected a set of features to implement based on this usage  
> scenario.
> This document will outline the following features:
> Anonymous Access
> Navigation
> Notification

I think the stuff below is technically not for the 0.3 target usage  
scenario? Should we mention that this is working towards our 2ndary  
Beta / 1.0 target user here? Chandler user checking their personal  
calendar on the web when they're away from their personal computer.
> Account Viewing
> Calendar Canvas
> Managing Time-zones
> Managing Events

> Anonymous Access
> Goals and Objectives
> The primary use case for 0.3 is to enable someone from OSAF to  
> easily update their PTO on the office calendar, using the web  
> client as an interface. Today, this individual would simply send an  
> e-mail to everyone at OSAF with PTO in the title and an office  
> admin (or in this case the executive assistant, Esther) is  
> responsible for updating an iCal version of the office calendar.  
> Eventually Esther’s time and the use of the iCal version of the  
> office calendar would be eliminated in the process and everyone  
> would update their PTO or other travel time on the shared read- 
> write office calendar.
> The goal of anonymous access is to create an experience of read/ 
> write to the office calendar to be as simple for the user as  
> sending out an e-mail.
>
> Use Cases
Are all of these users Individual Contributors like Andi?

> User A does not use the office calendar but wants to be able to  
> view and/or edit (depending on the url) the information in this share.
> User B receives the URL to the office calendar and decides to sign  
> up for a new account on Scooby.
What is the user motivation for signing up for an account?  
(Influences how we phrase the sign-up language.)
> User C receives the URL to the office calendar and wants to view  
> the office calendar in iCal (or some other CalDAV client).
Subscribe to the calendar?
By other CalDAV client do we mean Evolution?
What about subscribing with a Chandler client?

> User D already has a Cosmo account and uses Scooby and would like  
> to add the office calendar to his shared collection.
List of shared collections?

>

>
>

Does User C need to copy the URL from their email? or can they copy  
it from the Scooby UI? (Maybe copy to Clipboard button like in  
Chandler?)

Will the new calendar be automatically added to User B and D's accounts?

> Requirements
>
> URL/Ticket pointing to Scooby: A URL/ticket once received from  
> Chandler would directly point to Scooby when the user clicks on the  
> URL from an e-mail. The user could also copy and paste the URL into  
> some other CalDAV client such as iCal. This feature has significant  
> dependencies in the development of Chandler–That the URL/Ticket  
> when sent from Chandler and clicked on in an e-mail will do the  
> right thing and point to either a read/read-write calendar on Scooby.
or...

> Event editing without an account: Chandler currently sends out two  
> types of URL/tickets, read and read-write. In our current usage  
> scenario, when the user clicks on the the URL received in an e-mail  
> from Chandler, it would point to the office calendar on Scooby in a  
> web browser. If the URL/ticket is read-write the user would not  
> need to sign up for a Cosmo account to begin editing the calendar.
>
> Remember Me check box (as illustrated in the detailed work flows):  
> A check box which would allow the anonymous user to store event  
> edits and other changes on a cookie without requiring the user to  
> sign up for an account. Cookies are stored on the client side and  
> information is stored on a computer by computer basis. This feature  
> is dependant on the outcome of security concern discussion on the  
> list and has been deferred.
I think the [x] 'Remember me' feature is more to store URL ticket /  
passwords. The next time I click on a URL to access a share, there is  
a pull-down where I can choose from all of the other shares I've  
accessed in the past on this computer with Scooby.

> The proposal for anonymous access is defined for 0.3 but does  
> raises security concerns for the 1.0 timeframe.

> SECURITY ISSUES:
> If you get a hold of a ticket you can make anonymous changes to a  
> calendar and nobody knows. We are giving anonymous access to anyone.
> Tickets as they are implemented today are not very secure.
> In the web space, it's more common to force people to login ie; Flickr
> For something list evite, users can RSVP (have some level of  
> editing but not full access)
> There are concerns about things like calendar spam - people put the  
> URL on an online forum. We already have wiki spam issues today.
> We currently allow anonymous access for the desktop client but  
> there are strong feelings that there's a fundamental difference  
> between giving web access and doing this from a desktop client

> DESIGN ISSUES:
> Username/password account logins is a known usability problem.  
> Username/password accounts makes it easier for service providers to  
> manage security leaks. However, they are onerous for the user and  
> present a significant barrier to entry for new users, especially  
> casual users.
> On the other hand, it is common in the web space to for anonymous  
> users to participate as a viewer only or a restricted users (can do  
> limited things).
> ACLs are a more common scenario to handle something like this but  
> the current plan of record was to have ACLs for 1.0. From a PPD  
> perspective, ACLs are also very complicated and there would still  
> be significant work to figure out how to make this usable and  
> doable in the current product timeline.
> There are some questions about how ACLs fit in with our  
> "calendaring without IT" organization goals.
> Should we consider per user tickets? How difficult is this. Are  
> there other creative options ie: forcing anonymous users to  
> decipher an alpha-numeric string from a garbled up image?
> These issues are being addressed on the design list; discussion  
> topics: Anonymous Access and URL/ticket support.
>
> UI Details
> Please review the notes on the use cases and download the detailed  
> work flows (download .pdf file).
>

> Navigation
> Goals and Objectives
> The goal is be able navigate to different views to see the events  
> on a Chandler calendar in the web application Scooby.
>
> Use Cases
> 1. 'Go to' date: The user is attending a wedding September 8, 2006,  
> five months ahead. Typing in the {mm/dd/yyyy} will help navigate to  
> the exact date opposed to selecting the navigational arrows  
> multiple times to find the correct date.

Individual Contributor (IC) in a small work group needs to update the  
shared office calendar with their PTO information. IC is taking  
vacation in a month. When IC launches the office calendar in Scooby,  
the calendar is centered on 'This week'.

Should we add in why the user wants to figure out the wedding dates?  
e.g. I am going to a wedding in September. The couple getting married  
created a wedding schedule calendar and shared it with me. I am now  
trying to make flight and hotel reservations. I would like to go look  
at it to figure out optimal flight times and hotel check-in, check- 
out dates. I may also want to figure out where the all-night booze- 
fest party / reception is going to be held and pick a hotel that is  
in walking distance.

> A Miniature Calendar will help provide preview to the month ahead.  
> For example, if the user needs to see what day it is for an event  
> two weeks from today, a simple glance to the Mini Cal will provide  
> the information the user needs without having to navigate the main  
> calendar.
> Requirements

Should we add some use cases for Mini-calendar for our 0.3 target users?

> 'Go to' date: An empty field with the title 'go to date' allow  
> users to type in the {mm/dd/yyyy}. This will bring up the week of  
> that exact date, and that date will be highlighted.
>
> Nice to haves for 'go to' date:
> The date picker will be forgiving to inconsistent entries. When a  
> user enters {5/5/06}, the calendar is able to interpret the date to  
> {05/05/2006}; a two digit year will be interpreted to the current  
> century. The restrictions are specific to numbers and slashes for  
> dates.
>
> Error dialog box (see sketch below): Any dates entered with text or  
> other punctuation, such as dashes or periods, separating the month,  
> day and year will immediately pop up an error box which will  
> request the user to type in the correct date format. The entry box  
> in the the error dialog box will default to 'Today’s date' to  
> clarify how the date format is entered. If the user hit the  
> 'return' key after entering the date in the error box, the dialog  
> box will disappear and the calendar canvas will have gone to the  
> date specified in the 'go to' date. Currently on Chandler the input  
> box just adds a '?' when a date format is not recognizable.
>
> Keyboard short-cuts to the 'go to' date. Eventually the 'go to'  
> date may not always be visible from the calendar canvas. Currently  
> the keyboard short cut in Chandler is to hold down the 'Shift' - 
> key, 'Command' -key and the letter 'T' - key. A dialog similar to  
> the error dialog box would appear and allow the user to type in the  
> 'go to' date and hit the enter key. The main difference would be  
> the message in the dialog box, which would say, ”Enter the date  
> you would like to go to in the dd/mm/yyyy format”. The entry box  
> would default to 'Today’s Date'.
>
> The date format needs to accommodate internationalization. Date  
> formats in europe are typically {dd/mm/yyyy}. The selection of how  
> the user would like to view their date formats may be selected in  
> user preferences, and that will be defined in a later release.
>
>

>
>

>
> Miniature Calendar (Mini cal):
> The Mini cal will be integrated for Scooby 0.3, but is not a high  
> priority feature to focus on because it does meet the usage  
> scenario for 0.3. Development for the basic framework will be  
> integrated during this timeframe. The user can preview the month  
> days/weeks/month ahead without having to select the arrow buttons  
> multiple times to view a specific date.
>
> The following is a description for the basic functionality needed  
> for a miniature calendar in a target user's release.
> A miniature view of the current month and the month ahead will  
> always be displayed on the web application. Location of the Mini  
> cal on the web application is tbd.
>
> Clicking on a specific date will have three states. A mouse  
> rollover state: the specific date is highlighted. After three  
> seconds if the mouse stays still in the hover state, a tool tip may  
> appear displaying a message, ie. "Click here to jump to the date".  
> A pressed state: where the specific date is highlighted in a  
> different color/outline to indicate the date has been selected. The  
> selected state: the entire week is selected with the specific date  
> within the week.
>
> The specific date on the 'week view' of the calendar canvas is  
> highlighted. The Mini cal will have the week 'lightly' highlighted  
> and the 'current day' will have a 'strong' highlight color.
>
> Issue:
> Will need to provide visual and interaction states for the mini cal  
> Not necessary for the target user's release, but will be noted for  
> future implementation.
>
> Hiding the mini cal: A preference to hide/show the mini cal on the  
> web application. This may preserve space on the web application.
>
> Hover detail: A mouse hovering over the mini cal on days with  
> events will bring up information on the event without jumping to  
> that date/week or refreshing the page/week view area.
>

> Notification
> Goals and Objectives
> The goal of notification is to inform other users sharing the same  
> calendar that an event change has been made.
Probably not all changes to events. More like...
+ A new event has been added to the calendar
+ A significant change has been made to the calendar

> Use Cases
> After the user
Casual Collaborator?
> enters in their PTO on the office calendar, they would like to  
> notify other recipients who share the calendar that they have made  
> a change. Clicking on this link will launch their default e-mail  
> client and pre populate a form message in the subject line and the  
> body of the e-mail.
>
>

>
> Requirements
>
> Mail to link notification: This is a 'mail to' link which will  
> launch the user's default desktop mail application. A new e-mail  
> message will appear with the subject and message repopulated with a  
> form letter. The form letter message should indicate an event has  
> been changed on the 'Office Calendar' collection, and the details  
> associated with it.
>
> Subject line = Events changed on Office Calendar: Event title
> Body = Date/time information PLUS text from the Notes field of the  
> event.
> Date/time information includes:
> Start date/time
> End date/time
> Time-zones
> Recurrence rules
> Recurrence end date
>
> Chandler users receive notifications from users who made changes on  
> Scooby, not only from an e-mail, but be alerted when they open up  
> Chander. Is it possible to insert something into the Body of the  
> email that the Chandler could look for? This would complete the  
> workflow and allow Chandler users to receive Scooby communications  
> in the client.
>
>
> UI Details
> Sample E-mail
> To:
> everyone at osafoundation.org
> Cc:
> oval at tofu.com
> Subject:
> {Office} calendar change {Andi working from France}
> When: {July 12, 2006 - Aug 15, 2006, PST, All day}
> {Off to France with family. Will be working remotely from my  
> vineyard. ;)
> Salute, And.}
> Data within the {x} are typed in by the user on Scooby. Form  
> elements include {Name of calendar collection}'calendar change' in  
> the subject line and and 'When' in the body.
>

> Account viewing in Scooby (Subscribe workflow)
> Overview
> There are two types of users when you subscribe to your account  
> from Cosmo.
> Chandler users will want to view their shares (published and  
> subscribed), which is basically whatever data is in their account  
> on the server. Using the same account information, users should be  
> able to log into Scooby and view all the data information they see  
> in Chandler reproduced in Scooby.
>
> People who do not use Chandler and do not have Cosmo accounts. They  
> should be able to get a URL/ticket from someone's calendar when  
> clicking the URL/ticket will automatically view the shared  
> calendar. Depending on the URL/ticket the user will have either  
> read/read-write access, but do not have to log in to edit the  
> calendar. There is no publish operation on the Scooby side to  
> Chandler.
>
>
> An easy way of thinking of this is...
> There is information on the server - calendar events (and in the  
> future other items).
> Both Scooby and Chandler are simply giving a window onto that data.
> There may be some differences between what each application can do  
> to the data
> There also may be some differences on how the data gets onto the  
> server.
> Chandler has a local repository and Scooby does not.
>
>
> Dependencies: Workflow in Chandler to easily access your data on  
> Scooby? This is separate from publishing your individual collection.
Sync your Chandler data on Scooby?
A related, but separate use case is: I want to sync my Chandler  
client at work with my Chandler at home. How do I do that through the  
Hosted Service?

> Chandler user can publish their account information in Cosmo  
> including subscriptions to other servers (ie. .Mac, GCal, etc.) and  
> Scooby would be able to recognize all the collections in Cosmo and  
> display it on Scooby.
This is the issue being hashed out with Morgen right now?

> Once a user subscribes to another calendar elsewhere, it is synced  
> to Cosmo. Does Chandler need to sync with Cosmo first before this  
> subscription is viewed on Chandler?
>
> For the first phase, only data from the calendar collection will be  
> displayed. That is until a list view is created to view other data  
> translated from Chandler.
>
> Currently there is a discussion on the list about Scooby/Cosmo  
> merge which may have significant impact on this feature.
>
> Goals and Objectives
> The goal is for Chandler user to be able to view all their  
> collections in Scooby based on the user’s account information. So  
> if a Chander user has 2 collections from cosmo-demo and 1  
> collection from .Mac, Scooby would be able to interpret all the  
> collections based on the user’s account. This feature is deferred  
> to a future release as it does not meet Scooby 0.3 target user’s  
> need.
>
> Use Case
> Chandler users would like to be able to view their information via  
> the web application, Scooby. Having information stored on a web  
> application may be useful when the user does not have their usual  
> computer with them. When logging on to Scooby, the user will view  
> their account information and all the collections and data from  
> Chandler is displayed in Scooby. Though specific to 0.3, Scooby  
> will only be focused on calendar data.
>
> Requirements
> Log on to Scooby: If the user already has an account on Cosmo, when  
> they log on to Scooby using the same account information all the  
> information published and subscribed from Chandler will be  
> displayed in Scooby.
>

> Calendar Canvas
> Goals and Objectives
> The goal of the calendar canvas is to view information from  
> Chandler the desktop client via Scooby, the web application. Scooby  
> 0.3 is still primarily focused on only the calendar information, so  
> other information, such as task items etc. which may be in a  
> collection of Chandler may not be viewable in Scooby.
>
> Use Cases
> User may have a set of dates to enter in the calendar and by having  
> a list view, it may be easier to enter in all the dates in a list  
> format then having to click through the calendar canvas.
We also have Julie sharing a kid's events calendar with family and  
friends. The calendar is relatively sparse, maybe 10 events on it  
total, spread over a period of 3-12 months. Being able to view the  
events in a list allows the sharees to get a sense of what's on the  
calendar without having to troll through it week by week or month by  
month.

> A user may want to view just the events in the upcoming days. The 4  
> day view will open up more space on the calendar canvas and allow  
> more information to appear on the lozenge.
Should we add some specific examples for this? When would someone  
want to see the next 4 days versus the next week? e.g. I'm attending  
a 4-day conference that is packed with sessions and events.

> A user may want to see when someone is returning from maternity  
> leave. The month view can provide a visual cue of how long the  
> leave is from start to end.
+ Also keeping track of traveling is a really common use case.  
Assistants use the month view to keep track of when the Apex is where.
+ Really useful for event calendars (e.g. parties, performances, PTA  
meetings, games)
+ Coordinator might keep track of how long a particular museum tour  
runs for.
+ Hub keeps track of PTOs.

When would an user use Scooby to do this versus the desktop client?

> Having a day view will allow the user to be able view all the event  
> information displayed throughout the day in the event lozenges.  
> This view is particularly popular for printing out and carrying the  
> information as a person would go from one meeting to another  
> without bringing their computer with them.
Specific use cases? I'm at a conference. I log in at a kiosk and I  
want to print out the conference schedule I created for myself at  
home (all the sessions I wanted to go to).

> Visual cues help make the user identify between the desktop and web  
> applications; that they belong in a suite of products. The rules  
> for consistency are used only where it makes sense, and sometimes  
> there is technology or layout in a web application, Scooby to  
> differ from the desktop application, Chandler.
>
> A Chandler User views their calendar in Scooby. There are alarms  
> set on his events in Chandler. When viewing his Chandler calendar  
> in Scooby, the user would like to see all the information stored in  
> an event that is the same created in Chandler. Information such as  
> the status and if there is an alarm set on the event.
>

> Requirements
> List view: This view is primarily for the user add events to the  
> calendar or 'to do' items in a list. This view will also display  
> items from the 'Dashboard' from Chandler, though not all  
> functionality will fully functional, ie. drag and drop. Once items  
> are entered onto the list, the calendar event items would also  
> appear in the calendar views. Basic functionality for the list view  
> include, a header, in place editing, sort, multi-select, cut copy  
> duplicate & paste. Review Chandler Alpha 2 dashboard specification  
> for more detail information on basic table functionality.
>
> Next 4 days view: This view is primarily for the user to view  
> what’s happening for the next four days. When the user clicks to  
> view 'next 4 days', it should look similar to week view, but  
> starting at today’s date and only displaying the four days ahead.  
> The lozenges on the calendar canvas is opened up and more detail  
> information will be displayed.
>
> Month view: This view is primarily for the user to view one month  
> at a time on the calendar canvas. This view helps the user scan  
> several weeks at a given time.
>
> Day view + Print: This view displays more detailed information on  
> the event lozenge. The view will display the minimum amount of the  
> working hours, 8AM-6PM within the day. I recommend to have the 'day  
> view' page be printer friendly as it's common for users to print  
> out their schedule for the day and work from a printed sheet.
>
> Visual Tweaks: Based on the target user release goals. The  
> following is a high level list of visuals to work on and complete  
> for Scooby 0.3
>
> Review fonts–Should all the fonts exactly the same to meet  
> consistency on all browsers/platforms?
> The display of working hours (8AM-6PM) to be viewable on screen  
> with out scrolling down (1024x768 minimum screen size)–Is one line  
> of information displayed on the lozenge enough of a cue for users  
> to know what event that is? Does the user need more information  
> which could be displayed in a mouse over?
>
> A thicker line on the horizontal timeline to the left to indicate  
> working hours.
>
> Lozenge states for @time, anytime, and processing event.
>
> Alarm display: Events with alarms from Chandler bay display in the  
> lozenge and detail view in Scooby. Even though alarms will not be  
> fully functional in Scooby, the events created in Chandler with  
> alarms will need to be indicated so the information from Chandler  
> is not lost in Scooby. Visually this 'alarm icon' could be grayed  
> out or have a strike through to indicate the alarm is not  
> fuctioning. A mouse over with a tool tip could describe 'alarm set  
> on event in Chandler'. Since this feature is not required for 0.3  
> target user, it has been deferred. The team is is still flushing  
> out the details of this feature, if it is really necessary to build  
> this until it is fully functional. See the discussion on the list.
>
Layout issues?

> Managing Time-zone
Just to be clear, these use cases are not required for the 0.3 target  
user and usage scenario?

> Goals and Objectives
> To provide basic time-zone infrastructure with minimal UI for 0.3.  
> Fully functional time-zone features will be deferred to a future  
> release.
>
> Use Cases
> User is traveling and would like to see office meetings (in their  
> Home time-zone) on the calendar.
> User is managing a calendar for someone who is traveling in a  
> different time-zone.
> User is scheduling a meeting with someone in a different time-zone.  
> The user would like to be able to change the time-zone of their  
> calendar so they can view and pick a time that would work for both  
> parties.
> User receives a request for a meeting in a 'remote' time-zone. The  
> user would like to view the meeting time on their calendar in their  
> 'home' time-zone.
> Requirements
>
> Floating time-zone: This is when the user has not turned on time- 
> zone. All events will be in floating time until the user selects  
> time-zone support in the user preferences.
>
> Time-zone preferences: From the user preferences dialog, the user  
> would have to first turn on the time-zone support. Once turned on,  
> the time-zone will appear on the calendar canvas and default to the  
> computer’s time-zone. (Should be possible to locate time-zone from  
> computer, if not then default to floating time-zone)
>
>
> Edit time-zones on specific events: When the time-zone support is  
> turned on, a time-zone picker would also appear in the event  
> details. The location of the drop down box would appear right after  
> the end date/time line. The user can now change the time-zone on  
> the event and it would move the event lozenge to the time-zone  
> based on the calendar canvas. For example, the time on the lozenge  
> would display the 'home' time-zone on the calendar canvas, but in  
> the event details the time would start from the 'remote' time-zone.
>

> Managing Events
Just to be clear, these use cases are not required for the 0.3 target  
user and usage scenario?

> Goals and Objectives
> To allow the user to be able to set and make changes to recurring  
> events. Special events such as @time and anytime be displayed  
> correctly. Events which may have an alarm set in Chandler to  
> display disabled in Scooby since alarm functionality will not be  
> working for 0.3.
>
>
> Use Cases
> User has meetings bi-weekly on Thursday mornings. After entering in  
> the first event, a user can select from the 'occurs' drop down menu  
> 'bi-weekly' and the event will automatically populate the calendar  
> canvas bi-weekly.
>
> An @time event is used when a user wants to create an event, but  
> may seem more like a task item. Everyday at 7am the user jogs and  
> it is an event on the calendar. Even when the user travels to  
> different places, and the calendar canvas may have changed time- 
> zones, the user still jogs at 7am and the @time event does not change.
>
>
> An anytime event to help the user comprehend fuzzy dates. Sometime  
> today I need to pick up a gift for my husband. Sometime this week I  
> should meet with Jane for lunch. Sometime this month I need to take  
> the dog to the vet for a check up.
> Requirements
>
> Recurring events: Event details need to have line item after end  
> date, 'occurs' with a drop down box which the following selection:  
> Once, Daily, Weekly, Bi-weekly, Monthly and Yearly. The drop down  
> box should default to 'Once'. One the selection has been made, the  
> event lozenge should display according to selection in the  
> recurring event. Once the event is set, when the user makes any  
> change to the event, a dialog box should appear to confirm the  
> change of the recurring event. The user then has an option to  
> select 'Only this event', 'All future events' or 'Cancel'.
>

> Display of @time events/Anytime events: Review the different  
> variations of event lozenges. Bug# 6203 and bug# 6204.
>
> Assumptions
> The target user selected for Scooby 0.3 is performing a very  
> specific task and this task is not intended for a general audience.
>
> Calendaring is still the main focus for 0.3. Other features  
> addressed in Chandler will commence at a later release.

> Terminology
> There are currently two target users we are focused on for the  
> release of Scooby 1.0. They are:
> Casual Collaborator - Non-Chandler users viewing calendars  
> published from Chandler. These users are illustrated in the diagram  
> below.
>
> Chandler Users - Users of Chandler reading their calendars on the  
> web using Scooby. This implies casual use.
>
> For Scooby 0.3, our top priority is focused on a specific usage  
> scenario for the Casual Collaborator. Our top priority is to detail  
> what we need to satisfy our main target usage scenario first. We  
> will also be making progress for the Chandler user, though this  
> would be specific to calendar.
>

>
> Code Design
> Re factoring the new layout code. Mde to fill out...
> Specials Considerations
> QA / Test
> Any info that will be useful for testers. Special cases or  
> scenarios to consider.
> API / Developer Platform
> If relevant, how the feature will be made accessible to coders?
> Security
> Discussion topics: Anonymous Access and URL/ticket support.
> Fine grain security for RPC calls. Bobby to fill out...
> Internationalization / Localization
> 'Go to' date - User would be able to set in preferences how they  
> would like to see their dates displayed, {dd/mm/yyyy} or {mm/dd/yyyy}
> Accessibility
> UI must be accessible (Section 508).
> Build / Install
> To create a a 'start up script' to know when SNARF is being run for  
> the first time for Mac, Windows, & Linux. The will help developers  
> who are not familar with 'JAVA_HOME' and want to download the  
> bundle and start hacking away at the code. This is primarily for  
> developers and not for end users.
>
> Cuts
> Overlay
> Overlay is a feature currently in Chandler which will eventually be  
> in Scooby. This feature is dependent on how collections will be  
> displayed. Currently Scooby can only view one collection at a given  
> time. UI needs to be in place for viewing multiple collections  
> before the overlay feature can be implemented.
> Useful Links
>
> History
> Author
> Edit date
> Description
> Priscilla Chung
> June 25th, 2006
> First Draft

On Jul 17, 2006, at 3:24 PM, Priscilla Chung wrote:

> Last week I finally buckled down and sketched out/wrote down in  
> detail the features we've talked about for planning Scooby 0.3.  
> Here is the first draft of the spec for review. We're still working  
> out the details (per the discussion on the list) on some of the  
> features–though this may be a good place to start in terms of  
> understanding where features may fit and why we chose these  
> features for 0.3.
>
> http://svn.osafoundation.org/docs/trunk/docs/specs/scooby/rel0_3/ 
> zeroDot3.html
>
> Thanks, -Priscilla
> BTW. I'm sending this to the scooby-dev list for this time, but in  
> future, all specs relating to Scooby planning will be sent to the  
> design list tagged with [Scooby]._ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Design" mailing list
> http://lists.osafoundation.org/mailman/listinfo/design

-------------- next part --------------
Skipped content of type multipart/related