[long] Re: Legal traps in open source *WAY* OT.

[Doug.Palmer at csiro.au]

> So every time I hit 'd' to delete an email, I also have to 
> hit 'y' three
> times to tell mutt that I really, really, really want to delete the
> message? And I have to do that 250 times a day?

Mutt doesn't have an undelete/trash folder option? If it does, then the
consequences aren't potentially disastrous. If it doesn't, then it should
get one.

> Elementary software engineering includes such concepts as making it
> quick and easy to complete tasks, not annoying. 

Hence you provide reversibility or interlocks where you can and where you
can't ...

> Confirmation 
> dialogs are
> the most annoying thing I've ever had to deal with while computing.

You provide a confirmation dialog and try to make sure that it's used in
rarely used, bulk-mode operations (such as emptying a trash folder or making
a new file system).

How many times do people use mkfs.ext2, anyway? They must be very busy
typing it if they can't take the time to pause and hit y.

And, in the meantime, if you're not totally concentrated on what you're
doing -- oh, I don't know, say you're doing something at home with the kids
fighting and dinner just on the table, or your boss is breathing down the
back of your neck, or ... -- and have hit the tab key a little too
enthusiastically, you don't lose your file system. Good programs and systems
are built to accommodate people operating under stress and with partial
knowledge; anything else is just a cop-out by programmers too lazy or
ignorant to consider HCI issues.

I might make an exception with such things as development tools, which are
required to provide powerful facilities and run without human intervention
-- and tend to have a nice waterfall where things can be rebuilt from
source. But, even there, having good interlocks and explicit overrides is a
good thing.

> A
> well designed interface doesn't require confirmation dialogs, because
> the "close" button won't be right next to the "maximise" 
> button, so you
> won't *ever* hit it by mistake.

Including the mistakes which occur when you think you've saved something,
but haven't? Or, if you've got one of those programs which automatically
saves modifications, when you don't think you've modified something but
have?

No question at all, HCIs should be designed to minimise unnecessary clutter
and rubbish. But, at the end of the day, who's going to be more pissed off,
someone who lost an hours work or someone who had to click the "yes" button?
The level of confirmation required should be tailored to the level of
consequences and the frequency of operation.

> If you ask rm to nuke everything in the current directory, you should
> expect it to nuke everything in the current directory. If you can't
> trust yourself to handle the rm command correctly, don't use it. 

Or, as many people do, you put "alias 'rm=rm -i'" and then use /bin/rm when
you really want to do a bulk remove. The act of typing /bin/rm (or -f, or
any other explicit flag) provides an internal prompt to think about what
you're doing.

But the basic question is why isn't this the default? (Well, it is in some
distributions.) Or why doesn't the ext2 file system have a default undelete
capability? Why, after years of mistakes and ancient jokes about how to
shoot yourself in the foot
http://www.netjeff.com/humor/item.cgi?file=shootfoot this basic piece of HCI
design hasn't been included? 

Saying that:

> There are plenty of experts you can pay to come and remove your 
> files for you until you can gain the required expertise.

Just begs the question as to what kind of "expert" is so incompetent as to
design an environment where you need to pay an expert to safely remove a
file.

Actually, I don't think that anyone's that incompetent. I think that the
shell interface, while excellent in so many ways, has backed HCI design for
unix utilities into a corner. Since wildcards are expanded before the
argument list is passed to a program, there's no simple way the program can
compare specific knowledge of what you are trying to achieve to the
arguments that you've given. So the program can't tell if you're about to
commit a common error, such as a misplaced space, and query it.

> 
> Does you car ask "Are you sure?" when you turn the key to "start"? Or
> when you pull the bonnet release lever? 

What are the consequences of turning the key? The car starts. Does the car
automatically move forward? 

I find it interesting that, when there's a real possibility of catastrophic
consequences -- and the possibility of doing something about it -- there are
interlocks built in. My car won't start unless the gear control is in
"park".  Or, if reversing a truck where there's a rear blind spot, a little
beeper starts up.

Or should everyone contract out to a professional driver? I think that this
point of view has direct consequences wrt the uptake of Linux (and other
unixoid OSes) in general. Saying "well, just don't make mistakes" simply
encourages the high-priest mentality. And I'd hoped that 20 years of
personal computing had at least had some effect on that outlook.