No Section...

VII.5 Sept./Oct. 2000
Page: 28
Digital Citation

Textual bloopers


Authors:
Jeff Johnson

Introduction

In considering what makes a user interface good or bad, it is important not to underestimate the importance of text. One of the great ironies of graphical user interfaces is that they aren’t usually very graphical. The typical GUI consists mainly of textual settings displayed on panels. Most of the values of the settings are textual (even though they may be set via menus or radiobuttons). Most of the setting labels are also textual. Error and warning messages are mainly textual (perhaps augmented by a color and a graphical symbol to indicate the importance of the message). Graphical components such as sliders and gauges aren’t really used very much.

Computer-based products and services use text in a variety of ways: in status, error, and warning messages displayed by software for the users’ benefit; in labels for settings; in labels for the possible values of settings; in names of commands in menus and on buttons; in brief instructions intended to guide users through important steps; and, of course, in the names users assign to data files and other data objects. Though software designers sometimes express a desire to minimize or avoid the use of text in the products and services they design, the truth is that many concepts simply could not be expressed without using text. The old saying "A picture is worth a thousand words," while true in some ways, is an oversimplification: sometimes a few words are worth more than any number of pictures.

Even in the most graphical of user interfaces, for all but the simplest of products and services, text usually plays a role. Consider the control panel shown in Figure 1, for Creative Software’s Mixer application, which is part of their SoundBlaster suite. Even though this is nominally a Windows application, it is much more graphical than the typical Windows application. Nonetheless, it makes use of text: the company logo, the application title, the numbers in the volume meter, and the tooltips on every control on the panel.

One of the nice things about textual usability problems is that they are usually cheap and easy to correct. However, textual usability problems often have a root cause in the development process or even in the development organization. Correcting systematic problems in either of those areas is, of course, anything but cheap and easy.

Because text plays an important role in the user interfaces of almost all computer-based products and services—whether they are desktop computer applications, Web sites, electronic appliances, or scientific instruments—there are many ways to get it wrong. I refer to such errors as "textual bloopers." This article describes several such bloopers, and explains why developers sometimes make them. The bloopers will be classed under three headings: Unprofessional writing, Unfriendly messages and labels, and Misleading window titles.

Unprofessional writing

Our first four textual bloopers are about poor writing in the text displayed by software. They are the result of giving the job of writing text to the wrong people: programmers.

bullet.gif Blooper 1: Inconsistent terminology

One of the most damaging text-related mistakes you can make when developing a computer-based product is to be haphazard and inconsistent about what terms are used for what concepts. Unfortunately, this mistake is also one of the most common. Many development organizations aren’t even aware that this is a potential problem, so they make no effort whatsoever to assure that their product terminology is consistent and clear. What begins as a flaw in their development process turns into a flaw in their products: a many-to-one and one-to-many mapping between terms and product concepts.

When I review software products for clients, I often construct a table showing the various terms that are used in the program and in the documentation for each user-visible concept. The results are often eye-opening to development managers: "I had no idea! No wonder users are having trouble learning to use our product!" Unfortunately, the usual reaction from programmers is "So what? We have more important problems to worry about than whether we use the exact same term from one window to the next."

It turns out that there are two different ways to be inconsistent in referring to product concepts, and product developers often stumble across at least one of those ways.

Variation A: Different terms for the same concept. It is surprising how many software products use multiple terms for a single concept. For example, a program might refer to "results" in one window and "output" in another, even though the same thing is meant in both cases.

The following is an excerpt from a user interface review I performed of a client’s software product that was being prepared for release:

Certain terms are used inconsistently in BizAnalyzer [not the product’s real name]. For example, the Categorization Assistant uses the term "source table," while dialog boxes throughout the program refer to the same thing as "Discovery table." In one menu, the table properties are invoked via "Tables…"; in another menu, the same properties are invoked via "Table Properties." Other examples of multiple terms for the same concept: "Specify Goal" vs. "Define Goal," "Goal" vs. "Output Field" vs. "Statistics Task," "Task" vs. "Step."

In reviewing software for clients, I have found the terms in each of the following sets being used interchangeably for a single concept.

  • properties, attributes, parameters, settings, resources
  • Welcome Window, Introduction Window
  • version, revision
  • FAQ (Frequently Asked Questions), QNA (Questions aNd Answers)
  • find, search, query, inquiry
  • Back to results, Back to search results
  • arguments, args
  • server, service
  • Exit, Quit
  • Order Size, Order Quantity, Qty
  • Stock Symbol, Instrument ID, Instrument, Instr Id

Often, inconsistent terminology results from name changes during development that were not corrected everywhere in the software or documentation. Sometimes it results from a failure to develop a product lexicon during the conceptual design phase of development or a means of ensuring compliance with the lexicon after it is developed. Sometimes there simply was no conceptual design phase of development. Sometimes it is due to a lack of agreement or a lack of communication between programmers. In some cases programmers may not have considered it important enough, given the time pressure they were under, to make sure that concepts were referred to consistently throughout the software.

When different words are used in different contexts to describe the same thing, users may not realize that the same thing is being described. Users are thinking mainly about their work—the problem in their own task domain that they are trying to solve (for example, personal finance, letter writing, hotel reservations, information retrieval). They pay close attention to the data they are creating and manipulating, but they devote very little attention to figuring out what other things they see on the screen—controls, instructions, messages—mean. Tiny changes in wording can result in failure to recognize a previously encountered concept.

Inconsistent terminology forces users to keep thinking about the software—trying to decide whether two words mean the same thing or not—when they would rather think about their work. Well-designed software, in contrast, recedes into the background by letting users fall into use habits and unconscious activity, thereby allowing them to focus their conscious minds on their work.

Variation B: The same term for different concepts. Almost as common as using more than one term for a single concept is the opposite error: using a single term for more than one concept. For example, here is another excerpt from the previously mentioned user interface review I performed of a client’s product:

Certain terms have different meanings in different places in the program, potentially causing confusion. For example, the word "view" is used to refer to

  • the data display windows, e.g., Understanding View, Evaluation View, Fields Ranking View
  • different ways of filtering the Understanding View, e.g., Required View, Specific View
  • actions that affect the data flow diagram, e.g., Shrink View, Enlarge View
  • the View menu, which controls display of the Assistant, Data Flow, Toolbar, and Status bar

Furthermore, the View menu contains some items that assume that "View" is a verb (e.g., "View:Results") and other items that assume "View" is a noun (e.g., "View:Enlarge").

Using the same term to mean different things is usually not intentional; it happens because developers simply don’t think about it. After all, when people converse informally with each other, they often use words that have multiple meanings, and listeners can usually determine the intended meaning of a term either from the context in which it is used or by asking the speaker to clarify. However, human-computer communication is less forgiving of ambiguity. It does not provide conversational context that is as rich as the context provided by human-human communication—for example, a context that contains redundant cues about the meaning of terms. It does not allow the human participant to ask the computer to clarify what it meant by a particular term. Therefore, sloppy terminology is much less acceptable in software than it is in communication between people.

Microsoft Word exhibits such sloppy terminology in its Insert menu. This menu provides both an "Insert Picture…" command and an "Insert Object…" command (see Figure 2). The Insert Object command allows users to insert any of several different types of objects, including Equations, Excel charts, Excel worksheets, Word documents, and Word pictures. Users might expect "Insert Picture" to do the same thing as "Insert Object" with "Word picture" as the specified object type for the latter command. However, if they thought that, they’d be wrong. The Insert Picture command is for importing externally created graphic files. It displays a file chooser dialog box that lets users specify the image file to be imported and the file’s format (e.g., BMP, TIFF, PICT). In contrast, inserting a Word picture using the Insert Object command does not import a graphics file; it displays a structured graphics editor that allows a user to draw a graphic, which, when completed, is inserted into the document.

An especially common form of using the same term for different concepts is to use the same name both for an object and for a part of the object. For example, an email program might sometimes use the word "message" broadly, to refer to the entire data file it received from another user, including headers, message body, and attachments. Other times, it might use the word narrowly, to refer just to the textual content of email. A program that did that would confuse new users, impeding their learning. Such an error is the result of a faulty conceptual model, or the lack of one.

A very specific common form of this blooper is using "select" in one place to mean clicking on an object (highlighting it) to make it the operand of the next operation, and in another place to mean choosing an object from a collection to add to a list. Consider, for example, the page from a hypothetical grocery shopping Web site shown in Figure 3. The buttons below the two lists of available groceries on the left act on the currently selected item in those two lists, as the label on their left indicates. However, in this Web site, "select" also means adding an item to the list on the right. The list on the right is even labeled "Selected Items," which is very similar to, but has a different meaning than the label "Selected Item" in the lower-left corner. Needless to say, users of this Web site would find this confusing. Although this example is fictional, I have found in reviewing software and Web sites for clients that a great many use the term "select" in multiple, conflicting ways.

Another commonly misused term is "refresh," which is often used to mean both "fetch updated data from database (or from network host)" and "repaint the display." Three interrelated terms that are often confused in software and documentation are "cursor," "text insertion point," and "mouse pointer." Before GUIs, there was no such thing as a mouse pointer, and the text insertion point and the cursor were the same thing. With GUIs, these all became distinct concepts. However, one sees the term "cursor" sometimes used to mean the text insertion point and sometimes used to mean the mouse pointer.

Blooper 2: Unclear terminology

Sometimes terms are used consistently within a software product, but are still unclear in the sense that users can easily misinterpret them. I’ve found three different ways in which this can happen.

Variation A: Terms for different concepts are too similar. Suppose a software product provides two quite different functions, but the names of the functions are very similar. Users would be likely to confuse them, no? Yes.

An intranet Web search facility I reviewed for a client provided two different functions to allow users to find information related to that returned by their last search. One function was called "Related Concepts"; the other was called "Related Terms." Their effect was quite different. I warned the client that many users would have no idea what the difference between these two functions was and would either avoid them or choose randomly between them.

Another client had developed a Web site for prospective home buyers to use to look for a suitable home…anywhere in the United States. The Web site required users to subscribe to the service and to login when they used it. Requiring users to login allowed the system to provide places for users to store information they had collected while looking for a home for possible future use. One type of information users could store between sessions was information about them that would help indicate what type of home they were looking for: financial status, family size, and so on. Another type of information users could store was notes about houses they had found so far. These two different types of personalized information were stored and managed by separate facilities provided by the service. Unfortunately, the two facilities had similar names: the facility for storing information about oneself and one’s home-buying goals was called the "Personal Planner" and the facility for keeping notes about homes one had found was called the "Personal Journal." Not surprisingly, testing found that users often confused these two facilities.

This variation of the blooper is related to Blooper 3, Variation E: Assigning arbitrary meanings to short, nondescriptive terms.

Variation B: Concepts too similar. In Variation A, it is actually difficult to say whether the problem in the two examples was that the terms were too similar, that the concepts were too similar, or perhaps both. Sometimes, the problem is clearly that the concepts are so similar that they are easily confused.

The same home-buying Web site described earlier provided two different methods to begin looking for a home. One method was to name the state, county, or town where one wanted to find a home. The other was to point to a location on a map. Users had to choose which of these methods they wanted to use. Users were given the choice of whether to find a home "by Location" or "by Map." A colleague and I conducted a usability test of this Web site. We wrote the following in our test report:

Many participants did not distinguish between finding a home "by map" vs. "by location." Both are really by location; they differ only in how the location is specified.

The problem was that the designers of this Web site had created an artificial distinction—one that didn’t match the real world—and expected users to accept and understand it immediately. Unfortunately for the designers, the users didn’t cooperate. See Variation E of Blooper 3 for a discussion of a related textual problem.

A customer support Web site I reviewed exhibited a similar problem. It provided four concepts that the developers regarded as very different:

  • Membership: a customer company signs up and pays for the customer support service.
  • Subscription: a customer company subscribes to an online customer support newsletter.
  • Access: users in a customer company have privileges to access certain restricted information and functionality in the customer support Web site.
  • Entitlements: services are provided for each membership level.

In my review report, I warned the developers that these four concepts were very similar and would probably be confused by many users. I recommended that they consider merging them into one concept, or at least fewer than four.

Variation C: Ambiguous terms. When reviewing or usability-testing software for clients, I often find terms in it that are confusing because they are ambiguous. I don’t mean they have multiple meanings within the software; that’s a different problem that I discussed earlier in Variation B of Blooper 1. I’m referring to terms that, although they may have only one meaning in the software, have other meanings outside of it that make as much sense in the software as does the intended meaning. New users are likely to misinterpret such terms. Designers are so focused on their own intended meaning of a term that they often fail to even realize that the term might have other meanings that are equally plausible in the given context. This is a form of thinking inside-out rather than outside-in. This problem is not restricted to software; newspapers are infamous for printing headlines that meant one thing to the writer, but something else to the reader, such as "Teacher Strikes Idle Kids," or "Miners Refuse to Work after Death," or "Red Tape Holds Up New Bridge."

A common oversight in software is to use words that can be either nouns or verbs, such as "object," "file," "load," "refuse," "train." Consider how difficult it is to read the following newspaper headline: "Bank Funds Swamp Firm."

Textual ambiguity can be further exacerbated when verbs are used as nouns. For example, a software company for which I once worked developed an application development tool for C++ programmers. The menubar in the tool’s main window included a command "Build Window." The developers intended this to be a noun phrase: the window for building—programmer jargon for compiling and linking together—a program. Get it? The Build Window. Unfortunately, users—yes, even hard-core C++ programmers—persisted in reading the command as a verb phrase: Build Window. This alternative interpretation—building a window—made at least as much sense in the application development tool as the intended interpretation did. Nonetheless, it was a surprise to the software developers that anyone would interpret the command that way.

The problem caused by turning verbs into nouns is discussed more fully in Variation C of Blooper 3: Speaking Geek.

Some words have a fixed grammatical type, but many meanings. For example, "enter" is often used in computer software to refer to the (users’) act of typing data into the computer. However, "enter" also has another meaning in standard English: "to go into." In computer software and especially in Web sites, that meaning of "enter" may make just as much sense to users as the "type data" meaning.

For example, the "Welcome" window of an application I reviewed included a graphically labeled button that supplied the following tooltip text to explain its function:

  • Click here to enter application.

Clicking on the button closed the "Welcome" window and displayed the application’s main window. However, novice users might easily interpret the label as saying that clicking that button would prompt them to type the name of a software application.

bullet.gif Blooper 3: Speaking Geek

In some computer-based products, the terminology is consistent and not prone to misinterpretation…but incomprehensible. Users have no idea what the computer is talking about. Suppose you installed some new software on your computer, but when you tried to use it, you discovered that you had somehow obtained a foreign-language version of the software, and that all of the text displayed by the program was in a language you didn’t speak, such as Tibetan, or Amharic, or Greek. You’d probably have difficulty learning and using the software. In fact, you’d probably discard it and try to get the version that was in your own language.

As the number of people who use computer-based products increases to a larger share of the population, more and more people are finding themselves in a similar situation, except that the "foreign" language their software displays is not Greek, but rather Geek. However, users faced with software that uses in comprehensible Geek are actually worse off than those who mistakenly have software that uses Greek because they can’t get replacement copies in a language they understand.

As with many of the other bloopers there are several different ways to speak Geek.

Variation A: Using programmer jargon. Most professional fields and even many hobbies have their own jargon—a specialized vocabulary that allows practitioners of the field or hobby to communicate more precisely and efficiently. Some jargons even include specialized idiomatic expressions. There are jargons for air traffic controllers, stamp collectors, carpenters, model boat builders, lawyers, fishermen, surfers, airplane pilots, you name it.

From the looks of many software products and services on the market, many software developers don’t switch off their use of jargon when writing software for nonprogrammers. This can happen for a variety of reasons:

  • A lack of awareness that there is anything to switch off: they don’t realize they use a highly specialized jargon that others don’t know and don’t want to know.
  • An inability to switch the jargon off even though they are aware that they use it, just as some people are unable to switch off their local dialect when they converse with people from other regions.
  • A belief that if people want to use a computer, they need to learn to understand computer jargon.
  • A tight deadline and insufficient writer support, inducing programmers to simply use the terminology they know and hope that someone will improve the wording later.
  • An implementation that exposes to users technical concepts that have no counterpart in the target task domain.

For the above reasons, and perhaps others as well, much of the computer software on the market and on the Internet today is full of acronyms such as "ROM" and "grep," pure computerese such as "device drivers" and "macro" and "download" and "dot com," words that are rarely used in standard English such as "mode" and "buffer," phrases that turn verbs into nouns such as "do a compare" and "finish an edit," terms that reflect the developer’s point of view rather than the user’s such as "user defaults." Regardless of the reason, the effect on users is the same: lack of understanding and slowed learning.

The image on the top in Figure 4 is an error message displayed by the Eudora Pro software, from Qualcomm. What do you suppose the message is trying to say? It is telling the user that the email password the user typed (to download new mail from the mail server) is incorrect. Rather than just saying that, the programmer of this dialog box considered it necessary to explain the entire communications protocol between the Eudora Pro program and the email server. Not only that, the programmer had Eudora refer to itself as "I," as if it were a person. Bzzzt. Blooper! Maybe the developers of Eudora care about this interprocess communication stuff and maybe some system administrators want to see it, but normal users of Eudora do not.

The image on the bottom in Figure 4 is an even more geeky error message from Eudora Pro. In this case, an attempt to fetch new mail failed because the email server did not respond. Clear, eh? It is difficult for me to believe that Eudora’s designers expect users to understand these messages.

I once conducted a usability test for a company that had developed a business application. The application displayed the structure of the application’s data using a Windows-style tree control. The problem was that the application referred to the tree control using those exact words, even though "tree control" is hard-core GUI toolkit jargon. Not surprisingly, user testing showed that many users didn’t know what the term meant. Some probably wondered what the software had to do with trees.

Variation B: Turning common words into programmer jargon. A special case of using programmer jargon is the distinct programmer tendency to redefine common words to have specific meanings in software. The Unix operating system is infamous for command names such as "cat" and "man," which in Unix mean "concatenate a file" and "display the online manual," respectively, rather than "feline mammal" and "male person." When developers of computer-based products and services redefine common words and expect the users to adapt to them, they are not being considerate of users. They are committing a design blooper.

One common term that is often assigned a special jargon meaning is the word "resources." A lot of GUI-based software in today’s market misuses this word for what are really attributes or properties. This is especially true of software based on X Windows, a popular basis for Unix window managers (e.g., the Common Desktop Environment GUI platform used in Sun’s Solaris and Hewlett-Packard’s HP/UX). The word "resource" has a meaning in English: something useful that one has a certain amount of. My Webster’s dictionary defines it as "a new or reserve source of supply or support; available means." Managers in companies may refer to their personnel as "resources," and they may also use the term for various business supplies and/or funds, but stretching the term to cover what are essentially parameter settings is, in my opinion, stretching it too far. If programmers want to use this word this way inside their code, fine, but this usage of the term should never appear in the user interface.

Another example of an often-seen redefined word is "dialog." When reviewing software for clients, as well as when using software in my work, I often find references in the user interface to "dialog" (as in the dialog box from Microsoft Word shown in Figure 5). Although the word means "a conversation" in standard English, it is often used in GUI-based software as shorthand for the term "dialog box." In short, "dialog" is GUI toolkit jargon for a dialog box. For example, one client’s software had a button labeled "Close this dialog." Programmers and even user interface designers use this term so often that they forget that it is a redefinition of a standard English word. They also forget that even in GUI toolkit jargon, it’s an abbreviation. Given the recent rapid expansion of the personal computer market into the mainstream of society, many of today’s PC users have never heard of the GUI toolkit definition of "dialog" or "dialog box." They assume the word has its normal meaning—a conversation—and are confused because that meaning doesn’t make sense in the context where the term appears.

Other examples of words that are often redefined in computer-based products and services are "string," "object," and "client." A Web application developed by one of my clients displayed a login page titled (in large, prominent letters) "Thin-Client Login." Some of the users who logged into this application were probably surprised and pleased that it offered them the login page for thin clients instead of the alternative.

Variation C: Turning verbs into nouns. Another sort of jargon often seen in computer software is verbs used as nouns. This tendency is not restricted to computer software; you can see it in the specialized vocabulary of just about any field. For example: stockbrokers use "buys" and "sells" as nouns when discussing stock transactions, airplane pilots refer to "takeoffs," fishermen talk about the day’s "catch," and book reviewers sometimes describe books they like as "a worthwhile read."

Software engineers often use phrases such as "the compile failed," "start the build," "do a compare," "finish an edit." For communication between software engineers, such expressions are fine. However, they become a problem when they are used to communicate with users who are not software engineers, and so might misinterpret the jargon.

As an example, one of my client companies was developing software for finding relationships in business data (sometimes called "data mining"). One function of the software was called "Explore data." The programmers called using that function "doing an Explore." The software included an auxiliary function that predicted the time and resources required to "do an Explore." That auxiliary function was named "Explore Prediction," a noun phrase, not a verb phrase. Got that? There’s more: The same software had another function, for comparing two data files. Naturally, using that function was called "doing a Compare." Users could define comparisons that could be run repeatedly on different data files. The function for defining a comparison was called—you guessed it—"Compare Definition," another noun phrase.

Variation D: Exposing terms from the code. A fourth way to speak Geek to users is to lift terms right out of the code and include them in the user interface.

A very common way of exposing users to terms from the code is to include the GUI toolkit name of a component, control, or datatype in its name or label. I see this form of the blooper often in software I review for clients. Figure 6 shows a dialog box that includes the word "Dialog" in its title, a "Name" setting that tells users that the program stores the value as a "string," and a menu that has "Menu" in its label.

Lifting words and phrases straight out of the code is also common in error messages. I consider it a serious indictment of the computer industry that most computer users—whether technically oriented or not—have seen error messages like the following:

  • Uncaught Exception:
  • array_index_out_of_range. Execution terminating.
  • Bad inode. File not saved.
  • ParseObject: Error 347: Unknown data-type.

In the first of the above messages, the symbol identifying the exception was provided not only to the error-handling code, which presumably needs the information, but to users as well. Users most emphatically do not need that information. The second example is from the Unix operating system, infamous for forcing users to speak Geek. An "inode" is an implementation term for the data that tells the operating system what it needs to know about a file stored on a disk. In the third message, the user is told that the procedure ParseObject encountered a unknown data type it doesn’t recognize, a situation that apparently is classified as error number 347. Do 99 percent of users care about any of this? Is a bear Catholic?

One sometimes sees error messages in released software that mix code excerpts with information users can understand. The code excerpts may have been useful to programmers while the software was still being debugged, but for some reason were not removed before the software was released. Such a message was displayed by software developed and marketed by one of my clients. The message (with minor details changed to mask the client’s identity) was

  • OrgSoft.JavaWizard.lib.GUI.
  • NotAcceptingException:
  • JW.Frame("Names").member
  • ("Java.awt.last").select(2, "zoe"):
  • List entry not found.

The only part of this message that would make sense to users would be "List entry not found," which was the translated meaning of the preceding Java exception. I advised the client to remove the Java exception from the message and display only the user-friendly translation.

Sometimes users of software applications are exposed to implementation concepts and terms through no direct fault of the application, but rather because the software platform on which the application is based displays error messages on its own instead of passing them to the application. For a more complete discussion of such situations, see Blooper 5: Clueless error messages.

Variation E: Assigning arbitrary meanings to short, nondescriptive terms. Back in prehistoric times, when dinosaurs—that is, command-line user interfaces and glass-teletype terminals—ruled the earth, programmers did everything they could to minimize the amount of typing users would have to do.

One common practice was to refer to each user-visible command, attribute, and data object in a software product using a single-word name. Multiple-word phrases—for example, "delete paragraph"—to refer to commands and other concepts were avoided because they required too much typing. Usually, the assigned names came from the target user language, for example, English. They were selected because their normal meaning fit the software concepts reasonably well. If no suitable single words existed in the language, single-word names were made up (rather than using multiple-word names).

While this naming practice did minimize the amount of typing users had to do, it maximized the amount of learning, remembering, and task-time problem solving they had to do. Some specific problems were

  • When two similar software concepts had to be represented, programmers would often use synonyms from English to represent them: for example, "delete" for deleting text and "remove" for deleting files. Users had to learn which synonym meant what.
  • Command names that had precise meanings to the program might be ambiguous or vague in the real world. For example, "edit" might mean a specific type of data-changing operation in the software, even though it can refer to many different types of changes in standard English. Users had to learn what the word meant in the software.
  • Natural language words were assigned to software concepts even though the concepts didn’t really fit. Thus, words like "resources" were assigned entirely new meanings inside certain software. This is just another thing users have to learn.
  • When names were made up (e.g., "grep," "cat," "awk"), users were forced to add words—usually non-task-relevant words—to their vocabulary to be able to use the software.

However, point-and-click graphical user interfaces remove the motivation for short single-word names. Users don’t type command names any more, so brevity is much less important, especially when it comes at the expense of clarity. In modern GUIs, short, cryptic command names are an anachronism of a bygone design era.

Of course, it is well known that people tend to carry over unnecessary concepts, artifacts, and design habits from previous technologies into later ones. For example, early cars looked like and were called "horseless carriages." Thus, we would expect early GUI designers to continue to assign short, cryptic command names for a while. We can therefore perhaps excuse the designers of the Apple Macintosh for using the word "Copy" for copying document content while using the essentially synonymous word "Duplicate" for copying documents, forcing users to learn this arbitrary distinction. Old habits die hard.

bullet.gif Blooper 4: Careless writing

Even if the text displayed by a software product or service uses terms consistently, doesn’t redefine common words, and avoids programmer jargon, code terms, and ambiguous words, the writing can still be inadequate for a commercial product or service. It can be inconsistent, varying in style from one message or setting label to another. It can exhibit poor spelling and grammar. It can be misleading. It can be incorrectly capitalized. In short, it can be careless writing.

This section discusses several types of careless writing commonly found in computer-based products and services.

Variation A: Inconsistent writing style. Many applications exhibit stylistic inconsistencies in the text of built-in instructions, command names (in menus and on buttons), setting labels, window titles, and so on. Common inconsistencies include:

  • naming some commands after actions (verbs) but others after objects (nouns), for example, "Show Details" versus "Properties."
  • using terse, "telegraphic" language for some setting labels or messages (e.g., "Enter Send date:") but wordy language for others (e.g., "Please specify the date on which the message is to be sent").
  • using title capitalization (e.g., Database Security) for some headings but sentence capitalization (e.g., Database security) for others.
  • ending some but not all sentences (e.g., in instructions or error messages) with periods.

For example, the following is an excerpt from a review I performed of a client’s product:

The verbal style used in the program is inconsistent. Two examples:

  • In the startup dialog box, two of the choices are "Create New Study" and "Open An Existing Study." The first of these uses telegraphic English, omitting the article before the noun; the second uses standard English, including the article "An."
  • Some fields that require a user to type a name are labeled "X Name" while others are labeled "X," e.g., "Table Name:" vs. "File:." Either both should include the word "Name" or neither should.

In another client’s software, a Graph menu on the menubar contained the inconsistently capitalized commands: "Add Meter ...," "Print meter ...," "Add Graph ...," and "Print graph….." My guess is that one programmer implemented the Add functions and a different programmer implemented the Print functions.

The dialog box shown in Figure 7, from Band in a Box 6.0, a music accompaniment program from PG Software, has labels that are capitalized many different ways. Maybe Band in a Box’s developers assume that its customers won’t notice such inconsistencies. While it is true that most Band in a Box users won’t say, "Hey! That dialog box mixes title capitalization and sentence capitalization!," they might well say, "You know, Band in a Box strikes me as kind of amateurish. It just doesn’t seem like a polished product."

Variation B: Poor grammar, spelling, and punctuation. Many GUI-based applications suffer from poor spelling and writing in on-screen instructions, warnings, error messages, setting labels, and button labels. Although user documentation is usually written by technical writers, text that appears in the software is usually written by programmers. Programmers are rarely well-trained writers, and it shows in the quality of the writing in many programs.

Two recent—and costly—examples of poor writing in software are provided by a couple of medium-sized Silicon Valley companies that were consulting clients of mine. Each had a team developing a large desktop software application for the Microsoft Windows operating system. On both development projects, the engineers were responsible for all text displayed by the software, and none of that text was reviewed by technical writers. In fact, one of the two teams didn’t even have any technical writers. This by itself would probably have been enough to yield products riddled with vague or misspelled command names, inconsistently worded control labels, confusing instructions, and cryptic error messages.

However, the situation at both companies was even worse than that. Although the software was intended for English-speaking customers, none of the developers on either team were native speakers of English. Both of these companies had the practice of hiring most of their programmers from overseas, mainly India, Taiwan, and Russia. While the engineers on both teams were quite competent at programming, their attempts at devising command names, setting labels, error messages, and instructions bordered on amusing. However, potential customers were not amused. Management at each of these two companies probably thought that their hiring practices provided skilled programmers at a discount, but they failed to anticipate that those practices would also either add reviewing and rewriting costs or reduce the sales of the product.

Not all examples of poor writing are serious enough to impair understanding. Sometimes they are just simple typographical errors that were not caught. Nonetheless, software that contains typographical errors in the text it displays is likely to give users an impression of careless workmanship and amateurishness, which isn’t an impression that most product development organizations wish to convey. An example of such an error in a long-released software product can be seen in VirusScan 3.0.1 for Macintosh, from McAfee, a subsidiary of Network Associates, Inc. If a user’s virus definition files are old, the program displays, in its main window, the message shown in Figure 8. The typographical error in this message is a common one. Can you spot it? It should have been caught by technical writers before the product was released.

Variation C: Misleading text. Jakob Nielsen has often pointed out in his critiques of Web sites (see www.UseIt.com) that people often write labels, headings, descriptions, and instructions for software without considering how users might interpret the text in the context where it appears. I agree completely.

An example of misleading writing is provided by a customer support Web site I reviewed for a client. The site included a page listing software patches that could be downloaded and installed to correct known bugs in the company’s software. A section of the Patch page was set aside for the patches that the company was currently recommending that its customers install. That section was labeled:

  • Recommended Patches
  • These patches have been tested and will keep your CompanyX workstation running smoothly.

I pointed out in my review of the Web site that this might suggest to some customers that the other patches had not been tested. The person who wrote the section label had considered only how the label fit its own section, not what it implied about the rest of the page in which it appeared.

Variation D: Enter Id, Ok?. This variation of the "poor writing" blooper will strike some as trivial and unimportant, but it drives me crazy. Furthermore it is, for reasons I cannot fathom, extremely common. I almost devoted a separate blooper to it.

GUI-based applications contain many dialog boxes. Most dialog boxes have a control button labeled "OK," right? Well, sort of. A great many dialog boxes have a button labeled "Ok," with a lowercase k. This is just plain wrong: "OK" is spelled with two capital letters. This minor but annoying error is shown in the dialog box buttons in Figure 9, from the Which Chorus dialog box of Band in a Box 6.0 Pro for Macintosh.

Similarly, the term "ID," an abbreviation for "identification," is a common term in application software. Like "OK," it is often misspelled with a lowercase second letter, as "Id," especially by programmers who are not native speakers of English. Misspelled in that way, it can be mistaken for "id," a Latin word that has entered the English language as a term used by psychoanalysts to refer to the part of the human psyche that, according to the American Heritage dictionary, is "the source of instinctual impulses." "Please enter your Id: _________." Hmmm.

Unfriendly messages and labels

The next four textual bloopers pertain to the quality of error messages and setting labels displayed by software.

bullet.gif Blooper 5: Clueless error messages

As described in the previous blooper, one way that software often speaks Geek is by displaying error messages that are expressed in implementation terms, rather than in terms that are meaningful to users. A related blooper is displaying error messages that announce some generic error condition rather than giving users helpful information about what happened. This happens for three different reasons, giving rise to three variations of this blooper.

Variation A: Message determined by low-level code. This variation occurs when an error is detected by a low-level service function, which either displays an error dialog box directly, or passes the error up the call stack, where it is displayed without translation by a higher-level function. The function that the user explicitly invoked could, in theory, express errors in task-relevant terms, but the lower-level service functions it calls "know" nothing about user tasks and goals and so can only express errors in technical or generic terms. Consider the following hypothetical examples:

  • A user tries to follow a link in a Web site. The Web browser prepares to download the indicated data files, but finds that it is out of space in its cache of recently loaded pages. It attempts to delete some of the pages currently in the cache. For some reason, one such page is locked and cannot be deleted. The code that tried to delete the cached page detects this error and displays a dialog box containing the message "Cannot delete cached page. Page locked." From the user’s point of view, this error message comes out of nowhere; she clicked on a link and up popped this seemingly unrelated message. The user’s response would probably be "Huh? What does that have to do with what I was doing?"
  • A user receives an email message, reads it, and decides to save it in one of his mail folders. Attempting to pick the Sensor Project folder from a menu of mail folders, the user inadvertently selects the next folder in the list: Sent Messages. The Sent Messages folder does not allow users to save messages into it. The email application implements mail folders and messages as directories and files, respectively. To save the user’s message, the application calls an operating system service-function File.Create() with the Sent Messages folder as the destination directory. The Sent Messages folder does not allow the creation of the new file, so File.Create() fails. It displays an error dialog box reading: "File.Create() failed." The user doesn’t know (1) that he missed the intended folder in the menu, (2) what File.Create() is, or even (3) that messages are stored in files, so this error message would be triply mysterious.

When this variation of Blooper 5 occurs in an application, it may be difficult to correct. The low-level code that detects the error and displays an unhelpful error message may not be in the application itself. Instead, that code may be in the platform on which the application is running. If an application calls an operating system utility function and the function sometimes displays a poor error message, the application’s programmers probably won’t be able to fix the message because it is not in their code. Nonetheless, most users will perceive the message as coming from the application. If the message is seriously misleading, the application developers may have no choice other than changing their code so that it does not use the troublesome operating system utility function.

A similar situation can arise with Web-based applications: the Web browser may display cryptic, unhelpful, or misleading error messages in certain situations, but there may be little the application developer can do about it. As an example, users of a Web application developed by a client of mine would occasionally see the following error message:

  • Error 500 HTTP Web Server
  • GraphicsNotFoundException

It turned out that this message was being displayed by the Web browser, so there was little the application developer could do about it, short of recommending that users use a different browser.

Variation B: Reason for error not passed up to higher-level code. Sometimes software displays clueless error messages because the reasons for the errors are not properly passed from lower-level utility functions that detect the errors to the higher-level functions that the user invoked. For example, a client of mine had an application that displayed the following error message when a user tried to load a nonexistent data file:

  • Error parsing datafile. Data not parsed.

Although the message was true—no data was parsed—it was highly misleading. The real problem was that the specified data file was not found. After attempting to load the file, the code apparently did not check whether the load operation had succeeded, but rather simply passed an empty data buffer to the data parsing procedure, which duly reported that it couldn’t parse the data. Fortunately, this bogus error message was caught before the software was released.

Variation C: Generic message components. Another common way in which software displays unhelpful error messages is by using generic, one-size-fits-all error message texts and dialog boxes even though the software has more specific information that it could provide. After a user edits some settings in a dialog box and clicks OK, the software might display an error message indicating that one of the settings in the dialog box is invalid, but doesn’t identify the invalid setting. I see a lot of this sort of message in software I review for my clients.

For example, consider a stock investment application a client of mine had developed. The application allowed users to specify how much of a particular stock they wanted to buy or sell. New users of the application often encountered the following error message when they tried to submit orders:

  • Order size not multiple of trading unit.

It turns out that users of this application are not allowed to buy or sell just any old number of shares. The number of shares in a transaction must be a multiple of the "trading unit." The trading unit is (potentially) different for each stock. But the error message does not say what the trading unit for the stock is. The trading unit is also not shown anywhere on the ordering screen. Users just have to know, or guess, what the trading unit is for the stock they want to buy or sell.

Predictably, users of this application who hadn’t already memorized the trading units of various stocks wasted a lot of time adjusting the transaction size and resubmitting orders until they chanced on a number of shares that was a multiple of that stock’s trading unit. Because of this blooper and a myriad of others in the same application, I sometimes wondered if this client was really interested in selling software.

Figure 10 shows a message sometimes displayed by Microsoft Word 6.0 when a user attempts to open a document that contains graphic images. The message tells the user that one of two problems has occurred. If the two possible problems were similar, this might be acceptable, but in this case, the two problems are quite dissimilar; in particular, they have totally different remedies. If Word doesn’t have the appropriate graphics filter for the image, the user has to figure out what kind of image it is, and try to find and install the appropriate filter. If Word simply ran out of memory when trying to load the filter, then shutting down some other applications will probably suffice unless there are none to shut down, in which case the user needs to add memory to the computer. Thus, the user is left wondering what to do to resolve the problem. It seems unlikely that Word cannot distinguish these two quite different problems.

The Mother of all generic, uninformative error messages—the error message that, if there were a Nobel Prize for vagueness, would be the undisputed winner—has to be the error message shown in Figure 11, displayed by Eudora Pro 4.0, Qualcomm’s email software. Huh? What sort of help? Should I call the emergency services? Should I bring Eudora some chicken soup or warm milk? Should I try to put my arm around Eudora’s shoulder and give a reassuring squeeze? Should I tell Lassie to go fetch the sheriff? What the heck is this message asking me to do? Some programmer at Qualcomm (or given the rapid turnover in this industry, probably long gone from there) thought he or she was being really, really clever. Bzzzt. Blooper!

bullet.gif Blooper 6: Misuse (or nonuse) of "..." on command labels

Back in the early 1980s, the designers of Apple Computer’s Lisa computer (a predecessor of the Macintosh) decided it would be helpful for commands that execute immediately to be clearly distinguished from ones that first prompt the user for additional information. They decided to mark the latter sort of command by appending "..." (ellipsis) to the end of the command label, for example, "Save As…".

The "..." was intended to indicate that the software will display a dialog box prompting the user for more information. The choice of "..." as a marking was not arbitrary: it suggests that something additional must happen before the command can be fully executed. Commands that executed immediately did not end with "...". This convention was applied consistently to all command labels, whether they appeared in menus or on buttons. Details such as this convention were a part of what gave the Lisa and its more successful descendent the Macintosh reputations as easy-to-use computers.

In the software industry, good ideas spread. This convention was a good idea because it really is helpful for users to know in advance whether a command executes immediately or prompts for additional information. For example, it is safer to click on unfamiliar buttons if users can see that all that will happen is that a dialog box will appear.

Over time, the convention spread beyond the Macintosh to other computer platforms, such as the Commodore Amiga, Microsoft Windows, and Common Desktop Environment Motif standards. Nowadays, it is so pervasive that software not following this convention risks misleading users.

Unfortunately, many developers of GUIs do not follow this convention. In fact, violations of it are becoming more common. Some developers are simply unaware of the convention. Others know there is a convention but misunderstand it. Both sorts of ignorance are due partly to growth and turnover in the population of software developers and a lack of adequate training of new ones. Part of the growth in the number of "software developers" is due to the growth of the Web. As Web sites grow more and more elaborate and move beyond simple static pages, more people are becoming "software developers," often without any training.

Variation A: Omitting "...". The most common variation of this blooper is to omit the "..." on commands that should have it. Designers who commit this variation are usually those who simply don’t know about the convention. They don’t do anything to distinguish commands that execute immediately from commands that prompt for more information and provide an opportunity to Cancel the command. Users just have to guess or learn from experience how each command operates.

In the dialog box shown in Figure 12, which is from Newer Technology’s SpellTools software, the Import button is for importing files containing dictionary definitions from other spelling tools. Like most Import buttons, it first displays a file chooser dialog box that allows users to specify a file to import. Therefore, the Import button’s label should end with "...", but it does not. The Add Words button also displays a dialog box without indicating that.

Another example from an actual software product is shown in Figure 13, a toolbar from the main window of the music accompaniment program Band in a Box Pro 6.0 for Macintosh. The only buttons on this toolbar that do not bring up temporary dialog boxes are Play, Stop, Replay, Hold, Lyrics, and Not’n. The rest all display dialog boxes, and so should have "..." in their labels.

Variation B: Overusing "...". The next most common variation is to append the ellipsis symbol ("...") to command labels that should not include it. Designers who commit this variation of the blooper are those who have overgeneralized the convention. They mistakenly believe they should append "..." to the labels of any command that opens a new window. Therefore, one sometimes sees commands such as Show Graph…, which displays a graph in a new window. In this case, the command Show Graph executes immediately; it displays the graph. That’s what the command does. No additional information is required. The designer included the "..." simply because the command opens a new window.

An example of Variation B can be seen in Figure 14 in the Fonts menu of HP’s FontSmart font management software. None of the three menu items that end in "..." display a dialog box to collect additional arguments. The Magnify command displays a new window in which the currently selected font is shown magnified. The Info command displays a window providing information about the selected font. The Printer Fonts command displays a window listing the available printer fonts. In all three cases, the window displayed is the result of the command; when the window appears, the command is done. Therefore, none of the menu items for these three commands should end with "...".

Other common examples of this variation of the blooper are "New Browser…", "Debug Program…", "Edit Formula…", "Clone Window…", "Show Clipboard…", and "Help…". Assuming that these commands operate in the usual way (i.e., they open a new window to display the indicated information), these should be simply "New Browser," "Debug Program," "Edit Formula," "Clone Window," "Show Clipboard," and "Help."

bullet.gif Blooper 7: Inconsistent use of colons on setting labels

Controls, settings, and data fields in GUIs typically have textual labels that identify the value that the control or data field represents. This and the next few bloopers describe common errors in how labels are arranged and formatted.

When settings in a GUI have text labels, the issue arises, How should labels be visually separated from their corresponding setting values? The two most common solutions are (1) blank space and (2) a colon and blank space. The use of the colon character (:) rather than other possible separator characters (e.g., a hyphen) probably harkens back to the full-screen forms displayed by many business applications that were designed for character-based terminals and time-shared computers.

A common error in GUI applications is inconsistency in whether property labels end in colons or not. Sometimes no explicit convention exists,

Post Comment


No Comments Found