Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!gatech!udel!rochester!cornell!gvax!jqj
From: jqj@gvax.UUCP
Newsgroups: comp.windows.misc
Subject: Re: every icon is an object
Message-ID: <879@gvax.cs.cornell.edu>
Date: Tue, 2-Jun-87 11:16:44 EDT
Article-I.D.: gvax.879
Posted: Tue Jun  2 11:16:44 1987
Date-Received: Fri, 5-Jun-87 03:49:07 EDT
References: <8705190042.AA14664@cogsci.berkeley.edu>
Reply-To: jqj@gvax.cs.cornell.edu (J Q Johnson)
Organization: Cornell Univ. CS Dept, Ithaca NY
Lines: 39

I think we need some perspective on what we're trying to accomplish.  I believe
our goal is to design a *simple* yet powerful user interface.  Neither the
Mac/VP icon interface nor UNIX shell/pipes provides ultimate power.  For
example, I've often wished that I could more easily do Teeing and pipefitting
in shell programs. [see PS below].  But for many purposes pipes, with their
single input and output streams, are a very nice metaphor for program
decomposition; they aren't powerful, but they are powerful enough and
they are simple to understand.  Similarly, "opening" and copying into
another icon are simple metaphors for complex operations, ones we know
from experience that even an intelligent 3 year old can understand.

I don't think we understand user interfaces well enough to design a simple
icon-based interface with the power of the various graphical programming
languages I've seen.  The question from my perspective is whether we can
easily extend the Mac/VP interface, which we KNOW is easy for novices to
understand.  The extensions must be very clean and elegant, yet must provide
major increases in power.

So far, the best extension I've heard that provides pipes is a general
convention that some icons are filters, and that depositing on a filter
icon will pop up an output icon next to it.  Problems:
     1/ if that space on the display is already occupied, a more complex
	scheme for the placement of the output icon is needed.  This makes
	it very hard to design a macro language (programming by example), since
	the macro can't use relative placement to find the output icon.  Note
	that what I'm really saying is that I want not just UNIX pipes but
	a shell as part of my icon-based system.
     2/ being totally icon-based is fairly noninteractive.  It works well
	for pipe examples that could substitute a temporary file (i.e.
	in which "a|b" is equivalent to "a>/tmp/$$;b</tmp/$$") but what about
	filters like "more" or "tail -f" (using tail to look at a growing log
	file).
	
P.S. on pipefitting:  my most recent problem was wanting to write a shell
script that would concatenate stdin and an internally generated header.
I had program "headergenerator" already.  So I could do:
	#! /bin/sh
	headergenerator $@ >/tmp/foo
	cat /tmp/foo -
But using a temporary file for such a simple problem was inelegant.