Designing the Star User Interface
by David Canfield Smith, Charles Irby, Ralph Kimball, Bill Verplank & Eric Haslem

The Star user interface (UI) was developed by Xerox at the now famous Palo Alto Research Center (PARC). It was used in the Xerox 8010 Star Information System that was announced in 1981. It was a personal computer intended to be used for business professionals who handle information.

It was neither the first computer to have a mouse, nor the first to have a graphical user interface (GUI), but it was (to my knowledge) the first commercially available system to incorporate these features. The motivation for this was to make the system easy to learn and use by office personell that had no previous experience of computers.

The design methodology that was created for this project included the following:

• The user's conseptual model should be stated before the software is written.
  In this case the GUI was designed even before the hardware was built.
• The design of the GUI should be based on a taske analysis.
  A current task description should be used to build a new task environment.
• Prototyping should be used.
  [P]lan to throw one away; you will, anyhow. (p. 241, italics in original)

The methodology led to the following design principles.

• Familiar user's conceptual model.
  They created the electronic counterparts to the physical objects in an office: paper, folders, filing cabinets, mail boxes and so on. Everything did not, however, work exactly as their physical ekvivalents because although they wanted the physical analogy for familiarity, thet did not want to limit the functionality the capabilities of the physical office.
• Seeing and pointing versus remembering and typing.
  Seeing and pointing was favoured based on studies of short-term memory (STM) made in cognitive psychology stating that conscious thought deals with concepts in STM and that the capacity of STM is very limited. So the display can work as a sort of visual cache (p. 246) that relieves the load on the STM.
• What you see is what you get. (WYSIWYG)
  The GUI made it possble to reasonably well depict the state of a document consisting of graphical objects and text with different size and style while editing it, in stead of having to use ungainly document compilers. The composition was done on the screen.
• Universal commands.
  The star had a few commands that were available throughout the system such as MOVE, COPY and DELETE. These commands were derived from fundamental computer science concepts and had counterparts in the programming language that was used. The object-oriented programming method is also reflected in other aspects of the interface such as the extensive use of properties connected to objects.
• Consistency.
  Consistency to the metaphor is important in order to make the system easy to learn to use and intuitve but it was not always easy to follow. In a troublesome situation different methods should be tested by the future users. Consistensy to the paradigm is also important. Concepts, such as editing, information retreival and copying, that was used in one place in the system were also implemented in other places where it could be useful, in stead of creating more concepts.
• Simplicity.
  The tried to follow Alan Kay's advice that simple things should be simple; complex things should be possible (p. 253). From their work they learned that the intuition of designers is error-prone, the critical parts of a system should therefore be tested by the users. And that what is simplest along any one dimension is not neccesarily conceptually simplest for the user.
• Modeless interaction.
  Modes, such as those in vi, cause trouble by making habitual actions cause unexpected results. They examplify this by describing what happens if you type the word edit while being in the command mode in the Bravo editor.
  e: select everything in the document
  d: delete it
  i: enter insert mode
  t: type the letter t
  (Trying to undo this mistake would probably only undo the typing of the t.)
• User tailorability.
  Since users will want to speed up actions that are performed often, and differnt user have different needs and preferences, the environment should be changeable and extendable. This was done by making as many properties as possible editable by the user and making it possible to define your own operations. The tailorability of the system was, however, fairly limited with today's measures since the set of software applications that was includes was fixed.

It has been my intention not to include any personal views in these summaries, but here I will make a small exception. I have made two main reflections while reading this article. The first one is that it is interesting to see how well their ideas have survived over the years. The GUI's of today are surprisingly similar to the STAR UI. Of course some aspects have changed. Their displays did not have colour, in fact they stated that black and white images on a grey background minimised eyestrain (p. 244), and the set of different icons was limited and so on, but on the whole not much has changed.

The second reflection is that The Star was an office information system, not a general purpose system (GPS), it even had a fixed set of software applications pre-installed for this specific purpose, but still the metphor has been adopted by the GPSs of today.

What would have happened if Xerox had been in some other area than office machines? Is this the the ideal metaphor for GPSs?