0.1 Basic Calendar Specification

Authors: Bobby Rullo Matthew Eernisse Last edited: Dec 21, 2005 Creation date: November 4, 2005
Reviewers: 

Overview

Goals and Objectives

The purpose of the basic calendar functionality is to provide very simple calendar and event management functionality - basic CRUD for calendars. 


High Level Use Cases

1. Managing a single calendar. This includes creating, deleting, and modifying events.

Definitions

Requirements

         
Event Types: In addition to simple events which have a definite start and end time we need to support all-day events. Point-in-time events and any-time events will be viewable, but may not be distinguishable from other events. Creation of any-time and point-in-time events will not be supported  So-called any-time events are not in the iCalendar standard but is an experimental extension first used in Chandler.(mde to spec out how these different events should look)

Multi-Day Events: The events mentioned above (with the exception of the point-in-time events) can all span multiple days.  (mde to spec out ui behavior)

Navigation:
Navigation will be simply be navigating between weeks with forward and back arrows.

Multiple Calendars: We will be able to have multiple calendars, although you will be able to view events from only one of them at a time (mde to spec out how to choose which calendar to view, how to create new ones)

Event Collision:
Events that overlap will be obscured, and there will not be a way to view the obscured events short of moving away the overlaying events. 

Assumptions

High-level Decisions

Terminology

An "event" in the context of this document is a simple event with a start time and an end time and has the following fields:

An exception to the use of start and end times are all-day events, and so-called at-time events. All-day events have no times specified, and at-time events have only a single time associated with them (as they represent an event that happens at a single point in time).

More complicated events (like those with recurrence rules) will be discussed in other specs.

User Interface / Interaction


Week View

The user navigates to the week view by clicking a link/button. If an event was selected the week view for that event's week is shown. Otherwise the week naviagated to depends on the view the user was previously in:

The events for that week are displayed.

The minical displays the month of that week.


Event Detail View

The user clicks on an event in the Week view. The event detail area displays all the information for that event in editable form fields. 

The user optionally changes some of the information. The user clicks the save button and the changes are saved to the remote server. The event's display in the Week view is updated to reflect those changes. Failure of a save operation will result in an error, and the event reverting to its previous state.

Add an Event

The user clicks double clicks in the event canvas area in the WeekView and a new event is created. The detail section shows default new event information:

The new event is then saved to the server. Failure of a save operation will result in display of an error dialog, and the 'processing' event block will disappear from the canvas.

The event is displayed in the Week view.

Edit Event

see Event Detail

Delete an Event

The user clicks on an event, selecting it and bringing it into Event Detail View. The user clicks the Remove button in the detail view or presses the "delete" key on the keyboard.

A confirmation dialog box is displayed. If the user confirms, the event is deleted from the persistent store. If the removal fails, the user will see an error dialog, and the event block will remain in place. Otherwise, the event disappears from the Week view.

Move an Event

The user clicks and drags an event to another time/date and releases the mouse button.

If the user is in Day or Week view the event's start date will change so that it's within the nearest 15 minute interval to where the user dropped it (i.e. :00, :15, :30, :45). The end time is adjusted so that the new duration is the same as the old.

For month view the times will stay the same and only the date will change.

The changes are then saved to the remote server. If the save operation fails, the user will see an error, and the event block will move back to its original position.

Stretch/Shrink Event Duration

In Week View or Day View the user drags the bottom or top of an event, changing the start or end time.  When the mouse button is released, the start or end time snaps to the nearest 15 minute interval.

The changes are then saved to the remote server. If the save operation fails, the user will see an error, and the event block will change back to its original size.

Jump To Date

mde to fill out...

Event Collission

mde to fill out...

Appearance of Events

mde to fill out...

Code Design

This section must be completed by the developer. Schematic of any kind (class hierarchy, object relationship) is welcome.

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

Aspects of the design dealing with potential security issues.

Internationalization / Localization

Things to keep in mind for Internationalization. Caveats known at design time.

Accessibility

UI must be accessible (Section 508).

Build / Install

New info that coders need to know introduced by that feature. List here known dependencies in particular.

Cuts

Miniature Calendar (minical)
A minature calendar with the days of the month is displayed to the side of the screen. The user can naviagate from month to month by means of arrow buttons. If the user clicks a day, they will be brought to the {Month/Day/Week} view for that day.

Month/Day Views
For now we will just have a week view.

Event Types
We will not support Anytime, @Time (point-time) events

Event Collision
Events will not overlap in a way that we can pull them apart.

Useful Links


History

Author Edit date Description
nt January 12, 2006 Updated to reflect latest cuts
br December 21, 2005 Updated to reflect Scooby design meeting
br December 6, 2005 Minor changes, added high level use cases.
br November 4, 2005 First Draft