Sakai 2.6 and 3.0: Statement of Ambition

This document describes emerging goals and plans for two major releases of Sakai, based upon express readiness and interest of several institutions with resources to carry them out over the next year. These discussions grew out of a meeting in St. Paul MN (after the JA-Sig Conference) where a group of folks got together to discuss shared priorities and the desire to look further down the road at Sakai's future. The conversation has continued over the past few months and an encouraging amount of common grown has formed.

Status of this document:  This document is not yet a roadmap for Sakai. It is a statement of the desires ambitions of certain institutions who have some of the resources needed to execute it. To be a real roadmap there needs to be additional feedback from the community, additional detail on the plan and additional resource commitments. So, please take a look and let us know what it would take for your organization to participate in the process of making some version of this a reality.

Opportunity

Everyone is familiar with many issues in the Sakai product, from dissatisfaction with aspects of the user experience to concerns about the size and complexity of the current code base. Many of those who know Sakai best believe that this is the opportune time to make significant changes to the Sakai design and technical architecture. Not only have new technologies emerged that allow us to design and build software in different ways, user expectations have changed with the emergence of Web 2.0 technology and the "social" web. We need to take advantage of these technologies and respond to these shifting expectations quickly.

For those of us who are interested in the broader adoption of Sakai this is an especially important time. Continued questions about the commercial offerings have led many organizations around the world to look elsewhere. The current Sakai, while sufficiently capable of replacing an existing instance of WebCT or Blackboard, is not significantly different from the commercial products to provide a real advantage as a product.

Even among adopting schools there is a risk of disaffection if we continue to merely refine the old model of the institutional LMS.  Sakai (and every other LMS) duplicates generic web functionality in certain domains (e.g. discussion boards, file managers), but often with extra quirks or design departures which do not compare favorably with more "open" and powerful apps freely available from Google, Facebook, etc.  It's time to arrive at a clearer understanding of the capabilities that higher ed is uniquely positioned to supply - goals and tasks which the Googles and Facebooks, et al, will never satisfy - and for the Sakai community to focus its development effort on these capabilities while achieving a better equilibrium with regard to the broader SaaS world.

That said, there are many schools with significant resources committed to "classic" Sakai who need incremental improvements to their versions while they develop plans for moving their users bases to a significantly different Sakai. Many of these schools would not be able to move to such a significantly different version until the 2010 academic year. We can't ask them to stick with 2.5 until that time.

The approach is to simultaneously start Sakai 3.0 while continuing incremental development on 2.6. Because there is some leverage across these efforts, this isn't double the work. But it does require more resources and much more coordination across the community. So we need more organizations to jump in and help.

Goals

What are we trying to achieve with the parallel development of 2.6 and 3.0?

Driving toward market leadership at a pace which accommodates two different camps of need in the Sakai community. We believe there is a significant set of production schools that wish to continue the 2.X code for a longer period than others, even ignoring the greater implementation risk associated with the larger 3.0 work.

The 2.X work will be incremental.  It will introduce improvements to the user experience, although these improvements can be described as improvements that preserve the current metaphors (tools placed on pages within sites) and workflows within Sakai.  The current path towards 2.6 will be maintained. There may also be a 2.7 and a 2.8.  These would be additions of important improvements in focused sections of Sakai (e.g. a new gradebook interface) rather than a release that contained changes across the Sakai code base.

The 3.X work will be a significantly different Sakai both in terms of technology and user experience metaphor.

What are we trying to achieve with the proposed kernel work?

To address the fundamental quality and scalability goals for Sakai.
To significantly reduce the amount code that the Sakai community is obliged to support and maintain.
To increase the productivity of Sakai developers.
To introduce new capabilities to Sakai (e.g. multitenancy).

What are we trying to achieve with the envisaged UX changes?

To orient the user experience more clearly around the individual than the institution.
To better meet user expectations derived from Web 2.0 while providing a more consistent and coherent experience across Sakai functionality.
To apply lessons learned from other web successes (e.g. social networking) to novel solutions for academic contexts.
To orient application behavior around user goals and tasks rather than logically discrete blocks of functionality (i.e. tools).

Sakai 2.6

Projects (for which there are already some express resources, though not final commitments)

Kernel 1

• Repackage a subset of the exiting core code into to a single central package that will improve the speed of development towards the 2.6 release of Sakai (K1 API, K1 Implementation). (CARET - Ian and others)
• Gather requirements and document design for a significant comparative performance,  predictive scalability and quality testing component that will enable automated acceptance testing within stakeholder organizations. (K1 Test Requirements Document) (Who will do this?)
•  Implement and deliver a testing framework driven from the above requirements with the intention of supporting the creation of the tests themselves and the running of those test. (K1 Test Harness) (UCB and UCD - Ray Davis and Jon Gorrono)
•   Implement and deliver a suite of tests that address the need of the K1 Test Requirements Document. (K1 Test Suite) (UCB and UCD?)

User interface improvements. Widget-based rewrites of a few important sections of sakai based on UX designs from Nathan

1. My workspace/preferences (bring together with Cambridge work) (CARET - Nico and others)
2. Site home page (ditto) (Who will do this?)
3. Other UX improvements from Nathan's work (Who will do this?)
4. See Implementation Summary for scoping and additional detail

        All of these changes should strive to be compatible with 3.0
        Note that rewritten tools are optional. You can run a legacy tool in the new portal (in an iframe)

Gradebook - recommend getting service level API changes for new GB into 2.6, with UX changes coming later.

Site Archive/Delete/Import/Export
-- (UMich and Indiana [tentative])
-- See requirements here

Site Info helpers (UMich  [tentative])
-- Site Info refactoring into helpers and group improvements.
-- Possibly necessary for some of the UX work

Desirable Features (for which there are not yet resource commitments)

Reduced version of "Edit in Place" functionality, as simple Content Authoring tool
-- try to bring together authoring work in a single tool compatible with look and feel above
-- could be a post 2.6 item

File Manager (based on Cambridge work)
-- may need to add functionality to replace existing resources tool. Perhaps simply delivered as contrib

Site Hierarchy Service

Automated & Performance testing around the generic Sakai release.

Forums User Interface Improvements
-- Gonzalo has produced UI HTML, unclear if that will go further in this timeframe

Feed Tool
-- Based on Indiana's preliminary work

Release Target

Ready for early production in December 2008  (UCT will lead the way using a Release Candidate, as with 2.5.x) and general availability in March/April.

Sakai 3.0

Projects (for which there is already some degree of resource commitment)

Kernel 2 (K2 team still being formed, but notable lacks include project management and technical writing)

• Gather and document the requirements of the community stakeholders, the importance of those requirements to be balanced by the impact on the adoption of Sakai.  (K2 Requirements Document) 
• Progress the community to agree on a deliverable set of requirements, within available resources and to an agreed time-scale. (Scope-Resources-Time balance) 
• Deliver a design document to the community that details the design of the new kernel. (K2 Design Document) 
• Perform and report on a feasibility study of key kernel components and technologies with collaboration from critical stake-holders identified from the requirements process within the community. (K2 Feasibility Study) 
• With resources donated donated from stakeholders within the community implement the design as agreed by the community. (K2 API, K2 Implementation) 
• Implement a compatibility layer using K1 code, to enable K1 based tools to operate with the K2 kernel. (K2 Compatibility Layer) 
• Implement a full suite of unit and integration tests during the development of the kernel to ensure greater than 80% code coverage within the kernel, and report on that code coverage (K2 Code Coverage Report) 
• Produce a technical user manual for the new kernel. (K2 Technical User Manual) 
• Apply the K1 Test Suite to the K2 Kernel with Compatibility layer. (K2 Compatibility Report)

User Experience Redesign

Significant implementation of "edit in place"
 -- See "Google Sites" for a first glimpse at what this could mean:  diverse, integrated functionality treated together as a page composition problem rather than tool silos. That said, it should be acknowledged that Sakai will still comprise a suite of applications of varying levels complexity. For example, while it is possible to simplify, decompose and expose pieces of a gradebook or quizzing tool, they perforce will remain complex, internally coherent applications at the UI layer.
 -- need requirements fleshed out.
  -- will need to be led by significant design effort, presumably from Nathan
 

Introduce some preliminary social networking concepts*.*
    -- More robust profile tool, oriented around faculty goals
    -- An activity feed
    -- Prototype referral mechanism (e.g. people who share your research interests, or who have read the books you're reading)
    -- will need to be led by significant design effort, presumably from Nathan

Functional parity with the 2.6 core tool set
    -- A preponderence of Sakai's core functionality should move to the flat portal model. This will require re-writing, disaggregating and/or removing applications that rely on iframes. Current contrib/provisional applications/functionality have not been considered.
   -- Note that the notion of "tools" may disappear in 3.0, so this should be viewed as a list of capabilities we need to make sure are available.
    -- The 2.5.x set of tools w/ institutions currently committing code and tentatively planned 3.0 work:

Desirable Features (no resource commitment)

Design for mobile devices.

Offline Sakai working through "major" tools (that aren't inherently online like chat).
-- an example of how to bring an R&D project into the mainstream and avoid orphaning as we move from 2.X to 3.x

Release Target

Ready for production/pilot in June/July 2009. Most schools will stick with 2.6 for the 2009-2010 school year (Northern Hemisphere).  (Cambridge and Georgia Tech will aim to put this in production in July 2009)