December 15, 2006

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.