Blooper 42: Speaking Geek

< Day Day Up >

Text in websites and Web applications, as in desktop software, is often written in programmers' technical jargon, making it incomprehensible to the software's intended users. This is known as "speaking Geek" (Johnson, 2000).

Although Web developers come from a wide variety of backgrounds, many have programming backgrounds. When writing text for websites, they often use programmers' jargon. Why? There are several reasons:

They don't realize it's jargon.
They can't express themselves in nontechnical terms.
They expect computer users to learn the jargon.
They directly expose low-level software-to-software communication ”for example, java exceptions ”instead of translating it into terms related to what the user is doing.
They don't have time: "Someone will fix this before we go live!"
The site is poorly designed: It exposes implementation concepts that aren't easily " painted over."

Bill Griffith. Reprint with special permission of King Features Syndicate.

Geek speak can appear anywhere there is text in a website. Sometimes it's in instructions the site provides. Sometimes it's in error messages. Sometimes it's in the names of commands site users have to invoke to accomplish anything. Let's look at examples of each.

Geeky Instructions

Earthlink.net gives subscribers a way to create a "vacation" message that will automatically be sent in reply to incoming email, as well as a way to turn vacation auto-reply on and off. If you are a subscriber, you access your vacation settings by going to Earthlink.net and typing your email address and password (Figure 6.7). The instructions say to "enter your email address, domain, and password" ”three pieces of information ”but the form provides only two text boxes. Software developers know that the domain is part of the email address, but I doubt that my aunt Geraldine and others like her know that, or even what "domain" means in this context.

Figure 6.7: www.Earthlink.net (Sept. 2001) ”Asks user to enter three pieces of information into only two fields. Most users won't know what the domain is or that it is part of the email address.

In this case, the geek speak is entirely superfluous: The word "domain" could be dropped from the instruction with no loss. In fact, the entire instruction could be dropped with no loss, because the field labels are enough.

Website instructions sometimes also speak geek by using graphical user interface (GUI) toolkit terms for parts of the user interface. Programmers often forget that words like "field," "icon," "drop down," and "dialog" either are unknown or mean something else to most English speakers . The terms "drop down" and "dialog" are actually double jargon: They are abbreviations for longer jargon terms: "drop-down menu" and "dialog box," respectively. Perhaps programmers assume that learning GUI component names is a necessary part of learning how to use a computer. If so, they are wrong. Figure 6.8 shows excerpts from three websites that use the GUI toolkit jargon terms "field," "icon," and "dialog": FinancialEngines.com, OfficeMax.com, and Galor.com (Figure 6.8).

Figure 6.8: Graphical user-interface toolkit jargon in websites ” A ” www.FinancialEngines.com (Sept. 2002) refers to "fields" instead of, say, "information." B ” www.OfficeMax.com (Jan. 2002) says "click this icon." C ” www.Galor.com (Sept. 2002) uses both "dialog" (an abbreviation for "dialog box") and "icon."

Even worse than using GUI toolkit jargon is using it incorrectly. The San Mateo County (California) Department of Transportation's TransitInfo search page instructs users to "type a query in the Search dialog" (Figure 6.9). The problem is, there is no dialog box ”only a text field on a regular Web page. A dialog box is a little window that pops up to collect data from the user or display a message. If you're going to use implementation toolkit jargon, at least get the component names right!

Figure 6.9: www.TransitInfo.org (Dec. 2001) ”Geek speak that isn't even correct ” Calls a text field a "dialog."

Geeky Error Messages

Another obvious place for geek speak to show up is in error messages. A classic example of a geeky error message is from the website of an organization that should know better. The Association of Computing Machinery's Special Interest Group on Computer-Human Interaction (ACM SIGCHI) is all about making computers easier to use. Every year, SIGCHI holds a conference. The CHI conference pages at ACM's website allow people to register online until about 2 weeks before the conference. After that, online registration is closed; additional attendees must register at the conference. In 2002, if someone tried to register online for CHI 2002 after online registration had closed, the site displayed the helpful message: "RegMaster Error 105: Cannot open CHI02closed.txt." (Figure 6.10). Clearly, some internal Web-server message is being displayed by the site.

Figure 6.10: www.ACM.org/chi2002 (Apr. 2002) ”Message informing user that the deadline for online registration for the ACM CHI2002 conference has passed.

Even if SIGCHI fixed the message to say something sensible like "Sorry: Online registration for CHI 2002 closed on April 8. Please register at the conference." they would still be committing a blooper (see Chapter 2, Blooper 13: Dean-end Paths: Now you tell me!). The site should say up front that online registration is closed, and no longer provide links for that, instead of letting people follow links to online registration and then telling them registration is closed.

On the home page of Audi.com, menus are provided to let users go to sections of the site designed for specific countries . Select a continent and a country, then click the arrow button to go there. What if someone clicks the arrow without first choosing a continent and a country? The fancy pages with car pictures are replaced by a stark gray geekism: "Method Not Allowed," no doubt referring to a Java programming language method (Figure 6.11). Perhaps realizing that this message might not help visitors understand what they did wrong, Audi.com adds the helpful comment: "An error has occurred." Danke sehr!

Figure 6.11: www.Audi.com (Feb. 2002) ”(left) Global Home page, with Continent and Country menus. (right) Error message resulting from clicking arrow button without having chosen continent and country.

A special case of a geeky error message comes from Feldenkrais.com. If a visitor uses the site's search function, but the search function finds nothing matching the user's search terms, it displays an error message and a very geeky one at that (Figure 6.12). Of course, the main problem is not the geekyness of the message, but that not finding anything is treated as an error.

Figure 6.12: www.Feldenkrais.com (Oct. 2002) ”Error message exposes internal software communication.

Geeky Commands

A good example of speaking geek in commands comes from a client company's internal Web application for logging hours worked on a project. When a user first signs in, the site lists recently submitted hours and expenses and provides commands for viewing more of the history. The command for logging new hours is called "Create a new record" (Figure 6.13).

Figure 6.13: Client Web application (Apr. 2002) ”Command "Create a new record" is implementation focused, not task focused.

Why is the command called "Create a new record" instead of something more task-related such as "Log hours?" Because in order to log new hours, the back end has to create a new data record. The implementation has crept into the user interface. However, users don't want to "create a new record." They want to log work hours. Therefore it might take them a while to figure out how to log their hours.

Nice Try, But No Cigar

Many websites ” especially e-commerce sites ”are front ends for large, complex transaction-processing systems. In such sites, it is nearly impossible to predict all the ways a user can arrive at a given page, especially since Web users often navigate using their Back and Forward buttons . The site can also experience internal failures, both minor and major. It is therefore difficult to ensure that all instructions and error messages are task focused and helpful.

As examples, let's examine two different error conditions that can occur at United.com. In one situation, a user logged in, accessed his frequent-flyer account, backed out without doing anything, visited other websites, and then returned to United's home page and logged in again (Figure 6.14). From the site's point of view, the user is still logged in from before but is trying to log in again. ^[1] The message tries to explain in plain language what the user should do: log out. Nonetheless, my mother-in-law probably wouldn't understand this. For one thing, she probably wouldn't know what an "active session" is. It is also unclear what it means to "register an existing ... account." Most people's reaction to a confusing message would be to hit the Back button. In this case, that happens to be what United wants them to do anyway, so this message might be okay. On the other hand, it also asks users to log out. People rarely explicitly log out of websites. Instead, they just back out or send their browser to another site. If this situation arises frequently, United should reexamine it and try to devise a better solution.

Figure 6.14: www.United.com (Apr. 2002) ”User logged into site twice. Problem description is a bit geeky, but instructions at least make a good attempt to be helpful.

In the second situation, the user specified his flight details, then selected one of the resulting itineraries to get a price. According to the error message, something in the back-end system prevented it from pricing the itinerary (Figure 6.15). "Reservation system internal error" is a bit too geeky to meet the "retail product quality" standard. Consumers would never buy a car or TV that displayed "internal system error" messages. Still, it isn't a horrible message, and the rest of the message suggests in plain language what the user should do: Try a different flight. However, that "try a different flight" suggestion is also troubling because it is so likely to be wrong. For example, this customer tried several flights and got the same message for all of them. He had no way to tell whether the problem was a transient glitch or a restriction on what itineraries can be priced.

Figure 6.15: www.United.com (Apr. 2002) ”Internal glitch caused task failure. Problem description is a bit geeky, but instructions at least make a good attempt to be helpful.

Avoiding the Blooper

Geek speak must go! Web users aren't captive, so they are even more sensitive to geekisms than users of desktop software. If anything confuses or annoys them, they can leave at any time.

How to avoid speaking geek can be summarized as follows ^[2] :

Know your users. Interview representatives of your target user population to learn their vocabulary for the tasks your site covers. Don't expect people to learn a new vocabulary ”even just a few new terms ”to use your site. They won't, and you'll be the loser.
Develop a site lexicon. Create a list of all the terms and their corresponding meanings that will appear in the site. Base the list on the users' tasks and vocabulary. Follow it religiously and keep it current as the site changes. Assign a team member ”preferably a technical writer ”to be the keeper and enforcer of the lexicon.
Keep implementation terms out. This includes GUI component names like dialog, icon, field, and drop down. It includes technical terms like proxy server, SSL encryption, and authenticate. It includes internal exception symbols and program code like array_index_out_of_range, javascript error: file.open() failed, and illegal method.
Provide solutions for errors. Engineers like to describe the problem. Users want to know the solution. Of course describe the problem ”in terms related to what the user was doing ”but also suggest a course of action, as is shown in an excellent error message from Southwest Airlines' website (Figure 6.16).

Figure 6.16: www.Southwest.com (Sept. 2002) ”Great error message. Describes the problem in users' vocabulary and suggests what to do.
Put the right people on the job. The root cause of geek speak in software and websites is a management blooper: assigning the job of writing command names, instructions, and messages to programmers. Programmers are skilled in writing software code, not text. The writing of software text should be assigned to people who have the right training and skills: user-interface designers or technical writers, preferably the latter.
Test the text on users. The text in a website should be tried on representative users before the site is put on the Web. One nice thing about text is that it can be tested using paper-and-pencil tests or not-yet-connected static pages; you don't have to wait for the site to be finished. Another nice thing about text is that even if problems are discovered close to the release date, they are usually easy to fix.

Situations such as the two that occurred at United.com are admittedly difficult. In both cases, United.com made a reasonable attempt to avoid speaking geek to its customers. However, that still wasn't good enough for a mass consumer market. Here are some thoughts on how United.com might have better handled these situations.

In the first case, someone who still had an active session from a previous login tried to log back into the site. I see two possible solutions:

If you view the situation from the user's point of view rather than the website's, it shouldn't be considered a problem. From the user' viewpoint, he left United.com and then returned. He didn't know he was still logged in. The site should either just forget about the previous session and let the guy log in again or treat his new login as "unnecessary" and take him back to where he was before. Either way, a geeky error message is avoided because there is no error.
If it is necessary to consider this an error condition, rewrite the message in less technical language. For example, You are already logged in from a previous visit. You can either resume your last visit to United.com or you can start again. Resume Start Again

Note the use of the less-technical word "visit" instead of the geeky term "session."

In the second case, the site encountered an "internal error." Without knowing what the actual problem was, it is hard to know what the message should say. Whatever the problem, the message should be clearer about whether it is temporary or not. In other words, if the customer tries again later, will the site be able to price the itinerary or is there something about the itinerary that prevents it from being priced, ever?

^[1] The site detects that the user returned by checking for a "cookie" that it gave the user's browser during the first visit.

^[2] See Johnson (2000).

< Day Day Up >