Graphic User Interfaces were considered unnecessary overhead by early computer developers, who were struggling to develop enough CPU horsepower to perform simple calculations. As CPU power increased in the sixties and early seventies, industrial engineers began to study the terminal entry programs of mainframes to optimize entry times and reduce mis-types. The earliest mainframe query protocols still in use, i.e., airline reservation systems, were developed during this period to queue as much information as possible into the shortest command. Essentially, operators were trained to perform computer language interpretation in their heads.
For an example, read this vision of future computing from the science fiction novel Inherit the Stars, ©1977 by James P. Hogan:
"What do I do now?"
*"Type this: FC comma DACCO seven slash PCH dot P sixty-seven slash HCU dot one. That means 'functional control mode, data access program subsystem number seven selected, access data file reference "Project Charlie, Book one," page sixty-seven, optical format, output on hard copy unit, one copy.'"
In the middle to late seventies several companies, including IBM and Xerox, began research on the "next generation" of computers, based on the assumption that computing power would drop in price to the point where many more individuals in companies would be able to effectively use them. IBM directed most of its efforts at mainframe development, but also started a small division to design and produce a "personal computer", which, despite its obscure operating system, would recreate the home-built small computer market. Other companies were struggling to produce cost-effective small computers using the CP/M operating system.
The most notable interface research program was at a facility owned by Xerox called the Palo Alto Research Center (PARC). In 1973 the PARC team began work on the Alto computer system as "an experiment in personal computing, to study how a small, low cost machine could be used to replace facilities then provided only by much larger shared systems." The Alto project continued into 1979, replaced by the Star computer, which many consider the forerunner of the Macintosh. The Alto had many unique features, and pioneered the use of the mouse, the portrait monitor, WYSIWYG, local area networking, and shared workspaces.
Alto, and the later Star computers, derived many of these features from cognitive psychology work. The designers attempted to communicate with users more effectively by making the computer communicate in ways the brain uses more readily; using icons for instance, because the visual part of the brain can track their presence and state much better than words. They developed ways of organizing information in patterns which the eye can track through more easily, drawing attention to the work in progress. They developed the model of WYSIWYG (what you see is what you get) to improve print proofing performance, and found through testing that the digital representation of black text on a sheet of white paper increased information legibility and retention. The Star interface added the concept of the desktop metaphor, and overlapping and resizable windows. PARC discovered along the way that whole new subsystems had to be developed to enable their technology to work; but once demonstrated, testing showed dramatic improvements in productivity, job satisfaction, and reduced training time for users. PARC's research clearly showed that a computer system of sufficient power could be optimized for human use, and that optimization would be paid back with a range of productive (and profitable) behavior and attitude improvements.
In the early eighties the IBM PC running DOS became the runaway best seller among computers. DOS was a cryptic command line interface, a direct descendant of mainframes. The PC had many limitations, including memory access, power, and lack of color or graphic standards; but it had enough productivity to warrant purchases of millions of units.
At the same time, a small group of designers at a company called Apple Computer made a deal with Xerox PARC. In exchange for Apple stock, Xerox would allow Apple to tour the PARC facility and incorporate some of their research into future products. Apple took elements of the Star interface, refined them and produced the Lisa computer. The Lisa failed, owing to its cost, lack of software availability, and other factors. Apple's next try with an enhanced and friendlier Lisa interface was the Macintosh, which found a small market foothold in the design and publishing markets. Apple was committed to its GUI, spending millions of dollars over the next ten years to research and implement enhancements; their commitment paid off in the late eighties as the desktop publishing market exploded and Apple's interface was widely acclaimed by the artists, writers, and publishers using the computers. Interestingly, one of the most successful Macintosh application developers was the Microsoft Corporation of Redmond, Washington, owner of MS-DOS. Microsoft, following the Apple GUI standards, developed a spreadsheet for the Mac which set new standards for ease of use. This product was, of course, Excel.
Apple worked with artists, psychologists, teachers, and users to craft revisions to their software and developer guidelines. For example, in California they sponsored an elementary school where every student had an Apple Computer. Each year the teachers and Apple programmers spent the summer planning new lessons and making enhancements to the software used to teach them, because Apple believed that children give the truest reactions to basic interface issues. Although a distant second in number of systems behind IBM compatibles today, Apple's closed hardware and software implementation at one point made them the largest personal computer manufacturer in the world, eclipsing IBM in 1992. Apple believes that the principal contributor to their success has been the consistent implementation of user interfaces across applications. Macintosh users have been able to easily master multiple applications because commands and behavior were the same across applications: Command-S is always save.
In the late 1980s Microsoft Corporation, producer of DOS, DOS applications, and Macintosh applications, began a joint project with IBM to develop a new graphic user interface for IBM compatible computers. This partnership later dissolved, but Microsoft went on to take user interface lessons learned from their successful Macintosh products, Excel and Word, and created a series of graphic shells running on top of DOS which could mimic many of the Macintosh GUI features. Microsoft and Apple became involved in extensive litigation over ownership of many of these features, but the case was eventually dismissed. Later version of the Windows operating system became increasingly Macintosh-like. Today Microsoft gives little credit to Apple for pioneering and validating many of the ideas which they have copied.
With increasing desktop power and continued reductions in CPU pricing, another area of GUI development also entered business, that of UNIX. Like DOS, UNIX is a child of the seventies and inherits a powerful and obscure command line interface from mainframes; unlike DOS, it had been used in networked applications and high-end engineering workstations for most of its life. In the eighties UNIX GUI shells were developed by consortiums of workstation manufacturers to make the systems easier to use. The principal GUIs were Solaris (Sun Microsystems), Motif (Open Software Foundation, or OSF), and later NeXTstep (Next Computers).
Altogether new graphical operating systems were also developed for the emerging families of RISC desktop computers and portable devices, these include Magic Cap (General Magic), Newton (Apple Computer), People, Places, and Things (Taligent), Windows CE (Microsoft), and the Palm interface (US Robotics Pilot).
The mid 1990s brought two new movements to GUI design - the Internet browser and it's limited but highly portable interface, and LINUX, a freeware version of UNIX. Which of these will have greater long-term impact is open to debate, but it appears that the browser has had widespread effect on GUI design, and on human culture.
The HTML/browser interface comes in bewildering variety of implementations. With limited interaction in forms the designers were forced back to basics, building and testing iterations. Fortunately, HTML is relatively easy to create, though some would suggest, difficult to master. Newer versions of HTML and decendants like DHTML, XML, WML, SMIL, offer greater potential for true interactive experiences but at the cost of increased download times and questionable compatibility with a diverse legacy of installed browsers. Over time the legacy browser problem will be solved as users upgrade their systems, and bandwidth issues should also improve. But the important thing learned by GUI designers from the Web is that screens do not have to be complicated to be useful - if the form solves a need and is easy to use, then people will use it.
LINUX represents another trend in computing and GUIs, that of group-developed software based on components. Facilitated by the Web, software designers can collaborate and produce startling work in short timeframes. LINUX is small and reliable, yet supports a large base of usable processes. Along with Java, LINUX represents a possible future of portable software running on compatible systems anytime, anywhere.
Key Features Common concepts in good GUIs
Important similarities exist between these GUIs which are based on sound principles of cognitive psychology and proven through thousands of hours of testing and billions of hours of use. They are summarized below:
Consistency: Once a set of rules is picked for a GUI, it is vital that different applications share methods for invoking similar features (external consistency), and that applications use the same methods for similar functions within the program (internal consistency).
*Metaphor: To make complex processes easier to understand and manipulate, it is useful to choose a similar "real world" process to associate with the application, i.e., the desktop for managing files and choosing office applications. Use of visual images, sound, and actions serves to reinforce the illusion and make it more understandable.
*User Centered: The user is in charge of the interaction on several levels. Actions are initiated and controlled by the user, the user selects the objects the action will affect, the user sees immediate visible results of actions to confirm their changes, and the user is warned about negative effects of their actions. Ideally, the user cannot be wrong, he or she can always recover from an error. When questions arise during development of new applications, they should always be settled to the users' benefit. Design specifications should arise from user needs, and research on the efficacy of the design must be done with users. The user is not a programmer, the user will make errors, but the user is in control.
*WYSIWYG: Everything is seen, and features are not hidden except by the user, i.e., the tab settings on a word processor are seen unless turned off. Items which exist in the real world should look like them, especially if they may be printed, such as an invoice in an accounting program.
*Aesthetics and Environment: The human eye and mind are evolved to make sense out of a disordered world. However, this process can completely consume the resources of the human brain; chaotic screen designs take a long time to understand and use. Information should be ordered into a simplified grid or list, it must be organized hierarchically according to importance and grouped into similar tasks. The application should have 'look' which reinforces the sense of craftsmanship required to create quality applications.
At the same time, the design should help the user navigate the system; compatible changes to detailing, color, and patterns along with title bars help the user to recognize where they are in the application.
Marshall MacLuhan
To make things even more complicated, designers of user interfaces are aiming for a moving target. GUIs evolve, the hardware systems get faster, displays get larger, and the user is changing. As sociologist Marshall MacLuhan pointed out in the fifties while studying television, "...the medium is the message." This is because we must reject carrier information to extract real information from the events around us. For example, when we watch television we make constant evaluations on whether the information we see is important: the announcer's words instead of the color of his green jacket. If we did not evaluate the jacket color as unimportant and "reject" it, we would have great difficulty deciding what was important in the huge flow of information coming out of a TV. As we watch television we are constantly learning new information which must be rejected, so in many ways the TV is affecting our values and thought patterns. Similarly, GUI presentation of information has many levels of information which users learn to reject. A consistent interface makes it easier for the user to quickly extract information from the screen. Conversely, changes from learned ways of displaying or manipulating data lead to confusion and doubt, since the user must build a new internal model of hierarchical information. Since most users use multiple applications, and upgrades are constantly loaded, the user must make these evaluations daily. Users become more sophisticated, but they also develop technology induced blind spots which may prevent them from seeing important information.
Life with HTML What happened here? Why are so many sites so ugly?
HTML was developed by a group of engineers and scientists who wanted to share reports and papers over a network. Over time, image tags and miscellaneous formatting was added, but until about four years ago, NONE of the authors were designers.
(A good information/interaction designer is concerned with all of the aspects of the interface, from the server and database used, to the transport layers, to the features and limitations of the delivery platform, to the industrial psychology of the computer/display system, to the cognitive psychology/knowledge base/usage patterns of the end user. Their focus is on improving the user's experience through applied expertise with programming, marketing, sociology, psychology, art and design history, economics, technology, engineering, research methodology, etc., etc. But I digress.)
Sure, design is about making things look better on the surface. But you CANNOT SEPARATE FORM FROM CONTENT; good design is about making things clearer to understand, and much more useful, and that comes from careful use of sound design principals (yes, there are rules for how to design something, for example: http://www.dsiegel.com/tips/tips_home.html ).
Now, the original developers of HTML were smart people, but they didn't think "design" was important. They felt that once they could publish their papers, they were done (unfortunately, an all too common engineering fallacy, "It works, it must be finished"). As graphic designers started using the web, they brought with them some 400 years of printing experience and the rules of graphic design, for instance:
Whitespace organizes information better than lines
Humans reject information to read it*
Contrast = better readability
There are cultural meanings to color
So now we have a lot of arguments and "hacks" added to HTML so that information can be presented in a more useful and effective way: tables, alignment tags, color control, frames, face commands for fonts, etc., etc. Sure, this makes the code more complicated, but isn't that what computers are good for? Taking mundane, repetitive tasks and making information easier for humans to understand and use. Or would you rather give back your color monitor, your menu interface, and your mouse? (I know I wouldn't).
One thing is for certain, if you use the older HTML tags with their default behaviors, you WILL have an ugly page.
*Marshall MacLuhan wrote an entire book on this phenomenon. When you look at a list of information, your brain evaluates each piece of data, then rejects the unimportant/uninteresting ones so that you can focus on the important part(s) of the list. This happens at such a low level that most people are not aware they do it. Think about reading a map, which is an extremely rich interface; if you could not reject information, you would never find the road or city or distance which is important, since your brain can only hold so much information at a time.
Text Design Have we learned anything in 400 years?
With 400 years of design history and 50 years of psychology research to digest on print what do we know?. When reading text, the following things WILL improve reading speed and retention:
Contrast between the font ink and the background color
Use Serif fonts for printing
(but sans-serif fonts are marginally better for on-screen legibility)
8 to 11 words per line (column layout)
Whitespace margins to the sides of the column (gutters)
Minimal use of changes in font inside text
(no highlights, bold, italics for individual words)
Consistent text alignment (flush left preferred)
If you have to create wider columns, you really need to increase the leading (typographer's term for vertical space) between lines. Wide columns of text do not easily guide the reader's eye to the next line, resulting in confusion and slower speed. To use a wider column with small text, you must have more leading.
In CSS the argument to do this is:
line-height: normal |
Preferred:
line-height: 1.5em;
When you set text in a page without using a table (or div with a width) to control maximum width, you create a bad situation for your users with large monitors. The HTML default leading is too narrow for full width windows.
Cascading Style sheets allow you to set the space between lines of text. Unfortunately, the continuing browser competition between Netscape and Microsoft, combined with multiple platforms and old versions hanging around on many computers, left us with inconsistent results for several years. It used to be that if you depended on this feature to allow use of wide columns, you could create an ugly situation for many users without it but in the past three years the web population has largely adopted CSS and DOM compatible browsers - woo!
I could go off about how chaotic page layouts consume your brain's concentration, since your brain is evolved to impose order on chaos, and why it's important to provide navigation cues for large text blocks, but that would take too long, and you probably aren't interested.
Visual Chaos Why is it important to have clean layout?
Well, maybe you are interested. Cognitive Psychologists like Conrad Lorenz in Switzerland began serious and methodical studies of children's brain development in the 1950's. Their theory was that physical and cognitive brain structures developed in childhood affected our perception and thinking throughout our lives. This has since been repeatedly proven correct.
The core findings and their effects:
1) The order that structures develop determines their importance and speed of utilization; the order is Visual, then Aural, then Sense of Self, and finally, Abstraction.
This is why scientists estimate that 80% of our brain is given over to processing visual stimuli. As an infant develops, the first sense which comes under control is vision; these are the deepest, fastest, and most sophisticated structures in our brains. Static images are powerful, but moving images are completely gripping. Think of the pressures on our vision in the environment where we evolved; the search for food and for threats made vision very important. That is how most people can determine whether they've seen an old movie, when flipping channels late at night, within 5 seconds of seeing the footage. No one told you there would be a test on this later, but still we have this incredible ability. And it makes a large percentage of the population very susceptible to television advertising, which speaks directly to many of these deepest brain structures.
Aural senses develop next, adding sound to the infant's world. This sense builds on the visual sense and the infant begins to associate sounds with visual objects. As yet, we use very little sound in interface design, but we will be using it...
The Sense of Self comes with kinesthetic (body movement) awareness and a new level of higher-order thinking. The infant begins to control their own body, then to know their own limits, and to realize that they can/cannot control other objects around them. So the sense of self is a two edged cognitive tool, balanced by the Sense of Not-self, or otherness. The sense of self builds on visual and aural cues; so we see that higher order functions are based on earlier, simpler structures.
The final key cognitive structure builds on all of the above. Abstraction is the growing ability to take childhood elements and manipulate them as symbols. Spoken language is the principal method for abstract concept manipulation, but we all use other systems as well, such as currency, mathematics, and body language. We continue to build and use systems of abstraction throughout our lives.
2) The Human brain has evolved to create/impose order on chaos, to allow manipulation of environment.
If you get philosophical about it, you can easily argue that we live in a sea of energy. Photons bounce off molecules and have some of their energy absorbed, air moves in waves and we hear sound, the molecules of our fingers interact with other molecules and we feel touch. Of course, a lot of chemical/physical/organic phenomena occur just to get that energy, or the effects of that energy into our brains. But we don't think about energy absorption every time we see the color red, in fact, it took thousands of years to devise the physics model which "is" absorption. The point is, without the brain's ability to take all this energy and assign meaning to it, and then create metaphorical handles to manipulate those meanings, we would not be able to complete the simplest tasks because we would be overwhelmed with detail. See MacLuhan above. Instead we develop internal hierarchies of meaning and symbol as we learn to allow us to move through our day to day tasks without spending too much attention on our environment -- we have imposed our own vision of order onto our universe.
This ordering by labeling and rejection, like any useful tool, has good and bad uses. When we walk down the aisle of the grocery store and are able to find the correct brand of tomato paste without reading every can or bottle or box or bag, that is a good use. When we refuse to re-evaluate past values and assumptions in the face of new and contradictory information, that is a lazy thinking.
3) Without apparent order, the brain will set about creating order, even if only subconsciously. This consumes "bandwidth".
When faced with a new terrain of seemingly chaotic organization (like some web pages) the brain will begin searching for meaning and organization. This occurs on many levels, with some processes occurring beneath the level of consciousness. The brain will waste processing power searching for these missing relationships; this has been proven in experiments with reaction time and complex visual environments, reaction time goes down as the brain is occupied processing a complex (read chaotic) environment. The solution to this is to simplify the interface design, making tables clearly aligned, creating consistent navigation, and using whitespace and lines to create clear groupings of like information.
4) Abstraction is costly in terms of processing, and layers of abstraction are more costly.
An example of the power of the visual structures of the brain and layers of abstraction is the "Rooms of Animals" exercise, which I first heard Alan Kay discuss in 1990. If you have two rooms, one with walls filled with pictures of animals, the other with walls filled with names of animals, and you ask a volunteer to enter a room and find a specific animal, that subject will always find the picture faster, usually by a factor of 2 to 3. This is because the user dealing with names must read the word, recall associations (reverse abstraction to recall meaning), determine whether there is a fit, and only then accept or deny the term. On the other hand, a volunteer in the picture room can let their faster visual brain structure accept or reject the representations directly (while abstractions, the pictures are sufficiently visual to allow the low level, nonverbal, visual brain to make the comparison).
Use of slang, mnemonics, TV or literary metaphors, poetic descriptions, riddles, etc., all slow down an interaction even further since the user is now dealing with layers of abstraction (but it can make the experience richer, or more fun).
5) Humans think in three dominant modes: Visual, Aural, and Kinesthetic.
We all use three structural modes to interpret our world, rooted in the three earliest cognitive structures. But humans tend to select and reinforce one of those modes over time, and become more sensitive to information which is presented in their dominant mode (This is actually a separate branch of behavioral study called Neuro-Linguistic Programming, or NLP). The GUI interface is successful, in part, because it communicates in all three modes:
The GUI is Graphic, using visual representations of data and programs, this appeals to people with a visual bias. The majority of the human population is/are visually dominant. A clue to listen for is "I see what you're saying..."
The use of language, and some sound, appeals to Aural mode dominant users. The menu structures and written instructions in GUIs work on this level, and the hyperlinked aspect added to language by the Web is very powerful. Note that Aural users include language (an abstraction layer) as a working skill. "I'm listening...","What did they say?"
Finally, kinesthetic users, who are sensitive to body position, emotions, and movement through space find the mouse movements and apparent spacial relationships of GUIs appealing. "What did you do?","Where is it?"
Regardless of an individual user's biases, it is important to communicate in multiple modes whenever possible. This ensures that the interface will be effective for different groups, and that most users (who actually use all the modes regularly) will have redundant information to help them better understand the interface.
Common Page Problems in HTML I've made all of these mistakes. And lived to tell the tale.
Hop into the wayback machine headed for 1998... note that many of these issues are still with us today
More than three years of HTML design experience has knocked me around pretty well. Many things have gotten much better, but HTML still has a steep learning curve. Here are things we should all know better about designing for the web.
Use arguments for images...
Always use width and height tags so the browser can render the page before it finishes downloading the images. Yeah, it's a pain. But the pain is greater for users that wait and wait and wait for their modems to load a page, only to find it doesn't have what they want.
Avoid the
tag...
Use
instead, unless you are an advanced CSS jockey. The
tag will break any font formatting when it's properly read (per the HTML standards). Urg.
Use Relative font sizes...
A surprising number of web users have altered their default font sizes so that they are larger and easier to read. When you choose an absolute size you foil their desire to view information at a legible size.
Avoid bad backgrounds with poor text contrast...
Also remember to set the body bgcolor to be a similar color.
Check that spelling and grammar...
Also a pain. People take the information seriously (or not) when you take the extra time to check this over.
Use redundant navigation...
What do users want? To find related information? Sheesh. Sure, some viewers may get lost on large sites, but plan at least two ways to get to any page.
Check your pages in Netscape AND MSIE...
Brrrr. They really do look different sometimes. I also recommend Opera, because it has stricter HTML compliance. While you are at it, visit a friend and walk through the site with them. They'll have great comments.
A Brief Introduction to SIGMA: An Intelligent Visual Programming Environment for Scientific Modeling
Introduction and Motivation
Within both NASA and the scientific community at large, computer models are playing an increasingly important role in the conduct of science today. Scientists construct software models to analyze data, to validate theories, and to predict a whole variety of phenomena. Developing a new scientific model is a time-intensive and painstaking process. Usually, scientific models are implemented using a general-purpose computer programming language, such as FORTRAN. Implementation can involve writing large and complex programs that access multiple datasets and utilize numerous different statistical and numerical processing packages. Software development time for large scientific models can take on the order of many months to years of effort.
Although considerable resources must be expended to build a scientific model, for a variety of reasons it may difficult to share the completed model with colleagues in the scientific community. Model-sharing is highly desirable because it enables researchers to conserve resources and build upon each others' efforts in a synergistic fashion. Unfortunately, modeling code is typically low-level and idiosyncratic, and it may be difficult for anyone but the model's developer to understand. The relationship between the computations in the code and the actual physical situation being modeled may be obtuse and indecipherable. Furthermore, a great deal of important information about the various modeling assumptions made by the modeler is buried in the code and is very difficult to recover. Finally, documentation may be minimal or lacking altogether.
Despite these well-recognized problems and despite the acknowledged importance of scientific model-building, scientists today generally lack adequate software engineering tools to facilitate the development and sharing of modeling software.
The SIGMA modeling tool
We have constructed a prototype knowledge-based software development environment that makes it easier for scientists to construct, modify, share, and understand scientific models. The SIGMA (Scientists' Intelligent Graphical Modeling Assistant) system provides a type of "visual programming" environment customized for scientists. Rather than construct models using a conventional programming language, scientists use SIGMA's graphical interface to "program" visually using a high-level data flow modeling language. The vocabulary of this modeling language includes high-level scientific constructs (e.g., physical quantities, scientific equations, and datasets) rather than low-level programming constructs (e.g., arrays, loops, counters). Because SIGMA enables users to express their models using a natural vocabulary and an intuitive format, colleagues can more rapidly understand and modify the content of a model without assistance from the modeler. These same characteristics make SIGMA an excellent instructional environment for demonstrating the principles underlying a scientific model.
During the model development process, SIGMA takes on the role of a knowledgeable and active assistant to the scientist rather than a passive and uninformed subordinate. SIGMA assists the scientist during the model- building process and checks the model for consistency and coherency as it is being constructed. Using knowledge about the modeling problem and the scientific domain, SIGMA can automatically interpret the high-level scientific model as an executable program, freeing the scientist from error-prone implementation details. Users can test these models, conduct sensitivity analyses, plot results, and modify models -- all within the SIGMA environment.
--------------------------------------------------------------------------------
Figure 1. Data flow diagram representing computational dependencies in a model fragment.
--------------------------------------------------------------------------------
The visual data flow interface
Within SIGMA, the scientist views a computational model as a graphical structure called a data flow diagram, as illustrated in Figure 1. The data flow diagram represents the computational dependencies between the scientific quantities being modeled. By scanning the diagram, users can understand rapidly how one quantity is derived from others by applying a series of scientific equations.
The data flow graph in Figure 1 consists of two types of nodes: equation nodes and quantity nodes. The equation nodes are depicted in thick-bordered boxes, while the quantity nodes are shown in thin-bordered boxes. The direction of computation in the data flow graph is from right to left. The quantities at the extreme right represent known input data or exogenous quantities in the model. These quantities flow toward one or more equation nodes, where they are used in an equation formula to yield an output quantity. In turn, these intermediate quantities flow toward other equation nodes, and the entire computation cascades along as new quantities are computed and passed forward to new equations. The entire model execution culminates in the production of one or more final output quantities at the extreme left of the diagram. To compute a model output, the user clicks with a mouse on the "Compute" button associated with that output quantity node. (The "Compute" button is only active if all the required input quantities for the computation have been properly entered.)
Accessing model information
Users can access a wide variety of documentation about the quantities and equations in the model by navigating through the data flow diagram. For example, by clicking on the "Info" button of an equation node, the user gets detailed information about the equation, including the equation formula and its inputs and outputs. Figure 2 illustrates the information window associated with the "Density computation" Equation. In addition to the formula and a brief description of the equation, note how each symbol in the formula is described in terms of the experimental situation being modeled. For instance, the symbol N represents the number density of a parcel of gases in the atmosphere of Titan, while R and p represent the refractivity and polarizability associated with a Voyager radiation source interacting with the atmospheric parcel.
--------------------------------------------------------------------------------
Figure 2. Information window describing "Density Computation" equation
--------------------------------------------------------------------------------
By clicking on the "Citation" button in the information window (Figure 2), the user can access a literature citation for the Density Computation equation. This citation is shown in Figure 3. If the user wants to go further and inspect the actual citation, the "Text" button brings up a scanned bitmap image of a relevant portion of the cited material.
--------------------------------------------------------------------------------
Figure 3. Citation information associated with "Density Computation" equation
--------------------------------------------------------------------------------
Clicking the "Info" button on a quantity node also provides useful information. Suppose the user has clicked the "Compute" button on the output density quantity at the extreme left of the data flow diagram in Figure 1. SIGMA will compute the model output and subsequently the user can view the results by clicking "Info". This action brings up the window shown in Figure 4. Because density is a gridded quantity, the system displays the value for each altitude gridpoint. The user can plot the values by clicking the "Plot" button at the bottom of the window. If the user wants to see the results converted into a different set of units, he or she simply clicks on the displayed units and specifies new units. Conversion is handled automatically by SIGMA.
--------------------------------------------------------------------------------
Figure 4. Calculated values for number density
--------------------------------------------------------------------------------
Modifying the model
Aside from executing a model, users may wish to modify the model or to conduct a "what-if" type of analysis. SIGMA facilitates modification because all changes are made via the high-level data flow interface. No low-level programming changes need to be made by the user to modify the model. To change an input value, the user clicks the "Input" button on an input quantity node and enters a new value. Any previously-computed value that depends on this value is then invalidated and the user must request recomputation if desired.
A more fundamental type of modification consists of changing one or more equations used to compute quantities in the model. This is done by clicking the right arrow button on the node representing the output quantity of the equation to be modified. For example, if the user wishes to compute number density using a different equation than the "Density Computation" shown in Figure 2, he or she clicks the right arrow button on the number density node and gets a menu of alternative equations to apply (Figure 5). These equations are fetched from SIGMA's equation library. Because SIGMA has a record of the conditions under which each equation in its library is applicable, SIGMA only presents the user with viable alternatives. These alternatives are filtered from among the set of over 150 different scientific equations in SIGMA's library. (Note that SIGMA's library contains black box subroutines, as well as explicit scientific equations. Users may add their favorite FORTRAN or C subroutines to the library and these can be inserted into SIGMA data flow diagrams.) If the user selects a different equation from the menu, SIGMA will modify the data flow diagram to reflect the change.
--------------------------------------------------------------------------------
Figure 5. Applicable equations 
--------------------------------------------------------------------------------
For example, if the user decides to calculate density by applying the Ideal Gas Law rather than the Density Computation, the data flow graph is modified as shown in Figure 6. The Ideal Gas Law requires pressure and temperature as inputs to compute density. (The value of Boltzmann's Constant is already stored in SIGMA's knowledge base, so the user does not need to enter its value.) The user must now decide to either enter values for the required pressure and temperature inputs, or to select an equation to compute these input quantities. As with the number density computation above, the relevant equations can be viewed by clicking the right arrow button for these quantity nodes. The process of extending the data flow graph to the right of the Ideal Gas Law continues recursively until each of its inputs can be computed from known data.
--------------------------------------------------------------------------------
Figure 6. Modified data flow graph after applying "Ideal Gas Law" equation
--------------------------------------------------------------------------------
SIGMA's critical resource:
Science Knowledge
There are a number of different visual programming tools available to scientists today, including tools for image processing and scientific visualization (Khoros [Khoros, 1992], AVS [AVS, 1992], SGI's Explorer [Explorer, 1993], Iconicode/IDF [Iconicode/IDF, 1992]), tools for scientific instrument design (LabVIEW [LabVIEW, 1992]), and tools for modeling or simulation (STELLA/IThink [STELLA/IThink, 1992], Extend [Extend, 1992]). Although these tools enforce simple syntactic checks on data flow graphs and perform some type-checking, none of these tools has an "understanding" of what the data flow program is doing or whether the operations on the data make sense. Because these software tools have virtually no information about the application domain, they have no basis upon which to evaluate the appropriateness of a data flow program for solving a particular application problem. As a result, it is possible with these tools to create a syntactically valid data flow graph that is semantically incoherent and fails to solve the intended problem.
SIGMA is unique because it utilizes an extensive knowledge base of information about the scientific domain to assist the user during the modeling process. SIGMA's knowledge base contains both general-purpose science knowledge (e.g., descriptions of widely-used quantities, scientific units, scientific constants, equations, scientific concepts) and problem-specific knowledge (information related to the specific modeling problem and scientific discipline). The general-purpose knowledge comes as a standard reusable component of SIGMA, while the model-specific knowledge must be added by the user to support each new modeling domain.
Utilizing its extensive knowledge base, SIGMA can provide the following types of unique knowledge-based support for the model-builder:
* Equation applicability testing: SIGMA actively screens each equation in its library to determine whether it is applicable in the current modeling situation. The user only sees a viable set of candidate equations.
* Model consistency checks: During the model-building process, SIGMA works to maintain the global consistency and scientific coherence of the evolving model.
* Equation entry error-checking : When entering new scientific equations, SIGMA ensures dimensional consistency.
* Automated scientific units maintenance: During model execution, scientific conversion is done automatically to maintain consistency.
* Reusable libraries: SIGMA's knowledge base includes reusable libraries of scientific equations, quantities, and constants.
Establishing the modeling context
Aside from its extensive knowledge about the scientific domain, SIGMA has available a detailed description of the background context against which the modeling activity occurs. This background knowledge about the modeling problem is essential for proper understanding and communication with the scientist.
One of the first and most important steps taken by a scientific modeler is to abstract a given real-world modeling problem by casting it in terms of a set of equations. Thereafter, the problem can be solved purely using mathematics. Unfortunately, as a result of this initial abstraction step, an important link back to the original problem has vanished; subsequently, model users may have difficulty making the connection between the equations and the real-world modeling context. Because the contextual information that gave rise to the set of equations is unavailable to these users, they may have a hard time understanding, interpreting, and modifying the model. Similarly, without the appropriate contextual information, SIGMA cannot understand and assist users with their modeling tasks.
Within SIGMA, we provide this essential connection to the modeling context by linking the numeric computation depicted in the data flow diagram with an object-oriented description of the physical system being modeled. We call this object-oriented description the modeling scenario.
--------------------------------------------------------------------------------
Figure 7. Modeling scenario for Titan/Voyager encounter
--------------------------------------------------------------------------------
Figure 7 illustrates the modeling scenario upon which the data flow diagram in Figure 1 is based. The diagram represents one portion of a model intended to compute an atmospheric profile of Saturn's moon Titan based on radio signals sent from the Voyager 1 spacecraft during its encounter with Titan in 1980. The scenario in Figure 7 describes all details of the Voyager/Titan encounter relevant to the modeling task. Associated with the Titan object in the Figure is an Atmospheric Grid of Location objects. At each location, there is an Atmospheric Parcel, which represents the mixture of gases at that location. Each parcel is composed of pure gas Constituents, such as nitrogen. The Voyager Signal originates from the Voyager Spacecraft and subsequently passes through the parcel, where it causes an energy-matter interaction represented by the Signal/Parcel Interaction object. Associated with each of these objects is a set of quantity attributes relevant to the modeling problem. Some of these attributes have known or assumed values, while other attributes are computed by applying scientific equations to the known attributes.
SIGMA relates the abstract numeric computation specified in a data flow graph to the real-world modeling context by linking each quantity node in the data flow diagram with a specific attribute of some object in the modeling scenario. For example, the node representing the number density quantity in Figure 1 corresponds to an attribute called "number-density" associated with the atmospheric parcel object in Figure 2, whereas the refractivity quantity corresponds to the "refractivity" attribute of the energy-matter interaction between the signal and the parcel.
SIGMA maintains useful information about each of the objects represented in the modeling scenario and their associated attributes. Each attribute has a text description and a set of associated scientific units. There is a hierarchy of object types, and each specific object instance in the scenario inherits information and attributes from more general objects in the hierarchy. For example, the Titan Atmospheric Parcel object is a specialization of the more general Physical Entity object. All subclasses of physical entity inherit attributes such as mass, density, and temperature, for example. By utilizing object-oriented techniques, SIGMA's infrastructure is easily modified to accommodate new scientific domains.
Two domains we have worked on extensively are planetary atmospheric modeling and terrestrial forest carbon-water transport modeling. Although these two domains seem quite different, they share in common some basic object and attribute definitions. SIGMA exploits these commonalities to reduce the user's burden of providing information to the system.
Status and Limitations
SIGMA has been developed in close collaboration with scientists in planetary sciences and ecosystem sciences at NASA Ames Research Center. We have successfully used SIGMA to reimplement and extend portions of two scientific models reported in the literature: TGM (Titan Greenhouse Model [McKay, Pollack, & Courtin, 1989]), and Forest-BGC (Forest Biogeochemical Cycles [Running & Coughlan, 1988]).
SIGMA is a prototype system and is still undergoing development and testing. The current version of SIGMA is being tested by several different types of users:
* model developers -- people who develop new models from scratch;
* model users -- people who primarily use models developed by others but who may need to make some modifications;
* model observers -- people interested in understanding a model, primarily for educational or training purposes.
SIGMA has shown promise for all three categories of users, but currently, its limitations are most serious with respect to the model developer.
SIGMA's main limitation is on the types of mathematical models that can be built within the framework. SIGMA currently handles non-coupled algebraic and first-order ordinary differential equations. However, many models require the use of simultaneous equations, and these cannot be handled easily within current system, although extensions are planned to enable their use.
SIGMA is written in CommonLISP and GINA, a Motif-based graphical user interface package. SIGMA runs on a Sun workstation.
