ArsDigita Archives
 
 
   
 
spacer

Calendar Package Requirements

by W. Scott Meeks

I. Introduction

This document describes the requirements for the ACS Calendar package. The calendar primarily allows people to add, view, and edit items on personal and group calendars. It also provides an API which be used by other applications to provide additional calendar functionality.

II. Vision Statement

The ArsDigita calendar allows one to enter and keep track of anything that could reasonably be written on a paper calendar. In addition, the calendar can be accessed from any web browser. Various types of additional information related to an item can be added. This information is integrated with other components of the ACS. The calendar also provides different ways of viewing the calendar information. Eventually the calendar will integrate with other systems such as PDAs and email.

At a group level, the calendar can be tied to particular ACS groups where all group members can see items entered for that group. Items from the various groups one is a member of can be shown on one's personal calendar.

This package could be used with any application where tracking items in time is important. This would include most business settings for meetings and appointments, educational settings, clubs, and other community organizations.

III. System/Application Overview

The Calendar Package is made up of five major functional areas:
  • Item Manipulation
  • Views
  • Navigation
  • Group Calendars
  • Type Management
Item Manipulation includes every aspect of adding, editing, viewing, and deleting calendar items. This also includes adding attachments and setting up recurring items.

Views covers the display of calendar items in the context of a particular span of time.

Navigation comprises the links used to change the currently viewed date.

Group Calendars involve switching between group calendars and the personal calendar, adding group items, controlling the display of group items on personal calendar, and adding and deleting group calendars.

Type Management is for adding, editing, and deleting item types for users and groups.

IV. Use-cases and User-scenarios

There are four main classes of users for the Calendar:
  • Individuals
  • Community Members
  • Group Administrators
  • Site-wide Administrators

The individual is primarily interested in having a personal web-based calendar. The calendar needs to support manipulating basic calendar items that include times, titles, and possibly descriptions.

Here are some examples of how Al uses his calendar. At home Monday morning, after checking his email, he goes to the week view in the calendar for this week. He sees that he has a dental appointment at 9:30 this morning (which he almost forgot about) and a meeting on Wednesday.

After his dental appointment, he has to schedule a followup appointment. When he gets into work, he brings up his calendar there, looks at the month view for next month, makes sure the time for the appointment is free, then clicks the link to add an item on that day. In the form that comes up, he enters "dental appointment" as the title, the time of the appointments, and submits the form.

Tuesday morning, reminder email comes out about massages at work. He uses the Intranet massage reservation page to schedule his massage. After lunch, he checks his calendar to see what he has in the afternoon and notes the reminder for his massage.

Later that evening, he realizes he forgot his Mother's birthday last week. After getting off the phone with her, he immediately goes to his calendar and adds a new item. He enters the date as his Mother's birthday, specifies no associated time, enters "Mother's Birthday" as the title, and marks the item to recur. On the form for how the item should recur, he specifies every year.

In addition to the features available in the personal calendar, community members will be interested in the group calendar features.

Here is how Beth uses her calendar. She's a member of the Group Leaders (GL) group and of the Political Discussion (PD) group among others. Links to the calendars for these groups appear on her calendar. In addition, because GL is very important she has her calendar set up to show items for that group on her personal calendar. However, because PD is something she's only interested in when she has free time, items for that group don't appear on her personal calendar and she has to explicitly go to that calendar to see the group's schedule.

Because she's not always aware of the items being added to the group calendars, she finds the list view very useful. She can quickly see what has been added recently and what is coming up in the near future. She also finds attachments to items useful. In particular, by clicking on the attachment for a GL meeting, she is taken to the WimpyPoint presentation of the agenda for the meeting.

Group administrators by default are the only users that can add, edit, or delete items on group calendars. They can also create and delete calendars for the groups they administrate.

Carl, for example, is one of the administrators for the Marketing group. He needs to set up a twice weekly meeting. He goes to the Marketing calendar and selects the link to add an item. He sets the date to next Tuesday, the time to 10am, and sets it to recur every week on Tuesday and Thursday.

Now, once the agenda is prepared for each meeting, he can view the item for a particular meeting, select "add attachment" and add a link to the WimpyPoint presentation for the agenda for that meeting.

Oops, it turns out that the first meeting of next month will have to be delayed until 11. No problem. Carl edits the item for that particular instance of the recurring meeting. He changes the time to 11am and indicates that this change should only effect the current occurrence.

There is no qualitative difference in what site-wide administrators can do versus group administrators. The difference is that site-wide administrators can work on all groups and have an interface which allows them to effect more than one group at a time.

V. Related Links

VI.A Requirements: Personal Calendar

10 Personal Calendar

10.0 Overall User Interface

10.0.10 The root URL for the package should be /calendar/.

10.0.20 The calendar page should clearly identify which user or group the calendar is for.

10.0.30 The calendar should support navigation to view different dates in a simple manner.

10.0.40 Links to functions should be clear and obvious.

10.0.50 There should be a detailed calendar presentation showing an appropriate level of detail of the user's calendar items.

10.10 Views

10.10.0 Different views should be easily selectable.

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.

10.10.10.50 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 items for a particular day.

10.10.20.20 This view should show the items 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 times with items are shown.

10.10.20.50 Items that overlap in time should be shown in a clear fashion.

10.10.20.60 There should be a simple mechanism for adding an item starting at a particular hour.

10.10.20.70 The day view should support items 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 items for a particular week.

10.10.30.20 The items for a particular day should be grouped together.

10.10.30.30 There should be a simple mechanism for adding an item for a particular day.

10.10.30.40 The currently viewed date should be indicated in some manner.

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 items for a particular day should be grouped together.

10.10.40.30 There should be a simple mechanism for adding an item for a particular day.

10.10.40.40 The currently viewed date should be indicated in some manner.

10.10.50 Year View

10.10.50.10 Purely as a navigation 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 on 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.20 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.

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 whole 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 the day in week, month, or year view should take you to the day view for the appropriate day.

10.20.20.30 Selecting the month in year view should take you to the month view for the appropriate month.

10.30 Adding Items

10.30.10 Adding an item should involve entering information for the item in a form and then submitting that form. Title and date are required fields. Also required is either a start time or an explicit indication that this item does not have a start time. Date and time should have default values already entered. Non-required fields should include end time or duration, type information, a description, and an indicator as to whether or not this item recurs.

10.30.20 There should be a simple, clearly labeled link for adding an item. The date should default to the currently viewed date and the time to 12-1pm.

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. The date should default to the date associated with the link and the time should be 12-1pm.

10.30.70 The month view should have a link for each day for adding an item. The date should default to the date associated with the link and the time should be 12-1pm.

10.40 Viewing Items

10.40.10 Selecting an item's title from any view should display details for that view, including links to edit, add attachment, and delete.

10.50 Editing Items

10.50.10 While viewing an item, select "Edit". You should get a form allowing you to edit the title, date, times, types, and description for the item. Non-recurring items should have a "Repeat?" field but not an "Update?" field.

10.60 Adding Recurring Items

10.60.10 If the recurring item indicator is selected in the form for adding an item, then after submitting that form, a second form should be displayed summarizing the date and time of the item and providing 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.60.30 Recurring on a daily basis should be supported.

10.60.40 Recurring on a weekly basis should be supported. For weekly recurrences, it should be possible to specify exactly which days of the week.

10.60.50 Recurrences every month on a particular date should be supported.

10.60.60 Recurring every month on a particular day of a particular week should be supported.

10.60.70 If a date in the 4th or 5th week of a month has been selected, then an option should be presented allowing an item to recur on a particular day of the last week of a month.

10.60.80 Recurring yearly on a particular date should be supported.

10.70 Editing Recurring Items

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 Items

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 attachment supported should be an uploaded file. This type should be handled in the standard ACS manner.

10.80.40 One type of attachment should be a URL.

10.80.50 One type of 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 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.

10.80.120 The edit link allows directly editing the content of the attachment.

10.90 Item Types

10.90.10 Adding Types to Items

10.90.10.10 If the user or group has types defined for the calendar being viewed, then the add item form should have an input for specifying one or more types for the item.

10.90.10.20 If the user or group has types defined for the calendar being viewed, then the edit item form should have an input for changing the types for the item.

10.90.10.30 If the item has types specified, then the types should be listed when viewing the item.

10.90.10.40 The types information should also be shown in the list views.

10.90.20 Adding New Types

10.90.20.10 There should be a link from the calendar page to the type management pages which should clearly indicate whether the types being managed are for the users calendar or for a particular group calendar.

10.90.20.20 There should be a list of defined types.

10.90.20.30 There should be a form to enter a new type.

10.90.20.40 There should be a form to edit the name of an existing type.

10.90.20.50 There should be a form to delete a type.

10.100 Deleting Items

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 buttons will be OK and Cancel.

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 in all cases.

10.100.60 Selecting OK should delete the item in question.

10.100.70 If the item was recurring and all occurrences was 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: Group Calendars

20 Group Calendars

20.10 The calendar should display a list of calendars that the user can access. At a minimum, this will include the user's personal calendar. If the user belongs to groups that have group calendars, there should be additional links to those group calendars.

20.20 Selecting a link to a group calendar should present a calendar showing only items for that group.

20.30 The group calendar should have a link back to the user's personal calendar as well as to any other group calendars.

20.40 On the personal calendar, in addition to the links to the group calendars, there should also be a toggle for each group that controls whether or not items from that group appear on the personal calendar.

20.50 On the personal calendar, group items should indicate what group they are for.

20.60 The link for adding an item should clearly indicate whether a group item or a personal item will be created.

VI.C Requirements: Managing Group Calendars

30 Managing Group Calendars

30.10 If the user is an administrator for any groups, the calendar should display a link to a page for managing group calendars.

30.20 The page for managing group calendars should have a list of existing group calendars for the groups the user administers and controls to manipulate the calendars.

30.30 There should be a link to the admin page for the group.

30.40 There should be a link to the pages for managing types for the calendar.

30.50 There should be a way to delete the calendar which should include a confirmation dialog.

30.60 The page for managing group calendars should also have a form containing a list of groups the user administers which do not already have calendars. The user should be able to select some of these groups and create calendars for the selected groups by submitting the form.

VI.D Requirements: Calendar Administration

40 Calendar Administration

40.10 Site-wide administrators, should be able to access /admin/calendar/. This page should have a sections for groups with calendars and a section for group types with calendars.

40.20 The groups with calendars section you should have a function to create a group calendar and a list of groups with calendars.

40.30 The create a group calendar function should provide the administrator the ability to select from existing groups without calendars and then create calendars for those groups. After creating groups calendars, the administrator should be returned to the /admin/calendar/ page where the new group calendars should be listed.

40.40 The list of group calendars should include a link for each group to it's admin page.

40.50 The list of group calendars should include a delete function for each calendar. This function should have a confirmation dialog which returns to the admin page.

40.60 The group types with calendars should have a list of the top level group types defined. This list should indicate which group types automatically have group calendars and which don't.

40.70 When a group type is set to automatically have calendars, then all existing groups of that type will have calendars created if needed, and any new groups of this type that are added will automatically have calendars.

40.80 When a group type is set to not automatically have calendars, then any existing groups of that type that have calendars will keep their calendars, but any new groups of that type will not automatically have calendars.

VI.E Requirements: API

50 API

50.10 Calendar Item 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 group item, and it should support specifying a mapping between the new item and an arbitrary table and id in the database.

50.10.20 Provide a function to return a list of all groups with calendars.

50.10.30 Provide a function do delete items mapped to a particular table and id in the database.

50.10.40 Provide a function to delete a particular item.

50.10.50 Provide a function to insert a recurring item.

50.20 Calendar Views

50.20.10 Provide a function to generate the HTML for the table of upcoming items.

50.20.20 Provide a function to generate the HTML for the table of new items.

50.20.30 Provide a function to generate the HTML for the list view.

50.20.40 Provide a function to generate the HTML for the day view.

50.20.50 Provide a function to generate the HTML for the week view.

50.20.60 Provide a function to generate the HTML for the month view.

50.20.70 Provide a function to generate the HTML for the year view.

50.20.80 Provide a function to generate the HTML for the navigation widget.

50.20.90 Provide a function to generate the HTML for the complete calendar.

VI.E Requirements: Integration with Existing Modules

60 Integration with Existing Modules

60.10 Intranet Module

60.10.10 The pre-existing link to the old calendar showing absences and events on /intranet/ad-index.tcl (/calendar/monthly) should be changed to link to a new group calendar page which shows absences and old calendar items.

60.10.20 Adding an absence from /intranet/absences/ should add an equivalent item on the monthly calendar.

60.10.30 Editing the absence should cause an equivalent change in the corresponding calendar item.

60.10.40 Deleting the absence should also delete the corresponding calendar item.

60.20 Reservations Module

60.20.10 The /reservations/cr/ (conference room) page should provide an option for marking calendars.

60.20.20 If the mark calendar option is selected, then after the reservation information is submitted, an additional form should be presented for determining which calendars should be marked.

60.20.30 One option on the form should be to select from a list of existing group calendars. A calendar item corresponding to the reservation will be added to the group calendar.

60.20.40 One option should be to select a list of users. A calendar item corresponding to the reservation will be added to the personal calendar of each user.

60.20.50 Canceling a reservation should remove the corresponding item(s) from the calendar(s).

60.20.60 Making a massage reservation from /reservations/massage/ should add a corresponding item to the users personal calendar.

60.20.70 Canceling a reservation should delete the corresponding calendar item.

VII. Revision History

Document Revision # Action Taken, Notes When? By Whom?
0.1 Creation 2000/10/25 W. Scott Meeks


smeeks@arsdigita.com
Last modified: $Date: 2001/01/22 04:24:12 $
spacer