[Design] Re: [Scooby] Historical look at Scooby project and goals

[Mimi Yin]

Out of this write-up, it seems there are 4 sets of use cases or 4  
different "problems to solve". (This does *not* mean that these are  
the only 4 options for Scooby 1.0.)

The first is a personal web-based calendar that is more usable than  
say Yahoo calendar or Hotmail calendar have been traditionally.  
Something that is in the same "market" as 30boxes, Trumba and other  
recent AJAX calendar apps.

The second is the notion of providing a web-based solution to replace  
kiosk-mode for universities. The idea is that students and staff  
running around campus can have web access to their Chandler data.

The third is a "kiosk-replacement" focused just on calendars. Here I  
wonder if "Kiosk" mode is the right characterization for a couple of  
reasons:
+ The people who tend to maintain personal calendars ie university,  
administrators, staff, etc also tend to be less mobile.
+ The people who tend to be more mobile (ie. students) are less  
likely to maintain personal calendars.

Perhaps a better characterization of a "calendar-centric" solution  
for universities might be: a web portal for shared university calendars.
+ A way to upload calendars to the web portal from a variety of  
sources. (University schedule, Departmental calendars, Class schedule  
calendars, Events calendars, Student group calendars).
+ A way to browse all of these calendars.
+  A way to suck down calendar data into a variety of destinations,  
the least of which is Chandler (ie. Sunbird eventually, Outlook,  
iCal, Oracle, Lotus Notes, a personal Scooby account).

The fourth is a standards compliant front-end that can be stuck onto  
any standards compliant server back-end. Potentially useful to a  
university using Oracle server or for Evite to stick a Scooby front- 
end onto their server back-end. What are some other some other  
scenarios.

Mimi

On Mar 3, 2006, at 5:14 PM, Lisa Dusseault wrote:

>
> 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
>
>
>
> _______________________________________________
> Scooby mailing list
> Scooby at osafoundation.org
> http://lists.osafoundation.org/cgi-bin/mailman/listinfo/scooby