NN/g Home  AskTog  Interaction Design Section  10 Most Wanted Design Bugs

Design bugs tend to work through users, by tempting, cajoling, or forcing them to perform an action that results in damage. A prejudice within the engineering community holds users to be rather pathetic and deserving of punishment if they err, an opinion that, sadly, most users share. Because both engineers and users are quick to place blame on the user's head, instead of the d'ohltish design, correction of design bugs typically takes a back seat to coding bugs of equal or lesser seriousness.

To make it on this list, a bug must be a design error, not a coding slip, must have either persisted more than five years or persisted more than one year and also be potentially catastrophic, causing the user to lose significant time, data, or worse.

November 4, 2004: Air Force pilot, Maj. Roberto Balzano, his F-16 jet fighter lined up on the training school below, squeezed the trigger, strafing the facility with 27 rounds of 20mm ammunition, sending 8 of the deadly 2-inch slugs crashing through the roof to wreak havoc within.

Another terrorist training camp wiped from the face of the earth? Not exactly. The target he struck was the Little Egg Harbor Township Intermediate School in New Jersey.

Ooops!

The only reason no one was killed was that the pilot's night time training mission took place while the kids were home, tucked into bed.

What went wrong

Maj. Balzano not only believed his weapons were aimed at a target several miles away on the Air Force practice range, he had no intentions of firing his weapons. Both the hardware and software design of the weapons system contributed to the error. The process under which they were designed likely led to it.

The F-16 has two major weapons systems, a rocket-bearing "targeting pod" and a gun.

The targeting pod can be rotated independently of the aircraft to lock onto a distant target. The gun, however, is always fixed directly forward.

There's value in having the gun aim straight toward the target. When attempting to take out another aircraft during a dogfight, the pilot is busy enough aiming the plane toward the enemy without having to independently aim the gun.

Likewise, the rockets, used for targets many miles distant, should not require the aircraft to be aimed toward them to achieve a kill.

Even with these fundamental differences, both systems are manipulated with the same controls, with a mode switch to select which weapons system is in use.

Both weapons are fired by pressing a common trigger. The trigger is a time-honored firing mechanism. However, they've fancied this one up: Pressing the trigger all the way down fires the weapon, but pressing the trigger half-way down will paint the pod's target with a laser, offering the pilot target-orientation information.

Those of you who have tried to lock auto-focus on your camera by pressing the shutter half-way down know how well this works: half the time, you end up with an unwanted picture. With the F-16, some of the time you end up with a shot-up school.

The Fourth Time's a Charm

This was the fourth such incident for the year 2004. (The other three, thankfully, also resulted in no death or injury.) The solution arrived at after the first three? Pilots were to be told before every training flight, "don't do that!"

Specifically. pilots were instructed never to press the trigger to do laser-orientation when the weapons control system was in gun-mode, even though it was evident that insufficient feedback existed to let the pilot know the system was in gun-mode.

In Maj. Balzano's case, the pilot's mind was in "rocket" mode, with his attention locked on the range target at which he had aimed his rotatable pod. Because his weapons system, unbeknownst to him, was in gun mode, however, the accidental firing did not sent a rocket to where the pilot was aiming, but a string of heavy projectiles to where the aircraft and, hence, gun were at that moment pointing. That turned out to be the Little Egg Harbor Township Intermediate School.

The Air Force, based on their having told the pilots each and every day, "don't do that," leaped at the opportunity to blame the fourth incident on pilot error. However, the Accident Investigations Board did acknowledge that the Air Force really ought to fix the plane as "poorly-designed controls" contributed to the incident.

What we can learn from this

The problems with this interface are two:

1. Identical controls used for asymmetrical weapons systems, with insufficient mode feedback.
2. A trigger dependent on a subtle difference in pressure to effect two radically different results.

The nature of these problems leads me to suspect two errors in process:

1. Insufficient usability testing during development. These are not subtle problems and should have been flagged.
2. Insufficient attention to personas and scenarios during task analysis, even before design began.

During combat, the mode problem could pose a problem—shooting a rocket to the side when intending to fire on an aircraft toward the front would be problematic. However, the trigger problem would probably be of little consequence. (So you hit them with a few extra bullets.) If the designers concentrated on combat, the dual-detent trigger might have seemed like a good idea.

However, if they had considered a scenario of error conditions with an armed training aircraft under US East Coast conditions, where aircraft must stray out of the small ranges' immediate vicinity, maybe they might have considered that accidentally firing on civilian targets was a) a reasonable possibility and b) a really bad idea.

So many serious design errors that seem to pop up out of nowhere after a product ships could have been stopped in their tracks even before design begins. Do proper field studies and task analysis as the start and you just might avoid shooting up either your local school or your company's bottom line.

Bug on list since: 1 Feb 2005

Bug Name: Power failure crash

Duration: >30 years

Supplier: Desktop computer manufacturers

Alias: "Oh, Sh--!"

Product: Desktop computers worldwide

Bug: If the computer loses power for more than a few thousandths of a second, it throws everything away.

Class of error: "That's the way Grandpa did it..."

Principle: Protect the User's Work

Discussion: Somehow, the most destructive act a computer can carry out, other than destroying the contents of a hard disk, got "grandfathered in." Somehow it became OK for computers to just die if the power fails.

If cars modelled this behavior, you might drive your car from New York to Miami, run out of gas in Fort Lauderdale, 10 miles from your destination, and suddenly find yourself back in New York.

Immediate Fix: Web Developers

Store (encrypted) information in cookies even before transfer to the server, so information is preserved from all but the most serious "melt-downs."

Proposed Fix: Application Developers

Convert your existing software and write new software to perform Continuous Save, so users cannot lose more than the last few characters typed or gestures entered. Do not fail to provide sufficient Undo and Revert facilities enabling users to get back to where they were before they started doing the wrong thing.

For all the drawbacks of the crude system most applications have had until now, one advantage was that new drafts did not take the place of old until we said so.

Oh, and by the way, a dialog saying, "This action cannot be undone. OK Cancel," is not a suitable substitute for a Revert facility for anything at any time.

Proposed Fix: OS's

Build support for Continuous Save and Revert into the toolbox.

Proposed Fix: Computer Hardware

Add electrolytic capacitors or high-current, low-capacity batteries to systems with volatile memory, with perhaps 15 to 30 seconds worth of power. Have the OS initiate hibernation after around 2 seconds of power failure. Thus the system will continue working during momentary glitches and will save your work and shut down during extended outages, offering the same protection now available to portable users.

Bug first observed: 1976

Observer: Tog

Bug reported to Apple: 5 Mar 1985. Quote from that memo:

The age of computers that die when the power goes off will fade to an interesting footnote in history, just as radio gave way to TV. The question is not whether Apple will [address the problem], but when. I believe the time is now....We
have the opportunity to add another dimension to computers; let us take it.

Should happen any day now...

Bug on list since: List inception: 1 Dec 2004

Bug Name: The Macintosh Dock

Duration: Four and counting

Supplier: Apple Computer, Inc.

Alias: "The Cool Demo"

Product: Mac OS X

Bug: There are actually nine separate and distinct design bugs in the Dock, probably a record for a single object. You can read about them all in my Article, "The Top 9 Reasons the Dock Still Sucks."

Class of error: Confusing a demo with a product

Principle: Demos and products are two separate entities. The Demo's purpose in life is to help sell the product. The product's purpose is to serve the user.

Proposed Fix: Leave the Dock just as is. It looks great on stage during presentations; it looks great in the store. However, allow the user a graceful way to turn it off once its shortcomings become apparent, substituting instead less flashy looking tools with real power behind them.

Discussion: It's not that the Dock sucks so much as a productivity tool as it is that Apple threw away so many more powerful, useful objects in its favor. These, in an updated, extended form, should be returned.

For an article on how Mac users can "repair" these design flaws by themselves, using third party shareware, see my "Make your Mac a Monster Machine."

Bug first observed: January, 2000

Observer: Tog

Bug reported to supplier: January, 2000

Bug on list since: List inception: 1 Dec 2004

Bug Name: Mysteriously dimmed menu items

Duration: 25 years

Nickname: "Dimmed & Dimmer" or "Gray Doubt" [try saying it out loud]

Supplier: Apple, Microsoft, Sun, Linux, et. al.

Favorite Saying: "Ha, ha!" [in the manner of Nelson on the Simpsons]

Product: All GUIs

Bug: Designers offer no way for users to discover why a given menu or option has been dimmed (grayed out), nor how to turn it back on.

Class of error: Users are teased with options that they cannot access without guessing what was in the designer's mind

Principle: Interfaces should be fully explorable. Users should never have to guess at what unusual confluence of factors will enable them to take advantage of a given capability of a website, application, or system.

Proposed Fix: Make grayed-out objects clickable, revealing what has caused the object to be dimmed and what the user can do about it.

Discussion: This design bug has hung around since the work at Xerox PARC that laid the foundation for the Mac and the machines that followed.

In the earliest days, systems did very little, offering, therefore, few options. It did not take users long to understand that the reason Print was dimmed was because there was no document open to print. Then things got complicated.

Today, it can take users upwards of an hour to even a few days to figure out why an option is dimmed, often involving calls to the vendor. Too often, the vendor doesn't know either.

This bug has been ignored for too long and it has reached a critical point. Too often, an item on the File menu, for example, is dimmed because of some interaction on the fourth menu over, one that has no apparent logical connection with the File menu or item being dimmed, at least not in the user's world.

The software "knows" why it has dimmed the item. Some decision or decisions led to the flag being set. At the same time as the flag is set, the reason why should be made available. If the user clicks on a grayed-out option, the reason or reasons should be made known. And none of those, "Gosh, Oh, Gee, it could be any one of these 14 reasons or maybe something else" messages. The message needs to be intelligent, responsive, and accurate. This one is important. This one needs to be done right.

Reader Ben Roubique has sent me documentation of Powerworld Simulator developed by Powerworld Corp. It allows people to click on grayed out items and gives them lucid, targetted information on why a given field in their matrix is gray. Only 1 million developers to go...

Bug first observed: 1979

Observer: Tog

Bug reported to suppliers: On and off over the years

Corrective actions:

• Apple's Balloon Help: A great idea with a fatal implementation. (It actually made more people crazy than the Microsoft Word Paper Clip guy.) Few ever left it on long enough to discover that, in a few cases—perhaps one in ten thousand—it would point out the reason grayed out items were grayed out.

• Reader Gary M. Davis reports his 1998 Xerox patent that addresses the problem using little help buttons next to grayed out items. Not as ideal a solution as an industry-wide move to clickable gray, but nonetheless a good, clean solution. Read the patent.

Bug on list since: List inception: 1 Dec 2004

Bug Name: Dumb sorts

Duration: >30 years

Supplier: Almost everyone

Alias: "Really, Really Dumb Sort"

Product: Almost everything

Bug: 15 Dec 2008 sorts as being before 2 Jan 1900

Class of error: The Model T worked; why change it?

Principle: It is as important to continuously improve the old as it is to create the new.

Principle: Sort based on human custom and usage, not the internal math of computer character storage

Effect: People have been forced to learn bizarre and unusual ways of naming objects to force them to appear in the correct order. Such tricks as adding leading zeros and reversing the order of dates have become pandemic.

Proposed Fix: Add intelligent Alpha-numeric sorts to lists throughout the world of computing. Such sorts should be able to handle the proper sorting of expected numbers for the particular application. Quite often this just means that A2 should come before A10. Sometimes it means doing more, such as properly parsing and sorting dates, times, and other special formats.

Add language-specific exceptions, such as ignoring "The" and "A" or "An" when alphabetizing English.

But wait! No one would go that far, would they?

Yes. iTunes does this one already. The payoff? The clean, forgiving iTunes interface has helped sell millions of iPods and song downloads measured in the hundreds of millions.

(Just don't try to save any Les Paul songs, however, and expect to see them again. iTunes, unlike you, did not sleep through French class and will, as reader Devin Chalmers points out, read "Les" to be French for "the." You will find Messieur Paul under "Paul, Les")

Both Windows and Mac OSX have recently joined in, doing simple alphanumeric sorting. They still will list a file called, "February 3, 2004" before a file called, "January 1, 1901," but it's a start. (Some more complicated sorts will require the user to specify formats, such as US dating, European dating. So be it. Systems should be making such preferences available to visiting websites, anyway.)

Bug first observed: 1976

Observer: Tog

Bug reported to suppliers: Over and over

Bug on list since: List inception: 1 Dec 2004

Bug Name: URL naming bug

Duration: >10 years

Supplier: Browser Builders

Alias: %20 Off Bug

Product: All Existing Browsers

Bug: Many browsers disallow entry of spaces & other normal human-language characters into web addresses. The rest do inappropriate things with them.

Class of error: Keep it (too) simple

Principle: Support people's ability to communicate in the manner to which they are accustom.

Discussion:

Companies advertising in traditional media want to point people to their websites. They need potential visitors to be able to remember their web addresses long enough to get to their computers. That starts with people being able to read the addresses in the first place. Scrunched-together web addresses are difficult for humans to both parse and remember.

History:

For the last millennium or so, speakers of European languages have consistently separated written words with spaces. That changed around 30 years ago whenaspacebecameavaluableobjectnottobewasted.

Used to the existing system, later programmers feared that if they allowed users to include spaces in file names, etc., that users might sometimes enter double spaces instead of single spaces, thereby creating different filenames from what they intended. Because spaces are invisible, users might then may have difficulty figuring out what is wrong. The easy solution? Keep forbidding spaces.

It turns out users don't have those problems. The Apple II introduced spaces in filenames almost 30 years ago, and no one has suffered any reported problems since.

Today, that byte storing a space costs less than 1 trillionth that it used to. There is no longer any valid excuse for forcingPeopleToTypeLikeThisorworsetotypelikethis. None. Nada. Kein. Nikakoi.

Reader Zav suggests that we go beyond spaces, to allow such radical inclusions as (gulp!) apostrophes, so we can visit Macy's on the web, in the same way we can in real life.

Proposed Fixes:

Note: these proposed fixes are for URLs only. Don't bother writing me to tell me that they wouldn't work for, for example, lists of documents. We know that.

Proposal 1, from Tog: Allow advertisers to advertise and users to enter as many spaces and other normal characters in a web address as they want, then remove them all internally before matching.

At the same time, allow websites to store filenames with spaces and other normal characters, but, as was done with the user's entry, remove them before matching the user's request against them.

By removing all these characters just before testing, a proper match will always be assured, but the URL itself, as presented at the top of the window, will be easy for the user to read and will be the same as the URL advertised.

This scheme is analogous with how modern systems handle case, allowing both supplier and user the freedom to use whatever case they want by converting everything to lower case immediately before matching. (Tog)

Proposal 2, from Charles L Flatt: From a user-experience point of view, what I'd really like is this:

1. Company registers an IP address (no URLs anymore)
2. Company registers up to five friendly names to associate with that IP. These friendly names could be the same as those selected by other companies. For instance, Software Meadows might be registered for an Ohio company and a Dublin company, each to a different web site.
   
3. A new service, possibly an addition to DNS, queries this database and returns the possible choices to the requester.
   

From the user's point of view, she types in "Software Meadows". A select list appears saying

• "Software Meadows - Consulting - Ohio"
• "Software Meadows - Retail Sales - Dublin"

She then choose the desired site.

In effect, I get this with Google today. Registering the info would reduce the hits. In fact, this is what directory services should provide, so the technology probably already exists.

[This proposal would need special rules to keep me from opening a closet-sized book store in Podunk also named "amazon," but the approach has great merit—tog]

Proposal 3: "Instant On," from Mark Whybird: Processing of domain names already takes place: www.asktog.com, WWW.ASKTOG.COM and www.AskTog.com all resolve to the same IP address already.

The extra line of code in the DNS software to make www.Ask Tog.com and www.Ask Tog'.com also resolve the same is so ridiculously easy that it could probably be done worldwide within a matter of weeks, at the outside. The users wouldn't have to even update their browsers.

Bug first observed: 1994

Observer: Tog

Bug reported to Netscape: 1995

Bug reported to Microsoft: 1996

Bug on list since: List inception: 1 Dec 2004

Bug Name: Let's you save me some work

Duration: >12 years

Supplier: Too many people

Alias: "Deal with it, users!"

Product: Many, many websites and a few apps

Bug: Weird formats for standardized data

Class of error: Pure laziness

Principle: It is your job as designer or programmer to reduce the work of the user, not make their life more difficult so you can save some work.

Discussion: Ever come across credit-card input fields that forbid you to enter the number as found on the card? Ever been required to enter an American social security number without its hyphens? You've been bitten by the "Let's you save me some work" bug.

As far back as the 1970s, we had no reason to forcing such unnatural input, even though we were working with computers tens of thousands of time slower. Today, there is just no excuse. If you see such an input, you know there is a lazy person standing—lying down?—behind it.

The worst of it is that we have a mountain of scientific data proving that forcing people to enter and error-check unchunked information causes significant slow-downs and errors, yet these lazy people persist and, worse, their managers let them get away with it. The result is lost productivity and, in the case of electronic commerce, massive lost sales. Why do I say "massive?" Because, while users may slog through to the end to buy an item today, they are going to be repelled at the idea of doing it again.

Proposed Fix: Accept data in all known, unambiguous formats for the data type involved. Do the work on the back end to convert it to the format required by the data model.

Addendum by Kevin Grant: This one's actually equally important when interfacing between applications. Microsoft would say Windows crashed because the user wasn't supposed to enter 10 characters when 9 were requested; UNIX developers know the rule "be liberal in what data you accept, but strictly format any data you emit" (because they use it to tie dozens of small programs together in scripts). By looking at the philosophical differences of both worlds, it isn't hard to see in which world problems are likely to exist!

Bug first observed: 1977

Observer: Tog

Bug reported to suppliers: Over and over

Bug on list since: List inception: 1 Dec 2004

Bug: ecommerce hostility

Reported by: Tog & many others

Duration: Since there was Web

Supplier: ecommerce websites

Products affected: Browsers & Websites

Bug: ecommerce sites are making it as difficult to buy products as humanly possible

Class of error: catastrophic to the bottom line

Principle: Both current and repeat sales are being lost because we harass customers by demanding information that either is known or should be known to our systems

Proposed Fix: Develop a single, standard way for users to easily make purchases:

• Website stopgap:  Make Autofill work on more than just one browser.
  
  
• Website development toolmakers:  Offer standard order form stationery, then call up your competitors and tell them they can copy it for free. You will all benefit.
  
  
• Browser suppliers: Fix your Autofill, so that it exactly conforms to IE, since that’s the only browser most of these guys will test against.
  
  
• W3C:  Come up with safe, secure standards for checkout activity.  The standards should include standardized form blocks, such as Name, address, phone number, along with a standard Autofill specification that everyone will use.
  
  
• ecommerce industry: You're the ones throwing away millions of sales with both hands. Collectively develop a "two-click" order process or some other circumvention of Amazon's patent (it's a trivial undertaking), so people can buy on line the same way they have "in real life" for the past few thousand years. Patent it and licence it for free to browser makers/website toolmakers, as long as the rules are strictly followed. Invite Amazon to join as long as they'll donate One Click.
  
  
• Website long-term:  Once the standards are in place, use them.  If you find yourself on a browser that just won’t conform, tell your user!  About the third time a site informs them they are spending an extra 10 minutes filling out an unnecessary form because their browser won’t conform to an international standard, they’ll switch, particularly if you supply links to modern browsers.

Discussion: Ever since Amazon slipped its unfortunate “one click” patent by the patent office, the rest of the ecommerce industry seems to have become resigned to making their customers’ lives a living hell.

The lack of a single, supported standard for check-out is costing the ecommerce community billions of dollars in lost sales.

You may be feeling pretty good, knowing your log files show that only around 25% of your customers are bailing on your check-out pages.  Don’t.  I spent 15 years in bricks-and-mortar retail, and the instances of customers bailing after the deal is made is vanishingly small (except in the case of high-pressure sales, like automobiles, etc.).

Not only are you leaving a lot of money on the table today, but the customer you harass today is far less likely to return tomorrow. 

Can you imagine how you would react if the bricks-and-mortar stores did to you what you do to your customers?

You go into the supermarket. Every item you're interested in is inside a box. You press the button on the front of the box. It kicks off a 30 second time delay. You open the box. There's a fuzzy picture of the item along with a note that says it's out of stock.

Nonetheless, you finally fill your cart with items that are in stock and go to checkout. You hand over your ATM card, and they hand you a long, three-page form to fill out, similar, yet different than the one you filled out in another four stores down the block earlier today. The same one you filled out in this store last week, and the week before that, and the week before that.

Across the street is another supermarket that has all the food on display, instantly available, and will take your ATM card with a smile, then seems to have the advanced technology known as a computer to gain all the information it needs about you without bothering you with a form.

Where would you be shopping tomorrow?

You may think you're still in good shape because all your competitors have websites that suck, too. Guess again. Your real competition is bricks-and-mortar stores. The web bubble collapsed when Wall Street discovered that's where everyone was going again. Why? Because websites suck. The web experience is a miserable experience, so bad that people will actually leave the comfort of their home and go through the miserable experience of fighting their way through traffic, crowds, and uniformed salespeople just to avoid having to deal with your site.

The abysmal state of ecommerce in particular and web checkout specifically has delayed the promise of the web for more than a decade.

Fix it!

Bug on list since: Jan 2005

Have a comment about this article? Send a message to Tog.

Previous AskTog Columns >