Designing Xerox Star Software in 400 Pages
I’ve been reading Bringing Design to Software, an ancient tome (published in 1996) that collects interviews with a dozen software practitioners on the subject of software design. In modern parlance, what was called “software design” in 1996 might overlap with what today is called “user experience”, but in any event, it is an activity related to, but separate from, programming, that results in a well-planned specification for what is to be programmed.
The first interview is with David Liddle, who worked on the Xerox Star, an early desktop computer system aimed at business productivity use. How did Liddle and his colleagues go about designing the Star software?
We ended up writing a 400-page functional specification before we ever wrote one line of code. It was long, because it included a screen view of every possible screen that a user would see. But we did not just sit down and write it. We prototyped a little bit, did some testing with users to decide what made sense, and then wrote a spec for that aspect. Then we prototyped a bit more, tested it, and then spec’d it again, over and over until the process was done.
400 pages of software requirements may be commonplace in specialized applications like avionics systems, but it’s a lot more planning than most software gets today. Not even content with that, Liddle’s team hired Bill Verplank, a human-computer interface expert from MIT:
Verplank and his crew did 600 or 700 hours of video, looking at every single feature and function. From all these video recordings, we were able to identify and eliminate many problems. For example, we chose a two-button mouse because, in testing, we found that users demonstrated lower error rates, shorter learning times, and less confusing than when they used either one-button or three-button mice.
Being on the front line of developing early office applications, Liddle also addresses the misconception that the software models of files and folders and desktops was meant to copy a real-world office environment:
It is a mistake to think that either spreadsheets or desktops were intended to imitate accounting pads, office furniture, or other physical objects. The critically important role of these metaphors was as abstractions that users could then relate to their jobs. The purpose of computer metaphors, in general, and particularly of graphical or icon-oriented ones, is to let people use recognition rather than recall. People are good at recognition, but tent to be poor at recall. People can see objects and operations on the screen, and can manage them quite well. But when you ask people to remember what string to type to perform some task, you are counting on one of their weakest abilities.
Curiously, a lot of software written for programmers to use puts heavy demands on recalling arbitrary strings of text…
Would it still make sense to write a 400-page specification for office application software today? Would it still make sense to record hundreds of hours of video to research the optimal way to use the software? Maybe not. Thirty-three years have passed since the Xerox Star, and along the way, many good software design concepts have been identified and established as common practice. If you’re building software for an Apple desktop or mobile platform, for example, you can simply follow Apple’s design guidelines and save yourself a great deal of fundamental human-computer interaction research.
Nevertheless, spending time to plan your application up front may still be a good idea. Thinking through the interaction experience and the needed functionality with a pad of paper and a pen can make writing the code more straightforward, and software is easier to test if you have a precise definition of what it’s supposed to do.
Thanks to people like David Liddle, we can draw on years of experience in good software design to get a head start on our own projects!