Peter Seebach ([mailto:crankyuser@seebs.plethora.net?cc=&subject=You don't exist. Go away.] crankyuser@seebs.plethora.net) Freelance writer 2 February 2004
People were mistakenly declared dead long before people had computers. Frustration results when something or someone tells you that you don't exist, an experience the cranky user examines in this month's column.
When I recently received a scam in the mail, I decided to discover how the scam worked. Unexpectedly, I ran into a problem: When I told the scammers my name, they didn't believe me. I've experienced that problem before. A month after I bought my house, a store clerk, while setting up a department store credit card, told me I had no credit history. Same story: They didn't believe in my first name, and either they refused to look it up or their software wouldn't accept my name.
You see, my first name is just the letter A. Not an initial, it's the whole name, which creates havoc when well-meaning bureaucrats try to enforce rules such as "full name only, no initials."
Unix traditionally says this with, "You don't exist. Go away" -- an infamous message that has baffled people for a long time. Perhaps most disturbingly, it's been copied in modern versions of SSH (Security Shell), where it's been repunctuated as "You don't exist, go away!"
Either way, the message fails to properly inform users what the problem is: an attempt to get the password file entry for your numeric user ID failed. One could easily imagine a more informative error message such as, "Error: no password entry for uid 367."
In each example above, the problem stems from denial of a person's existence, even though the person is right there. Although the "You don't exist..." error message, for its part, at least sticks tongue-in-cheek, it's still a silly error message, especially in the old talk program where I first saw it. Wouldn't it seem more reasonable to first assume the person really does exist, even if she doesn't quite fit the mold?
The denial-of-existence problem surfaces more frequently with corporate policy than with software, although, as the aforementioned examples show, software proves guilty too. However, corporate policy declares that someone doesn't exist, then simply ignores that person. As such, policy represents a great way to abdicate responsibility; time and time again, I'm told that something is a policy with no person, indeed, no group of people, who can change it. So, where do policies come from? Do they spring full-grown from the foreheads of middle managers?
As a favorite example, a major retail chain near me pushes hard to get personal information; they want a phone number and address before they'll sell you anything. What, I wonder, do they do for people without a personal phone number? I assume those people just give a fake number. Me, I give the chain's customer service number. That way, those responsible for the policy receive all the telemarketing.
Error checking is a good thing. Likewise, sanity checks represent an important way to correct likely errors in user-entered data. Unfortunately, many sanity checks rest upon narrow world views. For instance, Apple Computer constantly corrects my address on file with them -- they keep moving me to a nearby city in the same zip code because 90 percent of my zip code resides in the city a few blocks north of here. It's not that they've done it once; they change my address every single time I deal with them. Worse, they do it after my last chance to interact with the system. So, when I order something they leave my address correct until I've confirmed my order; then they change it to the nearby city.
As that example shows, sanity checks should never depend entirely on a computer without human confirmation. Users should always possess the option to override the computer. Yes, confirm whether or not someone really means something, but don't try to outsmart the user too much.
Badly chosen sanity checks can be awful. Phone systems that refuse to let someone in without a valid number, for example, can be spectacularly annoying. I once spent more than an hour with a phone representative while he tried to navigate through a nonworking phone system. What went wrong? A sanity check caused the phone system to reject all possible input as erroneous.
A sanity check, moreover, should not check whether or not some data are reasonable, but whether or not the data are possible. Enough legally dead people pay taxes these days that you should use a very permissive notion of possible. Many things reside just outside the official specs; a system that can't deal with such things is a bad system. As a specific example, always let users enter dates residing in the future. You would be amazed at how often that problem comes up.
A friend of mine found a Web site that refuses to load on the Opera Web browser. Moreover, the site doesn't just look for a browser claiming to be Opera, it checks for what Opera would say even when configured to look like (spoof,) a supported browser. After he discovered how to spoof their browser check, the site worked fine.
So, in that example, the site's designers wrote a special check for browsers (Opera for my friend) that spoof the browsers they support, and refuse to display the page for such browsers -- even though the site works fine regardless. You see such moves often these days, but I can't say whether it stems from laziness or malice.
Sites that intentionally exclude a small percentage of users are a little unusual, but not unheard of. Generally, the designers claim exclusion cuts costs. When you look at the site's pages, however, it's pretty clear that a page that worked everywhere would have been a lot cheaper, though maybe not quite as flashy. In many cases, I'd rather have the easier page; even the supported browser may crash on a badly designed page.
Such examples show the strange belief that if you design a site to work exclusively with the most popular browsers and put in extra effort to keep other people out, somehow those with popular, yet unsupported, browsers should not visit your site -- as though no pages work in more than one browser.
It may seem trivial immediately to exclude five percent of the potential market, but the different excluded groups add up to a substantial chunk of a market. If your store won't sell to Mac users, people with third-party browsers, people outside the continental US, people with JavaScript turned off, people who won't use PayPal, or people with free e-mail accounts, you're running out of people. Yeah, a lot of potential customers are left, but how many businesses can afford to take a 20 or 40 percent cut in sales?
Along those lines, considering that those who don't exist comprise a big part of the market, granting their existence seems reasonable. As such, don't play "why can't they just..." with potential customers; it's frustrating and annoying. Furthermore, the question often becomes, "Why can't they just spend $2,000 on hardware and software to work around my mistake?" The obvious answer: they can, but they won't.
This week's action item: Look for funny stories about people who are legally dead. Do you maintain any databases of people? Would your company have coped with that problem any better than those in the stories you found?
Photo of Peter Seebach Some of Peter Seebach's problems are unique to him, which is why the form-letter approach to customer-service problem solving wastes a lot of his valuable time. If you're an individual that'd like to talk about being treated as a faceless, nameless generic problem, you can reach him at [mailto:crankyuser@seebs.plethora.net] crankyuser@seebs.plethora.net. (Please. No form letters.)