Thinking About Software

Software as a conversation between you and the user.

• By Mike Gunderloy
• 02/01/2005

The Roman emperor was no doubt thinking of things other than software when he penned those lines, but it’s still good advice to think about essences once in a while. Take our own chosen field of software, for example. Just what is software? Sure, it’s all ones and zeros at the end, but that’s not a very useful way to think about applications. Here are some alternative ways of thinking about software that have proven useful to me in the past. This material is based on a section in my recent book, Developer to Designer: GUI Design for the Busy Developer (Sybex, 2004), but I’ve revised and expanded it here.

Software as a Conversation
One way to think of your software is as a conversation between the developer and the user. The user starts the conversation by running your application. You return with an opening gambit that lists the things you’re ready to talk about. The user selects one and you respond. The interchange of the user taking an action and then you responding (through your software) continues through the life of the application. At times, there might even be multiple threads of conversation going on, if you present different information on different parts of the screen.

Thinking about software as a conversation makes it clear that you need to communicate with the users of your application. It’s unrealistic to expect users to figure out what the application does and how to make it work by guesswork alone. Fortunately, there are several ways to communicate with the user: help files, printed documentation, and the user interface, as well as the core functionality of the software, all contribute to your end of the conversation. Of these, the only one that you can depend on the user “hearing” is the user interface itself. Help files can be closed, manuals can be left unread, but it’s the rare user who can fire up the application and then ignore the user interface completely. Well, unless it’s a service application with no user interface, anyhow.

But don’t push this way of looking at things too far. Although you do communicate with users through the user interface of your application, it’s a very limited kind of communication. You don’t have any way to react to the user’s facial expression or body language. You can’t tell from timing whether they’re understanding your intentions or missing them wildly. In fact, you don’t even hear the user at all: The best you can do is stock the software itself with a set of responses that you hope will be pertinent to the user’s needs. Despite these limitations in the software-as-a-conversation model, there’s one big lesson to be learned here. In a real-life conversation, you wouldn’t arbitrarily start speaking Esperanto or Hungarian without some indication that listeners are expecting the switch. Similarly, in software it is very dangerous to suddenly discard what your users are expecting without a very good reason. A confused user is an unhappy user.

Similes, Metaphors, and Software
Another way to think about software is to compare it to some real-world object. This is a familiar tactic for making computer programs less scary—and their functions more obvious—to users. For example, Windows was originally designed as a sort of cartoonish electronic rendition of an office worker’s desktop, with file folders and documents and a calculator and a clock. You can move documents from one file folder to another, or discard them into a recycling bin. You can punch buttons on the calculator to do simple math, or set the time on the clock.

This may all seem quite obvious to you as a graphical user interface (GUI) user in the first decade of the 21st century. But when Windows first came out in the early 1990s, it was a revolutionary way to interact with computers (for most users, anyhow: some had experience with other GUIs, but Windows popularized the notion). The similarities between the Windows desktop and a physical desktop helped many of us figure out how to use this new breed of software.

Sometimes software developers speak of this sort of thing as coming up with a metaphor for their software. But that’s not precisely correct: The relation between applications and the real world is one of simile, not metaphor. Think back to your middle-school English classes, and you may recall the difference between a metaphor and a simile:

• A metaphor is a figure of speech in which one thing is equated to another, as in “Windows is an office worker’s desktop.”
• A simile is a figure of speech in which one thing is said to be like another, as in “Windows is like an office worker’s desktop.”

The distinction is important, because these comparisons between applications and parts of the real world inevitably break down at some point. For example, you can’t keep a pint of whiskey in the bottom drawer of the Windows desktop or spill ink on the letter you’re writing on screen (well, not unless you’re using a Tablet PC). But the Windows desktop lets you change the label on a file folder without needing an eraser or a typewriter—something that would be quite a trick in the real world. The point is that the Windows application is not identical to the real world. At best, it is similar to the real world.

Another way to think about this is to consider applications as analogies to the real world. One dictionary definition of analogy is as a similarity in some respect between things that are otherwise dissimilar. We know that computer applications and the real world are two different things, and they are wildly dissimilar: The real world is made up of atoms, and applications are made up of bits. But there are areas where the two are similar. Thus, the Windows desktop does have an analogy to a real desktop, and by conjuring up the image of a real desktop in the user’s mind, it suggests to the user how the Windows desktop can be manipulated.

Because applications are at best similar to the real world, users are forced to construct a map (a set of correspondences) between the application and more familiar objects. That is, some reasoning takes place of the sort “this application behaves like X, so I should be able to do Y” going on, either consciously or unconsciously, as the user tries to figure out which parts of the real world experience are applicable to the software at hand. Not all such mappings are created equal. Some applications map very closely to their real-world model. There are a few things about the application that aren’t in the real world, and vice versa, but the overlap between the two is substantial. The application behaves mainly as if it were a part of the real world. But other applications are a much less precise match to their real-world partners. Many things about these applications can’t be understood by reference to the real world.

It’s tempting to suppose that an application will be better and easier to use if it is a more precise match to its real-world model. This, in turn, implies that the user interface should mimic some portion of the real world. But that is not necessarily true. Remember Microsoft Bob? That was Microsoft’s most “realistic” user interface to date, and it was a resounding flop. Among other problems, imposing too much of the real world on the way the system worked led to very difficult navigation, with artificial constraints to traveling around from one part of the application to another. That’s fine in a game, but not in an operating system.

Another reason to beware of software similes is that they can lead to tunnel vision. If you’re trying to exactly mimic some piece of real-world hardware in a software application, you may well miss opportunities to add and extend functionality that would benefit users. So if you start with a simile in mind, make sure that you don’t stop there.

Software as a Means
As a final way to think about software, remember that software is a means rather than an end. The chance that a user will be running your application just because they want to run your application is almost zero. Instead, they will have some goal in mind, and your application is a way to reach that goal. Even when a user launches your application to explore its capabilities, they usually have a goal in mind, such as evaluating whether the application will meet their needs.

Keeping this principle in mind is a good way to avoid making your software overly cute at the expense of usability. Spending effort to add a photorealistic three-dimensional user interface inspired by your favorite movie may make you feel extremely clever, but if users can’t find the menus among the clutter, it’s a step backward for your application. Users also don’t care about how clever your code is, or how much work went into the program. They just want to reach their goals. If your program is the best means to that end, great. If not, there are plenty of other programs out there to try.

An Elephant is Like a…
By now you may be recalling the story of the blind men and the elephant. Is software a conversation, a simile, an analogy, or a means? Or just ones and zeros? The answer is “yes.” Despite all of our effort at simplifying it, software remains one of the most extraordinarily complex aspects of the modern world (give yourself brownie points for understanding it at all!). Above all, I urge you not to get locked into any one view of your software, especially early in the design process. We already have far too much software that all looks the same, that sinks into the gray vat of mediocrity. If you try to think outside of the normal patterns of software, no matter which piece of the elephant you’re grasping, your chances of coming up with something innovative are greatly increased.

How do you think about software? Or do you even have time to think when you’re writing the stuff? You can get hold of me at [email protected]. I’ll use the most interesting comments in a future column.