- Revision
- 853
- Author
- bear
- Date
- 2006-07-17 10:09:30 -0700 (Mon, 17 Jul 2006)
Log Message
setting text/html mime-type and removing duplicate test file - per Priss
Removed Paths
Property Changed
Diff
Property changes: trunk/docs/specs/scooby/rel0_3/zeroDot3.html
Name: mime-type
- text/html
Name: svn:mime-type
+ text/html
Deleted: trunk/docs/specs/scooby/rel0_3/zeroDotThree.html (852 => 853)
--- trunk/docs/specs/scooby/rel0_3/zeroDotThree.html 2006-07-16 17:50:59 UTC (rev 852) +++ trunk/docs/specs/scooby/rel0_3/zeroDotThree.html 2006-07-17 17:09:30 UTC (rev 853) @@ -1,664 +0,0 @@ -<!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>
_______________________________________________ Commits mailing list [email protected] http://lists.osafoundation.org/mailman/listinfo/commits
