CS789, Spring 2005, Lecture notes, Week 11
>CS789, Spring 2005
Lecture notes, Week 11
What happens when we look outside at the same set of objects
The same set of objects, different views
- by going outside?
- by looking through a window?
- by peeking through a crack in the door?
- by looking through a Venetian blind?
- by seeing thrtough the gaps in a passing train?
Perception problems solved in different ways
What happens when we want to call somebody back
The same goal, different affordances
- before they leave the room?
- when they're at the back door?
- when they're outside walking past the window?
Action problems solved in different ways
What happens when we want to find where a meeting is
Ideally we see the meeting, not the device
- using a conventional diary/agenda?
- using Xcalendar?
- using a PC schedule program?
- using a PalmPilot?
It's the same meeting seen through different views
How do we do this? Obvious answers.
- make them live off a common database
- make them simultaneously visible: changing together is powerful
- make them share sensory attributes like colour, visual texture, shape,
How do we deal with differing input and output capabilities? Not so
- use more or less constrained contexts to interpret incomplete
- provide many ways of doing the task in rich interfaces, so there are
lots of ways that survive when the interface degrades
- have well-defined, observable models of degradation (Remember that you
don't want absence of evidence to be evidence of absence.)
- find unexpected richness in degraded interfaces AND implement it in
Documentation is an extrememly important part of the user interface,
usually the first part of the interface with which the user interacts, and if
the user gives up on a program it is often the last thing with which he or
Documentation comes in four types:
- Integrated assistance,
- Error message, and
In what follows we will notice that rules and principles are very
different from each of them. For example, who reads it?
- Tutorial: a user who has little or no operational experience with the
interface, but who may have extensive experience with programs of similar
type, and may not, of course.
- Integrated assistance: a user who may or may not want it,
- Error message: a user who has over-stepped his or her assumed
expertise, but may just have typed incorrectly.
- Reference: a user who has some level of operational experience with the
interface, but may still be inexperienced with similar programs, or even
with the computer in general.
And how are problems like this usually solved:
- Tutorial. There are actually two tutorials, an implicit one in the
"quick start" installations, and a real one that is expected to be done
after the user has gone through the naive installation. How is this
peculiar? Quick start is usually designed for the knowledgeable user who
wants to get right down to work; the real tutorial can only be started
once an installation has been performed. Who do you have to be in order
to do the non-quick installation?
- Error message. These are optional reading. How do we make them so? Two
levels: signs, and sentences. These tend to be shaded into reference.
- Reference. We try to provide lots of re-entry to the tutorial for users
who have gotten beyond their expertise. This stuff, of course, also
allows the user to measure his or her expertise, and the confidence
provided by seeing a pointer and knowing "I don't have to follow that
one." is worth something. But not if it's unjustified by actual
knowledge. And it can go the other way. You don't want a user thinking
"What kind of an idiot do they think I am?"
Remember. Almost all documentation was written to describe an obsolete
version of the program!
- Different parts of the same program evolve at different speeds
- The constraints on evolution have more to do with users than with
1. How is documentation read?
Different documentation is read different amounts.
- Read-once documentation, like tutorials. The idea is that this
documentation is presented with the expectation that after one reading
the information is transferred to the long-term memory of the user. This
is done as continuous text, with many entry/exit points.
- Read-many documentation, like lists. The idea is that this
documentation is transferred only to the short term memory of the user,
and will be refreshed from the source when needed in the future. You
break this up as much as possible, allowing selection to vary the
salience of different parts from reader to reader.
Which requires its subject to be slowly evolving? Which can tolerate fast
You can expect that different users will read differently. Urgency is
bound to be an issue here.
- Careful reading. Who reads carefully? When?
- Scanning. Who scans? When?
2. When is documentation read?
How do users find what they need?
- Tables of contents
- Indices. (Indices cost a lot to produce.)
- Search, which may or may not be explicitly supported.
- Forward and backward reference. Implicit, explicit.
- Pointers in things that aren't documentation. (This produces a HUGE
coordination cost! It goes at least as the square of the size of the
entire package: code + interface + documentation.)
- Explorers who don't make maps get lost. How do we make maps easy to
- What persuades users to explore? The scent of buried treasure. Not
really. More like rewards the last time exploration occurred.
- Tip of the day is supposed to be the scent of buried treasure, but
actually it's junk mail.
3. How does documentation refer?
Types of reference:
- Direct sharing of features.
- the colour shown in the figure.
- Indirect sharing of features.
- The last colour I mentioned. What does this depend on?
- By exclusion.
- The colour that isn't yellow, blue or green. What does this depend
How does the medium of documentation affect its referential qualities?
How does the type of the interface affect the referential qualities of
documentation? For example, in a form "type in the traveller's name" clearly
refers to something abstract, the name, of which a representation is being
created in the form. Whether the user thinks that the representation is
letters on a screen, letters on a keyboard, pixels on a display, bytes in a
memory, doesn't matter much. But when documentation says "Drag the icon to
the shredder", the concreteness of the reference is unpredictable. And the
whole idea of the interface design is that different users can do the right
thing even while thinking very different things about what they are doing.
4. How are we going to handle the cost of documentation?
What's the problem?
- manufacturing cost
- preparation cost.
What are the solutions?
- Learning transfer
- Automatic production of documentation
- Learning transfer
- Interfaces that don't need documentation
- Learning transfer
- Communities of users who don't need documentation
- Learning transfer
Do illustrations help? Illustrations are very expensive. Manufacturing
cost will become unimportant as we go increasingly on-line. But preparation
cost won't change. It may even get worse. Reference is the problem. We don't
notice that there are very many different levels of abstraction. Which bird
book makes bird identification easier for the novice
- photographed figures?
- painted figures?
What is the most easily recognizable hand?
5. What is the most common substitute for documentation?
Models of technology spread.
6. Can interfaces be self-revealing?
"Self-revealing" is a buzz-word for self-documenting.