- In Progress - Create list of usabilty usability accessibility heuristics - use draft list to get started. In the spirit of agile, we'll refactor the list as we learn from the experience of combining the usability and accesibiliy heuristics and the cognitive walkthrough methods
- Agree on evaluation reporting format
Within the "application" teams:
- Agree on specifics of protocol and test-bed for the application under evaluation
- Agree on user profiles
- Define scenarios for cognitive walkthroughs
- Define priority settings for reporting out (evaluators will go away do their evaluation and come back together to synthesize the results)
- The coordinator arranges an initial team meeting, using the Breeze meeting room or other convenient venue.
- The team members identify their areas of experience, expertise, and interest in:
- Accessibility - cognitive, visual, etc
- Cognitive walkthroughs
- The team discusses the protocol (See Clayton's outline)
- What usability heuristics do the members find most suitable?
- What accessibility measures/tools are to be used?
- What user profiles are to be assumed?
- What cognitive walkthrough scenarios are to be attempted?
- What refinements are required in the protocol?
- The team assesses coverage. What areas are covered, and with how much (desirable) redundancy? What areas aren't covered? Each inspection should be done by more than one evaluator – ideally by as many as possible.
- Team member partnerships are arranged where possible to address usability and accessibility synchronously. Team leads are assigned in areas of expertise.
- The team discusses the logistics of actual inspection activities:
- What are the problems with geographically distributed teams?
- Can the Breeze facility help to overcome the problems?
- The team discusses reporting: (see Proposed Template)
- Does the proposed template meet the team's needs?
- Are refinements to the template required?
- What additional information will be reported?
- How can results be aggregated with those from other teams (consistency, style, references to heuristic principles, etc.)
- Individual evaluations are performed by 3 - 5 evaluators. (The 3 - 5 number is not an absolute requirement – only good practice, and strongly encouraged. An evaluation can be done by a single person if only one is available.)
- Findings are recorded.
The following steps may be done in several iterations, with ongoing communication of early draughts across the groups.
Some findings will drive component development, others can be used for general product development within the communities.
- Sakai - Integrate into requirements group. Do we need to create jira tickets? Are these really "design bugs" conceptually and thus have a different status than requirements?
- Moodle - how does this get fed back into the process?
- uPortal - how do we integrate into their requirements process? Deliver findings to the community?