UW Calendar logoWelcome to the University of Washington's
UW Calendar Project

Overview

Using UW Calendar

Download

Get Involved

Additional Resources

UW Calendar Requirements Document

Click on the Tracking Bug links to get more information, comment on the requirements, or to vote for the features you'd most like to see get done.

If you don't see the feature you're interested in, click on the Tracking Bug link next to the category that seems most appropriate (e.g., the link next to Calendar Store and Server if there's something you think the server needs to be able to do), and type your thoughts in the Additional Comments textbox.

Below we distinguish between three types of users of the UW Calendar application.

  1. A user is any user of the system. Most of the time, we assume a user must authenticate before accessing the system, but not always.
  2. A programmer is a user with the expertise to build programs that interact with the system; any user can be a programmer, but we assume most users are not.
  3. An administrator is one of the people in charge of an installed UW Calendar system.

UW Calendar Requirements

  1. Calendar Store and Server Tracking Bug
    1. The system should be able to work with any database with a JDBC driver.   DONE  
    2. The store should be able to store any RFC 2445-compliant iCalendar object, and give it back without loss of data. This includes any number of non-standard (extension) fields. Tracking Bug
    3. The store should be able to treat locations, sponsors, and keywords (categories) as independent entities so that, for example, a programmer can easily create a query for My 20 Most Common Event Locations.   DONE
    4. A programmer should be able to access the store using the IETF-approved calendar server protocol.   PARTIALLY COMPLETE   Tracking Bug
    5. A programmer should be able to access the store as a Web Service (using SOAP and XML). Tracking Bug
    6. An administrator should be allowed to limit the number of entries a user can have in the store. Tracking Bug
  2. Personal calendaring Tracking Bug
    1. A user should be able to add, update, delete and view their personal events, to-dos and journal items.   PARTIALLY COMPLETE   Tracking Bug
  3. Public calendaring Tracking Bug
    1. Public events entry Tracking Bug
      1. All users should be able to create public events (and keywords, sponsors, and locations). They should also be able to modify and delete their own public events. Tracking Bug
      2. Any number of classes of official public events should be supported (e.g., the academic calendar, Chemistry Department colloquia, intercollegiate women's soccer schedule). Tracking Bug
        1. For each class, selected users should be able to create events in the class, and modify and delete the ones they have created. Tracking Bug
        2. For each such class, there should be superusers with extra capabilities:
          • The ability to manage the list of users who can create events of this class (and the list of superusers).
          • The ability to modify or delete any event of this class.
          • The ability to specify a default set of keywords, sponsors, or locations for this class.
          Tracking Bug
        3. There should be a simple system for configuring the web interface for each particular class of events so that, for example, when you input a women's soccer game, you must enter an opponent, but when you input a Chemistry Department colloquium, you are asked for a speaker and their affiliation. Tracking Bug
        4. The system should include a method for someone to submit an already created event to the appropriate superuser for inclusion in a class of events. Tracking Bug
    2. Public events display Tracking Bug
      1. A user should be able to view public events using the same interface as the personal display application, without authenticating.   DONE
      2. An administrator should be able to specify a different skin for the public events display, so it can easily be distinguished from the personal display.   DONE
      3. Filtering Tracking Bug
        1. A user should be able to apply a filter to view a subset of the public events.   PARTIALLY COMPLETE   Tracking Bug
        2. Once a particular filter has been selected, a user should be able to navigate through the various views with the filter applied.   DONE
        3. The owner of a particular calendar (filter) should be able to specify a skin to use when it is displayed. Tracking Bug
    3. Public events and personal calendars Tracking Bug
      1. A user should be able to add individual public events to their personal calendar.   DONE
      2. A user should be able to subscribe to a particular public calendar (see Calendars and Filters). Any events in the calendar will automatically appear in their calendar without their selecting them.   DONE
      3. If any public event a user subscribes to or has chosen changes, the change should appear automatically in their calendar.   DONE
      4. A user should be able to remove any individual public events they chose, or unsubscribe to any calendar they have previously subscribed to.   DONE
      5. If a user has subscribed to a calendar, they should be able to choose individual events in the calendar that they do not want to see in their personal calendar. Tracking Bug
  4. Group calendaring Tracking Bug
    1. Group definition Tracking Bug
      1. A user should be able to specify an ad hoc group of people who can view an event, by entering a list of e-mail addresses. Tracking Bug
      2. A user should be able to specify a pre-existing group of people who can view an event, using LDAP or some other directory mechanism. Tracking Bug
    2. When a user creates a group event... Tracking Bug
      1. ...they should be able to specify a group of required participants, and a group of requested participants. Tracking Bug
      2. ...invitations should be sent to participants whom the user cannot schedule. (The user can also send invitations to users they can schedule, or can specify that they will send the invitations themselves). The invitations can be sent by e-mail or as invitations/messages the participants see when they access their personal calendar. Tracking Bug
      3. ...the system should track who has accepted and who has declined the invitations, sending e-mails/messages where appropriate. Tracking Bug
    3. Recipients of an invitation should be able to delegate another person to go in their stead. Tracking Bug
    4. A user should be able to specify a group that can view or even modify their calendar. Tracking Bug
    5. A user should be able to specify a group that can schedule them for an event. Tracking Bug
    6. A user should be able to specify a group that can view their free/busy list. Tracking Bug
    7. A user should be able to specify that their free/busy list is public. Tracking Bug
    8. A user should be able to specify access control on a particular event, to-do, or journal (i.e., who can read, write, delete, modify, etc.) Tracking Bug
    9. Event conflicts Tracking Bug
      1. A user should be able to specify whether an event in their calendar is opaque (another opaque event cannot overlap this event) or transparent (another event can overlap this event). Tracking Bug
      2. If a user tries to add an opaque event that conflicts with an existing opaque event, the system should warn the user and offer some appropriate courses of action. Tracking Bug
    10. A user should be able to block out times in their calendar when they cannot be scheduled. Tracking Bug
    11. To aid in scheduling a group meeting... Tracking Bug
      1. ...a user should be able to view the aggregate free/busy times of the group (for those members of the group for which the user has permission). Tracking Bug
      2. ...a user should be able to request the first available free time for the group, or all times the group is free (for those members of the group for which the user has permission). Tracking Bug
      3. ...a user should be able to schedule a meeting for the group if the meeting time is free for all required participants and the user has the ability to schedule all required participants. Tracking Bug
  5. Resources Tracking Bug
    1. A user should be able to create a scheduleable resource in the database, such as a meeting room or a workstation. Tracking Bug
    2. The creator of a resource should be able to specify most of the group calendaring characteristics for the resource as if it were a user. In particular, they should be able to specify: Tracking Bug
      1. Who can schedule the resource. Tracking Bug
      2. Who can view the resource's calendar. Tracking Bug
      3. Who can view the resource's free/busy list. Tracking Bug
      4. Whether the resource's calendar is public (note that we aren't letting a user's calendar be public). Tracking Bug
      5. Whether the resource's free/busy list is public. Tracking Bug
      6. What times are blocked out (unscheduleable) for the resource. Tracking Bug
    3. A user scheduling a group event should be able to treat a resource like another user (e.g., make it a required participant, include it in a search for the first common free time, etc.), except where it does not make sense (the resource will not usually receive or send e-mail, for example). Tracking Bug
  6. Personal Display Application Tracking Bug
    1. A user should be able to view all their events (personal, public, or group) on a particular day, week, or month. A user should be able to view all details of a particular event in a separate view.   DONE
    2. A user should be able to view their events for the next n days or weeks. Tracking Bug
    3. A user should be able to view events for one day as an hourly view, with time on one axis and the events as (possibly overlapping) boxes in the appropriate time of day. Tracking Bug
    4. A user should be able to view events for any period of time longer than a day as a list if they choose. Tracking Bug
    5. A user should be able to navigate easily to a particular day, week, month, or year.   DONE
    6. A user should be able to easily add, update, or delete events, to-dos and journals they created. A user should be able to remove events they did not create from their calendar.   PARTIALLY COMPLETE   Tracking Bug
    7. A user should be able to easily add, update, or delete locations, sponsors and keywords they created.   PARTIALLY COMPLETE   Tracking Bug
    8. A user should be able to create an entity by cloning an existing entity they have access to. Tracking Bug
    9. For some objects, there may be a simplified entry form that leaves out certain uncommonly used fields or options for ease of use. If that is the case, there should also be an advanced entry form (or series of forms) where all fields and options can be specified. Tracking Bug
    10. A user should be able to choose lists of favorite locations, sponsors and keywords that can be easily selected when creating an event, to-do, or journal. Tracking Bug
    11. A user should be able to search or filter their own events (see Calendars and Filters). Tracking Bug
    12. A user should be able to specify a priority for a to-do or event. Tracking Bug
    13. Views that display dates but not events should highlight the days that have events. Tracking Bug
    14. A user should be able to undo any number of commands in the current session. Tracking Bug
    15. An administrator should be able to specify a skin for the application appropriate to their institution.   DONE
  7. Calendars and Filters Tracking Bug
    Note: Calendars and filters are both names for collections of related events. For example, 'all events sponsored by the History department'. If the collection is unnamed, for example, if it is the temporary result of a search query, we will refer to it as a filter. If the collection is given a name, we will refer to it as a calendar.
    1. Defining Calendars and Filters Tracking Bug
      1. A user should be able to filter events by keyword, sponsor, location, or creator.   PARTIALLY COMPLETE   Tracking Bug
      2. A user should be able to create a search filter that selects the events that contain a particular string in a system-defined set of interesting fields.   PARTIALLY COMPLETE   Tracking Bug
      3. A user should be able to combine the filters above using standard boolean logic to create another filter. Tracking Bug
      4. A user should be able to name a filter so it can be saved and referenced later (as a calendar). Tracking Bug
      5. The system should allow filters and calendars to contain another calendar. There should be no limit on the depth of recursion (beyond disallowing circular inclusion).   PARTIALLY COMPLETE   Tracking Bug
    2. The system should allow calendars to be hierarchically classified.   PARTIALLY COMPLETE   Tracking Bug
    3. A user should be able to search for a particular calendar. Tracking Bug
  8. Alarms/Reminders Tracking Bug
    1. A user should be able to request an e-mail alarm for a specified amount of time before an event begins. Tracking Bug
    2. A user should be able to request a text message be sent to their pager, cell phone, etc. a specified time before an event begins. Tracking Bug
  9. To-dos Tracking Bug
    1. To-dos should be displayed in the Personal Display Application, separate from events. Tracking Bug
    2. A user should be able to specify a due date for a to-do. Tracking Bug
    3. A user should be able to specify a group to-do, analogous to a group event. Tracking Bug
  10. Journals Tracking Bug
    1. Journals should be displayed in the Personal Display Application (perhaps with the events, but displayed in a different font/color/something?). Tracking Bug
    2. A user should be able to specify a group or a public journal entry, analogous to a group or public event. Tracking Bug
  11. Recurrences Tracking Bug
    1. The store and all applications should be able to handle any recurrence legal under RFC 2445. Tracking Bug
    2. Specifying recurrences Tracking Bug
      1. A user should be able to specify the most common recurrences when creating a simple event: every day, every other day, every week, every other week, every month, every year, this day every month, this date every year. A user should be able to specify the recurrence ends on a particular date, or repeats forever. Tracking Bug
      2. A user should be able to specify more complex recurrences using another form: every n hours, days, weeks, months, years; the nth Monday/Tuesday/etc. every nth month; the nth Monday/Tuesday/etc. of this month, every nth year; Tracking Bug
      3. On the more complex form, a user should also be able to specify exception dates. Tracking Bug
    3. Changing recurrences Tracking Bug
      1. A user should be able to change details for the entire recurrence set, or just one particular instance. Tracking Bug
      2. A user should be able to delete a single instance in the set, all instances, or all instances prior to or after an instance.   PARTIALLY COMPLETE   Tracking Bug
    4. An administrator should be allowed to limit the number of recurring events that have a large number of instances (including those that extend forever). The administrator shall be able to define what large means. Tracking Bug
  12. Importing Tracking Bug
    1. A programmer should be able to import events or other entities in iCalendar or XML... Tracking Bug
      1. ...by communicating with the server using the IETF-approved calendar server protocol. Tracking Bug
      2. ...by sending an e-mail message with the entities. Tracking Bug
      3. ...by putting the entities on a web page, and sending the system a URL. Tracking Bug
      4. ...by putting the entities in a file, and invoking a command. Tracking Bug
    2. A programmer should be able to import events or other entities using a Java API. Tracking Bug
  13. Exporting and Printing Tracking Bug
    1. A programmer should be able to export events in iCalendar or XML by communicating with the server using the IETF-approved calendar server protocol.   PARTIALLY COMPLETE   Tracking Bug
    2. A programmer should be able to export events or other entities using a Java API. Tracking Bug
    3. Automatic export to web pages. Tracking Bug
      1. There should be a process available to automatically extract all public events in a calendar that fall within a certain date range to a web page, using XML and XSLT. Tracking Bug
      2. There should be a number of XSLT templates available so that a department or other entity with limited resources can easily generate a pleasing page of their events. Tracking Bug
    4. The personal display application (and hence the public display application) should supply printer-friendly versions of the day, week and month views. Tracking Bug
    5. The system should allow for printing to a number of standard dayplanner output formats, and page sizes. Tracking Bug
  14. Integration Tracking Bug
    1. There should be a uPortal channel that displays a user's personal calendar (including group and public events) and provides at least limited functionality such as adding a simple event or changing the time period of the view. Tracking Bug
    2. There should be a uPortal channel that displays a filtered version of the public events and provides at least limited functionality such as changing the filter or changing the time period of the view. Tracking Bug
    3. The system should be able to extract events from uPortal's announcements channel database, and the announcements channel should be able to get its data from UW Calendar. Tracking Bug
    4. The system should be able to act as the backend to IBS's uPortal channel. Tracking Bug
    5. The system should be able to act as the backend to Ximian Evolution. Tracking Bug
  15. Synchronization Tracking Bug
    1. A user should be able to synchronize with their Palm calendar. Tracking Bug
    2. A user should be able to synchronize with Outlook. Tracking Bug
    3. A user should be able to synchronize with Corporate Time. Tracking Bug
    4. A user should be able to synchronize with Meeting Maker. Tracking Bug
  16. E-mail integration Tracking Bug
    1. UW Calendar should be fully integrated with e-mail, so that it can send e-mails with the proper MiME type, and so that a user can set their mailer to send objects of this type to UW Calendar. Tracking Bug
    2. A user should be able to invite anyone to a public event, or invite them to subscribe to a public calendar, using e-mail. (If they choose, they can add the events or subscribe to the calendar.) Tracking Bug
  17. Aggregation Tracking Bug
    1. The personal display application and other display applications should be able to query multiple stores that understand the IETF-approved calendar server protocol and aggregate the results as if they came from a single source. Tracking Bug
    2. A user should be able to subscribe to a calendar on a different server and have the events show up in their display applications. Tracking Bug
  18. Preferences Tracking Bug
    1. A user should be able to specify which view appears by default. Tracking Bug
    2. A user should be able to specify which day the week begins. Tracking Bug
    3. A user should be able to specify whether week and month views appear as a list or a grid. Tracking Bug
    4. A user should be able to specify which fields appear in summary views of an event, to-do, or journal. Tracking Bug
    5. A user should be able to specify which fields appear in any simplified add or update forms for an event, to-do, or journal (apart from any required fields). Tracking Bug
    6. A user should be able to specify a particular visual cue for a particular type of event (e.g., high-priority to-dos are in red, birthdays have a balloon icon next to them). Tracking Bug
    7. A user should be able to specify their desired Locale. Tracking Bug
    8. A user should be able to specify whether they want links underlined or not in the display applications. Tracking Bug
    9. A user should be able to specify that they want to be warned if two events overlap. Tracking Bug
    10. A user should be able to specify that they want the month view to be smaller (by deleting or compressing entries) if there a lot of entries in the month. Tracking Bug
    11. A user should be able to specify graphical embellishments, such as the default background, font, or color for applications. Tracking Bug
    12. A user of the personal or public calendar should be able to specify that events that span more than one day only appear on the first day Tracking Bug
  19. Internationalization and Localization Tracking Bug
    1. The system should handle time zone information correctly. Tracking Bug
    2. The system should handle other languages (not just English).   DONE
    3. The system should handle other text and calendar orientations (not just left-to-right, top-to-bottom). Tracking Bug
    4. The system should handle non-Gregorian calendars.   PARTIALLY COMPLETE (MAYBE)   Tracking Bug
  20. Other Applications Tracking Bug
    1. The system should include a method or methods for adding a student or faculty member's class schedule to their calendar.   PARTIALLY COMPLETE   Tracking Bug
    2. The system should include an application that allows specific users to maintain calendars for a particular class (homework, midterm dates, etc.). Tracking Bug
    3. The system should include a method for adding the official academic calendar and list of holidays.   PARTIALLY COMPLETE   Tracking Bug
    4. An administrator should be able to generate useful reports and statistics about the system. Tracking Bug
  21. Performance Tracking Bug
    1. The system should be able to handle the calendaring needs of a University of at least 200,000 active users (assuming reasonable hardware and technical support). Tracking Bug
  22. Accessibility Tracking Bug
    1. The system's applications should be accessible to the disabled.   BELIEVED DONE FOR EXISTING APPLICATIONS   Tracking Bug
University of Washington
Computing & Communications
calendar_users@u.washington.edu