Report of the Cambridge Get-Together

The Cambridge Get-Together (March 08) was a small gathering of developers and others from Cambridge, Michigan, Georgia Tech and Toronto, who met for 4 days in Cambridge. Although the people invited were those active in the Resources working group, the objective was not to create the next Resources tool, but to evaluate a possible new approach to its creation.

Attendees Attendees included: Erin Yu (U of Toronto) Jim Eng (UMich) Stuart Freeman (Georgia Tech) Carl Hall (Georgia Tech) Clay Fenlason (Georgia Tech) Nicolaas Matthijs (CARET) Nick Desmet (CARET) Ian Boston (CARET) John Norman (CARET) Harriet Truscott (CARET) ... and other stalwart folks at CARET

So, one aim of the Cambridge Get-Together was to see whether it would be practical in future to develop some Sakai tools using primarily JSON, Javascript and HTML. Another aim was to tie this in to the work that Ian Boston has been doing on implementing JCR-170 for Sakai. The hope was that by the end of the week we would have developed a proof of concept, and have a clearer idea of whether this development methodology might be used in the future for Sakai. A consideration in investigating this approach was a desire to expand the community of contributors and make Sakai development accessible to a wider skillbase. In particular, we hope to enable people with Javascript and HTML skills to develop tools with the support of Java developers developing services. During the Get-Together, we had 1 person working on the Java code, 1 UI designer, a quarrelsome stakeholder, 1 HTML / CSS designer, and 4 Javascript / JSON developers.

With only a few days it would have been difficult to produce a tool that not only worked but that was also a genuine improvement in terms of UI and functionality! We were very pleased by the results as a proof of concept, and thanks to Erin's work it also looked very good, but this work could not and should not be seen as a replacement for the Resources tool, the Resources Viewer or the Image Gallery.

By the end of 3 days of development, we had a proof of concept "file manager", with the following functionality

• upload multiple files simultaneously into a JCR-170 content repository
• display two different views of the contents of a Sakai site
• create 'Collections' (or categories for grouping content)
• assign files to collections

Lessons Learned

We were pleasantly surprised by how much we had managed to get done in the time available (though there were a large number of people working simultaneously). This was particularly pleasing given that at least one developer had never worked with Javascript before.

The distribution of labor was also significant in how it differed from typical Sakai development. Out of six working developers, only one (Ian) was working in Java, on the service side. All the other developers were working on HTML, CSS or Javascript.

For further insight into what goes into this sort of development, see the "How To" pages of the MySakai contrib space.

This approach, in effect, introduces a tidier separation of concerns between the service developer and the front-end developer, allowing a great deal of user-centered work to be accomplished without requiring Java mastery (or Maven or Tomcat, for that matter). The development cycles could also largely avoid rebuilding and Tomcat restarts, which greatly improved productivity. The promise, then, is a further lowering of the bar for Sakai development and expanding our community development capacity.

There is additional promise for performance improvements (esp interface responsiveness) as the UI logic is off-loaded onto the client and server round-trips are minimized with client-side caching.

This approach also introduces a different perspective on Sakai services, tending toward a more purely SOA, where the services are focused on simply providing data.

A key value of this approach is for rapid UI prototyping and development cycles. Thus, even if the final deliverable must eventually use a different framework, this approach might be worth considering during the design and user testing stages. It is at the very least significant as a strategy for leveraging the greatest amount of community resource for improving the user experience of Sakai.

That all said, it was noted that there were issues to be wary of:

• Doing more development in Javascript on the Client side provides some freedom, but also more opportunities for spaghetti code, browser incompatibilities, maintenance problems, and an attendant testing burden. This situation is only partially ameliorated by mature libraries such as jQuery.
• Business logic on the client side is generally to be avoided, and this also requires additional developer discipline. Likewise, care must be taken not to introduce security problems. This approach may be utterly inappropriate in many cases, e.g. high stakes assessment tools.
• It's worth noting that for the proof of concept we neglected some aspects of accessibility. If people were working on a genuine Sakai tool it would be important that the HTML and Javascript developers had a reasonable knowledge of accessibility. Given the success of the meeting, we are engaging further with Fluid to ensure we write accessible code from the start.
• We didn't get around to talking to real users or looking at usage data, which would have really helped us make informed design decisions and minimized time spent discussing what users might or might not need. Although rapidly developing user prototypes reduces the cost of one-design "waterfalls," we're left to wonder what the right balance would be between doing user research before development and user testing after development.