Overview
Scooby is the next generation web calendar application. 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. 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
- 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
- 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.
- User C receives the URL to the office calendar and wants to view the office calendar in iCal (or some other CalDAV client).
- User D already has a Cosmo account and uses Scooby and would like to add the office calendar to his shared collection.
Requirements
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.
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
- '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.
- 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
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.
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.
Use Cases
- 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.
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
To: |
everyone@osafoundation.org |
Cc: |
oval@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.
;) |
|
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.
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.
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.
- 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.
- 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.
- 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.
- 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.
Managing Time-zone
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
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.