Path: utzoo!attcan!uunet!lll-winken!lll-ncis!helios.ee.lbl.gov!pasteur!ucbvax!WATSON.BBN.COM!dan
From: dan@WATSON.BBN.COM
Newsgroups: comp.society.futures
Subject: Re: desktop of the future
Message-ID: <8901131824.AA11890@multimax.encore.com>
Date: 12 Jan 89 18:58:46 GMT
References: <312@gloom.UUCP>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 49

I said:
>What I want is a way to look at hundreds or thousands of files at
>once, in such a way that possibly-important properties, whatever they
>are, spring out at me. 

Cory said:
>It sounds like you would be in a world of sensory overload... picture
>the cockpit of an airplane... now increase the number of controls,
>dials, etc 100 fold.  Now find the useful data with everything
>blinking lights at you to get your attention.

Not at all.  I'll try a more concrete example.  The screen you're
looking at right now can show you at least 2000 ASCII characters or
so, but you don't suffer information overload.  If each of those
characters represented a process, and you specified that processes
with different amounts of cumulative CPU time should be represented as
one of the characters ".", ":", or "X", you could instantly spot the
long-running processes in far less time than it would take to scan a
typical "ps -l" for high numbers in the cpu time column.  When the
number of entities gets large, it's the traditional way of displaying
things that causes information overload.

But I *would* suffer from sensory overload if I could not adjust the
display parameters as quickly and easily as I adjust the steering angle
of my car.  I'd need to move through many changes to get the display right
and avoid the problem you describe.  This is where new hardware, like
the DataGlove, might come in.

>Looking at files is a rather static view of the system...

Very true.  I was just giving an example from my experience.  Actually
I think the problem with files is not that they are "static", since any
information system is going to have static pieces of information, but
that files almost always represent the wrong level of granularity.  They
either have too much or too little information in them.  (And of course
in traditional systems there are no links between files other than 
being in the same directory.)

> ... to actually see the data as it is flowing around the system... 

There are systems that do this, in circumstances when it's appropriate.
A USENIX in the last year or two featured a signal-processing system
which used icons to represent filters of various kinds, tape recorders,
oscilloscopes, etc.  You could interactively couple them together in
various ways and "see the data".  I've often wanted the same thing with
UNIX pipes; my ten-stage pipelines are very elegant but real killers
to debug.

	Dan