[Usability]About usability and teaching things to users

[Daniel F Moisset <dmoisset arnet com ar>]

[Disclaimer: I'm not an usability engineer like some ppeople here. What
I say is based in personal opinion, built from experience teaching and
watching lots of user, most of them non computer-savvy, some of them
with no previous computer-experience. These people use mainly Windows
9x, Gnome, and WindowMaker (with some kde and xfce users)].

In my previous email I discussed a little about having or not to teach
stuff to the users. 

My idea of usability, is that it consists on giving users control over
their work environment. I'm not saying that that implies putting a lot
of choices in front of the user. Having too many choices scares mosts
users, actually taking control from them instead of giving it.

Ok. You all knew that. But what I said also implies that you cannot take
all choices away either. So in one extreme you have UIs with lots of
choices that confuse the users (like Enlightenment last time I used it)
or UIs that try to do everything for the user without asking, and
sometimes doing things wrong (like Windows), which is frustrating for
the users, because they have absolutely no control.

To be able to control something, you have to know how it works. Not how
it works internally, (I can drive without knowing what's inside my
gearbox), but how to manipulate the item (knowing that tuurning the
wheel steers, the right pedal makes you go faster, etc.) And some basic
rules about the item and the environment, usually due to limitations of
technology (you need time and space to break, more if you go faster. You
have to fill the gas tank before it goes empty. If you do a tight turn
while going too fast the car will roll).

The car example above has equivalents in user interface. You don't have
to know about the source code (or that *there is* something called
source code), or the storage format for the data. You have to know how
to open and use your apps. You have to know about some limitations
behind (Your hard disk has a limit, and you have to delete files if it
gets full of work. If you delete a file you might not be able to get it
back. Some operations take time and you have to wait for them).

When having to learn how to use a computer, you have to learn stuff,
some of it quite abstract. And the users doesn't wants to waste time
learning things, but he has no other choice. So the work of usability
people is:

1) Reducing to minimum the things that must be learnt
2) If something must be learnt, make the UI teach it, if possible in a
way that the user will learn it without knowing he is learning it.

The previous mail I sent (about widget vs. controls), tried to put more
in focus the first question: "Must we teach the user about this
abstraction called widgets?" (And "how much should we teach him about
them?"). I suggested no as an answer, but perhaps you think it's
important. When that happens, you have to consider point (2), i.e. "How
is the best way to teach the user about this concept" (and that includes
"what word should we use for this concept?").

The user does a lot of learning without knowing (and UIs do a lot of
teaching without their designers knowing). For example, most users get
to learn what a "window" is. Nowhere in the UI says "a window is..." or
"This is a window (big red arrow pointing to a window)", but you see the
word "window" everywhere, and you get it from context. The term used
might help, when it resembles the representation of the concept; and
it's usually easier with a more "visible/concrete" concept like "window"
(meaning computer windows here) (represented with more physical/concrete
terms like "window" (meaning glass windows here)).

J. Ramsey already pointed some of this. There is a lot of jargon in
computer UIs. Not only that, there are a lot of concepts that users
actually *learn*. So I think more attention should be paid to _how do
they learn it_. In the previous example, putting widget in some dialog
clearly and obviously designed to change widget appearence could make
the link in the user mind and make it learn the new term, the same way
he learn what a "button", "window", and "panel" were.

All new concepts should be put visibly somewhere so the user can learn
what they are and how to use it. That way you can introduce new terms,
and new concepts, actually giving control to users and enhancing
usability. We must not be afraid to introduce new things, we just should
be very careful about how we introduce them. (Once we've decided it's
useful to introduce them).

I think several computer games that have custom UIs have done a great
job on this (and obviously, a lot of them sucked as UI). That's where a
lot of effort has been put on interfaces that "teach themselves", taking
the user from the hand up the gentle learning curve. Of course, some
games can afford introducing the functionality slowly (in progressive
"levels", or things like that) which can't be done in a productive id,
where a tutorial-like interface can get obtrusive. But some
tutorial-like features that are not obtrusive could be added.

Well, i hope not to have borede you with my ramblings

	Daniel


-- 
Knowledge, sir, should be free to all!
                -- Harry Mudd, "I, Mudd", stardate 4513.3