Re: [Gnu-arch-users] Re: Online book for usability

[Tom Lord]

    > From: David Allouche <address@hidden>

    > Essentially, that paper says: "You may know, as an uber-geek, that your
    > tool is right and that new users get it wrong because the expect the
    > wrong thing. Still, what matters is your users, so you'd better consider
    > seriously whether doing the wrong thing user expects would not actually
    > be the right thing." But it says so is much more numerous words in order
    > to be convincing.

Ick.  It's a confused sentiment.

User interfaces are, in effect, "handles" on a particular device.

Handles always _suggest_ to users how to use the device.  I recommend
the classic "The Design of Everyday Things" by Donald Norman for
principles like "natural mapping" (between control (UI) and
functionality (interfaced device)).  If (like me) you have a stove on
which you're constantly turning on the wrong burner by mistake, that
book will shed new light on your life.

User's of hammers never (or rarely) make the mistake of picking up the
wrong end and trying to hammer a nail with what was supposed to be the
handle.  But if the head of a hammer were differently shaped -- looked
and felt, accidentally, more like the handle than the actual handle,
then that kind of mistake would be natural and people would make it
all the time.  Even experienced hammer users would sometimes make that
mistake.

So when a device has the right functionality but users consistently
try to use it the wrong way, it's the shape of the handle, not the
underlying functionality, that is wrong.   The answer isn't to modify
the device to do the wrong thing -- but to experiment with and tweak
the shape of the handle.

    > Most people want to _do_ something which is not essential to the tool
    > they are using. When the tool goes in their way and try to force them to
    > change the way they work, their are frustrated, and may even become
    > aggressive.

Yes, ill-fitting tools cause stress among people who have to use them.

    > That is the reason why untagged-source files are now "precious" instead
    > of "unrecognized". We may know that it is better to have
    > "untagged-source unrecognized" because it catches mistakes, but many
    > users just expect "untagged-source precious".

That particular change to "precious" rather than "unrecognized" was
probably a mistake.  It's a fix to a symptom, not the cause of the UI
disconnect.  It's a bogus fix because it encourages misuse of the
tool.  Since that change, I have sometimes found myself with revisions
that are messed up because of that change.  I've gotten in the habit
of remembering to change what `untagged-source' maps to in
=tagging-method whenever I start a new tree: that's a habit that's
born of compensating for the fact that the UI (after the change you
mention) encourages a dangerous usage pattern.

A better fix would revert that change, then try harder to understand
what is confusing about the resulting error messages for users, and
fix that.

    > Next time you have to explain something to a user who has read some
    > simple documentation, and that explanation has to be longer than one
    > phrase, or next time you have to answer a user something along the lines
    > of "you are doing the wrong thing", ask yourself whether burdening the
    > user with all that irrelevant (to the task at hand) information is worth
    > the trouble.

Often it will be, in the case of Arch.

Part of what's going on with newbies is that when they use CVS or
other systems, they often use them as "black boxes" and with very poor
sense either of what's going on, or of what the tool is capable of.

Arch is doing much _better_ than CVS in that it at least leads users
to _try_ to use scm-features they hadn't thought of before --- in some
cases, the UI doesn't lead some users far enough.

So, newbies to Arch, unlike newbies to, say, svn, often face two, not
one problem:

   1) learning to use a new tool (tla/svn/cvs/whatever)

   2) learning what revision control is for and is capable of
      in the first place 

-t