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.
- The Resources Viewer mockups have another idea
- there are a lot of buttons on the resources tool now, a lot of wasted real estate, and this is a strong argument for rethinking how actions are happening.
- three issues: screen real estate of extra fields, how to handle actions on resources, and bringing it new information.
4) Process for working out those interface changes (Kristol)
- what's done at IU - more UI design based on functionality requirements than usability studies - then Jim takes it and runs with it
- Kristol and Harriet might pair very well, since Harriet's focus seems to precede UI design
- practical constraints - design needs to be done early Feb., code freeze is March 15, so we basically have a month
- what's the scope of Kristol's work for January? changes to how hierarchy is handled
- how can we move ahead to a point where Kristol can have some mockups?
- some suggestions that came out of the UI camp? we can just ask the dg-ui group again
- we do need to deal with the question of actions for 2.4 - the number of extra buttons would just be too large
- we can't keep changing the resources UI with each release, that shakes things up for users and user support too much
- maybe just some minimal changes for now, and target 2.5 for all of them.
- Need to have a coherent design a few months ahead of Sept. 15
- this is around the time of the Amsterdam conference, and we could use the conference as a place to come to some closure on design decisions for 2.5.
- another meeting mid-January.