Although this is an entirely new project which is for the most part self-contained, there are two other systems with which it may need to interact via XML documents in order to share event information:
calendars on the UC Berkeley campus who choose to maintain their own website and repository of event information, but would like to share their events with or pull event information from other campus calendars
the CalAgenda personal calendaring system
The product functions we expect to include in this first release of the UCBCN application include:
Calendar & Event Management Application
Accounts - Each registered campus organization can sign up for one account (e.g. there is only one user account with administrative rights on the account for each organization), including major student organizations (e.g. ASUC). Users of these accounts must have a CalNet ID, and the accounts will be approved by Public Affairs.
Ability to modify calendar header, footer, text & calendar color & font, display range, global (site) navigation, calendar navigation, & calendar list view default elements (e.g. Title, Date, Time, Description), font & color
Ability to download & upload a CSS or XSLT to further customize the calendar
Ability to preview changes before they are applied to the live calendar
Queues for calendar owners to view and manage their pending, posted, and archived events
Provide event classifications of Public and Private
Differentiate events sent to a calendar owner via a internal form, external form, subscription, recommendation, or search
Event information may be saved in an archive or in a searchable format on the calendar for up to 5 years
A Create Event form, with both a Quick Entry & Advanced Entry interface, which will allow users to enter event information that is part of the UC Berkeley Events model
Support entry and display of parent-child events
Support entry and display of repeating events – by frequency, interval, and set position bounded by end date or # of occurrences
One primary sponsor for each event, who will have editing rights. The gateway calendar will be the primary sponsor of events whose sponsors do not have accounts on the system.
Allow HTML in the Event description
Search Campus Events & Search pending, posted, and archived queues
Defaults to a “simple” search of title & description
Search by (text in) Title & Description, Sponsor, Event Type, Audience, Performer/Speaker, Location, Event Date, Event Keyword, and Feature Type
Advanced Search (gives user the ability to search more than one of the above criteria)
Similar to Search interface in the Live Calendar
Subscription (pulling events from other calendars) which can be saved and run as searches when the calendar owner logs in
Recommendation (allowing calendar administrators to push events to other calendars)
Export (to delimited file (delimiter to be chosen), to XML file validating against UCBEvents.xsd schema, to iCal file, to RSS, to HTML (HTML is not a requirement, but should be done if it's easy once we have an XML export)
Upload XML Feeds of a file validating against UCBEvents.xsd schema to the repository, and give feedback on success or failure of upload
Allow Accounts to indicate whether they would like to approve events submitted to multiple calendars for whom they are the primary sponsor before they are sent to the other calendars. All public events are sent to Public Affairs by default.
Standard RSS feeds using RSS 2.0 of Today's Events, This Week's Events, This Month's Events, as well as Events, which will include the past 6 months of events as well as all future events
Allow events to be copied to use as a template for a new event
Allow Accounts to specify a list of mailing lists which will be displayed in the internal Create Event form
Provide ability to send automatic email to mailing lists or specific email addresses when an event is entered into the system
Add list of all campus buildings to the database with information on which map link to provide for each one, the add application logic to present the link on the Event Details page if user indicates they would like to include a map
Duplicate Event entry - warn users that they may be entering a duplicate event if there is an event at the same date, time, and location of the event being entered. It will, however, allow them to enter this event if they choose to continue. This will be a work-around for events with multiple primary sponsors, but we don't anticipate this happening very often
Event Changes – All changes should go live immediately, and events that have changed should be put at the top of the Posted queue in a different color or with an icon indicating that they have changed for a period of 7 days
Event Removal from calendar - When an event owner chooses to remove an event from their calendar which is still in use by other calendars, we will inform them that it is on other calendars and ask them whether they would like to change the status in the system (e.g. to canceled). They will not be able to delete this event from the system (since it is in use on other calendars).
Live Calendar
Allow anyone with a CalNet ID to enter an event in the system from any calendar, including the gateway website. They will access a web form similar to the one in the Calendar & Event Management Application, although because this web form will not be accessed through the Calendar & Event Management Application, it will be the same on all calendars. A non-editable field with their name preceded by “Submitted by:” will be used to ensure that users know that their name is associated with any event they submit.
Allow user to jump to Grid or List views
Allow a user to jump to a day, week, two weeks, month or year view of events
Filter events on a particular page of the calendar
By (text in) Title & Description, Sponsor, Event Type, Audience, Performer/Speaker, Location, Event Date, or Event Keyword
Search events on the calendar
By (text in) Title & Description, Sponsor, Event Type, Audience, Performer/Speaker, Location, Event Date, and Event Keyword
Ability to navigate to a particular date by clicking on the small, navigational calendar
Highlight Event Changes – All events with changed information should include an icon indicating that they have changed for a period of 7 days
Display all public event information for each event in an Event Details page
Display parent-child events
Provide a Print Stylesheet for Event Details page and Search Results page
Allow the creation of a calendar with no header, footer, navigation, or styling
Stream a webcast in-line in the Event Details page (lower priority, not essential)
Enable departments to distinguish their events from other events that have been added to the calendar with color (lower priority, not essential)
Requirements that apply to both
Support Unicode
Meet ADA Requirements
The first user class the UCBCN addresses is calendar owners/administrators. Our interactions with calendar owners throughout the User-Centered Design process revealed that calendars on the UC Berkeley campus exhibit a wide range of technical complexity. Some calendars have sophisticated payment systems and event data which is very specialized to their domain. Other calendars are static HTML pages which are simply lists of events. There are also many organizations on campus that do not currently have calendars, often due to a lack of available resources to create them.
In order to meet the needs of calendar administrators with this wide range of technical needs and expertise, our system outlines three processes by which different types of campus calendars can share event information with each other. For "low-tech" calendars we have created a centralized repository to store event information which is based on the UC Berkeley Event data model, as well as a Calendar & Event Management Application. This tool will allow calendar administrators to both manage event information and create their own customized, web-based calendar which will integrate smoothly into their current website by incorporating the website's look and feel. "Medium-tech" calendar owners who are able to use the system but would like to customize their calendar further than the Calendar & Event Management Application allows may upload their own XSL transforms and/or CSS stylesheets for the calendar. "High-tech" calendar owners who have specialized web development needs, or a need to maintain their own repository of event information, may send event information to, or pull information from the centralized event repository using an XML document which is also based on the UC Berkeley Event data model.
Another important user class is obviously the end user of the calendar and consumer of event information. As the major goal of the initial phases of this project was to convince calendar owners to switch to the UCBCN, our research has focused on the needs of calendar owners. However, 9 calendar end user interviews have been held and the results of these interviews and other end user research will be incorporated into future versions of the UCBCN.
The operating environment is to be decided. Potential options include hosting at on the Arachne web server at IS&T, hosting on our own server(s) at IS&T, or using a Managed Private Server at a company like Verio. More information can be found in Section 12.1, Programming Language/Software Recommendations, Section 12.2, Hardware Recommendations, and Section 15, Cost Estimate.
The major constraint that this project must take into account is the unique environment in which it must operate: the university. Most universities, including the University of California, have a decentralized administration structure which is designed to allow intellectual freedom and encourage innovation. This means that campus departments and organizations often have the authority to decide internally how they would like to do business.
At UC Berkeley there are very few formal guidelines about how websites or web calendars should be set up, and few resources, such as centralized databases, which can be shared among the various campus departments and organizations. Although U.C. Berkeley has a "WebNet" mailing list for web designers and editors, there seems to be little formal sharing of knowledge among different organizations. Because there are few standards set from above, most of these organizations create their applications and websites in isolation with little to no thought about how they might work together. Indeed, it would be very difficult to coordinate them without help from above.
In order to deal with this unique environment where community-wide standards seem to be adopted in a grass-roots fashion, we have viewed all work on our project as part a larger marketing process. We have involved as many campus calendar owners as possible in all phases of our project including the Event modeling process and the needs assessment, iterative design and usability testing of our tool. We plan to continue encouraging this level of user involvement during future phases of this project. We believe that integrating the input of all campus calendar owners throughout the development process is a critical step towards encouraging adoption of our system. Additionally, incorporating feedback calendar users into the development process ensures that the actual calendar is usable and meets user needs.
Additionally, each calendar must have a unique URL that it can embed in its own site using a URL alias if they choose to do so.
Assumptions
All cost estimates associated with this specification, especially estimates of the number of hours of work done on the application each month, are estimates which may change when actual development & maintenance work begins.
The XSL transforms can be done on each calendar page quickly enough to display the Live Calendar in a manner that fulfills our the performance requirements of the application. If this is not accurate, another system architecture which does not involve the XSL transformation layer (e.g. with only HTML, CSS & PHP) may need to be created. If we would still like to provide calendar owners with the opportunity to completely change the look and feel of their calendar with XSL (if they are willing to put up with the associated performance costs), the cost of the developing the application would be quite a bit higher (maybe 130% of the original figure) in order to build these two alternate architectures.
We can create one XSLT for each calendar that will render all the different calendar pages by transforming one XML document of Events and calendar widgets, and they will be simple enough for calendar owners or XSLT contractors to understand. However, it may be necessary to create multiple XSL transforms for each calendar, which would make the system more complicated for calendar owners.
The calendar and application will look like their designs in the following browsers:
Internet Explorer 5.0 and higher
Netscape 7
Safari 1.0
Mozilla Firefox 1.0
For other browsers the calendar and application will gracefully degredade, as long as it doesn't affect other requirements. A stylesheet for Netscape 4 may also be provided for the calendar.