0.5 Specification

Authors: Priscilla Chung Last edited:October 13, 2006 4:45 PM Creation date: June 25th, 2006
Reviewers:

Overview

Cosmo is a sharing server for calendar (calDAV) and other items as well as a web application to support Chander users. This document details the features for Cosmo 0.5.

Como 0.5 will focus on server side development. The project Cosmo web application merged with Cosmo the sharing server and integrating support for remote databases via Hibernate. In addition to server side development there will be an ongoing effort to complete features based on the target user: An OSAF employee who is tasked to use Cosmo 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. Read more about the discussion and decison outcome on the Cosmo dev-list about the Cosmo/Cosmo merge and integrating hibernate.

This document will outline the following features:

Scooby/Cosmo Merge

Goals and Objectives

To remove complexity from the technical infrastructure which simplifies maintenence and allows developers to add new features faster. For Cosmo 0.5, 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.

Requirements

To merge the Scooby code with Cosmo. [Ted - to fill out more technical details?] Description of what the merged UI should look/work like will be moved to a future release.

Back to top

Hibernate Integration

Goals and Objectives

To permit Cosmo to use a relational database for storage and query.

Requirements

To integrate the Hibernate object relational manager into the Cosmo code base.

Back to top

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 Cosmo.

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.
  2. 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

       
'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:
  1. 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.
  2. 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.
  3. 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 mm/dd/yyyy format”. The entry box would default to 'Today’s Date'.
  4. 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 Cosmo 0.5, but is not a high priority feature to focus on because it does meet the usage scenario for 0.5. 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.

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.


Back to top

Calendar Canvas

Goals and Objectives

The goal of the calendar canvas is to view information from Chandler the desktop client via Cosmo, the web application. Cosmo 0.5 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 Cosmo.

Use Cases

  1. 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, Cosmo to differ from the desktop application, Chandler.

Requirements

         

Visual Tweaks: Based on the target user release goals. The following is a high level list of visuals to work on and complete for Cosmo 0.5


Back to top

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 Cosmo since alarm functionality will not be working for 0.5.

Use Cases

  1. 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.
  2. 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.
  3. 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' and have a selection of 'daily', 'weekly', 'Biweekly', 'Monthly', 'Yearly'. One the selection has been made, the event lozenge should display on the calendar canvas according to selection in the recurring event. Once the event is set, when the user makes any change to the event, a dialog box will appear in the following use cases:

Need to review the following state maps to see which model makes sense to Cosmo.

The boxes in yellow is how iCal and Chandler differ.

iCal Model        
Recurring events User Action: Move User Action: Rename User Action: Delete User Action:Resize
Child (part of recurrence) All future events, Only this event All future events, Only this event All future events, Only this event All future events, Only this event
Master event All events, Only this event All events, Only this event All events, Only this event All events, Only this event
Disconnected child event (no longer part of the recurrence) No options No options All futures events, Only this event No options
Disconnected master (no child event) All events, Only this event All events, Only this event All future events, Only this event All events, Only this event
Chandler Model        
Recurring events User Action: Move User Action: Rename User Action: Delete User Action:Resize
Child (part of recurrence) All future events, Only this event All future events, Only this event All events, All future events, Only this event All future events, Only this event
Master event All events, Only this event All events, Only this event All events, All future events, Only this event All events, Only this event
Disconnected child event (no longer part of the recurrence) No options No options All events, All future events, Only this event No options
Disconnected master (no child event) All events, Only this event All events, Only this event All events, All future events, Only this event All events, Only this event
This is an example of what the dialog box would look like. Please note the button in the 'All Events' swaps out with 'All Future Events' in iCal, but is greyed out in Chandler currently. Need to confirm which direction would make the most sense?

Please refer to Chandler 0.6 spec for historical information on recurring events in Chandler. Additional information may also be found in the Chandler 0.7 Stamping spec, but is scattered throught the documenation. An update to the Recurrance spec for Chandler is currently being defined. –As of 10/12/06


Assumptions

  1. The target user selected for Cosmo 0.5 is performing a very specific task and this task is not intended for a general audience.
  2. Calendaring is still the main focus for Cosmo 0.5. 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 Cosmo 1.0. They are:

  1. Casual Collaborator - Non-Chandler users viewing calendars published from Chandler. These users are illustrated in the diagram below.
  2. Chandler Users - Users of Chandler reading their calendars on the web using Cosmo. This implies casual use.


Back to top

Code Design

Cosmo Architecture

The persistence layer has been completely rewritten in Cosmo 0.5. Instead of using a JCR Repository, Cosmo now uses Hibernate/JDBC to store and access data in a relational database. See database schema. -Documentation from Randy Letness

Review discussion for refactoring cal_main.js. -Discussion thread started by Matthew Eernisse

Other technical documentation, please add links here.

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

Although security is an issue that has been discussed for the longer term goal of the Cosmo project. There has been a decision made that any additional security will not be a feature until after post Preview. Please review the discussion topics: Anonymous Access and URL/ticket support.

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.

Back to top

Useful Link

History

Author Edit date Description
Priscilla Chung June 25th, 2006 First Draft - Scooby 0.3 spec
Priscilla Chung September 17th, 2006 Second Draft - Updated spec to Cosmo 0.5. Added description of Cosmo milestones.
Revised flowcharts, added state map for recurring events, deferred features to future release.
Priscilla Chung October 13th, 2006 Final - Updated spec to Cosmo 0.5. Revised description of Cosmo milestones/goals.
Revised flowcharts, deferring features to 0.6 release.