On Thu, Aug 10, 2006 at 05:43:37PM +0200, Alain Bench wrote:
> > but it is NOT intuitive, and should not be the default behavior, IMO.
>
> Here is the limit: Your model is valid, but you can't impose it with
> its constraints and consequences to other people.
Well, you're right in that there is a subjective intuitiveness for
each individual user. Everyone thinks their own way, so what you say
is true.
But, when designing an interface (computer program or other), there is
also an OBJECTIVE idea of what is intuitive. Of course, there is no
absolute objective truth about anything, so it is not pure
objectivity. This is just a more thorough approach to choosing design
elements that a large majority of users will find intuitive. I think
this largely relates to the names chosen for elements, and how the
functions assigned to those elements correlate to the natural language
definitions and common usages of those names. Also there is the
matter of how consistently the peices of the interface behave with
respect to each other. Finally there is the matter of how common an
element is in the context of historical computer program interfaces
(or whatever it is for which you are designing an interface). I'm not
trying to suggest that my way is right, and your way is wrong; but I
do insist that you CAN use logic to show that a particular design
choice is logically better / more intuitive than another. And that
I'm right. :-D
If you use the above as guiding principles to design your interface,
then yes, you can come up with an interface that is intuitive in an
almost objective sense. [Of course, this assumes that the interface
designer has not only an excellent grasp of logic (true for most
decent programmers), but also an excellent grasp of the natural
language you are using to name and describe your design elements
(which unfortunately many good programmers do not have, at least in
America...;-) and decent knowledge of common interfaces (which is very
variable).] Furthermore, as the interface designer, not only can you
impose your views on others, but it is actually your job to impose it
on other people! You don't have a choice; you must choose a default
interface for your users. And most importantly, if users find that
the existing interface is not intuitive, then the defaults should
change. Ideally, the interface should be flexible enough to allow
users who do think differently to change it to their liking.
Thankfully Mutt has that power. But another principle of good
interface design is that users want to use the program, not spend
weeks configuring it the way they want it to work.
The interface should be designed to minimize the amount of pain that
people must go through to make the program work they way they work. I
see that as generally lacking in Mutt... the prevailing attitude is,
"but you can do that with a macro." Yucky. It should be clear from
the number of queries that people post to the mailing lists, which are
answered with suggestions to write macros (especially the common ones)
or re-bind keys, that Mutt's default interface is still lacking in
many ways. I think a lot of this stuff people should not need to do.
In this specific case, we are dealing with several interface elements;
there is the key 'q' to which we bind some functions, and there are
the functions themselves. Lastly, there is the documentation which
describes all of the other elements, which includes the mutt help
screen, the manual, and the man page. The documentation is fine, so
no need to touch upon that.
In the index view, 'q' is mapped to <quit>, which is very
logical and intuitive. It uses the first letter of the bound function
as a mnemonic, a very standard interface design concept. However,
in the pager, 'q' is bound to <exit>. The fact that the key is bound,
by default, to two different functions in different contexts, even
though both functions are useful and valid in both contexts, is
inconsistent by definition, and therefore inherently unintuitive.
Keyboard-based interfaces very frequently use 'q' to mean quit, and
Mutt does also, SOMETIMES. In this way also it is therefore intuitive
for the user to associate 'q' with quit. So, what does it mean to
quit? Miriam Webster says this:
transitive verb
1 : to make full payment of : PAY UP <quit a debt>
2 : to set free : RELIEVE, RELEASE <quit oneself of fear>
3 : CONDUCT, ACQUIT <the youths quit themselves like men>
4 a : to depart from or out of b : to leave the company of c : GIVE UP
1 <quit a job> d : GIVE UP 2 <quit smoking>
intransitive verb
1 : to cease normal, expected, or necessary action <the engine quit>
2 : to give up employment
3 : to admit defeat : GIVE UP
Transitive definitions 2 and 3 are not commonly used in English
anymore, they are archaic. In all of the others (and #2 and #3 as
well actually, though perhaps less clearly), there is a clear
underlying idea of finality. Thus the quit function is itself aptly
named; it is very intuitive. Binding it to 'q', the obvious choice
for mnemonic, is also very intuitive. But what logical thought
process can be said to justify re-binding this key to the "exit"
function, once one is no longer in the index view? It certainly is
not an obvious mnemonic...
I can imagine none, and I'm betting that you can't either. The best
one can do is, "I used another program that behaved kind of
similarly." But even with that, in the vast majority of programs that
exist, the action which triggers the quitting of the program does
that, and only that. In that regard, changing the function simply
because the mode has changed is not intuitive, in an objective sense.
It is far more intuitive to leave it bound to <quit>.
This does not have to be the case always; context does matter. For
example, when the mode changes to "edit message" mode, then clearly
pressing 'q' must not exit the program: one needs to be able to type
the letter Q. But for it to be considered intuitive, there should be
an obvious, logical reason for the function to change. In Mutt, there
seems to be none.
While the <exit> function is not badly named, I think what mutt calls
"exit" might more accurately be described as "go back" or "escape"...
and indeed, many text-based programs (I would say most) with
menu/key-based input systems use the escape key for this purpose.
That is, when one selects a screen for a particular function by a menu
option, or a particular hotkey sequence, one generally returns to the
menu, or the previous screen, by pressing the escape key. Due to how
common that has historically been, this has become extremely
intuitive, and would be far more intuitive than re-binding the 'q'
key. Unfortunately Mutt makes heavy use of escape as a key modifier,
so this is not an option. Again, due to the commonness of it in other
programs historically, it would have been far more intuitive for Mutt
to use the Alt key as a key modifier instead of escape. Escape has
been used that way primarily in certain very Unixy programs, whereas
Alt is very widespread across most platforms. You might say that is a
pc-centric choice, but the fact is most people who have used a
computer today have never used one that didn't have an Alt key... even
on any Unix systems they may have used.
So far, I have covered the naming of the elements, natural language
definitions, and the commonness of rebinding a different function to
the key that quits. Using logic, one should be able to see that in
regards to each of these, there are more intuitive interface design
choices than re-binding 'q' to <exit>, in the objective sense of
intuitive. I'll finish off with consistency, though I already touched
upon that as well.
With mutt, there are actually three different functions that have a
similar purpose. There is <quit>, <exit>, and what I will call cancel
(I do not know if it is associated with an actual Mutt function),
which is what results when you press CTRL-g.
Frankly, this is very confusing, and when I'm at certain screens and
prompts that I don't use very often, I'm still not sure what the right
key to press to get out of it is. Mutt is the only program I have
ever seen, as far as I know, that has had three such functions.
Programs generally combine <exit> and cancel into one function. In
some places where it seems like you should press ^g, you actually need
to press 'q'. If there is any internal consistency about what to use
when, it is lost on me, and the re-binding of 'q' to exit only adds to
the confusion. So here again, I find that this is not at all
intuitive, though I'm willing to conceed that this is not an inherent
unintuitiveness, as it may be just my ignorance of a design which
happens to be consisent. But at the very least changing the meaning
of 'q' is not consistent, and as such it is inherently unintuitive.
> You clearly can't proclaim general lack of intuitiveness. What you
> say is perhaps true in your model, but is not an universal truth.
So, based on the above, yes I can. ;-) Or rather... there is no such
thing as universal truth. But I think you can say that using the
definitions of terms that you use to name your interface elements, and
the most common interface design conventions, in combination with
simple logic, you can determine that option A is more inherently
intuitive than option "B" with some certainty in a large percentage of
cases, and I think I've logically shown that this is one such case,
even if you still prefer the current behavior. Do you still disagree?
There is also the question of whether this is really intuitive for
you, or is it just what you have become accustomed to after years and
years of using Mutt? :-D
Also note that I'm not opposed to the staged exit model; but I think
there does need to be a function which always quits, and the most
obvious choice of a key to bind that to is 'q', particularly since it
already is (at least some of the time).
> It can be interesting to compare harm done by unadapted defaults:
>
> · You expect pager [q] to <quit> Mutt. It doesn't, but just <exit>s and
> leaves you in index. You have to press [q] again. Irritating, but
> harmless.
>
> · I expect pager [q] to <exit> to index. In the hypothesis Mutt has
> changed to suit you, [q] would <quit> Mutt, purging unreviewed D mails,
> changing N to O, and so on. Irritating, and potentially harmfull.
But this is the result of another bad default option. By default,
$quit should be set to ask-yes, to prevent that from happening. But
really, it's only a problem because some people have come to expect
that 'q' will escape back to the previous screen. If you are
concerned bout this, then you could make the default binding Q, to
make it a little harder to press by accident. Or whatever. Or just
rely on ^C. All of these are, I think, more intuitive than the
current behavior in the objective sense, for reasons I've just gone
into great detail to explain.
--
Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address. Replying to it will result in
undeliverable mail. Sorry for the inconvenience. Thank the spammers.
Attachment:
pgp02fLi6mmpS.pgp
Description: PGP signature