Scooby 2-year Plan, very rough draft

Scooby is a WebUI^? exposing the ability to use the Chandler information stored on a Cosmo server through a browser. This document is an extremely rough-draft 2-year plan outlining high-level feature requirements, major technology choices and sequencing decisions. As yet, many of these decisions have not yet been discussed and must be considered strawman decisions (and I welcome input).

Issues to resolve/discuss

• What's the process to decide on enterprise/Westwood requirements?
• Work on more detailed plan for hosting capacity (contingencies)
  • This might relate to issues of navigation and access control
• Relative balance between pure calendar features and others
• Implications for staffing

Audience and Use cases

The intended audience for Scooby in phase one and two is supporting workgroups using Chandler, and who want access to their calendar data away from their Chandler client, or people who are in the same workgroup but don't use Chandler and only want to use Scooby.

In phase 2 and 3 we will start to provide the user interface constructs needed to scale up for the number of users found in a typical university. There are more challenging access control and navigation problems at that scale than there are at the workgroup scale.

We will develop use cases for each phase, appropriate to these target audiences.

There's somewhat of an exception to these guidelines, in that we'll have to make Scooby work for a single OSAF-hosted server with 1000-10000 users, possibly starting in phase 2, to support our testing and to allow users to experience Chandler sharing and Scooby before committing to installing their own Cosmo/Scooby server. For example, doing actual hosting of thousands of users may require automatically-enforced quota limits on user accounts, even if workgroup use cases don't require that.

Requirements

Functional Requirements Overview

The sequencing plan has more details on how to break down high-level application functions into features and in what order.

Calendaring functions:

• Allow a user to view his/her own calendar data and that of others who have data on the same Cosmo server.
• Schedule other users, view their free-busy data.
• Schedule non-human resources and group calendars.
• Share via granting access (and rescinding) and sending invitations.

Non-calendaring functions:

• Expose generic data (including email) from a single Cosmo server in summary tables or directory listings
• Specialized functionality for tasks and contacts

Architectural/Technical Requirements

Scooby must work with Cosmo as a back-end. Although our architecture is designed for a certain amount of independence and use of standards in the communication between Scooby and Cosmo (use of WebDAV and JCR), it is not a requirement for Scooby to support other back-ends besides Cosmo. An instance of Scooby can be a separate server (or set of servers) from the Cosmo back-end or it can run on the same machine. For this timeframe, Scooby will be configured to use only one Cosmo back-end (only one server URL though it may be handled by multiple machines). (In the future we envision that Scooby might retrieve and present data from multiple Cosmo sites and even non-Cosmo calendar repositories, but that's not a requirement in the timeframe of this plan.)

Scooby must be a more responsive WebUI^? than was typically feasible in past years (this requirement motivates use of AJAX).

Scooby will support SSL as a configuration option (perhaps the only configuration option). Scooby will use HTTP form authentication over SSL to authenticate users. Unauthenticated users may also be able to view some publicly shared information.

Other

The Scooby UI must be accessible, providing text fallbacks for visual information.

Scooby will only be localized to English. We should however provide the framework for others to do localization, e.g. doing string lookups rather than fixed printed strings.

Scooby will be architected in a way to make rebranding (by editing stylesheets, editing entrance pages, changing images) reasonably easy.

Non-requirements

These are not requirements for Scooby in the first phases.

• no specialized email functionality. There are already WebUIs^? allowing browser access to email servers. People will probably not want to synchronize a lot of mail via Cosmo in the short-term (2 years) so email data won't be directly available to Scooby via Cosmo. Emails that appear in shared/cosmo directories can be viewed but not handled as email (no reply, no send or receive)

• no support for devices with high limitations in view screen or bandwidth (Palm devices, Win/CE or phones, blackberries). These devices can use WebDAV to get data directly from Cosmo using local programs, or somebody else (or volunteers) can work on limited WebUIs^?.

• no instant notifications of meetings. Support for RSS, email or IM notifications of events is not required.

• no alarms, as there isn't an easy way to send the alarm to the user. Scooby will attempt to preserve alarm information in calendar events where possible -- e.g. modify existing events stored in Cosmo without overwriting the alarm information.

• no Trash or Undo -- when an event/task/other is deleted, it's gone.

• no cross-site search within event text as would be required if we were doing something like EVDB. We will limit search to finding calendars, by searching the calendar name and possibly other limited metadata.

• No features specialized for public event calendars (we aren't intending to build something like upcoming.org or EVDB).

• No portal integration required in this timeframe.

• No branding configuration work. People running their own instance of Scooby can customize the branding manually.

• No work to support hosting multiple sites within one instance of Scooby.

• No work to support client certs in this timeframe.

Technology

To achieve a higher level of responsiveness, Scooby will use the asynchronous JavaScript and XML back-end data requests that comprise the AJAX architecture.

We expect there will be some cases where Scooby will need to write custom Web widgets or controls, in order to provide the high level of usability to correspond to Chandler's standards. These controls will be developed in JavaScript, hosted by a Scooby server and downloaded as modules that can be used on more than one page.

We use HTTP URLs for two distinct things: for Cosmo resources which are purely data, and for Scooby views which present data together with presentation and client code (and peripherally, Scooby support resources such as stylesheets and scripts). We will sometimes transmit Cosmo URLs (e.g. to Chandler clients, to use for synchronization) and sometimes Scooby URLs (e.g. for non-Chandler users to go to the Scooby WebUI^? to view the specified data).

Support Firefox 1.0 (Mac/Win/Lin), Safari 1.3, Internet Explorer 5.2 (Mac and Win)

Sequencing

As a rough plan, we sequence the framework, page and widget development into three phases over 2 years. The phases should correspond to three minor releases although we would like release even more frequently (subdividing the phases).

Phase 1: Basic Calendar Access, minimal sharing

Strictly Calendar functionality

• Day, week and month views of calendar data, navigation in time
• Create new events, edit and delete events
• Handle recurrence
• Handle user's current timezone (preference) and events with other timezones
• iCalendar import and export, into user's own calendar
• Mini calendar control
• Event date/time select control

Other

• Display a rough view of non-calendar data in a user's account
• Rough overall navigation within and between accounts, toolbar and select views
• Ability to bookmark somebody else's shared collection or calendar.
• Share whole collection of data with simple ticket access and email invitation
• Choice to issue either read-only or read-write tickets
• Sharing termination (revoke ticket)
• What to do about stamped items?
• What to do about items which link to other items (e.g. task link to event)?
• Preferences (timezone, views, change password)

Phase 2: Scheduling and group Calendars

Calendar features

• Support for delegation on entire calendar -- choose another user identity to grant them the ability

to read/write calendar (without using tickets) and also allows the delegate to grant tickets.

• Support for delegate to invite people "on behalf of" calendar owner.
• Support for granting read or read/write privilege to named users on entire calendar.
• Support an area of group and resource calendars, outside of the user account area.
• Support for changing the owner of a group or resource calendar.
• More powerful navigation so that users can find resource and group calendars
• View free busy -- more than one other user?
• View multiple calendars?
• Send scheduling invitations to other users on same server
• Send scheduling invitations (iMIP) to external addresses
• Move event between calendars?
• Include hCalendar scrapable data in event detail and summaries

Other

• General move/copy/delete resource
• Ability to create a new calendar or new general sharing collection
• Handle conflicting changes (ETag changes while resource being edited)
• Handle event (and task, and contact) attachments -- add, remove, download
• Storage quota limitations on user accounts

Phase 3: Tasks, contacts, other

• Search to find somebody's shares or calendars without navigating
• Specialized task views
• Some functionality to assign tasks to others, accept tasks from others?
• Specialized contacts views
• Paging through large collection contents
• Searching public calendars, searching a private calendar
• Searching tasks and contacts
• VCard import/export
• Use contact email address for name completion in invitations

Major issues

We really don't yet know how to translate a full PIM dashboard to a Scooby environment. There are a number of challenges:

• Will the user want to upload their dashboard items (and potential dashboard items like ticklers) to the server? Will they have the quota?
• How will a dashboard work without email send/receive functionality?

• How will a user view calendars shared to them? By navigating manually each time? By saving bookmarks to calendars they want to see frequently? Or will we have overlays, and if so, which phase? I assume that we don't support navigating to (or bookmarks to, or overlays of) calendars on other servers in the timeframe covered by this plan.

• Java Portlet API: need to re-evaluate how widely deployed this is to consider whether to do any portlet integration in this time frame.