- Revision
- 849
- Author
- priss
- Date
- 2006-07-15 23:46:02 -0700 (Sat, 15 Jul 2006)
Log Message
First draft Scooby 0.3 spec + images
Added Paths
- trunk/docs/specs/scooby/rel0_3/
- trunk/docs/specs/scooby/rel0_3/anonyAccessFC.png
- trunk/docs/specs/scooby/rel0_3/casualCollbDiagram.gif
- trunk/docs/specs/scooby/rel0_3/goToDate.gif
- trunk/docs/specs/scooby/rel0_3/goToDateError.png
- trunk/docs/specs/scooby/rel0_3/notificationFC.png
- trunk/docs/specs/scooby/rel0_3/recurringEvents.gif
- trunk/docs/specs/scooby/rel0_3/zeroDotThree.html
Diff
Added: trunk/docs/specs/scooby/rel0_3/anonyAccessFC.png
(Binary files differ)
Added: trunk/docs/specs/scooby/rel0_3/casualCollbDiagram.gif
(Binary files differ)
Added: trunk/docs/specs/scooby/rel0_3/goToDate.gif
(Binary files differ)
Added: trunk/docs/specs/scooby/rel0_3/goToDateError.png
(Binary files differ)
Added: trunk/docs/specs/scooby/rel0_3/notificationFC.png
(Binary files differ)
Added: trunk/docs/specs/scooby/rel0_3/recurringEvents.gif
(Binary files differ)
Added: trunk/docs/specs/scooby/rel0_3/zeroDotThree.html (848 => 849)
--- trunk/docs/specs/scooby/rel0_3/zeroDotThree.html 2006-07-14 00:38:12 UTC (rev 848) +++ trunk/docs/specs/scooby/rel0_3/zeroDotThree.html 2006-07-16 06:46:02 UTC (rev 849) @@ -0,0 +1,664 @@ +<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> +<html xmlns="http://www.w3.org/1999/xhtml"> +<head> + + <title>0.3 Spec</title> + <link href="" type="text/css" rel="stylesheet" /> + <meta http-equiv="Content-type" content="text/html; charset=ISO-8859-1" /> + <meta http-equiv="Content-Language" content="en-us" /> + <meta name="description" content="OSAF Project Specification" /> + <meta name="keywords" content="OSAF, Open Source, Specification" /></head> +<body> +<div id="masthead"> +<div id="breadcrumbs"><a href="" +Home</a> > <a href="" +> 0.3 Specification<br /> +</div> +<h1>0.3 Specification<br /> +</h1> +<table width="100%"> + <tbody> + <tr> + <td width="33%">Authors: <a href="" PROTECTED]">Priscilla Chung</a> </td> + <td width="33%">Last edited:<!-- #BeginDate format:Am1a -->July 15, 2006 11:32 PM<!-- #EndDate --> </td> + <td width="33%">Creation date: June 25th, 2006 </td> + </tr> + <tr> + <td colspan="3">Reviewers:</td> + </tr> + </tbody> +</table> +</div> +<div id="maincontent"> +<a name="top"></a> +<h2>Overview</h2> +<p> Scooby is the next generation web calendar application. This document details + the features for Scooby 0.3. The features are based on the <a href="" target="_self">0.3 + target user</a>. + An OSAF employee who is tasked to use Scooby to put in their paid time off + (PTO) on the office calendar. We’ve selected a set of features to implement + based on this usage scenario. </p> +<p>This document will outline the following features:</p> +<ul> + <li><a href="" Access</a></li> + <li><a href="" + <li><a href="" + <li><a href="" Viewing</a></li> + <li><a href="" Canvas</a></li> + <li><a href="" Time-zones</a></li> + <li><a href="" Events</a></li> + <li><a href="" Features specific to 0.3</a></li> + </ul> +<a name="AA"></a> +<h2>Anonymous Access</h2> +<h3>Goals and Objectives</h3> +<p>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.</p> +<p> 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. </p> +<p></p> + +<h3>Use Cases</h3> +<ol> + <li>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. </li> + <li>User B receives the URL to the office calendar and decides to sign up for + a new account on Scooby.</li> + <li>User C receives the URL to the office calendar and wants to view the office + calendar in iCal (or some other CalDAV client).</li> + <li>User D already has a Cosmo account and uses Scooby and would like to add + the office calendar to his shared collection. </li> +</ol> +<p><div style="margin-left: 10%;"><img src="" width="727" height="1078" /></div></p> + +<h3>Requirements</h3> +<b> <br/> +</b> +<div style="margin-left: 40px;"><b>URL/Ticket pointing to Scooby: </b>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. <br /> +<br /> +<b>Event editing without an account: </b>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.<br /> +<br /> +<b>Remember Me check box <em>(as illustrated in the detailed work flows)</em>: </b>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. <strong>This feature is dependant on the outcome of security concern discussion +on the list and has been deferred.</strong> </div> +<div class="issue"> + <p><strong>Issue</strong>: The proposal for anonymous access is defined for + 0.3 but does raises security concerns for the 1.0 timeframe.</p> + <p> SECURITY ISSUES:</p> + <ul> + <li>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.</li> + <li>Tickets as they are implemented today are not very secure.</li> + <li> In the web space, it's more common to force people to login ie; Flickr</li> + <li> For something list evite, users can RSVP (have some level of editing + but not full access)</li> + <li> There are concerns about things like calendar spam - people put the + URL on an online forum. We already have wiki spam issues today.</li> + <li> 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</li> + </ul> + <p>DESIGN ISSUES:</p> + <ul> + <li> 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.</li> + <li>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).</li> + <li> 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.</li> + <li> There are some questions about how ACLs fit in with our "calendaring + without IT" organization goals.</li> + <li> 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?</li> + </ul> + <p>These issues are being addressed on the design list; discussion topics: <a href="" target="_self">Anonymous + Access</a> and <a href="" target="_self">URL/ticket + support</a>.</p> +</div> +<b><br/> +<h3>UI Details </h3> + +<p>Please review <a href="" target="_self">the + notes</a> on the use cases and download the detailed <a href="" + flows</a> <em>(download + .pdf file)</em>.</p> + +<a name="N"></a> +<div style="margin-right;"> + <div align="right"><a href="" to top</a></div> +</div> +<h2>Navigation</h2> +<h3>Goals and Objectives</h3> +<p>The goal is be able navigate to different views to see the events on a Chandler + calendar in the web application Scooby.</p> + +<h3>Use Cases</h3> +<ol> + <li>'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.</li> + <li>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.</li> + </ol> +<h3>Requirements</h3> + +<b> <br /> +</b> +<div style="margin-left: 40px;"><b> +'Go to' date: </b>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.<b><br /> +<br /> +Nice to haves for 'go to' date:</b> +<ol> + <li>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. </li> + <li>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. </li> + <li>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'. </li> + <li>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. <br /> + <br /> + <br /> + </li> +</ol> +<div style="margin-left: 10%;"><img src="" width="500" height="349" /></div><p> +<div style="margin-left;"><img src="" width="949" height="479" /></div> + +<br /> +<b>Miniature Calendar (Mini cal): </b> +<p> 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.</p> +<p>The following is a description for the basic functionality needed for a miniature + calendar in a target user's release.</p> +<ul> + <li> 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.</li> + <li>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.</li> + <li>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.</li> +</ul> + +<div class="issue"> + <p><strong>Issue: </strong>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.</p> + <p>Hiding the mini cal: A preference to hide/show + the mini cal on the web application. This may preserve space on the web application.</p> + <p>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.</p> +</div> +<p><br /> +</p> +</div> + +<a name="#No"></a> +<div style="margin-right;"> + <div align="right"><a href="" to top</a></div> +</div> +<h2>Notification </h2> +<h3>Goals and Objectives</h3> +<p>The goal of notification is to inform other users sharing the same calendar + that an event change has been made. </p> +<h3>Use Cases</h3> +<ol> + <li>After the user 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.</li> +</ol> +<p><div style="margin-left: 30%;"><img src="" width="425" height="727" /></div> +</p> + +<h3>Requirements</h3> +<b> <br/> +</b> +<div style="margin-left: 40px;"> + <p><b>Mail to link notification: </b>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. </p> + <p>Subject line = Events changed on Office Calendar: Event title<br /> + Body = Date/time information PLUS text from the Notes field of the event. + <p>Date/time information includes: + <ul> + <li> + Start date/time</li> + <li>End date/time</li> + <li>Time-zones</li> + <li>Recurrence rules</li> + <li>Recurrence end date</li> + </ul> + <div class="issue"> + <p><strong>Issue: </strong>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.</p> + </div> + <div style="margin-left: 40px;"></div> +</div> +<p><h3>UI Details</h3> +<table width="700" border="0" align="center" cellpadding="8" cellspacing="0"> + <caption> + Sample E-mail + </caption> + <tr> + <td><div align="right">To:</div></td> + <td width="566">[EMAIL PROTECTED]</td> + </tr> + <tr> + <td><div align="right">Cc:</div></td> + <td>[EMAIL PROTECTED]</td> + </tr> + <tr> + <td><div align="right">Subject:</div></td> + <td>{Office} calendar change {Andi working from France} </td> + </tr> + <tr> + <td colspan="2"><p>When: {July 12, 2006 - Aug 15, 2006, PST, All day}</p> + <p>{Off to France with family. Will be working remotely from my vineyard. + ;)<br /> + Salute, And.} </p> + </td> + </tr> +</table> +<p>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. </p> +<a name="#AV"></a> +<div style="margin-right;"> + <div align="right"><a href="" to top</a></div> +</div> +<h2><b>Account </b>viewing in Scooby (Subscribe workflow) </h2> +<h3>Overview</h3> +<p>There are two types of users when you subscribe to your account from Cosmo.</p> + + <ol> + <li>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. </li> + <li>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. </li> + </ol> + + + <p>An easy way of thinking of this is...</p> + <ul> + <li>There is information on the server - calendar events (and in the future + other items).</li> + <li> Both Scooby and Chandler are simply giving a window onto that data.</li> + <li>There may be some differences between what each application can do to + the data</li> + <li>There also may be some differences on how the data gets onto the server.</li> + </ul> + <p>Chandler has a local repository and Scooby does not.</p> + <div class="issue"> + <p><strong>Issue/Dependencies: </strong>Workflow in Chandler to + easily access your data on Scooby? This is separate from publishing your + individual collection. </p> + <p>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.</p> + <p>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? </p> + <p>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.</p> + <p>Currently there is a discussion on the list about <a href="" target="_self">Scooby/Cosmo + merge</a> which may have significant impact on this feature. </p> + </div> + <h3>Goals and Objectives</h3> +<p>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. + <strong>For Scooby 0.3, this workflow is not needed to meet the target users workflow + and so this feature is deferred to a future release. </strong></p> +<h3>Use Case</h3> +<ol> + <li>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. </li> +</ol> +<h3>Requirements</h3></p> +<b> <br/> +</b> +<div style="margin-left: 40px;"> + <p><b>Log on to Scooby: </b>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. </p> + </div> +<a name="CC"></a> +<div style="margin-right;"> + <div align="right"><a href="" to top</a></div> +</div> +<h2>Calendar Canvas </h2> +<h3>Goals and Objectives</h3> +<p>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. </p> +<h3>Use Cases</h3> +<ol> + <li>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.</li> + <li>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. </li> + <li>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.</li> + <li>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. </li> + <li>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. </li> +</ol> +<h3>Requirements</h3> +<b> <br/> +</b> +<div style="margin-left: 40px;"> + <p><b>List view:</b> 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. <a href="" target="_self">Review + Chandler Alpha 2 dashboard specification for more detail information on basic + table functionality</a>. </p> + <p><b>Next 4 days view:</b> 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. </p> + <p><strong>Month view:</strong> 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. </p> + <p><strong>Day view + Print: </strong>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. </p> + <p><b>Visual Tweaks: </b>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 </p> + <ul> + <li>Review fonts–Should all the fonts exactly the same to meet consistency + on all browsers/platforms?</li> + <li>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? </li> + <li>A thicker line on the horizontal timeline to the left to indicate working + hours.</li> + <li> Lozenge states for @time, anytime, and processing event. </li> + <li>Alarm display-Events with alarms should display in the lozenge and detail + view. Even though alarms will not be fully functional in Scooby 0.3, the + events created in Chandler with alarms need to be indicated. Visually this + 'alarm icon' could be grayed out and a mouse over tool time could describe + 'alarm set on event in Chandler'.<br /> + </li> + </ul> + + </div> +<a name="MT"></a> +<div style="margin-right;"> + <div align="right"><a href="" to top</a></div> +</div> +<h2>Managing Time-zone</h2> +<h3>Goals and Objectives</h3> +<p>To provide basic time-zone infrastructure with minimal UI for 0.3. <strong>Fully functional + time-zone features will be deferred to future release.</strong> </p> +<h3>Use Cases</h3> +<ol> + <li> User is traveling and would like to see office meetings (in their Home + time-zone) on the calendar. </li> + <li> User is managing a calendar for someone who is traveling in a different + time-zone.</li> + <li>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.</li> + <li>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.</li> +</ol> +<h3>Requirements</h3> +<b> <br/> +</b> +<div style="margin-left: 40px;"> + <p><b> Floating time-zone: </b>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.</p> + <p><strong>Time-zone preferences:</strong> 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) </p> + <p><strong>Edit time-zones on specific events:</strong> 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. </p> +</div> +<a name="ME"></a> +<div style="margin-right;"> + <div align="right"><a href="" to top</a></div> +</div> +<h2>Managing Events </h2> +<h3>Goals and Objectives</h3> +<p>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.</p> +<h3>Use Cases</h3> +<ol> + <li>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.</li> + <li>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. </li> + <li>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. </li> +</ol> +<h3>Requirements</h3> +<b> <br/> +</b> +<div style="margin-left: 40px;"> + <p><b> Recurring events:</b> 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'.</p> + <p><img src="" width="562" height="199" /> </p> + <p><strong>Display of @time events/Anytime events: </strong>Review the different + variations of <a href="" target="_self">event + lozenges</a>. Bug# <a href="" target="_self">6203</a> and + bug# <a href="" target="_self">6204</a>.</p> +</div> +<br/> + +<h3>Assumptions</h3> +<ol> + <li>The target user selected for Scooby 0.3 is performing a very specific task + and this task is not intended for a general audience.</li> + <li>Calendaring is still the main focus for 0.3. Other features addressed in + Chandler will commence at a later release.</li> +</ol> +<h3>Terminology</h3> +<p>There are currently two target users we are focused on for the release of + Scooby 1.0. They are:</p> +<ol> + <li> Casual Collaborator - Non-Chandler users viewing calendars published from + Chandler. These users are illustrated in the diagram below. </li> + <li>Chandler Users - Users of Chandler reading their calendars on the web using + Scooby. This implies casual use. </li> +</ol> + + +<p>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. </p> +<p> <img src="" width="445" height="449"><br /> +</p> +<div style="margin-right;"> + <div align="right"><a href="" to top</a></div> +</div> +<h2>Code Design</h2> +<p><span class="issue">Re factoring the new layout code. Mde to fill out... </span></p> +<h2>Specials Considerations</h2> + +<h3>QA / Test</h3> +<p>Any info that will be useful for testers. Special cases or +scenarios to consider.</p> +<h3>API / Developer Platform</h3> +<p>If relevant, how the feature will be made accessible to coders?</p> +<h3>Security</h3> + +<p>Discussion topics: <a href="" target="_self">Anonymous + Access</a> and <a href="" target="_self">URL/ticket + support</a>.</p> +<h3>Internationalization / Localization</h3> + +<p>'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} </p> + +<h3>Accessibility</h3> +<p>UI must be accessible (Section 508).</p> + +<h3>Build / Install</h3> + +<p>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. </p> + +<div style="margin-right;"> + <div align="right"><a href="" to top</a></div> +</div> +</div> + +<div id="codicille"> +<h2>Cuts</h2> + +<h4>Overlay</h4> +<p>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. </p> +<h2>Useful Links</h2> +<br /> +<h2>History</h2> +<table width="100%"> + <tbody> + <tr> + <th width="15%">Author</th> + <th width="15%">Edit date</th> + <th width="70%">Description</th> + </tr> + <tr> + <td>Priscilla Chung </td> + <td>June 25th, 2006 </td> + <td>First Draft </td> + </tr> + </tbody> +</table> +</div> +</body> +</html> Property changes on: trunk/docs/specs/scooby/rel0_3/zeroDotThree.html ___________________________________________________________________ Name: svn:executable + * Name: svn:eol-style + native
_______________________________________________ Commits mailing list [email protected] http://lists.osafoundation.org/mailman/listinfo/commits
