Cambridge Get-Together

Added by Clay Fenlason, last edited by Nicolaas Matthijs on Apr 21, 2008  (view change)

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.

Labels

meetings meetings Delete
Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.

Comments (6)

 

  1. Mar 19, 2008

    Daphne Ogle says:

    Sounds like it was a productive week! This all looks good. A couple comments/que...

    Sounds like it was a productive week! This all looks good. A couple comments/questions:

    • A very strong mental model for our users is their file manager on their computers. Innovation is great and needed toward the more flexible organization structure shown here. However, I think we also need to to provide users with a folder view (particularly older faculty that have less experience with new models). The positive comments we've gotten (current Fluid CIs & preview research I've been involved in) from faculty, GSIs & students about resources are around the folders. It feels like we should offer some scaffolding for users to jump to this new model.
    • Is the idea that this view would be available from anywhere in Sakai? I've been thinking about a link (or icon or button or whatever) being available persistently. When the user opens, it could open on top of their current context/working space so they don't need to jump out of the work they were doing. And then allowing them to drag and drop files from the file manager into whatever presentation/tool they are in would alleviate a workflow for adding files to pages (if they are already in their file manager).
    • Has there been thinking about keeping the resources tool in a different form? As we know (and confirmed through research) it is one of the most used tools. What we've learned is that people like having all their files for a site in one place. If organized well, by topic or week for instance, students really like the simplicity and they it's obvious where to go for any course content. For those instructors that just want to make content more available the presentation of resources works well. I'd like to see us re-envision resources as a stripped down, simple, content presenter.

    1. Mar 21, 2008

      Clay Fenlason says:

      With John's caveat below aside, there was some unfledged discussion on a few of ...

      With John's caveat below aside, there was some unfledged discussion on a few of these topics:

      • The file manager on the desktop may be a strong mental model, but I think there is an argument that the mental model is shallower and less entrenched than the full structure desktop file managers exhibit. Does the average user have folder structures deeper than two or three layers, and if not, is a complete file-folder hierarchy really the design that gets at the mental model?
      • I think the idea was that this would be available from anywhere, yes, as a kind of "helper," and not a standalone tool that would appear in the lefthand navigation of a particular site.

  2. Mar 20, 2008

    John Norman says:

    Just to repeat what was said in the main body. This was not an attempt to create...

    Just to repeat what was said in the main body. This was not an attempt to create the next resources tool. That should come from work with users, this is the result of some brainstorming among a group of mainly developers. I think the idea was that this view could be accessed from anywhere. Think of it as a concept car that may never go into production.

  3. Mar 20, 2008

    Mara Hancock says:

    I like the goal of more rapid development and the focus on designer friendly tec...

    I like the goal of more rapid development and the focus on designer friendly technologies. Hope you all keep up the experimentation.

    1. Mar 21, 2008

      Clay Fenlason says:

      We at Georgia Tech are trying to extend the lessons learned to the assignments2 ...

      We at Georgia Tech are trying to extend the lessons learned to the assignments2 work. Many of the pain points in the assignments tool hinge upon a clear presentation of submission status and workflow metadata (e.g. when something was submitted, who graded it and when, what's waiting to be done, what the due date is, etc.), so it seems another good test case with a dashboard-view type of approach: the UX issues really can be tackled client-side, with simple lists of data coming from the service layer.

      We are therefore effectively going to try to use these sorts of rapid UI iterations, combined with regular user testing, to allow design approaches to catch up to the rest of the project. Not a replacement for having greater design attention at the outset, of course, but perhaps a credible coping mechanism in present circumstances. So yes, another experiment

  4. Mar 24, 2008

    Nathan Pearson says:

    This looks really promising guys! I'm excited with what you've been able to put ...

    This looks really promising guys! I'm excited with what you've been able to put out in a just a few days. I'd love to take this methodology out for a spin in a real UX project.