Re: [PATCH] Remove absolute paths from gpg.rc
On Wed, Mar 21, 2007 at 11:07:46PM +0000, Dave wrote:
> On Wed, Mar 21, 2007 at 08:18:52PM +0100, Oswald Buddenhagen wrote:
> > the sillier the thing, the stronger the guide should be. simple
> > principle.
>
> You're working on a sliding scale here. Sliding scales are never
> simple without a mapping function. Your mapping function here is way
> too subjective to be simple.
>
actually, the principle *is* simple. it's just the implementation that
is not simple. but common sense helps a lot. and in the remaining cases,
exceptional people like you can take full advantage of the free software
advantages and patch the code.
> > when pressing F8 instead of F7 means as much as deleting all of
> > /home instead getting a dialog to create a directory, you really
> > start to appreciate confirmation dialogs. ;)
>
> The problem there is artificial, created by the user interface. I'd
> counter (from a UI design perspective) that since the function keys
> aren't on the QWERTY keyboard, they're probably not being hit
> accurately. [...]
>
or accidentally in the first place. or the cat just running over the
keyboard. it doesn't matter why - a function that has the potential to
destroy an entire file system hierarchy cannot be activated by just one
key without any safety net. and not everybody has a versioned file
system - actually, almost nobody has.
> > i cut the rest of the quote, as it just doesn't make sense. the example
> > simply doesn't fit. ;)
>
> Why doesn't it fit?
>
c'mon, the example you constructed was just absurd, without any relation
to reality.
command line tools generally make no good example for adding
confirmation dialogs - typing the command is explicit enough.
> > > the user himself is the only one in a position to reverse engineer
> > > his own psychology in order to place prompts wisely.
> > >
> > it might surprise you, but hardly anybody is able to do that.
>
> It does surprise me. I'm not a UI design "expert" and I was able to
> build my own UIs for my own [...] editor, chat program, and email
> program.
>
i'm pretty sure you based the designs on existing concepts.
also, i woundn't be surprised if you would find these programs totally
unusable if somebody else created them exactly the same as you did - the
perception is simply different if you create something yourself.
and finally, you might be actually exceptional.
> > > > but like any other safety measure, they have to be placed wisely.
> > > [...]
> > apart from that, you are completely misinterpreting my statement. ;)
>
> Sorry ... what did you mean? ;-)
>
obviously, that the programmer has to be wise, but you already know
that.
> > > A programmer should write programs that simply do their job
> > > without asking qusetions, and leave Psychology assignments to
> > > Psychology experts.
> > >
> > surprisingly (not really, at least to me), those psychology experts
> > found, that confirmation dialogs in sensitive places are really
> > sensible. ;-)
>
> The Psychology experts who conducted those tests were looking for a
> Democratic solution. Unfortunately, people aren't all the same.
>
yes, that's what configs are for (an aspect that the gnomes fail to
realize, har har). however, its only sane to set the defaults to that
"democratic solution". and suddenly we are where we started from ...
> I love undo functions. [...]
> > however, this only works [in] closed systems.
>
> Please explain. I'm stupid ;-)
>
you can't undo sending a mail, for example.
> > and is useless if you don't realize you made a mistake,
> [...]
> > which is often enough the case in security context.
>
> An undo button is extremely useful after a guy breaks into your system
> and trashes everything he can get his hands on.
>
oh, no doubt. but somehow i doubt that a undo button exists for somebody
stealing your data. ;)
but what i meant is that undo won't help you if you don't even know that
your system was rooted and is being abused for sending millions of
spams.
> > also, in every professional software development environment which
> > takes its users seriously, there is a psychology expert (usually
> > called usability expert ;).
>
> There you have a fantastic reason to KISS. No
> Psychology/usability/whatever expert is required in the design of the
> rm(1) program, nor in the design of the mv(1) program, nor the cat(1)
> program, etc. I've just shown you how to save a lot of money _and_
> take your users seriously :-)
>
it's hard to discuss usability aspects of interactive programs with a
command line fundamentalist. ;-D
> > of course it is not their task to take away the gun from the user,
> > but pointing out to him that pointing it at himself is no good idea
> > is perfectly within scope.
>
> In the documentation,
>
first rule of good gui design is to make it that way that you don't need
documentation. of course it's unreasonable to expect some complicated
backend logic to be self-explanatory, but "superficial" functions should
be. effectively that means, that no regular user would ever read the
documentation of, say, kmail (except maybe the data recovery manual, har
har).
this rule is sort of inapplicable to mutt and even less to mv, but
that's the reason why those programs never will be mainstream.
> [...] In other words, we have a formula that guarantees us a fair
> world. If you're not going to stick to that formula, though, all bets
> are off.
>
yeah. that situation, however, is commonly referred to as the real
world. ;)
--
Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
--
Chaos, panic, and disorder - my work here is done.