Agenda:
1) Overview of long-range usability study (Harriet)
- brief roadmap?
- thinking behind it: create a tool within resources that supports tasks at Cambridge U. people do a whole variety of unanticipated things with Sakai, so our own ideas won't suffice. The first thing is to find out what people really want to do with Sakai. Go out to a bunch of universities, with surveys and user observation, see what they're doing with other, legacy systems. Then draw up a list of tasks that we'd like Resources to meet.
- the "roadmap" is an initial description of how this process might take place. List is up to seven stages right now.
- we hope that it will be something the whole Sakai community could get involved with.
- long-term, over the next year
- there is a study on how research groups use Sakai - they have a lot of rich data, log files, video diaries, and they have kindly agreed to allow us to use that.
2) Support for versioning or history in 2.4/2.5 (Pramod)
- quality control team at Michigan
- trying to get an end-user's perspective on versioning
- straightforward product development process
- research on how versioning is done in other systems
- next step, bring out requirements based on this research
- submit those to the community
- then develop some mockups for usability testing
- this work could be complicated by other work on how Sakai handles content (e.g. content handlers, JSR-170 repos)
- would you like to have international usability testing? Schools in the UK would be interested.
- initial requirements could go out in mid-January, but Mich might like some initial technical review of feasibility beforehand
- start with Resources group and the people who have commented on versioning in Confluence to get initial feedback
3) Resource Type Registry and interface changes needed to support it (Jim)
- the idea is that when you create a new resource you're dealing with both content and metadata
- Jim is going to advocate that we go back to revising content and metadata separately
- that may mean that there are more actions per resource type - need to deal with these changes without overwhelming users (design problem)
- there is a page in Confluence about list views; shows interfaces for things like filesystems; one way to simplify things is not to show too much of the hierarchy http://bugs.sakaiproject.org/confluence/display/RES/List+View
- can do something for 2.4, but need to do it quickly.
4) Process for working out those interface changes (Kristol)