[Design] Historical look at Scooby project and goals

[Lisa Dusseault]

This email is an attempt to document some of the motivation for the  
vision of Scooby from a point of view of describing what decisions  
have been made historically.  It might be useful to generate content  
relating to the Scooby landing page but isn't necessarily required.   
I didn't experience all of this history but have talked to Katie and  
Chao about some of what happened before I started at OSAF.  Although  
this is an overview of why we started Scooby, it should not be taken  
as a firm limitation of our audience or ambitions.

PRE-CONCEPTION

OSAF set out to solve certain problems in managing and collaborating  
over personal information.  While I'm not trying to give the whole  
history of OSAF, it's instructive for Scooby to think about why OSAF  
was created.  Among the problems OSAF wanted to solve:
  - No existing PIM solution worked for multi-platform  
organizations.  E.g. some PIM solutions required Windows or at least  
Mac and a Linux user could not participate and collaborate the same way.
  - Silos between application areas (email, calendar and tasks) were  
"solutions" that met the needs of programmers, not users -- the  
isolation of application areas blocked users from doing important  
workflows or at very least made them slower or harder.   People used  
email as a task list.
  - Calendar sharing only worked within big enterprises.
  - The dominance of a monopoly player left room in the PIM space for  
a usability focused entrant.
  - Flexible systems like Agenda and Ecco were an inspiration for a  
modern, adaptable way of managing personal data.
  - PIM systems had not been subjected to enough usability testing  
and user-centered design to be usable enough.  Email overflow and  
schedule confusion were perhaps the price of success in collaboration  
technology, making usability worse, but if so a new approach was  
needed to address those drawbacks.
  - No existing calendar sharing solution worked well for small  
organizations without dedicated, expensive IT resources.

Initially OSAF set out to solve these problems with a rich cross- 
platform client, because no other solution seemed usable enough at  
the time.  Of course WebUIs were discussed back then, but the two  
major flaws were that Web UI functionality was not as interactive and  
usable as rich client widgetry, and that Web UIs didn't allow for  
offline use of personal information.

The next major development was the involvement of the Mellon  
Foundation and several universities from the Common Solutions Group  
(CSG), who agreed to fund OSAF based on these requirements: http:// 
www.osafoundation.org/Chandler%20for%20Higher%20Education.pdf.   
(Those requirements are now out of date because we negotiated some  
changes, such as CalDAV instead of CAP).  The most interesting  
requirement for the Scooby project was the requirement for kiosk  
access to a user's personal information.  To universities, a use case  
illustrating this requirement is that a student should be able to  
walk into a computer lab, find any unoccupied computer, and use it to  
see their new mail and answer it, check their schedule and add  
events, all quickly and easily.

While OSAF remained focused on a rich client, there was a proposal to  
solve this use case within the framework of a rich client: OSAF  
proposed that universities could install a "kiosk-mode" version of  
Chandler on computer lab machines.  A user starting up Chandler in  
kiosk mode would provide their authentication credentials for a  
server hosting their Chandler data, and then appropriate data would  
be brought down from the server quickly, in order to display and work  
with that data locally.  Once the session ended, Chandler in kiosk  
mode would automatically clean up the cached information and be ready  
for the next user.

What changed in 2004 and early 2005 was that WebUIs became much more  
responsive and rich, as illustrated by GMail and others.  We also  
realized we had to exercise more focus in Chandler work in order to  
make quicker progress to 1.0.  So we started discussing a WebUI: not  
as a replacement for Chandler, but as an adjunct, as a "kiosk mode"  
replacement.

This proposal went hand in hand with the Cosmo proposal as it firmed  
up -- an open-standards calendar and sharing server would be yet  
another piece of our overall strategy that could be developed  
entirely independently of the main Chandler code-base, using an  
existing WebDAV server as a springboard.  Having such a server like  
Cosmo available made it possible to envision a WebUI that provided  
kiosk access to data that might be mostly managed in Chandler, so  
Scooby was conceived.

POST-CONCEPTION

Now I'm just trying to document what high-level decisions seemed  
important enough to discuss with Mitch, the board, or CSG and the  
Westwood Advisory Council.  Again, these are certainly the current  
decisions but don't necessarily limit movement for the future.

Current Scooby plan is to focus mostly on calendar features.  The  
reasons for this focus apply to both Chandler and Scooby:  
universities and other organizations desperately need calendaring,  
but most already have acceptable solutions for email.  Given that we  
had Chandler 0.6 focus on calendar functionality, it seemed natural  
to ensure that Scooby would first be able to handle the same data  
that would be generated most by Chandler users.  The current calendar- 
focused plans don't forestall work on other personal information in  
Scooby in the future, it's just a matter of getting one function  
usable first (agile planning).

Scooby use cases have so far been vaguely conceived around  
universities and Chandler users.  The potential for synergy with  
Chandler is evident, because without Scooby, users don't have a  
chance of a WebUI that will look at their calendars and email in the  
same way.  Universities are an important use case, an environment we  
have a lot of access to due to our partnerships, a useful example and  
a funding source for OSAF.

In the future, I expect our use cases might well go beyond  
universities and Chandler users, and in fact we haven't yet made many  
decisions that would limit us to those target users. Many multi- 
platform organizations besides universities have the same kinds of  
problems.   A WebUI can be useful even in organizations where users  
always use their own computers and there are no kiosks, just because  
some users prefer WebUIs to installing and configuring any rich  
client.   We want Scooby to be adoptable even without Chandler,  
although naturally we see some great opportunities for synergy.  I am  
looking to Priscilla to nail down use cases to drive Scooby  
development, whether those use cases are for universities, Chandler  
users or other.

Another decision we made at this high level was that Scooby would be  
a WebUI that is also an open standards *client*.  We proposed this so  
that Scooby would have a stable interface to Cosmo (short term work  
for long term risk minimization), and so that Scooby could talk to  
other back-ends  Yes, this means that somebody might run Scooby with  
some other CalDAV server as its main data source, but that isn't the  
most interesting result -- more importantly, it allows a Scooby user  
to see a variety of calendars from different sources, not just the  
"local" CalDAV instance (which might be Cosmo in most cases) but also  
other CalDAV servers and possibly other protocols/formats as well.

NOTES ON DISTINCTIVENESS

While writing this I took some notes on what made Scooby different  
from all the other AJAX calendars. The differences that stand out to  
me, between Scooby and all other AJAX calendars are (1) Control of  
data and (2) Flexibility of pulling from many data sources.

For (1),  you can run Scooby yourself and control the system and the  
data.  While most end-users won't directly take advantage of this,  
many organizations will.  A university could run a customized and  
well-supported version of Scooby that automatically populated student  
calendars with course schedules.  That will indirectly be a great  
help to end-users.  Even users that don't run Scooby personally will  
be given access to their data for import, export, mashups, access by  
any client, etc.

For (2), Scooby is the only service I've seen that aims not be (only)  
an open standards *server* (e.g. Eventful may be a CalDAV server and  
can certainly serve ICS files over HTTP) but also an open standards  
*client*, consuming information from other server sources.  This is  
important because it will allow Scooby users to pull together  
calendar information from more than one system as long as the source  
of the information supports some format that Scooby client code  
understands.  E.g. let's say my own calendar data is hosted by OSAF,  
as is my Scooby instance.  To begin with my view of the world through  
Scooby would have only my own calendar and perhaps some OSAF  
calendars.  But I could quickly add calendars of my Mozilla  
colleagues who use Sunbird, my university colleagues who use  
Bedework, and other colleagues too.

Lisa