Last changed
16 Feb 1998 ............... Length about 1,000 words (9,000 bytes).
This is a WWW document maintained by Steve Draper, installed at http://www.psy.gla.ac.uk/~steve/HCI/exA.html.
You may copy it. How to refer to it.
(Back
up to HCI module main page)
Major exercise A: Implementing and testing an interface
IT HCI module handout 9 (S.W.Draper, disk courses 6 22 Jan. 1998)
This is a web version of the handout, plus extra text from email messages
about Hypercard.
The largest exercise, for a total of 20% of the marks, is related to a
single large project of designing, implementing, and testing a user interface.
You will hand in 2 reports, and also give me a demonstration of your system
while I give you a short interview about it. You are recommended to use either
HTML for web pages or HyperCard on the Macs. You are recommended to work in
pairs, sharing all the work except for writing the assignments to be handed in.
However you may work alone or in larger groups if you feel this is best.
You can choose to design any interface that you like; but you are recommended
to make it small in size so that you have plenty of time for testing and
improving it. Most of the marks will be given for designing testing that
matches your aims well, and drawing useful conclusions from it. For instance
if you design an information system (e.g. how to find my office), can you run
tests on people actually using that information (i.e. walking to my office)?
You will learn more from doing something small very well, than something large
that you couldn't test thoroughly. Some possible subjects are: a computer
game, a help system for another (small) application e.g. electronic mail, how
to copy and tailor a Mac system from ITlib, a guide and map of the Boyd Orr
building. If you want to construct something really interactive then you will
need either: a) to learn Hypercard (until recently all students on this course
did this easily as part of this exercise: I can provide handouts); b) use Java
fluently; c) learn how to use CGI scripts and forms in web pages. (Creating a
good tutorial on the web to teach others how to do this would be an excellent,
if rather ambitious, project.)
Hypercard is permanently mounted on the machines in the IT lab.
A handout for teaching yourself Hypercard
is available, as previously announced, in ITlib in the form of a Claris
document you can print out. In previous years, students have taught
themselves Hypercard in a few hours using these materials, and although help
has been (and usually will be) available in the tutorial slots, in fact little
demand has been evident: hence my confidence that you can do it without
handholding.
In fact even if you intend to use HTML and/or Java as the basis of your ex.A
project, you would benefit from learning Hypercard as it will be used
extensively as an example in later lectures. It is a still-rare example of a
programming environment that makes creating user interfaces very easy (low
cost to the designer).
- To experience the heart of HCI: that you can't get all the design
decisions right first time, but you can improve them quite easily with
testing.
- To design, carry out, and write up an evaluation of an interactive program.
This will be a complete exercise of the approach to evaluation taught in the
lectures.
- To detect, diagnose, remedy, and describe (write up) bugs in a user
interface.
- You will also experience doing design in a small team, although this
exercise is not designed to do more than touch on this software engineering
issue.
- You will also experience doing the design of a small user interface.
Again, though this is interesting and important, and will give you some feel
for what it is like, it is not the main focus of the exercise.
To be completed by Tues. 3rd March. You
should decide in full detail what you are trying to do, and how you will test
whether you have succeeded. For instance, it is not enough to say you are
doing a map of the Boyd Orr; you must decide what your intended users will do
with it, and how you will be able to test how well your design works at this.
You should fully implement at least a first version of the design, and perform
a few preliminary tests on it -- perhaps 4 think-aloud protocols. Hand in a
SHORT report (less than a page) which states exactly what the interface is
trying to accomplish, and what your success criterion will be, and what you
learned from the first few think-aloud tests (i.e. a few examples of changes
you now want to make). Do not describe details of the interface: I will be
able to see them when I look at the interface itself. The point of the report
is to show that you are not just muddling around, but have decided on exactly
what you are aiming for.
I will arrange with you for you each,
individually, to demonstrate your project to me near the end of term, when the
project should be complete or nearly complete. I will expect to have a short
discussion with you about the interface, the problems you found, how your
testing is designed, and what you discovered from it. The marks you get will
take into account both the written reports together with this demonstration
session. It will be more convenient for me if I see all the people sharing a
project at nearly the same time: but I do need to see EVERY student, not just
one per joint project.
You are recommended to finish it by the end of term
(Fri 20th March), but the second report will be accepted up to the
start of term 2 (20th April) if handed into my office (room S615,
Adam Smith Building) or pigeonhole. (Note that it will not be easy to work on
it over the vacation, since you will need other students to test it. Other
courses will probably also set projects needing to be finished at the same
time.) This report should describe the testing you have done on your
interface, and what conclusions you draw from the results: what changes you
made to your interface, or would make next if you continued work, or that you
feel it is a successful design. Describe what tests you decided to make, and
why you chose them. This exercise is about designing and carrying out
measurements on a design: you will be assessed not on how good the interface
turns out to be (that is just the fun part), but on how well you tested the
success of your first ideas about its design.
This report should contain:
- A short description (a page or less) describing what your program does.
- An appendix dealing with the bugs you found at various times in the design.
This is to give you practice at describing these; you need not mention every
single one, but should deal with the main ones. For each bug you should
describe how you detected it (the symptoms), what you thing the real problem
was (your interpretation or diagnosis), and what remedy you decided on.
- The main part of the report should deal with your overall testing
(evaluation) of the design, using the user interface performance measurement
approach dealt with in lectures. You should state what your main aim in the
design was (e.g. with games, to amuse users, with information stacks to make
information available), and how you decided to test its success. You should
touch briefly on every aspect: why you chose the measures, the instruments, the
test subjects (users) you did; whether you set them specific tasks and why (or
why not); etc.
The marks will be allocated, as already indicated, for how well you applied
ideas about testing user interfaces to your particular project. They will be
given partly for what you did (as judged by your report, your partners'
reports, and what you tell me when I interview you during your demonstration of
the interface), and partly for how well you wrote it up. (Thus someone who
failed to hand in a report but had thought out and done a good testing scheme
might get up to half marks; and conversely someone who didn't think very
carefully about the evaluation until they wrote it up might get an excellent
writeup mark, though only a poor one for what they did.)
(Back
up to HCI module main page)