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

[James Blackwell]

David Allouche wrote: 
>> [hammer-based rebuttal]
>
> James Blackwell did a good job at explaining why you are missing the
> point.  He is doing much better a job than me at conveying how and why
> this essay is worth reading.

Wow, David! Compliments like that make me absolutely glow! 

One of the sub-points that I forgot to mention was that I don't think we
should change the way that we do busines here at the arch camp. Rather,
the essay is a useful little piece of logic that we should keep in the
back of our minds when working on the interface.  

The essay isn't strong enough to say 'oh gawd, we need to go back to to
the beginning and turn arch into cvs' (HECK NO!). Rather, the essay is 
a powerful tool that we can use in our rationale for development. I 
was hoping that many people would read it so that if it gets referenced,
everybody is familiar with the argument. When I read the esay, I said to
myself "Wow, this guy really makes a point! I'm going to keep this
argument in mind in the future"

Ironically, this suggestion has spurred more debate than reading the
essay took in the first place!

Again, If 'you' (the reader of this email) have a couple free hours,
check out:
 http://www.joelonsoftware.com/uibook/chapters/fog0000000057.html


David again:
> It is _maybe_ reasonable to send people who have _chosen_ to use Arch
> back to the documentation, or spend time explaining them what they are
> doing wrong (and ask them to contribute back documentation). However a
> significant, and hopefully ever-growing, part of the user-base is going
> to be people who have to use Arch because the organization they work in
> made this choice for them.


My thoughts on the matter is that when a user isn't using the
documentation, the documentation is somehow flawed. The documentation is
difficult to look up, is poorly organized, is too complicated to
understand, or something. Sometimes the problem with documentation is
that its being kept on a webserver that serves too slowly.

One of my favorite examples of excellent documentation is www.php.net.
The documentation renders well on every browser. The instructions for
the command set are clear and concise. Examples are provided, and
frequently users have appended very useful comments. Most importantly
for me, the documentation renders well in lynx, so I don't have to spend
five minutes starting x and mozilla. I can just type
'lynx php.net/fopen' and get the information I'm looking for quickly.
Unfortunately, the site isn't always fast.

Back to David:
> It is unreasonable, and frustrating to everyone, to ask those people to
> supply the same amount of learning effort as people who have willfully
> chosen Arch. And if they get frustrated, they are likely to be much more
> vocal than we would like them to be.

I think that what Tom is doing is trying to shift the whole paradigm of
what it means to perform version control. I'm actually in agreement with
him on this point; I *am* happier with revision control before I bumped
into arch. 

Yet I agree with you at the same time. The first few steps to knowing
arch are still a little too steep for everyone to climb. I don't think
that this is because of any inherent flaw in arch itself; rather, its a
flaw in the documentation.

Now I quote Tom Lord:
>>     > 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.

I agree _completely_ with the assesment, but disagree as to the order.
Yes, there's a disconnect. Yes, we should addres the disconnect
properly. _Then_ we should retake the ground that we lost by giving
suboptimal behavior. 

I could go on for pages, in great detail, on exactly what has gone wrong
here with the users, according to James. For the sake of brevity, you
could sum up my opinion as "the tools that our users are using aren't
ready to do the right thing yet"


Back to David:
> More on the screwhammer front.
>
> Many people are used to do things in ways we know are unsafe and wrong.
> But they will consistently be frustrated if a tool keeps on thinking
> he is smarter than them and preventing them from working as they are
> used to.

Exactly the point to the screwdriver analogy. If everybody is accustomed
to using screwdrivers as a hammer, then you'll quickly go out of
business if you don't make shatterproof handles. 

Tom Lord:
>>     > 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.

Yes. I agree completely. In fact, I can even expand upon it. People are
using tools like cvs and arch without a basic understanding of how to
use the tools, or what the tools are for.


Tom Lord:
>> 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.
 
Then David Allouche:
> To some extent that's a good thing. I like tools which gently push me
> to learn more and broaden my perspective.
>
> But to some extent it is also a bad thing. To quote Robin Farine, with
> whom I often disagree, but who is remarkably good at playing the bastard
> user from hell.

I think you're both right. 

> Robin Farine said:
>> Sometimes we forgot we even had to learn to drink, to walk, to use
>> CVS,. We want tools that think and do the right thing, whatever the
>> heck it might be. Just push the big red button there and the tool
>> takes care of the rest. Error messages? They tell me that something
>> went wrong, bad, the tool could not do its job, I am lost.  
> [...]
>> In fact, it is just a matter of personal taste. Some prefer
>> simplicity, some prefer correctness and some prefer beer.
>
> First and foremost, people want their work done. Arch users are in
> particular class which also make them likely to be interested in being
> educated.  But Arch should not try to force that education down their
> throats.

Oh, that wasn't quite what I meant. I'm actually *for* educating users
to new ways of doing things. Tom's whole rationale is obviously correct
to me; the old ways of doing things is simply _insane_.  What I'm
promoting here is that we take a step back and acknowledge human nature,
and build that into our solutions.

What I'm pushing for is to take the concepts that the essay illustrates,
and to put them in the back of our mind. We don't need code to to the
essay's way of understanding; rather, we need to just be *aware* of it.


-- 
James Blackwell          Try something fun: For the next 24 hours, give
Smile more!              each person you meet a compliment!

GnuPG (ID 06357400) AAE4 8C76 58DA 5902 761D  247A 8A55 DA73 0635 7400