CS789, Spring 2007

Lecture notes, Week 11

Scalable Interfaces

What happens when we look outside at the same set of objects

• 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?

What happens when we want to call somebody back

• before they leave the room?
• when they're at the back door?
• when they're outside walking past the window?

What happens when we want to find where a meeting is

• using a conventional diary/agenda?
• using Xcalendar?
• using a PC schedule program?
• using a PalmPilot?

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, etc.

How do we deal with differing input and output capabilities? Not so obvious answers

• use more or less constrained contexts to interpret incomplete input/output
• 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 rich ones

Documentation

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 she interacted.

Documentation comes in four types:

1. Tutorial,
2. Integrated assistance,
3. Error message, and
4. Reference.

In what follows we will notice that rules and principles are very different from each of them. For example, who reads it?

1. 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.
2. Integrated assistance: a user who may or may not want it,
3. Error message: a user who has over-stepped his or her assumed expertise, but may just have typed incorrectly.
4. 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:

1. 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?
2. Error message. These are optional reading. How do we make them so? Two levels: signs, and sentences. These tend to be shaded into reference.
3. 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 technology

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 evolution?

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.
• Hypertext
• 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.)
• Exploration.
  • Explorers who don't make maps get lost. How do we make maps easy to make?
  • 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.
  • red.
• Relative.
  • The last colour I mentioned. What does this depend on?
• Logical.
• By exclusion.
  • The colour that isn't yellow, blue or green. What does this depend on?

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.

Return to:

• Bill Cowan's home page.
• Bill Cowan's teaching page.
• Bill Cowan's CS789 page.
• Bill Cowan's CS789 page for Spring 2007.
• Bill Cowan's CS789 page for Spring 2007 : Lecture notes