Making paper go away
ucbvax!works
You've fallen into the same trap that most people do. If what you
want is the ability to scan quickly thru a document, this suggests
that a capability the computer should have is to scan quickly thru a
document. If you want to make notes, the computer should provide the
ability to make notes. If you want to doodle in color, the computer
should provide the ability to doodle in color. What you've stated is
not reasons for retaining paper, but a specification of what
capabilities we need in a computer if we want paper to go away.
Now current technology makes a lot of this extremely difficult. For
example, at very slow data rates (say, 9600, which is as close to DC
as one would care to get), it is unreasonable to browse thru most
large documents. With 24-line screens, finding enough context to
make sense of what has been typed is nearly impossible. But saying
that online retrieval will never replace paper is silly; it means
you've failed to adapt the computer to what people need.
The observation that it is useful to print things out on paper so
they don't have to be stored online is likewise looking at the
problem from the wrong side. What I want is a method of taking silly
pieces of paper and getting them onto the machine so I don't need to
store the paper! Fact: secondary storage is cheap, is getting
cheaper, and even primitive archiving techniques make it look even
cheaper. Why should I have to do something (file a piece of paper)
that the computer can do more effectively?
I keep all my source listings in hardcopy form. Why? Because it is
faster to look something up on hardcopy than online. Why? because a
24x80, 9600 baud terminal is too small and too slow to accomodate me.
If I had four or five 60-line screens with a typical effective
bandwidth (including disk latency, etc.) of about 100Kbaud, I
wouldn't need to print anything. One way of achieving this is to use
multiple windows, but it is not the only way (another is to have four
or five 60-line terminals).
If paper is more effective, then there is a mismatch between the
needs of the person and the software. I don't see anything which has
yet made that statement even suspect. What we need to do is explore
how to eliminate that mismatch.
joe
ucbvax!works
In response to the message sent 14 July 1981 1211-EDT (Tuesday)
from Joe.Newcomer@CMU-10A
Well, there is already a way to scan quickly through files:
it's called structured (or hierarchical, or whatever) files
a la Engelbart's NLS (now called Augment) and (Ted Nelson's ?)
Hypertext.
You can look at one or more levels, and independently one or
more lines of those levels, and open up or close up the part
on your screen to see more or less. It makes it very fast
to see what is in a document you've never seen before, or
to find something specific in an old document when you don't
know it's exact location. You may even be able to "address"
desired text by context. Combined with a windowing capability,
a pointing mouse, and auxiliary 5-key keyset, this gives an
extremely powerful tool - now if only it came packaged in a
briefcase-sized personal DEC-10...
Structured files are great, but do have an interface problem
because the rest of the world uses "flat" files - it's not
always easy to translate between the two - especially if there
is highly-formatted text like columnated tables, or "drawings"
(dot-and-dash boxes, etc.). Of course, the interface with the
rest of the world is a problem when using *any* advanced system
- I might have a little trouble putting a Star icon in a netmail
message, too.
-Rich
-------
ucbvax!works
One of the main problems in dealing with structured files is that
most operating systems give you "the files" and "the user space"
and you're on your own to figure out what to do with the files.
In Hydra, it was possible to define the text string transformation
of a file as part of the "subfile" type description. No matter
how peculiar the internal representation of the file might be,
the interface it provided to the outside world was a sequential
"flat" file suitable as input to a compiler or lister. Of course,
there were other interfaces which were presented; internally, the
editor for that file type was powerful enough to manipulate the
full representation. One could also have a "display" interface
by which illustrations were made visible on a CRT, or a "printer"
interface by which the file was presented in a form suitable for
printing (e.g., a Press file format would have been possible).
This is necessarily a simplified view, and we didn't begin to
explore all the problems, but the really important idea is that
at the basic interface, an ordinary program could NOT get at the
bits of the file. Only the bits presented by the file interface.
This abstraction is critical in protecting users from file repre-
sentations, and I consider any file system which does not support
at least this form abstraction to now be hopelessly behind the
state of the art.
I hope to do some more research in this area in the next few
years. The Hydra idea may NOT be the best, or even close to
right, but it is a whole lot better than any conventional file
system.
(In Unix, it is possible to use pipes to provide the transfor-
mation; a filter converts a complex file to a sequential byte
stream. Alas, Unix does not provide the protection necessary
to keep any random program from trashing the file by THINKING
it is a sequential byte stream file. Nonetheless, their heart
is in the right place. This is one of the reasons I think
pipes are a winning concept).
(The message based operating system for Spice, called Accent,
makes it possible to build systems with this style of
interaction).
joe
ucbvax!works
If paper is more effective, then there is a mismatch
between the needs of the person and the software.
Joe's implication that any mismatch between people and computers
needs to be eliminated is similar to the attitude that gave rise
to the BART fiasco. This zeal to automate everything is misplaced.
Some products already do their job quite well. Paper, for example.
One thing I particularly like about paper is that I can leave
it on the beach while I'm swimming without being too concerned
that someone is likely to walk off with it. Is anyone willing to
predict which century will see portable computers able to compete
with paper as an improbable target of petty thieves?
A more appropriate attitude would be to keep an eye open for
opportunities where the computer can outperform the traditional
product. I suspect this is what Joe really has in mind when
he talks about automating paper. Paper has its disadvantages
as well as its advantages. Pen-and-paper is a poor medium
for speed of text input (many of us type twice as fast as we
write, though presumably not Steven Gutfreund, who says he
prefers mice and chordsets to 4-row QWERTY keyboards). Paper
is inconvenient to transmit, with a delay measured in days
rather than minutes. It is difficult to search associatively.
It does not lend itself to alteration. Making duplicates for
redundancy (e.g. guarding against fire etc.) is awkward.
Text and graphics macros (Letraset, stencils, french curves,
rubber stamps, etc.) are relatively inflexible. Conversion
to machine readable form is much harder than the reverse
direction.
The moral is that while computers outperform paper in some
categories, it is wishful thinking to imagine that it will
also soon come to dominate in all the remaining categories.
Needless to say, the moral applies equally well to other
products besides paper, e.g. BART drivers.
Applying this to AI, I would prefer to characterize AI
not so much in terms of passing Turing's test as looking
for additional human activities that lend themselves to
automation.
ucbvax!works
Actually, your example is quite amusing. We were recently at a
conference at Pajaro Dunes. One of our participants was walking
along the beach during one of the interludes, and left his book
on the beach while he went into the water. When he came out, he
found that someone had stolen his book.
Yes, paper is more effective for some things RIGHT NOW. While I
don't believe automating blindly is a good idea, for most values
of use of paper I would prefer to use a computer. Even if I
produce hardcopy so it can be carried around, read on beaches and
busses, etc., I prefer to produce it via the computer. There are
lots of cases where paper is more convenient ONLY because of limi-
tations of the computer (e.g., 9600 baud slow lines). And when
computers will cost only $8.95 (or free with a deposit of $500),
there will be far less reason to walk off with one. We have to
quit thinking as if computers will always be expensive, and decide
what we can do with them when they are not. In fact, assume the
cost of the computer is ZERO. Now, what would you LIKE to do with
a computer? What capabilities should it possess at the interface?
Assume a communication cost of ZERO. How would you like to commu-
nicate with other computers? Now, at any given instant we have
to temper these ideas by the rather nasty fact that computers and
communications really do cost money. But that should NOT limit
our imaginations. A Dorado is a good example of what happens if
you let ideas not be limited by technology, and technology comes
along. Things which were unbelievably bad to run on an Alto run
just fine on a Dorado.
Don't tell me automating everything is bad. I don't believe it.
Automating everything INCORRECTLY is bad. I'd rather worry about
how to do it right, even if right isn't possible, than to not
think about the problem because this year's technology can't
support it.
joe