sas@beta.lanl.gov (Steven Smith) (12/17/88)
We are at the beginning of a design effort for an operator interface for an integrated subsystem of a large supercomputer network. This interface will replace (supercede?) an existing menu interface. There are zillions of issues and I can't approach them all. The issues I am looking for feedback on here are primarily general direction and principles. We have read some literature and each have our own experiences and biases. This is far from enough. Description: The organization is Los Alamos National Laboratory (LANL), the facility is the "Integrated Computing Network" (ICN) and the subsystem is the "Print And Graphics Express Station" (PAGES). (I don't like acronyms but am using them here for convenience, in particular PAGES is very contrived, not my choice, predates me.) What PAGES does is to provide centralized output for our user base of perhaps 7,000 scientists, engineers and support staff locally as well as an increasing number of remote contract users from other locations and administratively disconnected people. The services include "line printer style" listings, Formatted text, Vector graphics, Raster graphics and Photoplotter on a variety of media as appropriate including 8.5x11 paper, 35mm film, 16mm film, microfiche, 11" roll paper, 36" roll paper and vellum and cut sheet film (photoplotter). We are considering color paper (thermal and electrostatic) and video (disk and tape) as well as large format color film for publication. The operations staff is basically a crew of 1 to 6 people drawn from a pool of 15 to 20 computer operator types per shift. The task is nontrivial given the variety of hardware and media and users to deal with. There are several veterans who can handle anything and everything but they are outnumbered by the rookies/disinterested types. Each operator has a different perception of the system though to some degree the current interface has homogenized them. One goal is to leave them room for some of their "misconceptions" where they are not destructive. There are a whole raft of myths and superstitions about the system and some of the hardware which is completely uncorroborated but nevertheless held to be true by many. We need to provide and intuitive model of all aspects of the system which is simple enough for casual/disinterested staff to absorb while still giving easy access to more information and power to the sophisticated staff. An important point is that it is "their" system. We may define it and evolve it but they LIVE with it and their ultimate cooperation is essential. The development staff is three to five depending on how you measure. One of us is a system manager and I am mostly a manager. I no longer make progress towards goals, I simply define new ones :). I do have the option, fortunately, to buy most anything I need and contract expertise where I can find it. This sounds great but is dampened by the constraint that we don't want to build anything that we can't maintain and my experience has been consistently that it is hard to maintain something that was bought or hired out. We spend a lot of time building levers and this seems to help, we are now able to buy some levers and that helps more. Yet another design constraint is the exporting of this technology. We are expected to apply much of our work in the larger environment (ICN) and make it available to the much larger environment (Supercomputer sites and other interested parties). As a result, we have tried to stick to very standard items with as much leverage as possible. We moved to UNIX/C 5 years ago and are now moving from DEC equipment to "VME/UNIX/IP/ETHERNET/ XorNeWS/C++orObjectiveC/NSE/CGM-CGI/Etc." to the exclusion of whiz-bang vendor solutions. Back to the issues: I am trying to develop some design principles and a visual metaphor for the system that is intuitive and non-threatening. We will initially be prototyping in NeWS, Interviews, or Objective C IC-pack 2000 or the NeXT environment on Sun 4's. We haven't discovered exactly where the most leverage for prototyping will be. The production version will probably be in a more standard/mundane environment if neccesary but I am confident in our ability to re-implement a good idea in a "safer" environment once we know what we want to do. The foremost design principle I am pushing is intuitiveness of each element. We as systems people have a different view of the systems from the operator and while lists and queues and charts and plots may suit us, they don't suit them so well. I am trying to avoid the problems that come up when you give an engineer a new tool- he tends to use it to build things that aren't needed or are exaggerated in nature, "just because you can". Color is a good issue as well as dynamics. We used "beeps" in the current interface outrageously sparingly because the noise to signal ratio goes way up when someone is not using it correctly. I foresee having to damp some enthusiasm for making points with garish color and/or animation. The main uses for color will be added bandwidth, distinguishability from a distance and aesthetics, probably in the reverse order by importance. I am considering hiring a graphics artist to consult on the design, layouts, color and actual artwork. I have one person in mind who is currently making a full living as a professional illustrator using computer tools only. She is spanning the gap between artistic and technical fairly well now and this would be an opportunity for her as well as us to fill in that gap a little. She has shown strong interest in the project and has experience with an interactive book development effort and computer art with children that may bear on some of our unique considerations. The "objects" that the operators need to be presented can be classified loosely into two groups, "resources" and "work". The operations required may be loosely classified into two groups also, "turning resources on and off" and "diverting resources". All the while the "resources" and "work" need to be monitored and compared in the past and future as well as the present. To be specific, we need to be able to see what resources are being applied to what work, and how effectively as well as looking back to see what has happened in the past and to predict what is coming up. The existing metaphor, embodied in a text menu interface is a list of devices and a list of queues and which devices are available and doing what and how much data is in which queue. There is a little more information available through submenus about specific devices, queues, jobs and clients (users) as well as simple control. The basic functionality will be retained in a simple mapping but preferably available directly. To facilitate this I plan to introduce a physical metaphor for the devices that emphasizes the homogeniety that we have already imposed. For the "work" I hope to introduce a "fluid" analagy with plumbing to represent the "flow of "data" between "reservoirs" and "processing elements" with "flow rate meters", etc. This is a big step conceptually for some who know the system today but I hope that by prototyping it I can get 100% buy-in by system and operations or maybe even a better idea. If any of you have any general advice or comments, they are welcome. Steve Smith PAGES project, LANL, Los Alamos, NM