Bruce points out in various ways that verbosity will be the user's
choice. Of course, this is true, but I don't think that's the central
point.
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.
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 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.
Received on Sat Oct 21 14:36:12 2006