a version of this paper appeared in IEEE Computer, September 1989 and also in the book Human Computer Interaction: Toward the Year 2000 by Morgan Kaufman. The figures used in this web page aren't very good reproductions, but they are readable. ...Dave Curbow
The Xerox Star has had a significant impact upon the computer industry. In this retrospective, several of Star's designers describe how Star was and is unique, its historical antecedents, how it was designed and developed, how it has evolved since its introduction, and, finally, some lessons learned.
In April of 1981, Xerox introduced the 8010 "Star" Information
System. Star's introduction was an important event in the history of
personal computing because it changed notions of how interactive
systems should be designed. Several of Star's designers, some of whom
were responsible for the original design and others of whom designed
recent improvements, describe in this article where Star came from,
what is distinctive about it, and how the original design has
changed. In doing so, we hope to correct some misconceptions about
Star that we have seen expressed in the trade press, and to relate
some of what we have learned from the experience of designing
it.1*
In this article, the name "Star" usually refers to both Star and its
successor, ViewPoint. "ViewPoint" is used to refer to the current
product.
We begin by describing Star as a static system: stating what Star was intended to be and by listing and discussing the aspects that made -- and in some cases still make -- it unique. Following that, we describe how Star came about and how it has changed since its introduction. Finally, we discuss what we have learned from the experience of designing and building Star.
Star was designed as an office automation system. The idea was that professionals in a business or organization would have workstations on their desks and would use them to produce, retrieve, distribute, and organize documentation, presentations, memos, and reports. All of the workstations in an organization would be connected via Ethernet and would share access to file servers, printers, etc.
Star's designers assumed that the target users are interested in getting their work done and not at all interested in computers. Therefore, an important design goal was to make the "computer" as invisible to users as possible. The applications included in the system were those that office professionals would supposedly need: documents, business graphics, tables, personal data-base, and electronic mail. The set was fixed, always loaded, and automatically associated with data files, eliminating the need for users to worry about obtaining, installing, and starting the right application for a given task or data file. Users could focus on their work, oblivious of concepts like software, operating systems, applications, and programs.
Another important assumption was that Star's users would be casual, occasional users, rather than people who spent most of their time at the machine. This assumption led to the goal of having Star be easy to learn and remember.
When Star was first introduced in 1981, its bitmapped screen, windows, mouse-driven interface, and icons were unique in the marketplace. They were readily-apparent features that clearly distinguished it from other computers. Soon, however, these features were adopted by others. Today, windows, mice, and icons are more common. However, Star's clean, consistent user interface has much more to do with its details than with its gross features. We list here the features that we think make Star what it is, categorized according to their level in the system architecture, the levels being: machine and network, window and file manager, user-interface, and document editor.
Distributed, personal computing -- Though ViewPoint is available in a stand-alone configuration, Star and ViewPoint were designed primarily to operate in a distributed computing environment. This approach combines the advantages and avoids the disadvantages of the two other primary approaches to interactive computing: time-shared systems and stand-alone personal computers.
Time-shared systems, dominant through the Sixties and Seventies, allow expensive resources like printers and large data stores to be shared by many users and help assure the consistency of data that must be used by many. The disadvantages of timesharing are that all users are dependent upon the continued functioning of the central computer and that system response degrades as the number of users increases.
Personal computers, which have replaced timesharing as the primary mode of interactive computing, have the advantage, as one Xerox PARC researcher put it, "of not being faster at night." Also, a collection of personal computers is more reliable than are terminals connected to a centralized computer: system problems are less apt to cause a total stoppage of work. The disadvantages of PCs, of course, are the converse of the advantages of timesharing: Companies that use stand-alone PCs usually see a proliferation of printers, inconsistent data-bases, and non-exchangeable data.
The solution, pioneered by researchers at Xerox (see History of Star Development, below) and embodied in Star, is to connect personal workstations with a local area network and to attach shared resources (e.g., file servers, data-base servers, printers) to that same network.
Mouse -- An interactive computer system must provide a way for users to indicate which operations they want and what data they want those operations to be performed on. Users of early interactive systems specified operations and operands via commands and data descriptors (e.g., text line numbers). As video display terminals became common, it became clear that it was often better for users to specify operands -- and sometimes operations -- by pointing to them on the screen. It also became clear that graphic applications should not be controlled solely via a keyboard. In the Sixties and Seventies, many different pointing devices were invented and tried: the light pen, the track ball, the joy stick, cursor keys, the digitizing tablet, the touch-screen, and the mouse.
Like other pointing devices, the mouse allows easy selection of objects and triggering of sensitive areas on the screen. The mouse differs from touch screens, light pens, and digitizing pads in that it is a relative pointing device: the movement of the pointer on the screen depends upon mouse movement, rather than upon its position. Unlike light pens, joy sticks, and digitizing pads, the mouse (and the corresponding pointer on the screen) stays put when the user lets go of it to do something else.
To achieve satisfactory mouse-tracking performance, the mouse is handled in at a very low level. In some workstations, mouse-tracking is handled in the window system, with the result that the mouse pointer often jerks around the screen as and may even freeze for seconds at a time, depending upon what else the system is doing. The mouse is a hand-eye-coordination device, so if the pointer lags, users just keep moving the mouse, and when the system catches up, the mouse moves beyond the user's target. This was considered unacceptable at Xerox.
Star uses a two-button mouse, in contrast with the one-button mouse used by Apple and the three-button mouse used by most other vendors. Though predecessors of Star developed at Xerox PARC (see History of Star Development, below) use a three-button mouse, Star's designers wanted to reduce the number of buttons to alleviate confusion over which button did what. The functions invoked via the Alto's middle button are, in Star, invoked in other ways. Why did Star's designers stop at two buttons instead of reducing the number to one, as Apple did? Because studies they did involving users editing text and other material showed that a one-button mouse eliminated button-confusion errors only at the cost of increasing selection errors to unacceptable levels.
Bit-mapped display -- Until recently, most video display terminals were character-mapped. Such displays enable vast savings in diaplay memory, which, when memory was expensive, made terminals more affordable.
In the Seventies, researchers at Xerox PARC decided that memory would get cheaper eventually and that a bit-mapped screen was worth the cost anyway. Based upon this principle, they developed the Alto, which had a screen 8.5 inches wide and 10.5 inches tall.
Like the Alto, Star's display has a resolution of 72 pixels per inch. There are two reasons why the number 72 was chosen. First, there are 72 printer's points/inch, so 72 pixels/inch allows for a smooth interface with the world of typesetting and typography. Second, 72 pixels/inch is high enough resolution to allow a wide range of graphics and character sizes -- down to about eight points -- to be legible on the screen (see Fig. 1), but not so high that the memory burden is onerous, as a screen that matched the 300 dot/inch printer resolution would have been. The pixel size and density is the same horizontally and vertically, unlike many PC graphic displays, simplifying the display software and improving image quality.
Windows -- It is now common for systems to allow several programs to display information simultaneously in separate areas of the screen, rather than each taking up the entire display. Star was the first commercial system to provide this capability.
Some windowing systems allow windows to overlap each other. Other systems don't: the size and position of windows are adjusted by the system as windows are opened and closed. Star's windowing system could overlap windows and often did (e.g., property sheets were displayed in windows that overlapped application windows). However, Star's designers observed in early testing that users spent a lot of time adjusting windows and usually adjusted them so that they did not overlap. Because of this, and because Star's 17-inch screen was large enough that there wasn't as much of a need for overlapping windows as there is in systems having less screen space, the designers decided that application windows should be constrained so as not to overlap. However, due to later recognition that there are situations in which overlapping application windows are preferable and a reduction in the standard screen size to 15 inches (with a 19-inch screen optional), the constraints were made optional in ViewPoint, Star's successor, with the default setting being that application windows can overlap one another.
Integrated applications -- This industry buzzword has been used to describe many things; here it means that text, graphics, tables, and mathematical formulae are all edited inside documents. In many other systems, different types of content are edited in separate application windows and then cut/pasted together. For example: a MacDraw drawing put into a Microsoft Word or Aldus PageMaker document can no longer be edited; rather, the original must be re-edited with MacDraw and then substituted for the old drawing in the document.
Not even Star is fully integrated in the sense used here. For example, though the original structured graphics editor, the new one (see History of Star Development, below), and the table and formula editors all operate inside text files, spreadsheets and freehand drawings are currently edited in separate application windows and transferred into documents, where they are no longer fully editable.
Fig. 1 -- ViewPoint screen image. Star's bitmapped display, once unique in the market place, is now much more common. Such a display permits WYSIWYG editing, display of proportionally-spaced fonts, integrated text and graphics, and graphical user interfaces.
Desktop Metaphor -- Star, unlike all conventional systems and many window-and-mouse-based ones, makes use of an analogy with real offices to make the system easy to learn. This analogy is called "the Desktop metaphor". To quote from an early article about Star:
Every user's initial view of Star is the Desktop, which resembles the top of an office desk, together with surrounding furniture and equipment. It represents a working environment, where current projects and accessible resources reside. On the screen are displayed pictures of familiar office objects, such as documents, folders, file drawers, in-baskets, and out-baskets. These objects are displayed as small pictures, or icons.
The Desktop is the principal Star technique for realizing the physical office metaphor. The icons on it are visible, concrete embodiments of the corresponding physical objects. Star users are encouraged to think of the objects on the Desktop in physical terms. You can move the icons around to arrange your Desktop as you wish. (Messy Desktops are certainly possible, just as in real life.) You can leave documents on your Desktop indefinitely, just as on a real desk, or you can file them away.1
Having windows and a mouse does not make a system an embodiment of the Desktop metaphor. In a Desktop metaphor system, users deal mainly with data files, oblivious to the existence of programs. They do not "invoke a text editor", they "open a document". The system knows the type of each file and notifies the relevant application program when one is opened.
Most systems, even many windowed ones, use a Tools metaphor, in which users deal mainly with applications as tools: users start one or more application programs (e.g., word processor, spreadsheet), then specify one or more data files to edit with each. Such systems do not explicitly associate applications with data files; the burden of doing that -- and of making sure not to try to edit a spreadsheet file with the text editor or vice-versa -- is on users. Different kinds of files are distinguished by user-convention, usually via filename extensions (e.g., memo.txt). Star relieves users of the need to keep track of which data file goes with which application.
SunView is an example of a window system that is based upon the Tools metaphor rather than the Desktop metaphor. Its users see a collection of application program windows, each of which is used to edit certain files. Smalltalk-80, Cedar, and various Lisp environments also use the Tools metaphor rather than the Desktop metaphor.
This is not to say that the Desktop metaphor is superior to the Tools metaphor. The Desktop metaphor was intended for office automation and publishing. It may not be appropriate for other applications (e.g., software development). However, it can be argued that orienting users toward their data rather than toward application programs and employing analogies with the physical world are useful techniques in any domain.
The disadvantage of assigning data files to applications is that users sometimes want to operate on a file with a program other than its "assigned" application. Such cases must be handled in Star in an ad hoc way, whereas systems like Unix allow almost any file to be run through a wide variety of programs. Star's designers feel that, for its audience, the advantages of allowing users to forget about programs outweighs this disadvantage.
Generic commands -- One way to simplify a computer system is to reduce the number of commands. Star achieves simplicity without sacrificing functionality by having a small set of generic commands apply to all types of data: Move, Copy, Open, Delete, Show Properties, and Same (Copy Properties). These commands are invoked via dedicated function keys on Star's keyboard. Each type of data object interprets a generic command in a way that is appropriate for it.
Such an approach avoids the proliferation of object-specific commands and/or command modifiers that are found in most systems, e.g., Delete Character, Delete Word, Delete Line, Delete Paragraph, Delete File. Command modifiers are necessary in systems in which selection is only approximate. For example, in many systems, the object of a command is specified by a combination of the cursor location and the command modifier, e.g., Delete Word means: "delete the word that the cursor is on". Modifiers are unnecessary in Star because exact selection of the objects of commands is easy. In many systems, the large number of object-specific commands is made even more confusing by using single-word synonyms instead of command modifiers for similar operations on different objects. For example, depending upon whether the object of the command is a file or text, the command to use might be Remove or Delete, Duplicate or Copy, and Find or Search, respectively.
Careful choice of the generic commands can further reduce the number of commands required. For example, one might think it necessary to have a generic command Print for printing various things. Having Print apply to all data objects would avoid the trap that some systems fall into of having separate commands for printing documents, spreadsheets, illustrations, directories, etc., but it is nonetheless unnecessary. In Star, printing is invoked via the Copy command: users simply copy whatever they want to print to a printer icon. No Print command is needed. Similarly, the function Send Mail is handled via Move: by moving a document to the Out-basket.
Of course, not everything can be done via generic commands. Some operations are object-specific. For example, a word may be italicized, but italics is meaningless for a triangle. In Star, object-specific operations are provided via selection-dependent "soft" function keys and via menus attached to application windows.
Direct manipulation; graphical user interface -- Traditional computer systems require users to remember and type a great deal just to control the system. This is an impediment to learning and retention, especially by casual users. Star's designers favored an approach that emphasizes recognition over recall, seeing and pointing over remembering and typing. This suggested using menus rather than commands. However, the designers wanted to go beyond a conventional menu-based approach. They wanted users to feel that they are manipulating data directly, rather than issuing commands to the system to do it. Star's designers also wanted to exploit the tremendous communication possibilities of the display. They wanted to move away from strictly verbal communication. Therefore, they based the system heavily upon principles that are now known as direct manipulation and graphical control.
Star users control the system by manipulating graphical elements on the screen, elements that represent the state of the system and data created by users. The system does not distinguish between input and output: Anything displayed (i.e., output) by the system can be pointed to and acted upon by the user (i.e., input). When Star displays a directory, it -- unlike MS-DOS and Unix -- is not displaying a list of the names of the files in the directory, it is displaying the files themselves so that they can be manipulated by the user. Users of this type of system have the feeling that they are operating upon the data directly, rather than via an agent: like fetching a book from a library shelf onesself rather than asking someone to do it.
A related principle is that the state of the system is always reflected in the display. Nothing happens "behind the user's back." One needn't fiddle with the system to understand what's going on; one can understand by inspection. One of Star's designers wrote:
When everything in a computer system is visible on the screen, the display becomes reality. Objects and actions can be understood purely in terms of their effects upon the display. This vastly simplifies understanding and reduces learning time.2
An example of this philosophy is the fact that -- unlike many window-based computer systems, even some developed at Xerox -- there are no hidden menus in Star: all available menus are marked via menu buttons.
For a more detailed explanation of Direct Manipulation, see the Sidebar.
Icons and iconic file management -- Computer users often have difficulty managing their files. Before Star existed, a secretary at Xerox complained that she couldn't keep track of the files on her disk. An inspection of her system revealed files named: memo, memo1, memo071479, letter, etc. Naming things to keep track of them is bothersome enough for programmers, but completely unnatural for most people.
Star alleviates this problem partly by representing data files via pictures of office objects called icons. Every application data file in the system has an icon representing it. Each type of file has a characteristic icon shape. If a user is looking for a spreadsheet, his or her eye can skip over mailboxes, printers, text documents, etc.
Furthermore, Star allows users to organize files spatially rather than via distinctive naming. Systems having hierarchical directories, such as Unix and MS-DOS, provide an abstract sort of "spatial" file organization, but Star's approach is concrete. Files can be kept together by putting them into a folder or simply by clumping them together on the Desktop, modeling how people organize their physical worlds. Since data files are represented by icons, and files are distinguished by location and specified by selection rather than by name, users can use names like memo, memo1, letter, etc. without losing track of their files as easily as they would with most systems.
As bitmap, window, and mouse-based systems become more common, the use of the term "icon" is widening to refer to any non-textual symbol on the display. In standard English, "icon" is a term for religious statues or pictures that are believed to contain some of the powers of the deities they represent. It would be more consistent with its normal meaning if "icon" were reserved for objects having behavior and intrinsic properties. Most graphical symbols and labels on computer screens are therefore not icons. In Star, only representations of files on the Desktop and in folders, mailboxes, and file drawers are called "icons".
Few modes -- A system has modes if user-actions differ in effects or availability in different situations. Tesler has argued that modes in interactive computer systems are undesirable because they restrict what functions are available at any given point and force users to keep track of what state the system is in in order to know what effect their actions will have.3 Though modes can be helpful in guiding users through unfamiliar procedures or for handling exceptional activities, they should be used sparingly and with care.
Star avoids modes in several ways. One is the extensive use of generic commands (see above), which drastically reduces the number of commands needed, which, in turn, means that designers need not assign double-duty (i.e., different meanings in different modes) to physical controls. A second way is by allowing applications to operate simultaneously: when using one program (e.g., a document editor), users are not in a mode that prevents them from using the capabilities of other programs (e.g., the desktop manager).
A third way that Star avoids modes is by using a Noun-Verb command syntax: Users select an operand (e.g., a file, a word, a table), then invoke a command. In conventional systems, arguments follow commands, either on a command line or in response to prompts. Whether a system uses Noun-Verb or Verb-Noun syntax has a lot to do with how moded it is. In a Noun-Verb system such as Star, selecting an object prior to choosing a command does not put the system into a mode: users can decide not to invoke the command without having to "escape out" of anything or can select a different object to operate on.
Though modes are avoided in Star, it is not completely modeless. For example, the Move and Copy commands require two arguments: the object to be moved and the final destination. Though there are less moded ways to design Move and Copy, these functions currently require the user to select the object to be moved or copied, press the Move or Copy key, and then indicate the destination using the mouse. While Star waits for the user to point to a destination, it is in Move or Copy mode: other uses of the mouse are precluded. These modes are, however, relatively harmless because: 1) the state of the system is clearly indicated by the shape of the cursor, and 2) they are entered and exited by a user in the course of carrying out a single mental plan, making it unlikely that the system will be in the "wrong" mode when the user begins his or her next action.
Objects have properties -- Properties allow objects of the same type to vary in appearance, layout, and behavior. For example, files have a Name property, characters have a Font family property, paragraphs have a Justified property. Properties may have different types of values: The Name property of a file is a text string; the Size property of a character might be a number or a choice from a menu; the Justified property of a paragraph is either ON or OFF. In Star, properties are displayed and changed in graphical forms called property sheets.
Property-based systems are rare. Most computer systems, even today, allow users to set parameters for the duration of an interactive session, or for the duration of a command, but not for particular data-objects. For example, headings in WordStar documents do not "remember" whether they are centered or not; whether a line is centered is determined by how the program was set when the line was typed. Similarly, directories in Unix do not "remember" whether files are to be listed in alphabetical or temporal order; users must respecify which display order they want every time they invoke the ls command.
Progressive disclosure -- It has been said that "computers promise the fountains of utopia, but only deliver a flood of information".4 Indeed, many computer systems overwhelm their users with choices, commands to remember, and poorly organized output, much of which is irrelevant to what the user is trying to do. They make no presumptions about what the user wants, and thus are designed as if all possible user actions were equally likely and as if all information generated by the system were of equal interest to the user. Some systems diminish the problem somewhat by providing default settings of parameters to simplify tasks expected to be common.
Star goes further towards alleviating this problem by applying a principle called "progressive disclosure". Progressive disclosure dictates that detail be hidden from users until they ask or need to see it. Thus, Star not only provides default settings, it hides settings that users are unlikely to change until users indicate that they want to change them. Implicit in this design are assumptions about which properties will be less frequently altered.
One place progressive disclosure is used is in property sheets. Some objects have a large number of properties, many of which are relevant only when other properties have certain values (see Fig. 2). For example, on the page layout property sheet, there is no reason to display all of the properties for specifying running header content and position unless the user actually specifies that the document is to have running headers.
Another example of progressive disclosure is the fact that property displays in Star are temporary, displayed on demand. In some systems, the properties of the current selection are displayed at all times -- via codes embedded in the text or in an area of the screen reserved for that purpose -- even though the user usually doesn't care.
Fig. 2 -- Progressive disclosure.
Star's property sheets, like the rest of the interface, make use of a principle known as "progressive disclosure" to avoid overwhelming users with information. Usually, users don't need to see an object's properties: they only need to see and perhaps change its assigned style. Users see an object's properties only upon request. Also, even when a user sets a property sheet to show an object's properties, as is shown above, some information is hidden until the user asks to see it. For example, there is no need to clutter the property sheet shown above with boxes for entering numbers for "Other" values of Line Height, Spacing Before Paragraph, or Spacing After Paragraph until the user has actually sets the property to "Other".
A highly refined manifestation of progressive disclosure that has recently been added to ViewPoint is styles, which allows users to regard document content (e.g., a paragraph) as having a single style rule instead of a large number of properties. Thus, styles hide needless detail from users.
Consistency -- Because Star and all of its applications were designed and developed in-house, its designers had more control over its user interface than is usually the case with computer systems. Because the designers payed close attention to detail, a very high degree of consistency was achieved. The left mouse button always selects; the right always extends the selection. Mouse sensitive areas always give feedback when the left button goes down, but never take effect until the button comes up.
Strong emphasis on good graphic and screen design -- Windows, icons, and property sheets are useless if users can't easily distinguish them from the background or each other, can't easily see which labels correspond to which objects, or are overwhelmed with visual clutter. To assure that Star presents information in a maximally-perceivable and useful fashion, Xerox hired graphic designers to determine the appearance and placement of screen objects. These designers applied various written and unwritten principles to the design of the window headers and borders, the Desktop background, the command buttons, the pop-up menus, the property sheets, and the Desktop icons. The most important principles are:
Figure 3 -- Visual order and user focus.
The large amount of contrast present on the screens of many window
systems (upper screen) makes it difficult to focus on the relevant
information. The selection should be the user's main focus: it
is the object of the next operation. The lower screen shows how
Star/ViewPoint's screen design focuses attention on the selection.
Figure 4 -- Visual order and user focus.
Four candidate sets of icons were designed and tested for Star. A
representative sample from each set is shown here. In Star, the
icon selected by the user to be operated on is indicated by
inverting its image. Candidate icon sets in which the images are
mostly white allow icons to stand out when they are selected by
the user. The set that best satisfies this criterion, the one on
the upper left, was chosen.
Figure 5 -- -- Revealed structure.
At the top is the WYSIWYG view of mixed text and graphics. The
middle two panels show that structure is revealed when an object
is selected. When a line segment is selected, its control points
are shown. When text is selected, the text "string" is revealed.
The bottom panel shows the effect of the Show Structure and Show
Non-Printing Characters commands, which is to reveal the location
of embedded graphics and text frames (dotted lines) and "new
paragraph" and SPACE characters.
Fig. 6 -- Desktop grey.
25% grey pattern designed to reduce flicker and provide background texture.
WYSIWYG document editor -- Within the limits of screen resolution, Star documents are displayed as they will be printed, including typographic features such as boldface, italics, proportional spacing, variable font families, superscripts, and layout features such as embedded graphics, page numbers, headers, and footers. This is commonly referred to as "What You See Is What You Get", or "WYSIWYG".
Star adheres to this principle even in domains where other "WYSIWYG" document editors do not. For example, mathematical formulae are created and edited in documents using a WYSIWYG editor that has knowledge built into it about the appearance and layout of mathematical symbols. A square root sign has a slot for an expression, and grows when the expression becomes large (see Fig. 7). In most systems, mathematical formulae are created either by putting together special characters to make mathematical symbols or by using a special in-line notation (e.g., sqrt(sigma(1, n, (x*3)/2))) to represent the formula that will eventually be printed. Formulae created with such systems usually require several print-edit cycles to get right.
Fig. 7 -- WYSIWYG formula editing.
Mathematical formulae are edited in Star in a highly-WYSIWYG fashion, in contrast to most systems, in which formulae are specified via in-line expressions or by constructing them from pieces in a special character font.
Extended character set for multilingual capability -- Star uses sixteen-bit character codes, in contrast to most of the computer industry, which uses seven- or eight-bit character codes (i.e., ASCII or EBCDIC). The Star character set is a superset of ASCII. The reason for a sixteen bit code is a strong market requirement for enhanced multilingual capabilility coming from Xerox's subsidiaries in Europe and Japan. Most systems provide non-English characters via different fonts, so that the eight-bit "extended" ASCII codes might be rendered as math symbols in one font, Greek letters in another font, and Arabic in yet another. This has the effect that when any application loses track of font information while handling the text (which happens often in some systems), a paragraph of Arabic may turn into nonsensical Greek or math symbols or something else, and vice-versa.
Star uses sixteen-bit character codes to permit the system to reliably handle European languages and also Japanese, which uses many thousands of characters. All Star and ViewPoint systems have French, German, Italian, Spanish and Russian language capabilities built in. The Japanese language capability was developed as part of the original Star design effort, and released in Japan soon after Star's debut in the U.S. Since that time, many more characters have been added, covering Chinese, Arabic, Hebrew, and nearly all European languages.
As is explained in several articles by Joe Becker, the designer of Star's multilingual capabilities, handling many of the world's languages requires more than an expanded character set.5,6,7 Clever typing schemes and sophisticated rendering algorithms are required to provide a multilingual capability that satisfies customers.
The document is the heart of the world, and unifies it -- Most personal computers and workstations give no special status to any particular application. Dozens of applications are available, most of which are incompatible with each other in data format as well as user interface.
Star, in contrast, assumes that the primary use of the system is to create and maintain documents. The document editor is thus the primary application. All other applications exist mainly to provide or manipulate information whose ultimate destination is a document. Thus, most applications are integrated into the document editor (see Integrated applications, above), operating within frames embedded in documents, and those applications that are not part of the document editor support transfer of their data to documents.
Having described what Star and ViewPoint are, we will describe where they came from and how they were developed. Fig. 8 graphs this history, showing systems that influenced Star and those that were influenced by it.
Fig. 8 -- How systems influenced later systems.
This graph summarizes how various systems related to Star have influenced one another over the years. Time progresses downwards. Double arrows indicate direct successors (i.e., follow-on versions). Many "influence arrows" are due to key designers changing jobs or applying concepts from their graduate research to products.
Although Star was conceived as a product in 1975 and was released in 1981, many of the ideas that went into it were born in projects dating back over three decades.
Memex -- The story starts in 1945, when Vannevar Bush, a designer of early calculators and one of President F.D. Roosevelt's science advisors, wrote an article describing his vision of the uses of electronics and information technology. At a time when computers were new, room-sized, and used only for military number-crunching, Bush envisioned a personal, desktop computer for non-numerical applications, and called it the Memex. Due to insufficient technology and insufficient imagination on the part of others, Bush's ideas languished for fifteen years.
SketchPad -- In the Sixties, people began to take interactive computing seriously. One such person was Ivan Sutherland. He built an interactive graphics system called Sketchpad that allowed a user to create graphical figures on a CRT display using a light pen. The geometric shapes users put on the screen were treated as objects: after being created, they could be moved, copied, shrunk, expanded, and rotated. They could also be joined together to make larger, more complex objects that could then be operated upon as units. Sketchpad influenced Star's user interface as a whole as well as its graphics applications.
NLS -- Also in the Sixties, Douglas Engelbart established a research program at Stanford Research Institute (now called SRI International) for exploring the use of computers "to augment the knowledge worker" and human intellect in general. He and his collegues experimented with different types of displays and input devices -- inventing the mouse when other pointing devices proved inadequate -- and developed a system commonly known as NLS.2* NLS was unique in several respects. It used CRT displays when most computers used teletypes. It was interactive (i.e., on-line) when almost all computing was batch. It was full-screen-oriented when the few systems that were interactive were line-oriented. It used a mouse when all other graphic interactive systems used cursor keys, light pens, joy sticks, or digitizing tablets. Finally, it was the first system to organize textual and graphical information in trees and networks, which today would be called an "idea processor" or a "hypertext system".
The Reactive Engine -- While Engelbart et al were developing ideas, some of which eventually found their way into Star, Alan Kay, then a graduate student, was doing likewise. His dissertation, The Reactive Engine, contained seeds of many ideas that he and others later brought to fruition in the Smalltalk language and programming environment, which, in turn, influenced Star. Like the designers of NLS, Kay realized that interactive applications do not have to treat the display as a "glass teletype" and can share the screen with other programs.
In 1970, Xerox established a research center in Palo Alto to explore technologies that would be important not only for the further development of Xerox's then-existing product line (i.e., copiers), but also for Xerox's planned expansion into the office systems business. The Palo Alto Research Center (abbreviated "PARC") was organized into several laboratories, each devoted to basic and applied research in a field related to the above goals. The names and organization of the labs have changed over the years, but the research topics have stayed the same: materials science, laser physics, integrated circuitry, CAD/CAM, user interface (not necessarily to computers), and computer science (including networking, databases, operating systems, languages and programming environments, graphics, document production systems, and artificial intelligence).
Alto -- PARC researchers were fond of the slogan: "The best way to predict the future is to invent it." After some initial experiments with time-shared systems, they began searching for a new approach to computing. Among the founding members of PARC was Alan Kay. He and his collegues were acquainted with NLS and liked its novel approach to human-computer interaction. Soon, PARC hired several people who had worked on NLS and in 1971 signed an agreement with SRI licensing Xerox to use the mouse. Kay and others were dedicated to a vision of personal computers in a distributed environment. In fact, they coined the term "personal computer" in 1973, long before microcomputers started what has been called the "personal computer revolution". One result of the search for a new approach was the Alto (see Fig 9).
The Alto was a mini-computer that had a removable, 2.5 mega-byte hard disk pack (floppy disks did not exist at the time) and 128 to 256 kbytes of memory. Unlike most machines of its day, the Alto also had a microprogrammable instruction set, a "full-page" (10 1/2 x 8 1/4 inch; 600 x 800 pixel) bitmapped graphic display, about 50 kbytes of high-speed display memory, and a mouse.
The first Alto was operational in 1972. At first, only a half-dozen or so Altos were built. After software that exploited the Alto's capabilities became available, demand for them grew tremendously, spreading beyond PARC into Xerox as a whole and even to external customers. Eventually, over a thousand Altos were built.
Ethernet -- Another product of the new approach was the Ethernet. With its standardized, layered communications protocols, Ethernet provides a way of connecting computers much more flexibly than had been previously possible. Soon after the first Altos were built, they were networked together. Eventually, the network grew to thousands of workstations (Altos and Alto-successors) within Xerox's worldwide organization, giving Xerox millions of person-hours of experience with networked personal computers and servers.
Smalltalk -- Alan Kay had been one of the main advocates of the Alto. His Learning Research Group (LRG) began using the Alto to build prototypes for a personal computing system "of the future": a portable machine that would provide -- rather than a canned set of applications -- the building blocks necessary for users to build the tools and applications they need to solve their own information processing problems. The technologies needed to build a lap computer with the power of the "DynaBook" (as the envisioned system was called) were unavailable at the time, and still are. The prototypes developed by Kay's group evolved into the Smalltalk language and programming environment. They further promoted the notion of personal computing, pioneered complete, interactive programming environments, and refined and solidified concepts of object-oriented programming that had been extant only in vestigial form in previous systems. Most importantly for Star, they demonstrated the power of graphical, bitmapped displays, mouse-driven input, windows, and simultaneous applications. This is the most visible link between Smalltalk and Star, and is perhaps why many people wrongly believe that Star was written in Smalltalk.
Pygmalion -- The first large program to be written in Smalltalk was Pygmalion, the doctoral thesis project of David Smith. One goal of Pygmalion was to show that programming a computer does not have to be primarily a textual activity: it can be accomplished, given the appropriate system, by interacting with graphical elements on a screen. A second goal was to show that computers can be programmed in the language of the user interface, i.e., by demonstrating what one wants done and having the computer remember and reproduce it. The idea of using icons -- images that allow users to manipulate them and in so doing act upon the data they represent -- came mainly from Pygmalion. After completing Pygmalion, Smith worked briefly on the NLS project at SRI before joining the Star development team at Xerox.
Bravo, Gypsy, and BravoX -- At the same time that LRG was developing Smalltalk for the Alto, others at PARC, mainly Charles Simonyi and Butler Lampson, were writing an advanced document editing system for it: Bravo. Because it made heavy use of the Alto's bitmapped screen, Bravo was unquestionably the most WYSIWYG text editor of its day, with on-screen underlining, boldfacing, italics, variable font families and sizes, and variable-width characters. It allowed the screen to be split, so that different documents or different parts of the same document could be edited at once, but did not operate in a windowed environment as we use the term today. Bravo was widely-used at PARC and in Xerox as a whole.
In 1976-78, Simonyi and others rewrote Bravo, incorporating many of the new user-interface ideas floating around PARC at the time. One such idea was modelessness, promoted by Larry Tesler3 and exemplified in Telser's prototype text editor Gypsy. They also added styles, enhancing users' ability to control the appearance of their documents. The new version was called BravoX. Shortly thereafter, Simonyi joined Microsoft, where he led the development of Microsoft Word, a direct descendent of BravoX. Another member of the BravoX team, Tom Malloy, went to Apple and wrote LisaWrite.
Draw, SIL, Markup, Flyer, and Doodle -- Star's graphics capability (i.e., its provisions for users to create graphical images for incorporation into documents, as opposed to its graphical user interface) owes a great deal to several graphics editors that were written for the Alto and later machines.
Draw, by Patrick Beaudelaire and Bob Sproull, and SIL (for Simple Illustrator) were intellectual successors of Sutherland's Sketchpad (see above): graphical object editors that allowed users to construct figures out of selectable, movable, stretchable geometric forms and text. In turn, Star's graphic frames capability is in large measure an intellectual successor of Draw and SIL.
Markup was a bitmap graphics editor (i.e., a paint program) written by William Newman in BCPL for the Alto. Flyer was another paint program, written in Smalltalk for the Alto by Bob Flegel and Bill Bowman. These programs inspired Doodle, a paint program written for a later machine by Dan Silva. Doodle eventually evolved into ViewPoint's Free-Hand Drawing application. Silva went on to write DeluxePaint, a paint program for PCs.
Laser Printing -- Fancy graphics capabilities in a workstation are of little use without hardcopy capability to match it. Laser printing, invented at PARC, provided the necessary base capability, but a way was needed for computers to describe output to laser printers in a uniform way. For this purpose, Bob Sproull developed the Press page-description language. Press was heavily used at PARC, then further developed into Interpress, Xerox's product page-description language and the language in which Star encodes printer output. Some of the developers of Interpress later formed Adobe Systems and developed Postscript, a popular page description language.
Laurel and Hardy -- A network of personal workstations suggests electronic mail. Though electronic mail was not invented at PARC, PARC researchers (mainly Doug Brotz) made it user-friendly for the first time by creating Laurel, a display-oriented tool for sending, receiving, and organizing e-mail. The experience of using Laurel, which was named after a tree, inspired others to write Hardy, named after Laurel, for an Alto successor machine. Laurel and Hardy were instrumental in getting non-engineers at Xerox to use e-mail. The use of e-mail spread further when Star and ViewPoint spread throughout Xerox. Today, Xerox employees depend heavily upon the company's global e-mail network for communication, both work-related and otherwise, with other employees.
OfficeTalk -- One more Alto program that influenced Star was OfficeTalk, a prototype office automation system written by Clarence "Skip" Ellis and Gary Nutt. OfficeTalk supported standard office automation tasks and tracked "jobs" as they went from person to person in an organization. Experience with OfficeTalk provided ideas for Star because of the two systems' similar target applications.
The debt that Star owes to the Alto and its software is best summed up by quoting from the original designers, who wrote in 1982:
Alto served as a valuable prototype for Star. ... Alto users have had several thousand work-years of experience with them over a period of eight years, making Alto perhaps the largest prototyping effort in history. There were dozens of experimental programs written for the Alto by members of the Xerox Palo Alto Research Center. Without the creative ideas of the authors of these systems, Star in its present form would have been impossible. ... In addition, we ourselves programmed various aspects of the Star design on the Alto...1
To develop Star and other office systems products, Xerox created the Systems Development Department (SDD). SDD was staffed by transferring people from other parts of Xerox, including PARC, as well as by hiring from outside. Thus, contrary to what has often been stated in the industry press, Star was not developed at PARC, but rather in a separate product development organization.
When SDD was formed, a decision was made to use Mesa, an "industrial-strength" dialect of Pascal that had been conceived at SRI and further developed at PARC, as the primary product programming language. SDD took over development and maintenance of Mesa from the Computer Science Laboratory (CSL) at PARC, freeing CSL to develop Mesa's research successor, Cedar.
Star Hardware -- Star is often discussed as if it were a computer. In fact, Star is a body of software.3* However, using the name Star to refer to the machine is understandable since the machine was designed in conjunction with the software to meet the needs of the software design. This is in sharp contrast to the usual approach, in which software is designed for existing computers.
The 8000-series workstation was based upon a microcoded processor that was designed within Xerox especially to run the object code produced by the Mesa compiler. Besides being microprogrammed to run Mesa, the processor provided low-level operations for facilitating display operations. For example, the BitBlt operation for manipulating rectangular arrays of screen pixels is implemented as a single instruction. As sold, the machine was configured with at least 384 kbytes real memory (expandable to 1.5 Mbytes), a local hard disk (10, 29, or 40 Mbytes), a 17-inch display, a mechanical mouse, an eight-inch floppy disk drive, and an Ethernet connection. The price was initially $16,500 with software.
Even though the machine was designed to run Star, it also ran other software. In addition to selling it as the 8010 "Star" workstation, Xerox sold it as a server machine and as an Interlisp and a Smalltalk workstation.
Star Software -- Alhough Star incorporated ideas from a number of predecessors, it still required a mammoth design effort to pull all of those ideas -- as well as new ideas -- together to produce a coherent design. According to the original designers, "... it was a real challenge to bring some order to the different user interfaces on the Alto".1 About thirty person-years went into the design of the user interface, functionality, and hardware.
To foster uniformity of specifications as well as thoughtful and uniform design, Star's designers developed a strict format for specifications. Applications and system features were to be described in terms of the objects that users would manipulate via the software and the actions that the software provided for manipulating objects. This "objects and actions" analysis was supposed to be at a fairly high level, without regard to how the objects would actually be presented or how the actions would actually be invoked by users. A full specification was then written from the "objects and actions" version. This approach forced designers to think clearly about the purpose of each application or feature and fostered recognition of similar operations across specifications, allowing what might have seemed like new operations to be handled via existing commands.
When SDD was formed, it was split between two locations: Southern California (El Segundo) and Northern California (Palo Alto). Few people were willing to transfer one way or the other, leaving SDD with the choice of losing many competent engineers or being creative. SDD's management took the creative route: they put the Ethernet to work, putting the development machines at both sites onto a network, connecting the two sites via a 56 kbit/second leased line, encouraging heavy use of electronic mail for work-related communication, and developing tools for facilitating distributed, multi-party development.
As might be expected from Star's origins, most of the design and prototyping work was done in Palo Alto, whereas most of the implementation was done in El Segundo. Though this split was handled creatively, some of Star's designers now believe it caused problems that were not overcome by extensive use of e-mail. For example, the implementors did not benefit from much of the prototyping that had been done at PARC.
The development process has been recounted in detail elsewhere6 and will not be repeated here. Suffice it to say that the Star development effort:
Since the machine upon which Star ran was developed in parallel with the software, it was not available early-on to be used as a software development platform. Early prototyping and development was done on Altos and successor research machines developed at PARC. Though the Mesa language ran on these machines, development aids for Mesa programmers were lacking.
When the 8000-series workstation was available, the systems group within SDD began developing a suitable development environment. When it became available, the development environment, known internally as Tajo and externally as Xerox Development Environment (XDE), and the numerous tools written to run in it were quickly adopted by programmers throughout SDD. As Star was improved later, many good ideas from Tajo were adopted.
ViewPoint Software -- Soon after Star was released, the designers and implementers realized that it had serious problems from a performance, maintenance, and enhancement standpoint. Its high degree of integration and user-interface consistency had been achieved by making it monolithic: the system "knew" about all applications and all parts of the system "knew" about all other parts. It was difficult to correct problems, add new features, and increase performance. The monolithic architecture also did not lend itself to distributed, multi-party development.
This created pressure to rewrite Star. Bob Ayers, who had been heavily involved in the development of Star, rewrote the infrastructure of the system according to the more flexible Tajo model. He built, on top of the operating system and low-level window manager, a "toolkit" for building Star-like applications. Transfer of data between different applications was handled in the new infrastructure via strict protocols involving the user's selection, thus making applications independent from one another. The object-oriented user interface, which requires that the system associate applications with data files, was preserved by having applications register themselves with the system when started, telling it which type of data file they correspond to and registering procedures for handling keyboard and mouse events and generic commands. User-interface consistency was fostered by building many of the standards into the application toolkit. The development organization completed the toolkit and then ported or rewrote the existing applications and utilities to run on top of it. Other software changes included:
To underscore the fact that the new system was a substantial improvement over the old, the name was changed from Star to ViewPoint. ViewPoint 1.0 was released in 1985.
ViewPoint Hardware -- In addition to revising the software, Xerox brought the hardware up to date by designing a completely new vehicle for ViewPoint: the 6085 workstation. The new machine was designed to take advantage of advances in integrated circuitry, reductions in memory costs, new disk technologies, and new standards in keyboard design, as well as to provide IBM PC compatibility. The 6085 workstation has a Mesa processor plus an optional IBM-PC-compatible processor, one megabyte of real memory (expandable to 4 megabytes), a hard disk (10 - 80 megabytes), a choice of a 15- or a 19-inch display, an optical mouse, a new keyboard, a 5 1/4 inch floppy disk drive, and, of course, an Ethernet connection. The base cost was initially $6340 with the ViewPoint software. Like the 8010, the 6085 is sold as a vehicle for Interlisp and Smalltalk as well as for ViewPoint.
Recent ViewPoint changes -- ViewPoint 2.0 has recently been released, adding many features relevant to desktop publishing. These include:
Partly out of excitement over what they were doing, PARC researchers and Star's designers didn't pay enough attention to the "other" personal computer revolution that was occurring outside of Xerox. By the late Seventies, Xerox had its own powerful technical tradition (i.e., mouse-driven, networked workstations with large bitmapped screens and multiple, simultaneous applications), blinding Star's designers to the need to approach the market via cheap, stand-alone PCs. The result was a product that was highly unfamiliar. Nowadays, of course, such systems are no longer unusual.
Developing Star and ViewPoint involved developing several enabling technologies, for networking, communicating with servers, describing pages to laser printers, and software development. At the time they were developed, these technologies were unique in the industry. Xerox elected to keep them proprietary for fear of losing its competitive advantage. With hindsight, we can say that it may have been better to release these technologies into the public domain, or at least to market them early, so that they would become industry standards. Instead, alternative approaches developed at other companies have become the industry standards. Xerox's current participation in the development of various industry standards (e.g., Open Look) indicates its desire to reverse this trend.
The personal computer revolution has shown that it is futile to try to anticipate all of the applications that customers will want. Star should have been designed to be open and extensible by users from the start, as the Alto was. In hindsight, extensibility was one of the keys to the Alto's popularity. The problem wasn't that Star lacked functionality, it was that it didn't have the functionality customers wanted. An example is the initial lack of a spreadsheet application. The designers failed to appreciate the significance of this application, which may have been more important even than word-processing in expanding the personal computer revolution beyond engineers and hobbyists into business. Eventually realizing that Star's closedness was a problem, Xerox replaced it with ViewPoint, a more "open" system that allows users to pick and choose applications that they need, including a spreadsheet and IBM PC software. Apple Computer learned the same lesson with its Lisa computer, and similarly replaced it with a cheaper one having a more open software architecture: Macintosh.
Star's initial per-workstation price was near that of time-shared mini-computers, dedicated word-processors, and other shared computing facilities. Star was, however, competing for desktop space with micro-computer-based PCs. ViewPoint has corrected that problem: The 6085 costs about the same as its competition.
Star's designers should have established performance goals, documented them in the functional specifications, and stuck to them as Star was being developed. Where performance goals couldn't be met, the corresponding functionality should have been cut.
In lieu of speed, the user-interface should have been designed to be more responsive. By designing the system to handle user input more intelligently, systems can be made more responsive without necessarily making them execute functions faster. They can operate asynchronously with respect to user input, making use of background processes, keeping up with important user actions, delaying unimportant tasks (e.g., refreshing irrelevant areas of the screen) until time permits, skipping tasks called for by early user actions but rendered moot by later ones. ViewPoint now makes use of background processes to increase its responsiveness.
Having a development organization that was split between Palo Alto and El Segundo was probably a mistake, less for reasons of distance per se than for lack of shared background in "PARC-style" computing. However, the adverse effect of sheer distance upon communication was certainly a factor.
Direct Manipulation and the Desktop metaphor aren't the best way to do everything. Remembering and typing is sometimes better than seeing and pointing. For example, if a user wants to open a file that is one of several hundred in a directory (folder), the system should let users type its name rather than forcing them to scroll through the directory trying to spot it so they can select it.
Though there are aspects of Star that perhaps should have been done differently, most of the aspects of Star's design described at the beginning of this article have withstood the test of time. These include:
Iconic, direct-manipulation, object-oriented user interface -- The days of cryptic command languages and scores of commands for users to remember (a la Unix and MS-DOS) should have passed long ago.
Generic commands and consistency in general -- Even Macintosh could use some lessons in this regard: it uses Duplicate for copying files within a disk but dragging of icons for copying them across disks, not to mention Copy-Paste for copying anything else.
Pointing device -- Although cursor keys have some advantages and certainly would have enhanced Star's market appeal (as they have ViewPoint's), Star's designers stand by the system's primary reliance on the mouse. This does not imply a commitment to the mouse per se, but rather to any pointing device that allows quick pointing and selection. As interfaces evolve in the future, high-resolution touch screens and other more exotic devices may replace mice as the pointing devices of choice.
Star has had an indisputable influence on the design of computer systems. For example, the Lisa and Macintosh might have been very different had Apple's designers not borrowed ideas from Star, as the following excerpt of a Byte magazine interview of Lisa's designers shows:
Byte: Do you have a Xerox Star here that you work with?
Telser: No, we didn't have one here. We went to the NCC when the Star was announced and looked at it. And in fact it did have an immediate impact. A few months after looking at it we made some changes to our user interface based on ideas that we got from it. For example, the desktop manager we had before was completely different; it didn't use icons at all, and we never liked it very much. We decided to change ours to the icon base. That was probably the only thing we got from Star, I think. Most of our Xerox inspiration was Smalltalk rather than Star.7
Elements of the Desktop metaphor approach can also be seen in many other systems.
The history presented here has shown, however, that Star's designers did not invent the system out of nothingness. Just as it has influenced systems that came after it, Star was influenced by ideas and systems that came before it. It is difficult to inhibit the spread of good ideas once they are apparent to all, especially in this industry. Star was thus just one step -- albeit an important one -- in an evolutionary process that will continue both at Xerox and elsewhere. That is how it should be.
1. Smith, D.C., Irby, C.H., and Kimball, R.B., Harslem, E.F. "The Star User Interface: An Overview" Proceedings of the AFIPS National Computer Conference, 1982, pages 515-528.
2. Smith, D.C. "Origins of the Desktop Metaphor: A Brief History" Panel: The Desktop Metaphor as an Approach to User Interface Design, in Proceedings of the ACM Annual Conference, 1985, page 548.
3. Tesler, L. "The Smalltalk Environment" Byte, August 1981, 6(8), pages 90-147.
4. Winner, L. "Mythinformation" Whole Earth Review, January 1985.
5. Becker, J. "Multilingual Word Processing" Scientific American, July 1984, 251(1), pages 96-107. [See Further Reading for other articles on Star's multilingual capability.]
6. Harslem, E.F. and Nelson, L.E. "A Retrospective on the Development of Star" Proceedings of the Sixth International Conference on Software Engineering, 1982, Tokyo, Japan.
7. Williams, G. "The Lisa Computer System" Byte, February 1983, pages 33-50.
Sidebar: Further Reading
Pre-Xerox
Bush, V. "As We May Think" Atlantic Monthly, July 1945, 176(1), pages 101-108.
Engelbart, D.C. and English, W.K. "A Research Center for Augmenting Human Intellect" AFIPS Proceedings of the Fall Joint Computer Conference (Vol. 33), 1968, pages 395-410.
English, W.K., Engelbart, D.C., and Berman, M.L. "Display-Selection Techniques for Text Manipulation" IEEE Transactions on Human Factors in Electronics, HFE-8, 1967, pages 21-31.
Kay, A.C. The Reactive Engine. Salt Lake City: University of Utah, 1969.
Sutherland, I.E. Sketchpad: A Man-Machine Graphical Communications System Ph.D. Thesis, M.I.T., 1963.
Card, S., English, W.K., and Burr, B. "Evaluation of Mouse, Rate-Controlled Isometric Joystick, Step Keys, and Text Keys for Text Selection on a CRT" Ergonomics, 1978, 21, pages 601-613.
Ellis, C. and Nutt, G. "Computer Science and Office Information Systems" Xerox PARC Tech. Report SSL-79-6, 1979.
Geschke, C.M., Morris, J.H. Jr., Satterthwaite, E.H. "Early Experience with Mesa" Communications of the ACM 1977, 20(8), pages 540-553.
Ingalls, D.H. "The Smalltalk Graphics Kernel" Byte, August
1981, 6(8), pages 168-194.
Kay, A.C. and Goldberg, A. "Personal Dynamic Media" IEEE
Computer, March 1977, 10(3), pages 31-41.
Kaye, A.C. "Microelectronics and the Personal Computer" Scientific American, September 1977, 237(3).
Smith, D.C. Pygmalion: A Computer Program to Model and Simulate Creative Thought. Basel and Stuttgart: Birkhauser Verlag, 1977.
Thacker, C.P., McCreight, E.M., Lampson, B.W., Sproull, R.F., and Boggs, D.R. "Alto: A Personal Computer" In Siewioek, D., Bell, C.G., and Newell, A. (eds), Computer Structures: Principles and Examples, New York: McGraw Hill, 1982.
Curry, G., Baer, L., Lipkie, D. and Lee, B. "Traits -- An Approach to Multiple-Inheritance Subclassing" Proceedings of the ACM Conference on Office Automation Systems (SIGOA), 1982.
Dalal, Y.K. "Use of Multiple Networks in the Xerox Network System" IEEE Computer, 15(10), October 1982, pages 82-92.
Johnsson, R.K. and Wick, J.D. "An Overview of the Mesa Processor Architecture" SIGPLAN Notices 17(4).
Lipkie, D.E., Evans, S.R., Newlin, J.K., Weissman, R.L. "Star Graphics: An Object-Oriented Implementation" Computer Graphics, July 1982, 16(3), pages 115-124.
Shoch, J.F., Dalal, Y.K., Crane, R.L., and Redell, D.D. "Evolution of the Ethernet Local Computer Network" IEEE Computer, 15(9), August 1982, pages 10-27.
Smith, D.C., Irby, C.H., Kimball, R.B., Verplank, W.H., and Harslem, E.F. "Designing the Star User Interface" Byte, 1982, 7(4), pages 242-282.
Sweet, R.E. and Sandman, J.G. Jr. "Empirical Analysis of the Mesa Instruction Set" SIGPLAN Notices 17(4).
Becker, J. "Typing Chinese, Japanese, and Korean" IEEE Computer, January 1985, pages 27-34.
Becker, J. "Arabic Word Processing" Communications of the ACM, July 1987, 30(7), pages 600-610.
Bewley, W.L., Roberts, T.L., Schroit, D., Verplank, W.L. "Human Factors Testing in the Design of Xerox's 8010 Star Office Workstation" Proceedings of the ACM Conference on Human Factors in Computing Systems, 1983, pages 72-77.
Bhushan, A. and Plass, M. "The Interpress Page and Document Description Language" IEEE Computer, June 1986, pages 72-77.
Curry, G. and Ayers, R. "Experience with Traits in Star" Programming Productivity: Issues for the Eighties, 1986, IEEE Computer Society Order # 681.
Halbert, D. "Programming by Example" Xerox OSD Technical Report OSD-T84-02, 1984.
Lewis, B. and Hodges, J. "Shared Books: Collaborative Publication Management for an Office Information System" Proceedings of the ACM Conference on Office Information Systems, 1988.
Bly, S. and Rosenberg, J. "A Comparison of Tiled and Overlapping Windows" Proceedings of the ACM Conference on Computer-Human Interaction, 1986, pages 101-106.
Goldberg, A. Smalltalk-80: The Interactive Programming Environment. Reading, Massachusetts: Addison-Wesley, 1984.
Goldberg, A. and Robson, D. Smalltalk-80: The Language and its Implementation. Reading, Massachusetts: Addison-Wesley, 1984.
Halasz, F. and Moran, T. "Analogy Considered Harmful" Proceedings of the Conference on Human Factors in Computing Systems, Gaithersburg, MD, 1982, pages 383-386.
Houston, T. "The Allegory of Software: Beyond, Behind, and Beneath the Electronic Desk" Byte, December 1983, pages 210-214.
Johnson, J. "Calculator Functions on Bitmapped Computers" SIGCHI Bulletin, July 1985, 17(1), pages 23-28.
Johnson, J. "How Closely Should the Electronic Desktop Simulate the Real One?" SIGCHI Bulletin, October 1987, 19(2), pages 21-25.
Johnson, J. "Modes in Non-Computer Devices" in press, Int. J. Man-Machine Studies, 1989.
Johnson, J. and Beach, R. "Styles in Document Editing Systems" IEEE Computer, 21(1), January 1988, pages 32-43.
Malone, T.W. "How Do People Organize Their Desks: Implications for the Design of Office Information Systems" ACM Transactions on Office Information Systems, 1983, 1(1), pages 99-112.
Nace, T. "The Macintosh Family Tree" MacWorld, November 1984, pages 134-141.
Rosenberg, J.K. and Moran, T.P. "Generic Commands" Proceedings of the First International Conference on Human-Computer Interaction (INTERACT-84), 1984.
Teitelman, W., "A Tour Through Cedar" IEEE Software, April, 1984.
End Sidebar: Further Reading
When Star was announced, several articles on it appeared in trade magazines, journals, and at conferences. Many of these were reprinted in the Xerox publication Office Systems Technology (see Bibliography). Since then, several more articles have been published that are relevant to this retrospective. They include an article from MacWorld 48 that describes the historical antecedents of Apple Computer's Lisa and Macintosh computers, which share much of Star's history. This retrospective owes a great deal to those previous writings. We also acknowledge the valuable contributions that Joe Becker, Bill Mallgren, Doug Carothers, Linda Bergsteinsson, and Randy Polen of Xerox Corporation, Bob Ayers, Ralph Kimball, Dave Fylstra, and John Shoch made to this retrospective.
2footnote * The actual name of the system was On-Line System. There was a second system called Off-Line System (abbreviated FLS), hence NLS's strange abbreviation. NLS is now marketed by McDonnell-Douglas under the name Augment.
3footnote * The official name for Star was the Xerox 8010 Information System. The machine was called the 8000 Series Network Systems Processor. "Star" was only an internal name.