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