Re: [unrev-II] user education

From: Eric Armstrong (eric.armstrong@eng.sun.com)
Date: Sun Jan 30 2000 - 22:15:24 PST


From: Eric Armstrong <eric.armstrong@eng.sun.com>

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.

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

--------------------------- ONElist Sponsor ----------------------------

GET A NEXTCARD VISA, in 30 seconds. Get rates as low as 0.0 percent
Intro APR and no hidden fees. Apply NOW.
<a href=" http://clickme.onelist.com/ad/NextcardCreativeCL ">Click Here</a>

------------------------------------------------------------------------

Community email addresses:
  Post message: unrev-II@onelist.com
  Subscribe: unrev-II-subscribe@onelist.com
  Unsubscribe: unrev-II-unsubscribe@onelist.com
  List owner: unrev-II-owner@onelist.com

Shortcut URL to this page:
  http://www.onelist.com/community/unrev-II



This archive was generated by hypermail 2.0.0 : Tue Aug 21 2001 - 18:56:41 PDT