|
Clark
Stone wrote:
I
went to JefRaskin.com and
looked at the summary of "The Humane Interface." With
that limitation, I have some serious misgivings about what Raskin
appears to support and how it appears to conflict with the usual
vectors of your own site. In particular, I am concerned about what
appears to be an uncritical support for a-modal interaction and
its obvious real-world conflict with what is "humane."
In
the summary, Raskin refers to the command line interface (CLI) as
the ultimate in amodality, and I have to say that scared the pants
off me. If I never have to deal with a CLI for the rest of my life,
it will be too soon. I understand the power of such - I was working
with IBM mainframes at Shell Oil's computing headquarters in 1978
- but power is not the only index of good. In the past, CLI required
the user to memorize, memorize, memorize command after command (and
many combinations thereof) and almost always punished the slightest
infraction of the CLI law. Comparing no-metaphor CLI with some-metaphor
GUI, I'm going with GUI as significantly more humane.
Of
course, it's possible I'm grossly misunderstanding what's in the
book and on your site; and perhaps this future CLI is somehow metaphorical
so folks don't get lost in that UNIX-like maze of arcane idiocy;
but until then, my escutcheon reads "GUI."
Next,
I'm worried about the general non-humane-ity of amodal interfaces
because "people don't much operate amodally." Language
is probably the central example of this: if I say, "Where is the
chair?" it means one thing if I'm standing in my living room where
my recliner used to be; and it means another thing if I'm at a committee
meeting. That kind of context-sensitive interpretation of inputs
(modality) is pervasive in the human demesne, almost ubiquitous,
so I have trouble understanding what's so wrong with modal behavior.
I
understand there are limits to modal behavior, and mistakes can
be made. I'm Win at work and Mac at home, so I often reach for the
control key in the wrong place when I'm just beginning at either
place; and it's also true that people are confused when listening
to someone talk and using the wrong frame of reference to interpret
what's being said. But it's also true that we can usually sort it
out with a few questions.
Perhaps
that is the true danger of modality: people who are creating modal
tools don't make it possible for users to ask a few framing questions
in a human (humane) way. I work around this every day by saying
to myself, "I know what it does, and this program has to have it...so
what do they call it?" followed by a crawl through the user manual
to orient myself to "what they call it." Now, I'm good
at that, but most people aren't, and it would be a significant challenge
for any tool to have a humane index, table of contents, and manual
design.
Well,
I've blown my gas, and I hope I wasn't too far away from what either
you or Raskin actually said or meant.
cjs
uidesign.net
reply...
Thanks
Clark! A thoughtful note which requires a thoughtful reply.
This
is one of the biggest and trickiest topics for the Interaction Designer.
The real answer is that - amodal is mostly best except when it's
not! In the same way that - users never scroll except when they
do.
I
don't think that I or Raskin have advocated a return to command
line interface as it has it's failings as you point out. It also
has a big plus, that the basic way it operates is consistent. It's
that level of consistency that we're looking for. It's important
not to confuse the modelessness issue with other issues of usability.
I
have been giving some thought to the human ability to deal with
modes. I have particularly been studying the development of my young
dog. Though intelligent by dog standards, even a young human should
have a stronger cognitive ability. I have observed that he is capable
of understanding several modes and responding to commands in a mode
sensitive manner. For example he understands two modes of walking
on the leash: "Let's go" - walk on a loose leash without
pulling; and "Heel" - walk to heel, no other options permitted.
He can also handle more complex modes such as the command "Bedtime"
which is a direction to return to his crate. This command is only
followed if the sky is dark, most lights are out, the TV is switched
off and so forth. Otherwise he simply ignores the directive as it
is clearly "in error". The command to return to his crate
at other times is "Home". If a dog can grasp modes then
surely people can too?
The
issues with modes are simply that communicating the mode switch
to a user is often difficult or impossible. We tend to use environmental
clues as well as the expressions and moods of others to communicate
a mode. If your wife is stomping around the house, banging doors
closed, playing music loud and ignoring you, then it's a pretty
clear indication that it's not a good time to ask about that new
car you want to buy. Or put another way, as humans we use a lot
of markers to detect and identify modes. This is much harder to
do on a computer.
As
an example of this I have recently been doing a lot of work with
WAP phones. Usability studies have shown that users are incapable
of distinguishing the difference between the phones operating system
and the microbrowser. The microbrowser is an application which runs
on the phone. An application is a mode of operation. In a PC applications
have a considerable latitude to display themselves in a recognizable
fashion. Even then consistency is preferable across applications.
With the phone it is impossible and therefore the microbrowser should
ideally not represent a different mode of operation.
A
typical phone might have an address book. If you like a collection
of "my favorite people's numbers". Your WAP Phone portal
may come with access to a stock brokerage such as Fidelity.com.
They may offer the ability to store a list or collection of "my
favorite stock ticker symbols". Semantically these are not
particularly different cognitive objects. They are collections of
favorites. It stands to reason that a user of a humane interface
might expect those similar cognitive objects to be processed in
a similar fashion. However with current WAP Phone technology this
is not the case. The phones operating system handles the "my
favorite numbers" completely differently from the WML microbrowser
handling of "my favorite ticker symbols".
The
WAP Phone browser looks "almost" identical to the phone's
operating system on screen. There is "almost" no visual
affordance that the microbrowser is running rather than the standard
phone OS. Because the user has little or no way of distinguishing
the difference in mode, and the cognitive objects being manipulated
are semantically similar, the user has an expectation that they
be handled in the same way.
With
this example, a modeless design is certainly best.
In
my editorial "Myth of the Big
Screen" and in my earlier letter reply on "modal
vs. amodal" I point out that I do believe that modal is better
under some circumstances. However, the designer has to be very very
sure why they are doing it and that it genuinely offers an improvement.
It
is perhaps for this reason that application developers have been
able to put modal designs to good use. They have an advantage that
they can often tightly define their usergroup and identify the tasks
and goals which they must assist or facilitate with the design.
I
have argued that amodal design is a means for the designer to delegate
the implementation to the end user. Much of the customizability
built in to operating systems and environments is simply the designer
delegating the final design to the end user. It is possible to get
into deeply philosophical debate about whether this is better or
worse. Are you a democrat or a republican in the field of user interface
design?
At
the risk of misinterpreting Raskin's point. When you are designing
a device for anything other than a single purpose, for anything
other than a narrow, tightly defined audience, then you must strive
to establish a consistent and monotonous handling of similar cognitive
objects. This is an A-Modal design.
I
hope this throws some light on your questions. Thanks again.
David
|
