CS 589: Human-Computer Interaction: Spring 2004
Assignment Details
- A1: See schedule for requirements. The key is to be organized -- make a list for each of parts b-d, so that you can be sure you are not forgetting anything important. Presentation will be oral (only). I'll call upon some team to be part b, others to do part c, etc. (You don't know in advance which part you'll need to present.) Each team will get 10 minutes for the part you have to present.
- A2: As mentioned on the schedule, this will give you experience using scenarios, use cases, essential use cases, and task analyses as a way to get a handle on user requirements.
Using your "patient" project, pick tiny enough portions of the project such that you can use each technique once, well. Your goal is to do a great job on the tiny portion you pick. That is, depth and quality matter, breadth does not. To succeed, you'll need to be able to understand some stakeholder (who should be one of the users) well, and do 1 scenario, 1 use case, 1 essential use case, and task analysis of 1 task they might perform.
Looking ahead to A3, you'll need to continue this work for the other classes of users, tasks, etc., that are within the scope of what you want to tackle in your team's project this term.
Note that I've moved the deadline to Monday 4/12.
What to turn in: Each item should say which individuals did which parts. This will tell me how to assign individual grades. The overall team grade will come from the sum total of the package.
- A3: (Similar in overall idea to the assignment on p. 234): Finish the requirements specification for the part of your project you intend to consider "within your scope". You're responsible only for:
- Users (not other stakeholders)
- Usability requirements (not other types of requirements)
You'll use Volare's "requirement shell" (from Figure 7.5 in your book) to
deliver the requirements to me. The way you figure them out will be by continuing with scenarios, use cases, etc., from assignment A2.
- Detailed instructions for preparing usability requirements.
- What to turn in: the requirements shell, and any documents it refers to (use cases, etc.).
- Also turn in a cover sheet, that tells me which pieces were done by whom. The "whom" will be used to compute individual grades. The entire package will be used to compute team grades, which spread in a low-weighted way across the team's members.
A4: The attention investment assignment. Start with a "present" (not futuristic) use case involving your 'patient' project. (This can be one you've already done, if you have one suitable for this assignment; otherwise prepare a new one for this assignment.) At each stage where the user has some kind of possible choice, analyze the possible perceptions of cost, risk, payoff, investment. If it is necessary for this analysis to be valuable, you may also consider rewards that are external to the model (ie, that don't involve "attention units"), but be sure you differentiate them from payoff. If the attention investment analysis you're doing reveals problems in the interface, point them out.
What to turn in: Turn in the use case as well as the detailed attention investment analysis. As always, I need to know who did what.
Also, tell us in class (@ 10 min./team) what you found out.
A5: Do a cognitive walkthrough OR representation benchmark analysis of part of your project. (Do one or the other but not both). Pick some aspect of hte project you haven't yet analyzed that thoroughly, if possible, so that your coverage of the whole system (looking ahead to the final project) expands with this project.
- Cognitive walkthroughs are good for analyzing the unfamiliar user's ability to learn and deal with the low-level details. For a cognitive walkthrough, you will need to restrict your view to some small slice. Aim for turning in about 1 "step 1", and about 3 or so "step 2/3" pairs. I've put some forms and a summary paper up on the web page.
- Representation benchmarks are higher-level than cognitive walkthroughs, aiming more at problem-solving needs than mastery of low-level details. They're intended for (1) static representation, especially that needed to support (2) problem-solving. For representation benchmarks, you will still need to restrict your view, but not as tightly as for cognitive walkthroughs. Pick a situation of some kind. Aim to turn in say about 3 or so pages.
A6: As a team, your job is to create a questionnaire that will help obtain data relevant to the research question presented by Laura in class. To do this, you'll need to work in your teams to:
- Create a questionnaire (written). Length is up to you -- the goal is to learn as much useful to the research question as possible.
- Explain the attributes of the questionnaire that influenced its design. For example, talk about the number of questions you decided on, wording you chose, and anything else that influenced the way the questions came out.
- Ask at least 2 males and 2 females of the target population (end-user problem solvers, not CS people) to fill out the questionnaire. If the questionnaire is designed to be used after the person has performed some particular computer task, just ask them to pretend they performed it.
- If you learned anything about the design of your questionnaire from step (3), say what. (You are allowed to change the questionnaire accordingly if desired.)
- Also, if you learned anything relevant to Laura's research question from step (3), please point it out.
- Turn in these items in writing. As usual, say who did what.
A7: Use goa-oriented design to correct 1 problem you ve found in your patient project. Due Wednesdap. Show the old interface (the part you've selected for this assignment), the new improved version. Explain where it came from by showing the Goals, hierarchy of subgoals/unit tasks, and finally the artifacts. As part of your use of this method, also include an abbreviated cognitive walkthrough. (Team, written + oral presentation).
Margaret M. Burnett, burnett@cs.orst.edu
Date of last update: May 12, 2004