>Russ Allbery writes:
> > I'd like to back this up, and point out here that too much Microsoft
> > bashing on this one is misplaced.
>
>Sorry, Russ, this *is* a Microsoft problem. When many people make the
>same mistake, it is a failure of technology, not a failure of people.
>Software that fails to adapt to people's usual and expected behavior
>is wrong.
Well, yes and no.
Yes, in the sense that Microsoft has actively convinced people that their
products are "easy to use", when clearly they aren't: they aren't easy to
use to send RFC-conforming work via RFC-conforming channels (else I wouldn't
get so much gratuitously-MIME-encoded email, and come up against so many
web pages largely inaccessible using my own choice of browser).
And, they aren't easy to use in a way that protects against the harsh,
cruel, outside world. (There's somebody's .signature somewhere that
includes two quotes claimed to be from some MS higher-up -- one line
says something like "Windows 9[58] should not be used in a hostile
environment", the other "The Internet is hostile".)
No, in the sense that, to the extent Linux and other advocates claim
*their* favorite software is "easy to use", reduced to the extent that
their software has similar problems, they're making the same unfulfilled
promises.
The "rm -i" problem mentioned earlier highlights this.
It is, I believe, a fact that human beings can be lulled into responding
incorrectly to *any* question via simple repetition and the occasional
misdirection:
Okay to delete file foo.o (no)? y
Okay to delete file foo (no)? y
Okay to delete file foo.c (no)? y
(Oops, just deleted the source. Okay, given alphabetical ordering of
typical globbing, that particular example wouldn't happen, but is
anyone going to claim that's the result of sound ergonomic design? ;-)
(I should mention, I've gotten nearly-life-or-death prompts from programs
that were too poorly worded for me to be sure of the right answer,
sometimes in a context where on-line documentation was unavailable.
E.g. a start-up run of fsck that prompts something like `File foo is
listed as deleted, but is not deleted...fix (yes/no)?'. That particular
problem has a "local" fix, though.)
So, these problems will persist throughout all software, to the extent
that software doesn't *faithfully* represent the models humans use,
in their minds, when viewing the objects being manipulated by the
software, and doesn't then properly account for potentially risky
differences between the view a human *might* have about a situation,
and the "reality" as the computer sees it.
I know that might seem pretty weird, but a straightforward example of
something computers *must* someday account for is the difference (not
just binary, either) between *source* and *derived* content.
If the computer (apps, OS, network, etc.) knows which are source files
(including distinctions between newly-authored source and source
obtained, e.g., via the net) and which are derived files (object files,
executables, yacc/bison output, etc.), many worries, in the forms of
prompts, displays, etc., could be dispensed with.
And *that* would be an important step, but *just* a step, towards not
bothering the user with spurious queries. Which, in turn, would tend
to decrease the likelihood of incorrect responses to such queries.
(One of my favorite examples of a poorly formed query was from a
air-traffic-control tower, to a plane they saw was losing altitude
too early during the approach. The tower radioed something like
"Is everything okay up there?" The answer was "Yes", because, after
all, the pilot and crew were working on the problem -- the lightbulb
for the landing-gear-down indicator being out. Shortly thereafter,
the jet plunged into the Everglades, killing pretty much everyone
on board. Had the tower communicae been "Report your current altitude
immediately", the crew would, in my opinion, almost certainly looked
at the altimeter, reported the altimeter reading, gotten confirmation
from the tower, and perhaps realized they'd accidentally disabled the
autopilot while trying to localize the landing-gear-indicator problem.
Instead, by the time they *did* look at the altimeter, took a few
moments to discuss whether *it* was failing, and finally noticed the
autopilot was off, it was too late. Among many things, this incident
highlights the importance of asking a potentially-stressed human
for *more* information than they wish to provide at the time, and
cross-checking that information, because, even though such a question
might increase short-term stress, it could avoid disaster.)
Another example is that systems must accommodate, even insist on, is
more clear, straightforward communication.
Almost *nobody* ever really "means" `rm' when they type `rm', because
`rm' is so vastly overloaded with meaning and effect. Instead, they
*usually* mean just a *few* of the following (a partial list, I'm sure):
- I think I might need the disk space occupied by this file, later
- I'm pretty sure I don't need the information in this file
- I *know* I don't need the information in this file
- I don't want this file's name listed in this directory anymore
- I want to see if this file gets automatically regenerated later
- I want to force this file to get automatically regenerated later
- I no longer need this old version of some other file
- This file contains a potentially dangerous security breach
- I want to signal (to another process/system/user) by removing
this file from this (shared) directory
- I want to run my `rm' script, which is friendler than the default
The (sometimes subtle) differences among the above can be teased out,
if they aren't already evident, by asking yourself just how faithfully
a system would carry out the simple `rm' request in the context of
the following system facilities:
- The system chooses whether to prompt before deletion
- The system chooses whether to produce a list of prompts for
consideration, by the user, at a later time, picked by the
user
- The system chooses whether to immediately reclaim the disk space
- The system chooses whether to allow for "un-rm"-ing (undeleting)
the file
- The system chooses whether to make a backup copy of the file
- The system chooses whether to simply hide the file (e.g. shove
it into a "trashcan" the user can choose when to *really* delete
it)
- The system chooses when and how to notify other users sharing the
same directory structure that the file has been removed (via making
that removal visible in *their* view of that directory)
- The system chooses whether to immediately overwrite any persistent
memories containing the file's contents with garbage
Note how some of the above seem to interact and conflict. Also, some of
them might have seemingly simple answers, which might only push the
complexity elsewhere (e.g. the trashcan approach can be naively implemented
in a way that doesn't scale well, up to millions of files and/or millions
of users sharing access to the directory).
(I could go on and on, but I already have. :)
So, until we have software that has some clue about what we are thinking,
and we have the ability to actually tell the computer what we think we're
trying to do (I call this Say What You Mean (SWYM), as versus Do What
I Say (DWIS), the difference being most evident in language/interface
design), the problem won't be *near* to being solved. (And, it's highly
questionable whether it ever *will* be solved, in the sense of coping
with all humans in all situations. That would presumably require every
automaton interacting with a human to faithfully model the current,
and thus predict the future, mental state of the human.)
The problem, therefore, isn't owned by Microsoft, though MS does
probably do more to amplify the problem than any other entity on
the planet. In a sense, MS does the equivalent of selling houses
with electricity supplied in huge voltages by open wires about
6" off the ground, where kids can easily get at it. But we don't have
anything quite like Underwriter's Laboratories (UL) listings -- yet --
to keep them from so easily profitting from such clearly dangerous
practices.
(One of the main reasons I didn't, long ago, just plunge into this whole
GUI/iconic approach, when it came to writing new programs, is because
I saw the perils in assuming they'd really produce "easy-to-use" results.
I'd rather wait and do it right. MS employees prefer earning $B by
doing it wrong and selling people the results. :)
tq vm, (burley)
