ietf-822
[Top] [All Lists]

Human Factors of email

1991-11-27 04:54:02
This was posted in comp.human-factors in response to a message
referencing RFC-XXXX that I posted.  Quoted material is mine, the rest
is by Bob Kerns.  Folks, what's your opinion regarding Bob's
pessimistic world view?  Should we be more optimistic now?  What is
our answer to Bob's non-rhetorical question?

--Guido van Rossum, CWI, Amsterdam <guido(_at_)cwi(_dot_)nl>
"The lawnmower.  Surely such a gadget could not have been generated
independently in two separate areas."

-----------------------------------------------------------------------
From: rwk(_at_)crl(_dot_)dec(_dot_)com (Bob Kerns)
Newsgroups: comp.human-factors
Subject: Re: Human Factors of email
Date: 27 Nov 91 01:31:59 GMT
Organization: DEC Cambridge Research Lab

In article <4781(_at_)charon(_dot_)cwi(_dot_)nl>, guido(_at_)cwi(_dot_)nl 
(Guido van Rossum) writes:
Bob Kerns:

Well, both of you: multimedia e-mail may be here faster than you
think.  At this very moment a group of clever (*) people are cooking
up an official Internet standard (dubbed RFC-XXXX for now) for the
transfer of various new types of e-mail.  Part of the standard
("richtext") will be a standard way to indicate font changes and the
like in a document.  This means that the constraints of the medium as
perceived by Erik will change.  Being an Internet standard may mean
that both reasons mentioned by Bob Kerns will fade away, at least to
some extent, within the Internet.

[This is not a rhetorical question.]

Why do you believe yet another standard will do the job?
There's a long history of standards in this area, which have
NOT done it, which leads me to believe the inertia is very high.

Times ARE changing, so I don't reject the concept that another
standard will do the job, but I don't automatically accept it,
either.

Admittedly, the Internet community has a pretty good track record
for actually getting things done, as these things go.  But in terms
of mail, a lot of the time the Internet mail standards have been
held back because N flavors of Unix with NY local varients screwed up
if you used feature X in your headers, and so various parts of the
standard never came into play, because people who otherwise followed
the standard didn't dare to use them.

It seems to me that the same social factors apply even more
strongly to multi-media mail, both at the implementor's level
and the user's level.

To illustrate the problem at the user's level:

If you use Symbolics Zmail, you've had the ability to use multiple
fonts, languages, even diagrams in your mail.  But after being flamed
by crippled readers who couldn't handle it, I avoid all use of multiple
fonts in mail.

By the way, I can think of another reason why mm mail has caught on so
slowly: sheer equipment price and availability.  While the happy few
may be used to color RISC workstations for years, I would guess that
by far the majority of e-mail and netnews articles are composed and
read on equipment capable of little more than a single size monospaced
font with 2 or 3 variations.

Has anyone tried to quantify this?  Frankly, I know of fewer operating 
character-cell terminals than I do typewriters. ... One terminal, and
two typewriters.  The character-cell terminal operates our soda machine
here.  The typewriters fill out multi-part shipping forms and the like
occasionally.

I don't claim I'm typical, which is, of course, why I have to ask.

RFC-XXXX has a nice provision for
phase-in (at least in theory): a message may be sent as a list of
alternate forms of the message, where a mail reader program should
pick the first (or last, that's still subject to debate :-) form that
it's able to handle.

[I take this as a small piece of the answer to my non-rhetorical
question above, btw; namely that you're trying to solve the problems
which have held back implementation of prior standards].

I hope this isn't your only mechanism for dynamic adaptability.

I know of people doing active work in the area of automatic
transliteration of foreign scripts, and also there are a number
of people working on machine translation.  The issue of whether
a reader can handle a particular type of message is really multi-
dimensional.  I would hate to have to revert to an ascii message
with the pictures stripped out, just because my machine can't
handle Arabic, just Japanese, and the .signature included an
Arabic quotation

It does sound suitable for phasing in the standard as a whole,
however; it should be easy for old-fashioned readers to just
read the first ascii part, and punt when they come to the
unreadable version.  (Which argues for it being better to pick
the *LAST* version you can handle, so the dummest reader can
just show the user the bare ascii version up front).

<Prev in Thread] Current Thread [Next in Thread>