Last update: Thu, Mar 3, 2005



Join my intensive (and fun!) lecture/ workshop course. Sign up now! Interaction Design course: Go from zero to interaction designer in just three days.



You may be coming in cold from engineering or graphic design. You may already be an interaction designer wanting to "fills in the blanks," establishing a more solid theoretical and practical base. I've aimed this course at all of you, covering the needs of both individual contributors and managers.



Join me as I teach the Apple method and show you how to not only organize for and come up with successful designs, but sell them to engineering and upper management.



It's intensive, yes: A one-semester-equivalent with a strong, real-world bias. However, we have a lot of fun along the way, and you'll leave having worked with a team to design and build a complete project, so you will have not only learned, but experienced everything taught. User Experience Conference Website There's more than my course at an NN/g conference. You'll find a breadth of other specialized courses and networking opportunities that will put you and your company at the leading edge of the design curve.

What makes a bug a "design bug"? Coding bugs arise strictly from error in the sequencing of computer commands. Design bugs are born either before coding begins or are former coding errors that became design bugs by either being ignored over time or being carefully documented in the manual. Once a coding bug has been acknowledged or purposefully ignored, it becomes part of the official design. 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: Identical controls used for asymmetrical weapons systems, with insufficient mode feedback. 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: Insufficient usability testing during development. These are not subtle problems and should have been flagged. 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: Company registers an IP address (no URLs anymore) Company registers up to ﬁve 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.

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





Bug Name: "Smart" functions that aren't smart Observer: Tog & many others Duration: Since ~1986 Supplier: Many Alias: Dumb & dumber Product: any "smart" text processor routine Bug: "Smart" functions often make the wrong decisions Class of error: Incomplete design Principle: The "smarter" you make an operation, the more responsibility you have to do it right. Discussion: You expect more from an executive secretary than you do from a clerk-typist. Similarly, users expect more from a "smart" function than a simple one Case in point: drag and drop. Originally, drag and drop wasn't very smart. It's only rule was, "always drag the space after the word with it." This worked fine unless the word was at the end of a sentence, which resulted in the word's leading space left behind, now separating the (new) last word in the sentence from the period. Some cut and pastes still work like this, leading to, at best, frustration and, at worst, error, as people fail to notice the lingering space. Even this cut and paste is not enough. Smart cut and paste should also, for example, recognize that the two words or phrases separated by an "and," "&," "or," vs.," or some other fulcrum are being switched. How? If a phrase before or after a conjunction is moved behind or in front of another word cluster, flip the second word cluster. Then provide an easy undo if the user is intending more extensive editing. Example sentence: "He wore a white tie and black shirt" Dragging "black shirt" to just before "white tie" should flip "white tie" to the other side of the "and." (A future version, with an actual functioning grammar checker could flip "black" and "white" if only "white" were dragged back to "black"'s position.) The worst "feature" of today's smart cut & paste is that computers keep "forgetting" how to do it. In one text field they do it in a sophisticated manner, in a second, they do it in a clumsy manner, and in a third, they don't do it at all. Why? Because today smart cut and paste is left up to the application when it should be embedded in the system, either as an OEM tool or as a system-wide add-on. Until that's done, smart cut and paste will remain dumb. Many other opportunities for smart abound: How about the effort required when you add an opening phrase to an existing sentence? Example: "She will go to the store." You want to prefix it with, "When it stops raining," but when you do, "She" doesn't turn to "she." Even when you type in a lower case "s," you are staring at "sShe," and must forward-delete the old "S." Why is that? Finally, there are many functions we don't even necessarily categorize as "smart" that are smart, or at least ought to be. I'm typing this discussion in Adobe GoLive, once the leading light of HTML editors, but slowly sinking in the sunset of mediocre add-ons. One is their spell-checker. It is dumb in one sense because it is not "live," as spell-checkers are now expected to be. Instead, it requires a special pass. However, worse is that it, unfortunately, doesn't know how to parse standard Englishor at least standard English punctuation. An example is to be found in the previous sentence. GoLive doesn't know what a dash is, so it suggests I probably mean to say, "alongshore," instead of "Englishor." (I guess it could be worse.) GoLive also doesn't know what a smart apostrophe is, so any possessive or contracted word that has been created anywhere but inside GoLive will be flagged as misspelled. In my use, more than 95% of the words it flags as misspelled aren't. Now, that's dumb, so dumb I often fail to do spell checking at all (raising the wrath of my readers) because the odds of my introducing an error by clicking the wrong button and flipping, e. g., "Englishor" to be "alongside," exceeds the chances of my finding and correcting a truly misspelled word. Proposed Fix: Use your own software. Observe experienced users doing the same. Where can you either introduce, augment, or correct "smart" code so that it increases user-efficiency. Bug on list since: Jan 2005

Bug Name: Focus-stealing Reported by: Andrewpants [sic], Wally Hartshorn, and many others Duration: >15 years User response: “Hey, what just happened?” Bug:



Example A: You’re typing a URL into your browser and the application that I clicked on 30 seconds ago finally starts up and interrupts your typing to launch itself.

Example B: You're working on a multitasking system, typing away merrily in window A. Meanwhile, some background task decides it needs your attention, pops up a dialog, and moves the keyboard input focus from the window you were working on to its dialog box. If you're lucky, you'll just momentarily type a few characters that are ignored. If you're unlucky, you'll hit the space bar of the Enter key and select some default command, at which time the dialog box closes, leaving you to wonder what you just did. Class of Error: Lack of “awareness” of the user’s activity Principle: The user is in charge Proposed Fix: The OS needs to report whether the user is interacting with the computer, so that processes know whether it is appropriate to change focus. Focus should never be changed when the user is actively typing. Discussion by Andrewpants: This happens under windows and under the various flavours of *nix that I use. Damn it, the computer is meant to be a tool for me to use and my use (typing stuff in) should be given priority. When the computer interrupts me to tell me something, it is acting (in my opinion) like a child demanding attention. Some fixes for this are available, but it needs to be built into. Discussion by Wally Hartshorn: This has happened to me in several areas, including email notification dialogs. My (least) favorite involves downloading a large file over a dialup connection using Internet Explorer. The download might take 30 minutes, so I tend to work on other things while I wait. When the download has completed, Windows pops up a dialog to show you that it is copying the downloaded file from some temporary area to the location where you wanted it. (Why doesn't it download the file there directly?) It helpfully has a Cancel button available (because after waiting 30 minutes for the download, you might very well not want to wait the 10 seconds it would take to copy the file from one place to another). Keyboard focus has been yanked from what I was doing to this dialog box, where anyone without very quick reflexes can accidentally hit the space bar and select Cancel. How nice. My memory might be incorrect, but I believe that the Commodore Amiga way back in 1985 prohibited any window from taking keyboard input focus away from the user. Discussion by Tog: Focus-stealing was the biggest complaint among the letter-writers, with more than four times the number reporting any other bug. This is at least partly a product of the natural selection for power-users brought about by the posting on Slash Dot. It is worth heeding, however, as power users are both frequent users themselves and more likely to recognize irritants that even naïve users hate just as much, but can only verbalize as "something weird about this software." Beyond the examples given above, look for his bug also within browsers. Try launching Google, then start typing a new URL into the browser’s address box. As soon as Google arrives, the focus will flip to Google, and the second half of your URL will appear in Google’s input field. (The bug is the browser’s, not Google’s. I used Google merely as an example because it loads quickly.) Check out your own software and ensure you are not likewise guilty. Bug first observed: 1980s Bug on list since: Jan 2005

Have a comment about this article? Send a message to Tog. Previous AskTog Columns >

