Colloquium at Stanford
The Unfinished Revolution


Memorandum

Date: Sun, 30 Jan 2000 22:15:24 -0800

From:   Eric Armstrong
eric.armstrong@eng.sun.com
Reply-To: unrev-II@onelist.com

To:     unrev-II@onelist.com

Subject:   User education

On Mon, 31 Jan 2000 16:28:12 +1100 Jeff Miller wrote:

It was interesting to hear that it only took an hour to teach a user to use nls/augment to the point where they could go away and use the system by themselves. Why is it that people expect to be able to sit down in front of a computer and use it without leasons? They never question the number of hour spent learning to drive a car or the amount of money they spend on driving lessons. While I agree computers, in general not in every case, should be easy to use. The potential power of the system should not be drained out of such a system in the name of usablity.

The number of programs a computer user interacts with can be very large. If each is an interface entity unto itself (as it was in the early days), then the situation is equivalent to renting a new car in a new city every few days, and finding a totally different set of controls (functions), as well as traffic signals and other signposts that tell you where you are, keep you oriented, and let you navigate. If your job is to travel from city to city and solve problems, you wind up having to become an expert on a multitude of auto and traffic systems -- when your real objective was to drain the swamp.

On Mon, 31 Jan 2000 16:28:12 +1100 Jeff Miller wrote:

In any system we consider implementing we must have a gradient of usablity vs flexibility/power. There needs to be the commoners interface for day to day tasks and a set of tools that allow more flexible manipulation to be carried out on those tasks that are uncommon but necessary or where not thought of originally.

I think so. I've always wanted a dynamic help page. It would keep the functions I use just infrequently enough to forget, yet often enough that I want the instructions close at hand. At first, that would be the most common, ordinary functions in the system. But once they became second nature, I would remove the "oh yeah" elements and add deeper functions I had begun using.

In general, operations that occur frequently should most easily available, while operations that occur less frequently can be harder to access. There is a wide range of interface expectations, however. Users will adapt to a new system readily if a) It is consistent, and therefore predictable and b) It delivers enough power (that they use frequently enough) to make it worth the investment. If that can be done in a familiar, the interface will always be accepted. (Often, though, there are conflicts between familiarity and consistenty, as well as between consistency and keeping-frequent-operations-the-simplest.)

The conflicts create the possibility for a wide number of interface options. Which in turn implies that the system must be either extensible (so people can set up interfaces they like) or open (so people can select the interface they like). The openness/extensibility must apply to functionality (what operations are available and how they work), as well as to display, keyboard, and pointer characteristics.

Sincerely,


Eric Armstrong