Article View: comp.windows.misc
Article #754Re: every icon is an object
From: jqj
Date: Tue, 02 Jun 1987 15:16
Date: Tue, 02 Jun 1987 15:16
40 lines
2951 bytes
2951 bytes
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.
Technical Details
Message-ID:
<879@gvax.cs.cornell.edu>Path:
arc1-ca.pugleaf.net!utzoo!utgpu!water!watmath!clyde!rutgers!gatech!udel!rochester!cornell!gvax!jqjReferences:
<8705190042.AA14664@cogsci.berkeley.edu>Show Full Headers
Complete Article Headers
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: arc1-ca.pugleaf.net!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