View this PageEdit this Page (locked)Attachments to this PageHistory of this PageHomeRecent ChangesSearch the SwikiHelp Guide
Hotspots: Admin Pages | Turn-in Site |
Current Links: Cases Final Project Summer 2007

CA3

UI Evaluation (2 points)

For each of the three UI evaluation techniques used in M5 (heuristic evaluation, cognitive walkthrough, and think aloud protocol), answer the following questions: What is the objective of the technique (for what usability reason is it best used)? What inputs are needed to execute the technique? How is it conducted?

Heuristic Evaluation
Objective:
The technique is about carefully analyzing a user interface in terms of a set of heuristics or rules, often using
small number of evaluators. The objective of heuristic evaluation is to find the usability problems in the design so
that they can be attended to as part of an iterative design process. Among the most important heuristics are Nielsen
heuristics, which are:
  1. Visibility of system status
  2. Match between system and the real world
  3. User control and freedom
  4. Consistency and standards
  5. Error prevention
  6. Recognition rather than recall
  7. Flexibility and efficiency of use Accelerators
  8. Aesthetic and minimalist design
  9. Help users recognize, diagnose, and recover from errors
  10. Help and documentation

Inputs:
Evaluation team of 3-5 people who are familiar with the method.
Evaluators need to get familiarized with domain of their evaluation (i.e. the software they are going to evaluate).

How:
Evaluators review interface individually and report problems to coordinator. Coordinator combines problems and removes
duplicates. Evaluators review combined list individually and assign severity ratings. Coordinator averages ratings and
ranks problems by severity.


Cognitive Walkthrough
Objective:
The goal of this technique is to figure out if the systems makes sense to the user. Cognitive walkthrough involves one
or a group of evaluators inspecting a user interface by going through a set of tasks and evaluate its understandability
and ease of learning.

Inputs:
Description of the prototype of the system.
Description of the task the user is to perform on the system.
Complete, written list of the actions needed to complete the task with the given prototype.
An indication of who the users are and what kind of experience and knowledge the evaluators can assume about them.


How:
Based on a user's goals, a group of evaluators steps through tasks, evaluating at each step how difficult it is for
the user to identify and operate the interface element most relevant to their current sub goal and how clearly the
system provides feedback to that action.

Think Aloud Protocol
Objective:
This techniques is a way of getting users to tell you what they think while they test a software by performing some
tasks. The Think Aloud method is specifically good for flushing out a user's mental model which gives the researcher a
window into the user's thought process when they use the system.


Inputs:
A scenario of tasks to be completed. It is helpful to have an audio and/or video recording of the session to review
details of the session during the analysis period.

How:
Participants are to think aloud as they are performing a set of specified tasks. Users are asked to say whatever they
are looking at, thinking, doing, and feeling, as they go about their task. This enables observers to see first-hand the
process of task completion. Observers at such a test are asked to objectively take notes of everything that users say,
without attempting to interpret their actions and words.

Virtual Machines (1 point)

What is bytecode and why is it useful? Give an example of Smalltalk code and its translation into bytecode.

Bytecodes are instructions of a virtual machine. A byte-code program is interpreted by a VM. The advantage of this
technique compared with outputting machine code for some particular processor is that the same byte-code can be executed
on any processor on which the byte-code interpreter runs.

Example:
Smalltalk code to calculate NOT gate output-
| value |
value := (inputs at: 1) value.
value := value not.
output emitSignal: value

Bytecode-
13 <05> pushRcvr: 5
14 <76> pushConstant: 1
15 <C0> send: at:
16 <C9> send: value
17 <68> popIntoTemp: 0
18 <10> pushTemp: 0
19 <D0> send: not
20 <68> popIntoTemp: 0
21 <06> pushRcvr: 6
22 <10> pushTemp: 0
23 <E1> send: emitSignal:
24 <87> pop
25 <78> returnSelf


Link to this Page