Calendar Package Requirements
by Gary Jin and W. Scott MeeksI. Introduction
A calendar is an aggregate of events which fall within a given time interval, e.g., on a particular day, week, or month. The ArsDigita Calendar application provides users with a tool which allows them to add, view, edit and organize these events at both the personal and party/group levels.II. Vision Statement
The ArsDigita Calendar application is a Web based calendar system that can be accessed through any browser. The application allows people to keep track of events as they normally would on a paper calendar while giving them the opportunity to share these events with other parties. Various types of additional information related to a calendar item, such as a URL, a map indicating a meeting's location, et cetera, can also be managed through the Calendar application. The Calendar application also provides different end-user specifiable presentation formats for viewing this information. In its current form, the Calendar application can be integrated with other ACS components, for example, our Intranet application and our Portals application; eventually the Calendar application will integrate with yet further systems, for example, PDAs.Calendar objects have been designed to allow them to be tied to particular ACS parties where each party member can see events associated with that particular party. Events from the various parties of which one is a member can also be shown on a party member's personal calendar.
This package could be used for any application where event tracking is important. This would include many business, educational, club, and other community scenarios.
III. System/Application Overview
In our system, a party-specific event is an event associated with a particular party, typically of the sort scheduled by that party or of particular interest to members of that party. For example, a reading group may wish to associate an upcoming book signing event with their reading group party using the Calendar application.A user's calendar is the aggregate of the party-specific events which are associated with parties of which the user is a member and which have been specified by this user as desirable for calendar inclusion. Users will have the option to suppress the inclusion of all party-specific events for a particular party of which they wish to remain a member but the party-specific events of which they do not wish to have appear on their calendars. Since in our system, groups are parties and parties can have calendars, this account of a user's calendar generalizes to cover a party's calendar.
The Calendar Package is built on top of the ACS Event service package and performs the following three high-level functions:
- Event Management
- Calendar Views
- Navigation
Calendar Views covers those aspects of the application which pertain to the display of calendar events for a particular span of time.
Navigation covers those aspects of the application which pertain to ways in which the end-user can change the timespan currently being displayed.
IV. Use-cases and User-scenarios
There are three main classes of users for the Calendar:- Individuals
- Groups and Parties
- Administrators
Groups and Parties can have a collective calendar that stands apart from the private individual calendar. This would be useful to display calendar events for the public, for whom there is no individual calendar. For example, ArsDigita can display a schedule of upcoming bootcamps, lectures and other approved events on a calendar on arsdigita.com. A common visitor does not have to be registered with the site to be able to obtain this event information through their personal calendar. To allow this functionality, the calendars for groups and parties would need to support all the event management and calendar views had by individual calendars, and in addition, the role of calendar administrator must be assigned to handle event management.
Administrators for a group and party wide calendar are given create, read, and write permissions on each individual item on the calendar. He or she also has the privilege to change the permissions for each of these items and also individual's ability to interact with these items. For example, the side-wide administrator, Joe Admin, who also has the role of the calendar administrator realizes that the date on which one of the ACS bootcamps is scheduled to take place this month is incorrect. He has the permission to change it. He also can grant Jane Bootcamp write permission on that particular event, so that Jane can make changes on her own.
V. Related Links
- Design Document
- System Overview
- MIT's 6.916 course calendar
- vCalendar/iCalendar proposed standards
- Acceptance Tests
- Yahoo Calendar
- Excite Planner
VI.A Requirements: Private Calendar
10 Private Calendar10.0 User Interface
10.0.10 The calendar page should indicate whether or not private, public or party-specific events are to be displayed.
10.0.20 The calendar should support navigation to view different dates in a simple manner.
10.0.30 Links to different calendar functions should be clear and obvious.
10.0.40 Each calendar item should be displayed with its subject and time span as the basic information.
10.10 Views
10.10.0 Different views should be easily selectable.
10.10.0 Different views should also be indicated in a clear and noticeable location
10.10.10 List View
10.10.10.10 The calendar should support a view showing selected items in a tabular list format.
10.10.10.20 Columns should include date, time, and other relevant information.
10.10.10.30 The columns should be sortable.
10.10.10.40 There should be at least two lists of items. One list should consist of items whose dates occur within a user-specified number of days of the currently viewed date. One list should consist of items that have been added within a user-specified number of days of the current date.
10.10.20 Day View
10.10.20.10 The calendar should support a view showing all the events for a particular day.
10.10.20.20 This view should show the events arranged chronologically with a time guide along one side.
10.10.20.30 The range of the time guide should be user-specifiable.
10.10.20.40 The user should have the option of compressing the time guide so that only those time intervals upon which fall selected calendar events are shown.
10.10.20.50 Overlapping events should be displayed in an easy to understand fashion.
10.10.20.60 There should be a simple mechanism for adding events which start at a particular hour.
10.10.20.70 The day view should support events that don't have a specified start and end time, and the time guide should include a slot for these items.
10.10.30 Week View
10.10.30.10 The calendar should support a view showing all the events for a particular week.
10.10.30.20 The events for a particular day should be grouped together.
10.10.30.30 There should be a simple mechanism for adding an event for a particular day.
10.10.30.40 The currently selected day should be highlighted or otherwise clearly indicated to the user.
10.10.30.50 There should some way to move to the next and previous week from this particular view.
10.10.40 Month View
10.10.40.10 The calendar should support a view showing all the items for a particular month.
10.10.40.20 The events for a particular day should be grouped together.
10.10.40.30 There should be a simple mechanism for adding an event for a particular day.
10.10.40.40 The currently selected day should be indicated.
10.10.40.50 The application should display only some of the events per day on the month calendar as oppose to every item.
10.10.40.60 There should some way to move to the next and previous week from this particular view.
10.10.40.70 For each day, there should be a link to the day view for that day.
10.10.50 Year View
10.10.50.10 As a navigational mechanism, the calendar should support a view that shows all months and days in a particular year but not necessarily with any information on items for the days displayed.
10.10.50.20 For each month, there should be a link to the month view of that month.
10.10.50.30 For each day, there should be a link to the day view of that day.
10.20 Navigation
10.20.10 Navigation Widget
10.20.10.10 The calendar should provide a widget for collecting together related navigation links. This should be similar to the widget provided by Yahoo Calendar and Excite Planner.
10.20.10.20 Navigation to a different date should maintain the same view.
10.20.10.30 In the list, day, and week views, the widget should display a mini calendar of the days of the current month. Each day should be a link except for the currently viewed day which should not be a link and should be highlighted in some manner.
10.20.10.40 In the month view, the widget should contain a list of the months of the year. Each month should be a link except for the month containing the currently viewed day which should not be a link and should be highlighted in some manner.
10.20.10.50 In the year view, the widget should contain a short list of years before and after the current year. Each year should be a link except for the year containing the currently viewed day which should not be a link and should be highlighted in some manner.
10.20.10.60 The widget should contain some mechanism for entering an arbitrary date using a clearly defined format, such as that employed by Yahoo Calendar.
10.20.10.70 The widget should clearly display today's date along with some mechanism for navigating to that date.
10.20.10.80 In the list, day, and week views there should be a mechanism for jumping forwards or backwards by a whole month at a time.
10.20.10.90 In the month and year views, there should be a mechanism for jumping forwards or backwards by a year at a time.
10.20.20 View Specific Navigation
10.20.20.10 Each view except for 'list' should have some easy mechanism for jumping forward or backward by the interval being viewed.
10.20.20.20 Selecting a day in week, month, or year view should take you to the day view for the that day.
10.20.20.30 Selecting a month in year view should take you to the month view for that month.
10.30 Adding Events
10.30.10 Adding an event should involve entering information for the event in a form and then submitting that form. Form should include title, start date and time, or an explicit indication that the event does not have a start time. Default values should already be entered with the correct timezone offset in place. Non-required fields should include end time or duration, type information, a description, to which party the event belongs, and an indicator as to whether or not this event recurs.
10.30.20 There should be a simple, clearly labeled link for adding an event. The date should default to the currently viewed date and the present time.
10.30.30 The time guide in the day view should have links from each hour and from the slot for items with no start time.
10.30.40 Selecting the 'no start time' link should bring up the form with the date defaulting to the currently viewed date and the 'no start time' indicator set.
10.30.50 Selecting a link from a specific hour should bring up the form with the date defaulting to the currently viewed date, the start time to the hour selected, and the end time to one hour later.
10.30.60 The week view should have a link for each day for adding an item.
10.30.70 The month view should have a link for each day for adding an item.
10.30.80 As in the Yahoo style calendar, there should be a 'quick add' box on the side of their calendar that allows user to add events quickly without having to click through on different days and different views.
10.40 Viewing Events
10.40.10 Selecting an event's title from any view should display details for that event, including links to edit, add attachment, and delete.
10.50 Editing Events
10.50.10 While viewing an event, select 'Edit'. You should get a form allowing you to edit the title, date, times, types, and description for the event. Non-recurring items should have a "Repeat?" field but not an "Update?" field. [need to clarify what this means]
10.60 Adding Recurring Events
10.60.10 If the recurring events indicator is selected in the form for adding an item, then after submitting that form, a second form should be presented which summarizes the date and time of the item and provides fields to set how the item recurs.
10.60.20 The form should include fields to enter the type of interval, the number of intervals between recurrences, and any specific information for the selected type of interval.
10.70 Editing Recurring Events
10.70.10 Selecting Edit when viewing a repeating item should add a field at the bottom of the form to specify whether any changes should be applied to only the current instance being edited or to all instances of this recurring item.
10.80 Adding Attachments to Events
10.80.10 When viewing an item, there should be a link to add an attachment to that item. Selecting that link should bring up a form to add attachments of various types.
10.80.20 The form should include a field for the title of the attachment.
10.80.30 One type of admissible attachment supported should be an uploaded file. This type should be handled in the standard ACS manner.
10.80.40 One type of admissible attachment should be a URL.
10.80.50 One type of admissible attachment should be a block of text. The form should provide a text box for entering the text and a way to indicate if the text is plaintext or HTML.
10.80.60 After adding an attachment of any sort, the calendar should return to the view of the item which should have a list of attachments including the attachment just added.
10.80.70 For each attachment listed, there should be displayed -- when permissions admit -- the title of the attachment, a link to the content of the attachment, a link to manage the attachment, and a link to edit it.
10.80.80 For a file attachment, the content link should return the content of the file.
10.80.90 For a URL attachment, the content link should navigate to the URL.
10.80.100 For a text attachment, the content link should display the entered text.
10.80.110 The manage link links to the management page of the corresponding file in the file-storage system. [file-storage or CR?]
10.80.120 The edit link allows direct editing of the content of the attachment.
10.90 Inviting other groups to view Events
10.90.10 The application should have a link that lets the owner of the event to invite other groups, individual or parties to add this event to their personal calendars.
10.100 Deleting events
10.100.10 When viewing an item, there should be a link to delete that item.
10.100.20 Selecting the delete link should bring up a confirmation dialog.
10.100.30 If the item is not recurring, then the choice button will simply be labeled 'OK'.
10.100.40 If the item is recurring, then in addition to the choice buttons, there should be a selection to indicate either the current instance only or all occurrences.
10.100.50 Selecting 'Cancel' should return to the item view.
10.100.60 Selecting 'OK' should delete the item in question.
10.100.70 If the item was recurring and 'all occurrences' had been selected, then all other occurrences of the item should be deleted as well.
10.100.80 Selecting OK should return to the view where the item was originally selected.
VI.B Requirements: Party-Specific Events
20 Party-Specific Events20.10 The calendar should display a list of calendars to which the user has access. At a minimum, this will include the user's personal calendar and a public events calendar. If the user belongs to parties that have party-specific events associated with them, there should be additional links to these party-specific events as well as the calendar of the party to which the user belongs.
20.30 On the personal calendar, there should also be a toggle for each such party that controls whether or not events from that party appear on the personal calendar.
20.40 On a user's calendar, party-specific events should indicate to which party they are specific.
20.50 The link for adding an event should clearly indicate whether a party-specific item or a personal item will be created.
VI.C Requirements: Managing Party-Specific Events
30 Managing Party-Specific Events30.10 If the user has write permission to any parties, when he chooses to add an event, the choice of which party to associate with that event is given.
30.20 There should also be a page where permissions of read, write, approve, and delete can be given to different parties
30.30 There should be a link to the admin page for the group.
30.40 There should be a way to delete the calendar. This route should involve passing the user through a confirmation dialog.
VI.D Requirements: Calendar Administration
40 Calendar Administration40.10 Calendar User Privilege Administration
40.10.10 Cal Admin must have access to pages where permissions can be set for different parties
40.10.20 Cal Admin can also add new user party/groups/person to the entire calendar
40.10.30 Cal Admin can also add new user party/groups/person to individual calendar items
40.20 Calendar Items Administration
40.20.10 Provides the functionality to delete, add, edit any item on the calendar
40.20.20 Provides the funcatinality to allow Calendar Administrator to change the permissions on each calendar item.
40.20.20 Provides the funcatinality to allow
Calendar Administrator to change the default permissions of the
entire calendar
VI.E Requirements: API
50 API50.10 Calendar Events Manipulation
50.10.10 Provide a function to add a new item to a calendar. This function should support specifying all the values that can be specified in the 'add item' form. It should allow creating either a user or a party-specific item. Iit should support specifying a mapping between the new item and an arbitrary object in the database.
50.20 Calendar Views
50.20.10 Provide a function to generate the HTML for the list view.
50.20.20 Provide a function to generate the HTML for the day view.
50.20.30 Provide a function to generate the HTML for the week view.
50.20.40 Provide a function to generate the HTML for the month view.
50.20.50 Provide a function to generate the HTML for the year view.
50.20.60 Provide a function to generate the HTML for the calendar navigation.
50.20.70 Provide a function to generate the HTML for the complete calendar.
VII. Revision History
| Document Revision # | Action Taken, Notes | When? | By Whom? |
|---|---|---|---|
| 0.1 | Creation | 2000/10/25 | W. Scott Meeks |
| 0.2 | Emendation | 2000/11/10 | Gary Jin |
| 0.3 | Edit for Content and Consistency | 2000/11/10 | Joshua Finkler |
| 0.4 | Additional revisions and included cX-Mozilla-Status: 0009eview | 2000/11/30 | Gary Jin |
| 0.5 | Further Revisions | 2000/12/02 | Joshua Finkler |
| 0.6 | Revisions of User Cases and Scenario sections and applied corrections. | 2000/12/04 | Gary Jin |
| 0.7 | Further Revisions | 2000/12/06 | Joshua Finkler and Gary Jin |
gjin@arsdigita.com and smeeks@arsdigita.com
