On Thu, Nov 09, 2006 at 01:08:29PM -0800, cold wolf wrote:
> I see now. I'm going to quote Raskin himself, because he says it best: "To
> understand modes, we must first define a gesture. A gesture is a sequence of
> human actions completed automatically once set in motion. For example,
> typing a common word, such as 'the', is a single gesture for an experienced
> typist, whereas the typing of each letter would be a separate gesture for a
> beginning typist. [...] Modes are manifested by how an interface responds to
> gestures. For any given gesture, the interface is in a particular mode if
> the interpretation of that gesture is constant. When that gesture has a
> different interpretation, the interface is in a different mode." [p37, The
> Humane Interface.]
>
> He goes on with a good example: "A flashlight that is operated via a
> push-button toggle can be either on or off, assuming that it is in good
> operating condition. Pressing the button turns the light on if the present
> state is off, and turns the light off if the present state is on. The two
> states of the flashlight correspond to two modes in the interface..."
>
> "Let's say I argue "Archy has modes". I might say that while you are
> holding caps-lock, this is a mode, because now when you press "e" you
> are starting a command, rather than inserting an "e" into the document.
> Thus, the meaning of the "e" key has been changed."
>
> Holding caps-lock is a quasimode. Consider this: "Most of our nervous system
> operates such that a constant stimulus yields signals that, in time,
> decrease in their ability to capture our attention. This decrease continues
> until out cognitive system receives no signal at all. However, the signals
> that reports back to us whether our muscles are actively producing a force
> do not fade." So a quasimode takes advantage of this by requiring the user
> to activate and hold a control while performing another user action in order
> to eliminate problems caused by modes, but still giving them the benefits
> that modes offer. The Shift key is also quasimode.
>
> With regards to locus of attention, again Raskin explains better: "When you
> are awake and conscious, your locus of attention is a feature or an object
> in the physical world or an idea about which you are intently and actively
> thinking. You can see the distinction when you contemplate this phrase: "We
> can deliberately focus our attention on a particular locus." Whereas 'to
> focus' implies volition, we cannot completely control what our locus of
> attention will be. If you hear a firecracker unexpectedly exploding behind
> you, your attention will be drawn to the source of the sound. 'Focus' is
> also used to denote, among the objects on a computer display, the one that
> is currently selected. Your attention may or may not be on this kind of
> focus when you are using an interface. Of all the world that you perceive
> through either your senses or your imagination, you are concentrating on at
> most one entity. Whatever that one object, feature, memory, thought, or
> concept might be, it is your locus of attention. Attention, as used here,
> includes not only the case of actively paying attention but also the passive
> case of going with the flow, or just experiencing what is taking place."
>
> Our goal is to create an interface that is responsive to human needs and
> considerate of human frailties. This requires an understanding of the
> relevant information on how both humans and machines operate. It seems that
> you're putting more emphasis on the latter though (but please correct me if
> I'm wrong). Anyway, I hope this helped.
It did help indeed. I think a lot of these definitions are pretty fuzzy
and really depend on the user's state of mind and experience. I think
the point of "no modes" is to avoid situations where the user is
expecting the interface to do one thing, but instead it does another. Of
course, what the user expects depends much on the experience of the
user, and what cues are available.
I would argue that a flashlight is not a bad interface, because usually
a flashlight is used in the dark, and in such situations, experienced
flashlight users are quite aware of the current state of the light.
Having a single button that toggles the state has some advantages: it's
compact, cheap, and one can't press the wrong button (a useful thing in
the dark). The point is yeah, it has modes, but the modes are expected
and obvious so it's not all that bad.
I would not be so willing to design for no modes, ever. I think modes
are beneficial when a mode coresponds to a particular task in the user's
head, there are good cues that the interface is in that mode, and the
consequences of doing something when in the wrong mode are not terrible.
To take Archy's quasimodes as an example, they are useful because
"entering a command" and "inserting text" are distinct tasks in the
user's mind. Holding a key is a good cue that the interface is in this
mode, and should the interface be in the wrong mode, nothing really bad
will happen (and there is undo, anyway). The only reason they are
"quasi" is because they are designed well.
The original vi with its insert and normal modes didn't provide any
indication of the current mode. I admit this is at times annoying,
although it ususally isn't a problem unless I'm inserting text, get
interrupted, and forget I've left it in insert mode. Vim is a newer vi
clone with many added features. With the default configuration, vim will
display a bold '-- INSERT --' at the bottom of the screen when it is in
insert mode. It will also change the cursor shape in the GUI versions
where this is possible. I don't find this mode annoying because there
are decent visual cues telling me what to expect. The changed cursor is
most obvious, since I'm always expecting what I type to take effect at
the cursor. The distinct modes allow some specialization of
the commands, with advantages previously discussed.
Where we disagree I think is on the expected ability of the user. The
difference between these two examples of modal interfaces is that vi has
less obvious cues and it's modes corespond to a distinction of tasks
that most casual users would not need.
A programmer probably spends more time manipulating existing text in
,ontrivial ways than he does inserting new next. Thus it makes sense to
allow him to use that mode without enslaving a digit, so a less obvious
visual cue is better. Obviously we wouldn't want to require a key to be
held for inserting text, either.
|
