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.
- 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
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
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:
- 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.
- 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.