Sakai 3
Contributing Institutions: |
Those who are directly contributing funding, FTEs, or both: Cambridge, Georgia Tech, CSU, IU, UC Berkeley, HEC Montreal, Sakai Foundation, NYU |
|---|---|
Project Links: |
|
What the project aims to accomplish and who should benefit from it - explained in clear, simple language.
Sakai 3 is a design-led rewrite of Sakai from the ground up. Its aim is coherence and simplicity for a yet more flexible and powerful user experience, but its benefits will extend to technical matters like performance and maintainability of the codebase as well.
It will deliver:
a) a new kernel (K2) based on the Apache Sling project, minimizing Sakai-specific code
b) a new front-end which communicates with the kernel via REST-like services, using jQuery with enhancements from Fluid for accessibility
c) a holistic design for Sakai, including a style guide for ensuring ongoing coherence
Which institutions and individuals are committed to it, for how long, and in what roles.
Cambridge has been leading its development on the front and back-ends since Q3 2008. Georgia Tech has played a supporting role in that development for just as long. In Q3 2009 IU seconded a senior developer (Lance Speelmon) to the Sakai Foundation to focus on migration issues for K2. CSU and HEC Montreal joined in contributing funding to a second design phase in Q4 2009 and will bring additional development resource to bear in Q2 2010. UC Berkeley is devoting staff time to the front-end development, including user research and testing, along with assisting in the development of K2's support for group management use cases.
What other components or projects, if any, does this project relate to or depend upon?
Every effort is made to use quality third-party code wherever practical, with due consideration of the community we'd be relying on as well as the code. The strongest dependency is on Apache Sling, which in turn depends on Apache Jackrabbit and Apache Felix. On the front end jQuery is used with accessibility improvements from Fluid.
Links to any proof-of-concept code, wireframes, or other documentation that may exist at this point.
Wireframes, sketches and other design resources are being organized on http://www.sakaiuxframework.com
A demo instance is hosted at http://3akai.sakaiproject.org/dev
K2 documentation and tutorials can be found in the Confluence wiki: /wiki/spaces/KERNDOC/overview
What does the project know and not know about how it will achieve its aims at this point?
A first deployable milestone should be ready for QA in March 2010, and will be put into production at Cambridge and Georgia Tech in June/July. This will be relatively limited in its functionality, but it should establish the framework for what follows.
Migration is going to be a key concern, as is functional parity (with S2); we've found promising answers to some of these concerns in proofs-of-concept of "hybrid modes" which run S3 and S2 in parallel.
The contributors to S3 development work thus far are not primarily driven by a need to have a full LMS replacement (at least not right away). Among these stakeholders the opportunities most keenly felt are those outside traditional course contexts, eg. global content management, grouping and networking, workflows freed of tool and site silos.
The coordinated effort has so far failed to find a successful model for project management of distributed and cross-functional teams. Such a large undertaking really requires a tighter coordination of distributed development activity than Sakai has so far been able to achieve. This lack of coordinated project management stands as a key risk to timely delivery.
The project puts much greater reliance on client-side technologies, technologies which the Sakai community of developers has not gone as far in mastering (as compared with the coding of Java services). Despite our best attempts, and leaning on the expertise of the jQuery and Fluid communities, we will likely need time and steady effort to socialize knowledge on good practice and sound QA metrics for front-end development.
The alignment of our use cases with those assumed by the Apache Sling and Jackrabbit communities is not perfect. Although a year or more of working with Sling has not revealed any dealbreakers, there are still periodically points of friction that can force Sakai code to perform gymnastics - at least temporarily, until Sling or Jackrabbit patches are accepted - in order to cope. The benefit we gain from reliance on these other open source communities is considerable, but it still involves a measure of risk.
What public communication methods are being used, how may a curious person contribute to or track the project?
The front-end work, both technical and not, is discussed on the public sakai-ux list.
The K2 work is discussed in the public sakai-kernel google group.
Design wireframes and component prototypes are organized at http://www.sakaiuxframework.com, where they can be publicly commented on.