Web-based events calendar for Cornell University by oox83341

VIEWS: 16 PAGES: 12

									Cornell University Web-based events calendar
Request for proposals
Draft 2, December 6, 2006


Abstract
The goal of this project is to provide a Web-based University-wide events calendar for Cornell
University that supports current and ongoing needs for centralized online events browsing and
advertising, receives data from other electronic calendars using accepted data exchange
standards, and allows units to extract just those events relevant to their audiences and display
them on their own Web sites.


Objectives
      Establish a common language and a controlled vocabulary for describing the most basic
       elements of an event at Cornell.

      Reduce the number of events data repositories at Cornell by identifying and meeting a
       core set of basic needs with the central system.

      Simplify the process of publicizing events.

      Enable unit Web sites to tie into the central events data repository for events data search
       and display on their own sites.

      Increase Web audience engagement with the central Cornell events calendar system.

      Provide an easy-to-use, intuitive interfaces for manually adding and updating events in
       the central calendar. Make these interfaces available to any Cornell community member
       wishing to submit an event for consideration.

      Wherever possible, establish communications between existing calendaring systems and
       the central calendar system to alleviate the need for event providers to enter their events
       data multiple times in more than one system.

      Establish a data exchange specification, using an industry-standard calendar data format,
       by which events data can be imported from other electronic calendar systems at Cornell.
       This will provide an automated way for Cornell event providers to contribute events data
       that originates from existing systems.

      Support a manual review and approval process of events data, where deemed necessary to
       determine the appropriateness or validity of the event for inclusion in the central
       calendar.
      Support a “pre-approved” event provider status within the system. Pre-approved events
       providers will be allowed to post their events immediately to the calendar, bypassing the
       approval process.

      Integrate into the main Cornell Web site an intuitive, easy-to-use, and flexible interface
       for end to search and display events data.

      Provide Cornell Web site developers with automated ways to find and display central
       events data relevant to their units on their own Web sites, and to apply their own interface
       to that data on their sites.

      Offer end users ways of subscribing to event calendar data that will be “pushed” to them
       regularly and automatically, based on their preferences for event types and channels
       through which to receive customized events data.


Background
The need for a University-wide electronic events calendar has been recognized for many years,
as evidenced by the many previous projects to implement such a tool. The most recent resulted
in the PHP/MYSQL system we use today as part of Cornell’s main Web site,
http://www.cornell.edu/events/. This system was built on an application developed at George
Mason University, but which today includes only remnants of the original George Mason code
base. The calendar is owned jointly by the Office of Web Communications and Campus
Relations, both departments within University Communications, and supported through technical
resources within Cornell Information Technologies.

The end-user browse and search interface for the calendar was redesigned in the summer of 2004
in conjunction with the redesign of the www.cornell.edu site. The interface by which any person
can suggest an event for the calendar was also redeveloped, but the administrative interface for
pre-approved (“Tier 2”) event providers was not redesigned. This project needs to not only
address these problems we have observed, but also provide channels for data exchange and for
better end-user interaction with the system, so that University Communications can promote the
system as one that truly serves the needs of the community, and work toward the “system of
record” status that Cornell needs this system to attain.

This project is not intended to address the following issues:
    Space reservation for events
    Attendees registration for events
    Approval for use of space or sponsorship of events
    Events data for which end-user authentication is required to view
    Personal or group calendaring and scheduling
    Overall content management for Web sites (Cornell already has a CMS, CommonSpot)

Stakeholders in this project, in addition to University Communications and Cornell Information
Technologies, include event sponsors, college and unit IT managers and Web site developers,
owners of current calendaring systems at Cornell, and owners of integrated Web systems with
which this system may interface, such as uPortal and R25.
Required system functionality
This is a brief summary of some key elements of functionality that are required for Cornell’s
events calendar system. This is not a comprehensive description of the ideal system, but a list of
some of the key features that we know are required in any future events calendar system we offer
at Cornell.

See http://forum.web.cornell.edu/solutions_groups/events/uwide-calendar-about.html for a more
in-depth description of our current calendar.


   1. Events attributes (see http://www.cornell.edu/events/add.cfm )
         a. Easy entry of one-time events
         b. Easy and efficient entry of recurring events
         c. Public or closed events – specify if general public is invited
         d. Entry fee or free; if fee, associated text notes. Can accommodate an event that is
             free for some audiences and fee for others.
         e. Any event record can be assigned multiple types from a controlled list
         f. Event description field supports basic HTML formatting, special characters, and
             hard returns (free text).
         g. A single event can span multiple days (e.g. last past midnight, or lasts several
             days)
         h. Any event record can be assigned multiple event sponsors from a controlled list.


   2. Event data input and submission
         a. Manual – public interface, proposed events go into approval queue
         b. Manual – “Tier 2”, secured interface, only list of pre-approved event providers
             can access this interface
         c. Tier 2 event provider’s interface secured through Kerberos authentication
         d. Tier 2 event providers can copy existing or past event to start new event
         e. Can indicate different event times for selected dates in a recurring event (e.g.
             Friday and Saturday 8:00pm, Sunday matinee 2:00pm, or different museum
             opening hours on weekends)
         f. Spell check of selected free-text fields
         g. Only Tier 2 event providers and central administrators can add closed events
         h. Batch upload of tab delimited files available to Tier 2 event providers


   3. Event approval workflow
         a. All events submitted by public require approval by list of pre-determined calendar
             administrators
         b. Approval of events generates automatic email notification to event provider
         c. Calendar administrators can edit all aspects of events, and choose not to approve
             events
             d. Store date/time/user stamp on last record change


    4. Event data update
          a. Events proposed by general public cannot be updated by the event provider, must
              go through calendar administrator
          b. Tier 2 event providers can update their own events without assistance from
              calendar administrators


    5. Calendar browse on cornell.edu (see http://www.cornell.edu/events)
          a. Interface must be skinned to fit into the cornell.edu site design
          b. Display current day’s events by default
          c. Closed events not displayed in central calendar but can be pulled and displayed on
             a local unit’s Web site.
          d. Browse by day, by week, by month
          e. Restrict view by event categories
          f. Restrict view by time of day
          g. Efficient display of recurring events, condensed into single listing
          h. Sidebar highlighting featured events
          i. Simple display for PDAs


    6. Calendar search on cornell.edu (see http://www.cornell.edu/events/)
          a. Calendar-based search interface for all events, as in browse
          b. Advanced search (see http://www.cornell.edu/events/search.cfm)
          c. Display event sponsor(s)
          d. Exclude/omit recurring events from a search


    7. Export/push of records
          a. Each department/unit can specify automated views of the calendar data,
              independent of what technologies are used to build their site
          b. Each department/unit can make these views available on their own Web sites
          c. Each department/unit can specify keywords they want to use to tag and extract
              their events
          d. Consumers1 can sign up for email alerts
          e. Consumers can subscribe to RSS feeds
          f. Alerts d and e will only deliver public events
          g. Alerts d and e can be delivered daily or weekly



1
  Note that people contributing events or interested in making them available to other audiences are called
'producers'. Those using the web-view to look for events personally of interest are called 'consumers'.
   8. Calendar administration
         a. Access to event approval queue
         b. Manage Tier 2 event provider list
         c. Manage calendar administrator list
         d. Manage event categories
         e. Manage event locations
         f. View events by year or month, selected by any search criteria.
         g. Report of records added since last login, searchable by date range, filtered by Tier
            2 and/or general event providers
         h. Report calendar use statistics, including who is visiting and searching the
            calendar, how often, from what originating page
         i. Report of all Tier 2 event providers, including name, department, email
         j. All reports and lists printable
         k. All reports and lists exportable


Desired new functionality
The following is a list of desired features that have arisen during stakeholder conversations about
a future Cornell events calendar. These features are generally recognized as desirable and
potentially valuable, but are not required for an initial implementation of a calendar system.


   1. Event attributes
         a. Can request coverage of the event from multiple media sources: Cornell.edu
             homepage, Chronicle, Press Office, Sidebar Highlight with a photo submitted for
             consideration, automatically generating email with URL to relevant contact for
             those selected, with option for cover note from event provider.
         b. “Highlight” checkbox, visible only in admin view, for pushing to sidebar (see
             “Calendar search on cornell.edu”, below) and for reporting.


   2. Event data input and submission
         a. Can omit individual dates from a series of dates in a recurring event
         b. Tier 2 event providers can add events using sponsor(s) outside of their own
             organizations
         c. Departments/units can program, with central knowledge and approval required,
             their own data input interfaces that prompt users to assign unit-specific tags to
             events


   3. Event approval workflow
         a. Event approval could be distributed to units (e.g. one approver in the Engineering
             College could review and approve events proposed by Engineering, but not events
             proposed by Arts and Sciences)
   4. Calendar browse on cornell.edu
         a. Ability to highlight a featured event with a photo
         b. “Best Bets” view of selected upcoming week’s events, as an alternative first page
            of the calendar, that would include photos and publicity style write-ups,
            assembled dynamically from flagged events stored in system


   5. Calendar search on cornell.edu
         a. Consumers can save a search to rerun later
         b. Printable results (one or many records)


   6. Export/push of records
         a. User alerts can be based on a user-defined saved search
         b. Consumer can email event record from browse view
         c. Search results can be emailed from consumer view
         d. Unit Web developers can enable RSS subscription to events displayed on their
             sites, whether public or private


   7. Calendar administration
         a. Report activity levels of Tier 2 and other users (numbers of records users have
            added- searchable by date range, filtered by Tier 2 and/or general users)
         b. Reports of events by year and month to compare from year to year. Be able to
            separate by recurring/nonrecurring, by highlight, and all other attributes



Checklist for submission
Cornell University welcomes proposals from vendors of Web events calendar systems whose
products meet the requirements listed above. Please ensure that your proposal contains the
following:

      completed product functionality grid
      completed vendor questionnaire
      supported platforms and architectures
      system diagram of a typical installation housed on-site
      product documentation
      pricing and licensing structure
      references from institutions using your product that are similar in size and type to
       Cornell, and that use a distributed model for content entry for their online events calendar
Product functionality grid
Please complete the following grid to describe the current and potential functionality of your
product in relation to Cornell’s events calendar needs.

1. Event attributes:
Desired feature                                  Feature       Could be    Could be      Not
                                                 currently     extended    extended by   possible
                                                 exists        by client   company
Easy entry of one-time events
Efficient entry of recurring events
Public or closed events
Specify entry fee or free
Event can be fee and free by audience
Event type multiple assignment
Event type assigned from controlled list
Event description supports HTML format
Event can span multiple days
Event can have multiple sponsors
Request coverage from media sources
Email notification when media coverage
requested
Flag event for “highlight”

2. Event data input and submission:
Desired feature                                  Feature       Could be    Could be      Not
                                                 currently     extended    extended by   possible
                                                 exists        by client   company
Manual public propose event interface
Manual secured “Tier 2” user add interface
Tier 2 interface secured with Kerberos
Tier 2 providers can copy existing or past
event to start new event
Different event times within recurring event
Spell-check of selected free-text fields
Only Tier 2 providers can add closed events
Batch upload of tab delimited files available
to Tier 2 providers
Can omit individual dates from a series of
dates in a recurring event
Tier 2 providers add events outside their org.
Units can build custom event data input
interfaces

3. Event approval workflow:
Desired feature                                  Feature       Could be    Could be      Not
                                                 currently     extended    extended by   possible
                                                 exists        by client   company
Publicly-proposed events require approval
by calendar administrator
Event approval generates email notification
Administrator can edit event, deny approval
Store date/time/user stamp on last change
Event approval distributed to unit approvers

4. Event data update:
Desired feature                                Feature     Could be    Could be      Not
                                               currently   extended    extended by   possible
                                               exists      by client   company
Publicly-submitted events editable only by
calendar administrator
Tier 2 event providers can update their own
events without admin help

5. Calendar browse on cornell.edu:
Desired feature                                Feature     Could be    Could be      Not
                                               currently   extended    extended by   possible
                                               exists      by client   company
Main browse interface can be skinned to fit
cornell.edu site design
Display current day’s events by default
Closed events not displayed in main browse
Closed events can be pulled and displayed
on local unit site
Restrict view by day, week, month
Restrict view by event categories
Restrict view by time of day
Recurring events condensed into single
listing
Sidebar highlighting of featured events
Simple display for PDAs
Highlight featured events with photo
“Best Bets” view as alternate first view

6. Calendar search on cornell.edu:
Desired feature                                Feature     Could be    Could be      Not
                                               currently   extended    extended by   possible
                                               exists      by client   company       at this
                                                                                     time
Calendar-based search interface
Advanced search
Display event sponsor
Exclude or omit recurring events
Consumer can save search to rerun later
Printable results (one or many records)
7. Export/push of records:
Desired feature                               Feature     Could be    Could be      Not
                                              currently   extended    extended by   possible
                                              exists      by client   company
Units can specify custom automated views
of calendar data, independent of site
technologies used
Units can display custom views of calendar
data on their own Web sites
Units can specify keywords for tagging and
extraction
Consumers can sign up for email alerts
Consumers can subscribe to RSS feeds
Alerts deliver public events
Alerts can be delivered daily or weekly
Email or RSS alerts can be based on a user-
defined saved search
Consumer can email event record from
browse view
Search results can be emailed from
consumer views
Units can enable RSS subscription of their
views of the calendar


8. Calendar administration:
Desired feature                               Feature     Could be    Could be      Not
                                              currently   extended    extended by   possible
                                              exists      by client   company
Access to event approval queue
Manage Tier 2 event provider list
Manage calendar administrator list
Manage event categories
Manage event locations
View events by year or month, selected by
any search criteria
Report records added since last login,
searchable and filterable
Report calendar use statistics
Report Tier 2 users
All reports and lists printable
All reports and lists exportable
Report activity level of Tier 2 users
Report comparison of events year to year or
month to month
Vendor questionnaire
 Because proposals are often submitted in different forms, they can be difficult for us to evaluate.
To help us compare the bids fairly, please answer the following questions in the order provided
below. Please use the associated numbering in your proposal and answer all the questions. You
are welcome to refer to other answers to where appropriate.

1. When was your product first launched? Describe its history briefly.

2. Describe your company’s experience addressing online events calendar needs in higher
   education.

3. Describe how your product could be used in a distributed events environment to reduce
   duplication in events data entry and storage.

4. Describe how your product is aware of and takes advantage of current data exchange
   standards.

5. Describe architectural changes you’ve made in the last 3-5 years. (How “mature” is your
   product)

6. Describe to what degree your product is compatible with Rehabilitation Act of 1973 Section
   508 guidelines for accessibility of Web applications.

7. Typically, how long does your product take to implement the first time?

8. What challenges have clients encountered during initial installation?

9. How do you address bugs and minor updates to your product?

10. How often do you issue major upgrades?

11. How much investment of resources is required for each upgrade?

12. If we buy your product, how long would you estimate before we can expect to replace it or
    significantly overhaul it?

13. Describe the structure and cost of your training services.

14. Typically, how much product-specific training (both formal and informal) is required for
    system administrators and other technical professionals supporting the product?

15. Typically, how much product-specific training (both formal and informal) is required for
    Web developers who want to display events data on their sites?

16. Typically, how much training is required for end users of your product (e.g. those providing
    events)?

17. Describe the structure and cost of your technical support services.

18. Are you willing to give access to source code?
Vendors to receive this RFP (still an incomplete list)

Commercial
Active Data Exchange http://activedataX.com
Apple
Eventful http://eventful.com/
nTreePoint http://www.unidigm.com/events
Oracle
Plan-it-Purple (Northwestern U.) http://planitpurple.northwestern.edu
Trumba http://www.trumba.com/
WebEvent http://www.peoplecube.com/products/webevent/default.cfm (Brown, Princeton
unhappy with it)

Open source:
VTCalendar http://vtcalendar.sourceforge.net/ (Michigan State and others say they love it)
Bedework http://www.bedework.org/
http://events.unl.edu/ (Source is available at http://pear.unl.edu/)
Cornell in-house calendar (Tim Perry)

From a Google search:
Google Calendar: http://calendar.google.com/
EventsLink Network http://www.eventslink.net/
CalendarWiz http://www.calendarwiz.com/
Calendars for the Web http://www.greathill.com/calendar.htm

Other???
PaperThin (proposal to collaborate on software development)

CalConnect members, http://www.calconnect.org/
      * Apple
      Boeing
      * Eventful (may be hosted off-site only?)
      IBM
      NASA JPL
      Kerio (mailserver, firewall, collaboration servers?)
      Marware (Apple accessories)
      Mozilla
      Novell
      Open Source Applications Foundation (OSAF)
      * Oracle
      * PeopleCube
      Rockliffe (email server and messaging?)
      Symbian (smart phones?)
      Timebridge (personal scheduling)
      * Trumba
      Yahoo
      ----------
      CalState Fresno
       Carnegie Mellon
       Dartmouth
       Duke
       MIT
       NYU
       RPI
       Stanford
       UCBerkeley
       University of Chicago
       University of Washington
       University of Wisconsin Madison

Universities doing central entry/distributed display:
       Rice – custom ColdFusion/SQL Server application written on top of EMS (room
           reservation system)
       Stanford – custom Java/JSP app with MYSQL db
       UChicago – not sure of infrastructure

PCI (alumni relations products)
https://www.publishingconcepts.com/index.asp?&SSLChecker=TRUE

Microsoft Sharepoint

								
To top