CHAPTER 15: But…How Do It Know?" – User Interface Design for Programmers

CHAPTER
15
But...How Do
It Know?"

Remember the old advertising slogan for Thermoses? They "Keep Hot Drinks Hot and Cold Drinks Cold!" To which your slightly brighter-than-average five-year-old asks: "But...how do it know?"

That's what we in the software design field call a heuristic.Here are a few well-known examples of heuristics:

  • If you type the word "teh" in Microsoft Word, Word will decide you probably meant "the" and change it for you.
  • If you enter "Monday" into a cell in Microsoft Excel and then drag down, you get the days of the week (see Figure 15-1).
  • When you search for text that looks like an address using the Google search engine, it will offer to show you a map of that location.
  • If you buy a lot of Danielle Steel books on Amazon.com, and a new one comes out, the next time you visit Amazon.com they will try to sell it to you.

As a rule of thumb, the way you know something is a heuristic is that it makes you wonder, "how do it know?" The term heuristic itself comes from the field of artificial intelligence, where it's used when the fuzziness of real life doesn't line up properly with the sharp true/false world of computers. A more formal definition is that a heuristic is a rule that's probably right, but not guaranteed to be right:

FIGURE 15-1


Excel has heuristically decided that you must want the days of the week because you happened to type Monday. (But...how do it know?)
  • English speakers intend to type "the" much more often than they intend to type "teh." If they typed "teh," it's probably a mistake.
  • When you type "Monday," you are probably referring to the day of the week. If you expand out the series, you probably want to see days of the week.
  • When you type something that looks like a number followed by a name followed by the word "Street," it's probably an address.
  • If you buy a lot of Danielle Steel books on Amazon.com, you'll probably want to buy the new one.

The operative word here is always probably. We're not sure. That's why it's just a heuristic, not a hard and fast rule.

In the olden days of programming, heuristics were very, very uncommon, because programmers are very logical creatures and they don't like rules that are "98% right." In the logical world of programmers, "teh" and "the" are equally valid sequences of three ASCII characters, and there is no logical reason to give one of them special treatment. But as soon as the designers of Microsoft Word broke through this mental logjam, they realized that there were zillions of interesting assumptions you could make about what people wanted. If you typed a paragraph starting with an asterisk, you probably want a bullet! If you type a bunch of hyphens, you probably want a horizontal line! If you start out a document with "Dear Mom," you're probably writing her a letter!

In their zeal for heuristics, the designers of Microsoft Office came up with more and more clever features, which they marketed as IntelliSense. As a marketing pitch, these features sound really neat. Word figures out what you want and does it "automatically!"

Unfortunately, somewhere, something went wrong. Woody Leonhard wrote a whole book called Word 97 Annoyances, mostly about how to turn off the various heuristics, and people were so thankful they gave the book five-star ratings on Amazon.com. Somehow, heuristics crossed the line from "doing what you want automatically" to "annoyances."

Nobody sets out to write annoying software. So where is the line? When does a heuristic stop being a really cool, helpful feature that saves time andstart being an annoyance?

Here's the thought process that goes into developing a typical heuristic:

  1. If the user types "teh," there's a 99% chance they meant "the."
  2. So we'll just change it to "the" for them. Then there's a 1% chance that we're wrong.
  3. If we're wrong, the user will have to undo the change we made.
  4. Ninety-nine out of one hundred times, we improved the user's life. One time out of one hundred, we made it worse. Net value to user: 98% improvement.

This tends to get generalized as:

  1. If the user does x, there's an n% chance they meant y.
  2. So we'll just do y for them. Then there's a (100 - n) chance that we're wrong.
  3. If we're wrong, the user will have to correct us.
  4. Net value to user: (100 − 2n)%, which is better than doing nothing for n>50.

Aha! I think I've found the bug. It's in step 4, which does not logically follow. Happiness is not linear. It doesn't really make a user that happy when they type "teh" and get "the." And happiness is not cumulative.The bottom line is that every single time you apply a heuristic incorrectly, you are making the user a lot more unhappy than you made them happy by applying the heuristic correctly all the other times. Annoyances are annoyances, and people don't weigh annoyances against joy when deciding how happy to be. They just get annoyed.

How annoyed? That depends on step 3: how hard it is to undo the heuristic if the program guessed wrong. In Word, it's supposed to be pretty easy: youcan just hit Ctrl+Z, which means Undo. But a lot of people, even people who know about the Undo command, don't realize that Undo undoes the computer's actions as well as their own. And if you watch them, they usually try to undo the error themselves by backspacing and retyping, and of course, Word blindly applies the wrong heuristic again, and now they're getting really frustrated and they don't know how to fix it. By now the annoyance factor is deep into the triple digits, which has more than wiped out the minor satisfaction that the heuristic was intended to cause in the first place.

In general, I don't like heuristics because of the principle from Chapter 2:


If your program model is nontrivial, it's
probably not the same as the user model.


This gets back to the "How Do It Know" factor. If users can't figure out why the program is applying a heuristic, they will certainly be surprised byit, producing a classic example of "the user model doesn't correspond to the (inscrutable) program model," and therefore, the program will be hard to use. To judge a heuristic, you have to decide if the rule for the heuristic is obvious enough, or if users are going to stare blankly at the screen and say, "how do it know?" Turning "teh" into "the" maybe obvious, but changing three dashes into a horizontal line is probably not what people expected, and they probably won't know why it's happening. This makes it a bad heuristic because it leads people to say, "how do it know?"

The second way to judge a heuristic is by the difficulty of undoing it, and how obvious the undo procedure is. When you write a check in Intuit's Quicken program, and you start typing the name of the payee, Quicken looks for other payees that start with the same letters as the payee you're typing and pretypes that for you. So if you've paid someone named "Lucian the Meatball" in the past, and you type "Lu," Quicken will propose thefull name "Lucian the Meatball." That's the heuristic part, and it's pretty obvious why it's happening—nobody's going to ask "how do it know?" But the brilliant part of Quicken is that the "cian the Meatball" part will be selected, so that if the heuristic was wrong, all you have to do was keep typing and it will effectively undo the heuristic right away. (This invention spread from Intuit's Quicken to Microsoft Excel and eventually to Microsoft Windows). When a heuristic is really easy to undo, and it's obvious how to undo it, people won't be so annoyed.

The third way to judge a heuristic is, of course, by how likely it is to be correct. Changing "teh" to "the" is pretty likely to be correct (although it was wrong about ten times while I was typing this chapter). But a lot of other heuristics are less likelyto be correct (such as Word's morbid insistence that I want help writing a letter).


A good heuristic is obvious, easily
undone, and extremely likely to be
correct. Other heuristics are annoying.