matt@braithwaite.net (Matthew Braithwaite) writes:
> The excellence of a program is in its defaults. Users don't read the
> directions, or they read only enough to get started; and they don't
> change the defaults much. Unfortunately people are easily cowed into
> being apologetic for not reading directions, but really, they
> shouldn't be, because it encourages us programmers to think that as
> long as we've provided an option to do something, we've done our job.
> In fact, it's all about getting the default right. If more users
> said, without apology, ``my time is too important to read the manual''
> it would be easier to remember this.
Completely agree.
> What this says to me about the matter at hand is that the appropriate
> focus is ``what behavior makes it hardest for the user to get bitten
> in the ass?''. I'll pick on a message of Karl's
> <874s22qtmu.fsf@galois.collab.net> by way of example:
>
> But in general, I think a lot of users, not just myself, are happier
> if interactive commands that might take more than a few seconds *do*
> print out progress reports
>
> So what? One could argue that ``unhappy'' means ``more likely to hit
> ^C and screw himself up with a half-updated tree'', and this would be
> a worthwhile point.
>
> But that aside, the argument that ``verbosity makes it easier for the
> user to get bitten in the ass'' is more important than ``verbosity
> makes the user happy'' IMHO.
I don't see how verbosity makes it easier for the user to get bitten
in the ass. Can you describe a scenario? My whole point in
supporting the progress reports is that I think they're the best
default.
> I am distrustful of designing an
> interface according to users' stated preferences, rather than
> according to the observed frequency with which it causes them to screw
> up.
Yah; same question -- how do the progress reports cause screwups?
Received on Sat Oct 21 14:36:13 2006