karlton@decwrl.DEC.COM (Philip Karlton) (05/19/87)
In article <8705190042.AA14664@cogsci.berkeley.edu> boring!jack@cogsci.berkeley.edu (Jack Jansen) writes: >If you view every icon as an object that can be activated, there >are only two primitives that you need to do almost everything: > >- Activating an object ... >- Feeding an object ... > You might try taking a good look at the design for Xerox Star user interface. It first became commercially available in 1980 or 1981. The implementation had more than one performance bug. PK
jqj@gvax.cs.cornell.edu (J Q Johnson) (05/24/87)
In article <9954@decwrl.DEC.COM> karlton@decwrl.UUCP (Philip Karlton) writes: > boring!jack@cogsci.berkeley.edu (Jack Jansen) writes: >>If you view every icon as an object that can be activated, there >>are only two primitives that you need to do almost everything: >>- Activating an object ... >>- Feeding an object ... >You might try taking a good look at the design for Xerox Star user interface. >It first became commercially available in 1980 or 1981. The implementation had >more than one performance bug. Actually, the Star interface, and its successor ViewPoint (which has fewer performance problems) has at least 3 primitives: opening/activating, feeding to another icon, and examining/changing properties. Typical properties of an object include the name of a file, the generation retention count of a directory, and switches that one might want to pass to a particular program. Seems to me this third generic primitive is extremely important in an icon-based system as a means of setting defaults. It also nicely parallels the property-setting functions of a typical wysiwyg editor. For example, in ViewPoint the same "PROPS" key is used to set properties of icons and properties of text within the editor (text properties include all sorts of things--font, line spacing, width and dashing of graphics, number of columns in a table, etc. One problem with the "feeding the object" primitive: how do you specify where output should go? In ViewPoint, destination is hardwired into the particular process icon. For example, an ascii-to-internal converter always makes another icon on the desktop, while a printer always sends the output to a physical laser printer. How could one usefully extend the "feed to by dropping on top of" metaphor to UNIX-style pipes?
crs@osu-eddie.UUCP (Craig Stevenson) (05/26/87)
As a user of the Xerox Viewpoint (&XDE) workstations, allow me to comment: > One problem with the "feeding the object" prmitive: How do you specify > where output should go? In viewpoint, destination is hardwired into the > particular process icon Granted, Viewpoint hardwired it. However, it doesn't have to be that way. I would seem that the properties of the printer could include a switch to set the destination e.g. the "chooser" on the Mac. > For example, an ascii-to-internal converter always makes another > icon on the desktop. ... How could one usefully extend the "feed to by > dropping on top of" metaphor to UNIX style pipes? Actually, not all operations in Viewpoint automatically create a new icon on the desktop. Some operations will convert the cursor to a small icon, indicating that it is waiting for *you* to point & click to where you would like the new object to appear. This would seem to be able to be extrapolated to a generalized system for taking output of one process and using it as inputing into the next pipe. I would like to raise the general question of how to best to handle "pipes" in an icon oriented system. I am new to this newsgroup and this topic of discussion. If this topic has already been beaten to death, please send me the autopsy. Otherwise, I look forward to hearing some new ideas. -- Craig -- Craig Stevenson The Ohio State University ARPA: crs@Ohio-State.arpa Columbus, Ohio UUCP: ...!cbosgd!osu-eddie!crs (614) 292-7347
steve@mimsy.UUCP (05/26/87)
In article <868@gvax.cs.cornell.edu> jqj@gvax.cs.cornell.edu (J Q Johnson) writes: [ ... ] >One problem with the "feeding the object" primitive: how do you specify >where output should go? In ViewPoint, destination is hardwired into the >particular process icon. For example, an ascii-to-internal converter >always makes another icon on the desktop, while a printer always sends the >output to a physical laser printer. How could one usefully extend the >"feed to by dropping on top of" metaphor to UNIX-style pipes? There was an interesting paper presented at the Summer 1986 Usenix (the one in Atlanta). It was entitled, "A Data-Flow Manager for an Interactive Programming Environment," and was written and presented by Paul E. Haeberli of Silicon Graphics, Inc. In this paper and presentation, the author described a set of simple changes to a window-based environment that I feel was the best mix of pipes and windows that I've ever seen. (Not that I've seen all that many, though.) The idea was that programs could be written to provide all sorts of inputs and outputs... all of which had associated with them information as to what input was expected or what output was provided. The window manager provided a visual paradigm by which tools could be tied together. There was some mouse function that popped up menus containing the names of the various inputs and outputs for a given tool, and the actual connections were displayed as lines/pipes on the screen. The pipe information could be hidden so that it wasn't always in the way -- something which I thought was a nice touch. Haeberli showed a videotape in which he (or someone else, but I'll assume it was him) took a tool that provided rotation and translation information, a tool that provided images, and a tool that displayed images, and tied these simple tools together to build a tool that could display an arbitrary image under arbitrary rotations and translations. The final tool was something that would have been quite time-consuming to code as a unit, but each tool itself was quite simple. It was *awesome*. I was impressed, and I don't think that I was the only one. I don't think there was any hard-core typing information associated with the input and output streams, but I'm not sure. Even if there wasn't, I'm not sure that the results of feeding a x-y-z output into an input that was expecting an image would be any worse than, say, cat'ing a raw disk device into troff's stdin. Some special coding within tools is required, but special coding (admittedly, not a lot of it) is required to use stdin and stdout, too. The implementation sounded quite simple, too. I wouldn't put it past someone to knock out a simple version using Your Favorite Window System For Which You Have Source and sockets of some flavor or another in a couple of months at the outside. (Of course, there's probably some subtleties here that I'm missing and that make the problem much harder.) If anyone does an implementation for SunView, NeWS, or X, I'd love to take a look... -Steve -- Spoken: Steve Miller ARPA: steve@mimsy.umd.edu Phone: +1-301-454-4251 CSNet: steve@mimsy.umd.edu UUCP: {seismo,allegra}!mimsy!steve USPS: Computer Science Dept., University of Maryland, College Park, MD 20742
bob@tut.cis.ohio-state.edu (Bob Sutterfield) (05/27/87)
In article <6787@mimsy.UUCP> steve@mimsy.UUCP (Steve D. Miller) writes: > ... > There was an interesting paper presented at the Summer 1986 Usenix >(the one in Atlanta). It was entitled, "A Data-Flow Manager for an >Interactive Programming Environment," and was written and presented >by Paul E. Haeberli of Silicon Graphics, Inc. > ... > Haeberli showed a videotape in which he (or someone else, but I'll >assume it was him) took a tool that provided rotation and translation >information, a tool that provided images, and a tool that displayed >images, and tied these simple tools together to build a tool that >could display an arbitrary image under arbitrary rotations and >translations. It sounds like they've re-invented (or borrowed) some ideas from the Evans and Sutherland Picture System's environment. As far back as the PS-300 in 1983 or so, this sort of stuff was available, and maybe before then or on earlier PSs. The native language of the box (68000-based, coupla Megs RAM) had a Pascal-like syntax for dataflow system. While the machine had no window system per se (it was oriented towards fast monochrome vector graphics), it had lots of user interface toys like knobs, buttons, light pens, etc. There was a development environment (PIGS?) that allowed one to manipulate pictures of boxes representing functional elements of a dataflow circuit. An instance of Rotate could be picked from a palette, rearranged with the light pen, and outputs attached to inputs of other boxes, the final one of which represented the display itself. Boxes' inputs could be wired to pictures of the input devices as well, to make Knob3 control X on the Scaling box or whatever. To test your system, I think there was an imbedded interpreter, so that you could hide the diagram of your circuit and turn on its function and play with knobs for debugging. All this was just a wonderful editor, that spat the native Pascal-like language out the back for compilation when you were done prototyping. My details may be foggy - it was a long time ago and I didn't know much about user interface design then (many would say I still don't :-) and I never got the chance to use it much. But I watched Julian Gomez do wondrous things with it, and it really felt like The Right Way to do what it was doing. -=- Bob Sutterfield, Department of Computer and Information Science The Ohio State University; 2036 Neil Ave. Columbus OH USA 43210-1277 bob@ohio-state.{arpa,csnet} or ...!cbosgd!osu-eddie!bob soon: bob@aargh.cis.ohio-state.edu
rjf@eagle.ukc.ac.uk (R.J.Faichney) (05/28/87)
Summary: Expires: Sender: Followup-To: In article <6787@mimsy.UUCP> steve@mimsy.UUCP (Steve D. Miller) writes: >[..] >If anyone does an implementation for SunView, NeWS, or X, I'd love to >take a look... > > -Steve I'm working on something like this (actually, The Interconnection of Highly Interactive Software Modules) right now, supported by the UK Science and Engineering Research Council. An actual product is not the aim of this research - we are in the early stages yet - but there may be a by-product. Please email me if you are interested. Robin Faichney rjf@uk.ac.ukc ...mcvax!ukc!rjf
shebs@utah-cs.UUCP (Stanley Shebs) (05/28/87)
In article <3614@osu-eddie.UUCP> bob@tut.cis.ohio-state.edu (Bob Sutterfield) writes: >In article <6787@mimsy.UUCP> steve@mimsy.UUCP (Steve D. Miller) writes: > It sounds like they've [Haeberli] re-invented (or borrowed) some ideas >from the Evans and Sutherland Picture System's environment. As far >back as the PS-300 in 1983 or so, this sort of stuff was available, >and maybe before then or on earlier PSs. >[...] > There was a development environment (PIGS?) that allowed one >to manipulate pictures of boxes representing functional elements of a >dataflow circuit. [...] Probably folks from E&S are more competent to comment on this, but unless I'm mistaken, you're referring to the "network editor" written by Dave Schlegel. I used it a few times; not too novice-friendly, and was a little slow, but very sophisticated. Also necessary, since the "Pascal-like" language has approximately the feel of assembly language, what with dozens of little connection numbers that all have to match up! I don't think the dataflow language of the PS-300 is sufficiently appreciated by the language community - I found that programming dataflow seems to need some rather strange synchronization-type operators of a sort never mentioned in the literature... The language is quite powerful - Sandra Loosemore wrote a flight simulator complete with SLC streets and the Wasatch mountains. The whole thing runs locally in the PS-300! stan shebs shebs@cs.utah.edu
jqj@gvax.UUCP (06/02/87)
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.drg@utai.UUCP (06/04/87)
We've done some work here at UofT on a system that allows you to interactively wire up icons on the screen to perform some task. The icons can represent programs or physical devices like keyboards and D/A converters. We've used it to control a music synthesizer, and to build a filter simulation package. We've been calling the idea Virtual Patch Cords (VPC). In looking around, we have discovered at least half a dozen other systems that have the same flavour. Here is a partial list of the papers we know about. If anyone has some more that could be added to the list, please let us know. %A David Blythe %A John Kitamura %A David Galloway %A Martin Snelgrove %T Virtual Patch-Cords for the Katosizer %J International Computer Music Conference 1986 %P 359-363 %I Computer Music Association %C San Francisco, CA %D Oct 1986 %K virtual patch cords ICMC %X An object-oriented graphics system is presented which allows a musician to program a very versatile signal processor/synthesizer by drawing a block diagram of the desired 'patch'. %A David Galloway %A David Blythe %A Martin Snelgrove %T Graphical CAD of Digital Filters %J IEEE Pacific Rim Conference on Communications, Computers and Signal Processing %C Vancouver, BC %D June 1987 %K virtual patch cords digital filters %X A system that allows a filter designer to wire together basic filter elements on the screen, then watch them react to simulated inputs. %A Peter Desain %T Graphical Programming in Computer Music: a Proposal %J International Computer Music Conference %P 161-166 %I Computer Music Association %C San Francisco, CA %D Oct 1986 %K direct manipulation virtual patch cords ICMC %X Lisp based graphical environment for building up patches. Suggested application is programming of signal processors, but no back end implemented. Discussion of direct manipulation versus conversational metaphors, advantages and disadvantages thereof. Other suggested applications: studio patches, music composition, UNIX pipes. %A Andrea A. diSessa %T Notes on the Future of Programming: Breaking the Utility Barrier %E Donald A. Norman and Stephen W. Draper %B User Centered System Design: New Perspectives on Human-Computer Interaction %P 125-152 %I Lawrence Erlbaum Associates %C Hillsdale, NJ %D 1986 %K device programming virtual patch cords boxer direct manipulation %X Mainly an article on Boxer, a replacement for Logo at MIT. Contains 2 page description of "device programming", which fits virtual patch cords to a tee. %A Paul E. Haeberli %T A Data-flow Environment for Interactive Graphics %J Proc. of the Second Computer Graphics Workshop %P 1-12 %I USENIX Association %C El Cerrito, CA %D December 1985 %K virtual patch cords %X A set of slides given at a talk. Describes a virtual patch cord system for an Iris. Contrasts virtual patch cords and the UNIX shell. Intended for use in a graphical editing environment, with sliders, recorders, 2 and 3D curve editors, etc. No implementation at the time. %A Paul E. Haeberli %T A Data-Flow Manager for an Interactive Programming Environment %J USENIX Summer Conference Proceedings %P 419-428 %I USENIX Association %C El Cerrito, CA %D June 1986 %K virtual patch cords %X An expanded description of virtual patch cord work at Silicon Graphics. Description of implementation. Comparison to UNIX shell. Applied to graphical editing environment. No macros yet. %A Byte %T Labview: Laboratory Virtual Instrument Engineering Workbench %J Byte Magazine %P 84-92 %D Sept 1986 %K VPC virtual patch cords %X This system is very close to VPC, but is oriented towards real time instrument control, over GPIB. It has hierarchy and a full set of programming primitives, including looping and recursion.
fgm@icdoc.UUCP (06/04/87)
In article <879@gvax.cs.cornell.edu> jqj@gvax.cs.cornell.edu (J Q Johnson) writes: >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 > >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. There IS one metaphor in common use on the Mac system which handles more complex types of operation: the palette. For example, in Macpaint, Macdraw etc. the user selects a tool from the palette and then clicks in the drawing pane. The exact meaning of the click depends of course on the individual tool. We could have each filter be represented by an entry in the filter palette. The standard user interface for such a filter tool is to connect two (or more) icons in the desktop. The first click would select the source icon and the when the mouse is released (or the second click depending on your preferences) the mouse should be over a target icon. If it is not over a target icon then a new output object is created. Connecting the results of several filters is accomplished by sucessive selection of different filters from the palette. In a truly multitasking system the first filter operation is executed while the user makes up his mind what to do next. -- Department of Computing Imperial College Janet: fgm@uk.ac.ic.doc London, SW7 2BZ UUCP: ...{backbone}!doc.ic.ac.uk!fgm England
peter@sugar.UUCP (06/11/87)
> >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. This is basically a dataflow system. I suggested something like this a couple of years ago and watched it vanish without a trace. One thing to consider is that some filters have more than one output... for example "tee". Some filters have more than one input, for example "diff". The actual mechanism for building the picture may vary, but the result should look something like this: ------ --------------- |FILE|-->--| IN | | |___/ | | DIFF | ------ -------_______| ------------------- ------ |FILE|-->--| IN | OUT |-->--| IN | TEE | OUT |-->--|FILE| |___/ |_____|_______| ------------------- |___/ | OUT | ------- | V | ------- |LPR2 | \__,--' The problem comes from the idea of icons being non-atomic. Would you start things up by putting the DIFF in, then dropping the files into its input baskets? Perhaps having pipelines permanently affixed to the icon and you connect them tinkertoy fashion?
kent@xanth.UUCP (06/11/87)
While you're looking at examples of wiring up icons to do jobs, don't miss
the educational program "Rocky's Boots", appearing on a home computer near
you. If it's simple enough for kids to do, it can't be all bad.
Kent.
--
Kent Paul Dolan, LCDR, NOAA, Retired; ODU MSCS grad student // Yet
UUCP : kent@xanth.UUCP or ...{sun,harvard}!xanth!kent // Another
CSNET : kent@odu.csnet ARPA : kent@xanth.cs.odu.edu \\ // Happy
USPost: P.O. Box 1559, Norfolk, Virginia 23501-1559 \// Amigan!
Voice : (804) 587-7760 -=][> Last one to Ceres is a rotten egg! -=][>lsr@apple.UUCP (06/15/87)
In article <1205@xanth.UUCP> kent@xanth.UUCP (Kent Paul Dolan) writes: > >While you're looking at examples of wiring up icons to do jobs, don't miss >the educational program "Rocky's Boots", appearing on a home computer near >you. If it's simple enough for kids to do, it can't be all bad. I've never tried Rocky's Boots, but I have tried a similar program called Robot Odyssey. In that program you have to write up robots to perform tasks for you. The reasons is that you are stuck in an underground world and are trying to get out of it. You wire circuits to control the robots' thrusters, sensors, radio, etc. You have a limited supply of components, so you also have to burn chips. (Burning a chip creates a compiled version of your circuit, and allows you to reuse its componenets.) -- Larry Rosenstein Object Specialist Apple Computer AppleLink: Rosenstein1 UUCP: {sun, voder, nsc, mtxinu, dual}!apple!lsr CSNET: lsr@Apple.com
larry@ingres.Berkeley.EDU (Larry Rowe) (06/24/87)
Several comments on the recent discussions: 1. Paul Haberli gave a demo of his pipe-fitting system at Berkeley 18 months ago. It was very impressive. A student implemented a (buggy) version of it in a user-interface class I teach here. Paul's system used shared files to communicate which required a kernel modification. Our system used 4BSD sockets so no kernel mods were required. We also used the X windowing system rather than the silicon graphics windowing system. Another student took this package and implemented some simple tools for accessing a relational database. I wrote a paper describing the system. I will be glad to send a copy of it to anyone who sends email to me at Berkeley. Please include your postal address. The paper includes screen dumps that I had to cut/paste into the text. I seemed to have misplaced/lost my multimedia, wysiwyg document editor....:) I'd be glad to send folks the code, but it is not really usable at the moment. The student who did the 2nd project has left and we never really made it run reliably. If there is enough interest, I can probably dig up the code and send it to folks. Better yet, if someone wanted to pick it up and work on it, I would be thrilled. 2. Interesting comment on the difficulty of publishing user interface papers. Paul sent his original paper to 3 places before it was finally accepted by Usenix. I've sent my paper to 2 conferences that both rejected it (close votes, but not good enough) and have now sent it to a third. Neither paper is very deep technically, and in a sense, communicate an obvious idea once you've thought about it. the idea is simple enough that folks can't believe it's worth publishing. of course, we still labor with lousy user interfaces because .... Sigh! 3. I too strongly support the creation of a user-interface newsgroup. Is someone going to do the survey? larry