Reported by: Todd William Hensley

 

Duration: Since the late 1970s

 

Alias: Tunnel Vision 

 

Product: Operating Systems and Applications

 

Bug: Dialog boxes that contain more information than can fit in the window, but give you no way to resize the window and in some cases no way (or a clunky way) to scroll inside the window.  Controls (like drop-down menus) that contain selections that are wider than the menu.

 

Class of Error: Lack of usability testing, laziness.

 

Principle: If it's worth displaying, it's worth letting people actually see it.

 

Proposed Fix:

 

Discussion:

 

This tends to show up whenever Microsoft creates a dialog box that contains a multi-column grid.  You can almost never resize the dialog box itself, so you have to mess around with resizing the columns in the grid and scrolling the grid left and right to see the information you need.  I also see this often in drop-down menus that let you pick server names, database names, or other dynamically generated selections.  The right-most characters get truncated.  Of course, this usually this happens when the selections all begin with the same characters (as server names often do: CorpServer01, CorpServer02, etc).

 

Bug first observed: I've blocked it out.

 

Bug reported to Supplier: Why bother?

 

Bug on list since: Jan 2005

 

Bug Name: File Handling Made Unnecessarily Complex

 

Reported by: Dmitri Zdorov

 

Duration: since memory can hold more than temp data

 

Supplier: all software and OS makers

 

Alias: Let's rearrange some data

 

Product: All computers

 

Bug: Data written in files

 

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

 

Principle: Avoid unnecessary operations

 

Proposed Fix: redesign the way data is stored

 

Discussion: When programs start to work with data, they read a file, then store it in the memory in a different way. It takes time to load and save files. However when a computer is out of memory, data is pushed to a swap file, and retrieving it from there is a lot faster. It makes sense to store data in the same format as a paging file or memory. When the OS has to be loaded, it should be just read from memory or disk. Only parts that are needed at the moment are read, all other once are just ready. In some cases, data still can be compressed (like NTFS file compression) to reduce the amount of used space. It will give tremendous burst in speed and reliability.

 

Bug first observed: April 1985

 

Bug reported to Supplier: I tried to push this idea to many software developers but they gave me "every one is doing that the standard way.." answer.

 

Bug on list since: Jan 2005

 

Bug Name: Double Clicking

 

Reported by: Marko Macek

 

Duration: since 1980

 

Products: All GUIs

 

Bug: example: clicking fast on file launches it, clicking slowly activates rename

 

Class of Error: user action timing

 

   Principle: don't penalize too slow or too fast users

 

Proposed Fix: example: see OS/2 -> uses Alt+left click for rename.

 

Discussion by Tog: Double-click was added to the Apple Lisa computer in 1980 to overcome a small problem: The computer had only a single button.  The single-button was a defensible decision in 1980.  It was no longer defensible after around 1985, but, at least on Macs, the decision has persisted, much to the detriment of Mac users.

 

Meanwhile, Microsoft was engaged in wholesale copying of the Mac interface.  People at Microsoft did understand that a multi-button mouse was superior, but failed to understand why double-clicking was there in the first place, so they slavishly duplicated it.

 

Because users often have to “activate” a window before they can double-click, they often have to triple click or even quadruple-click (in the case of MS Word) to accomplish their task.

 

Because one can’t tell whether a window will require activation, users often click more than they need.  This not only leads to confusion, but often results in injury, as sustained multiple clicking can lead to repetitive stress injury, etc.

 

Perhaps all this unnecessary clicking will stop when some lawyer files a class-action suit.  Perhaps software houses will reexamine their 25 year old decisions.

 

Bug first observed: 1980

 

Bug reported to suppliers: over and over again

 

Bug on list since: Jan 2005

 

Bugs: Harassing Confirmations & Missing Confirmations

 

Here’s a pair of bugs, both of which show a lack of understanding of how to compute the cost/benefit of confirmation dialogs.  Following the two bugs, I present guidelines for performing such an analysis.

Bug Name: Harassing Confirmation

 

Reported by: Poet, dapalmer

 

Duration: [in years] Not too sure, every Microsoft Operating System I've used since 95 ( the first one I used ).

 

Supplier: Microsoft

 

Alias: "We think you're an idiot."

 

Product: Most

 

Bug: Being presented continuously with "Are you sure?" pop up quizzes.

 

Class of Error: "Stupid people are in the majority therefore we must treat all people as stupid!"

 

   Principle: Users want speed and responsiveness from their PC's and    should be allowed the option to turn off Nannying if they so desire.

 

Proposed Fix:

 

1. (Poet) Include a, "I've been using your products for long enough now that I know what I'm doing, in spite of your moving everything into different menus with each release to make them appear new," button.
   
   
2. (Tog)
   1. Fix undo if it is the cause of the dialog’s existence.
   2. Remove other unnecessary confirmation dialogs. 
   3. Add a “Don’t show this again” checkbox to most that remain.

                                                           i.      One exception is the exception confirmation: a dialog that comes up when conditions are not that which the user normally expects.

                                                          ii.      Another is when test subjects have demonstrated a lack of understanding of state such that they may lose data without being aware that it has happened.  (HCI designers are trained to detect this condition, one of the reasons successful companies hire them.)

 

Discussion by Poet: Ever since I began using Windows operating systems ( back in about 1995 ) it became quite quickly apparent that I was being regarded as an idiot who could not be trusted with his own equipment.

 

Yes, maybe the first couple of times I pressed "delete" on a file, it might have been a good idea to check whether I really wanted to delete that file or not, you know, just in case I mistook the word delete for the word Print or something. But after having emptied my Recycle Bin a few thousand times, perhaps, just perhaps, I might not want to be asked if I'm sure. I might be well aware of the consequences of my own actions and be perfectly happy at not being endlessly questioned by my own PC.

 

And from what I understand of some of the software security features being planned for Longhorn, Microsoft’s next OS, I can foresee a near future with pop-up boxes asking "Would you like to ask Bill's permission to install this software?"  "Are you sure?"

 

You get the point.

 

Not once have Microsoft anywhere offered an option to turn of this persistent nannying, it's there to stay as far as they see it, an essential part of there operating system to protect the planet's idiots from themselves. But for me its an insult, I'm only a part time idiot, and do quite well the rest of the time, and I want to disable those nags!

 

Discussion by dapalmer: You are repeating some operation 47 times.  You click on a delete button and a pop-up appears all the way across the screen asking you to confirm.  You have to move the mouse all the way across to the OK box to click it.  Why don't they (a) forget the stupid confirm boxes or (b) pop it under your mouse so you don't have to travel all over to find it.

 

Discussion by Tog: Confirmation dialogs was another “feature” carefully copied by Microsoft from Apple.  The Star and Lisa machines that preceded the Mac had such dialogs because they were being introduced to a new class of user: volunteers who were not computer-savvy.  Before that, computers and peripheral equipment were used exclusively by technogeeks and minimum-wage laborers.

 

Even by the time the Mac was introduced, many people had already gotten used to unfriendly technology and were building an understanding of where the minefields lay.  Certainly, by the time Windows was a marketable product, such overprotection was being felt as harassment, rather than tender support.

 

Many, if not most, such dialogs that persist today do so because it is easier for the programmer to say, “hey, are you sure you want us to destroy all your work?” than it is to save a copy for an Undo feature, so they’re prepared to restore things if the user made an error.

 

The exception to turning off all “nannying” is the unusual outcome.  If users can be expected to do something 95% of the time and something else 5% of the time, and that 5% can result in data destruction, it’s a really good idea to throw up a confirmation dialog for the 5% only.  It alerts the users that they did something different.  If it was on purpose, all they have to do is press return.  If they didn’t do it on purpose, they’ve got a chance to back out.  (Never make them do more than press Return in this case.  The dialog box itself, with the extra key press required, gets the point across.  They shouldn’t have to also navigate to a non-default option to get the job done.  That’s harassment.)

 

The point here is that you are purposely blocking motor memory from working, so that the user will notice.  If you throw up a dialog each and every time—like Canon’s photo applications that ask if you’re sure you want to exit the application now, after you just told it you did—users will just develop the motor memory to always hit an extra Return as they exit, negating all benefit of a confirmation dialog.

 

I’ve been happy to see a number of applications recently begin to include “Don’t show this again” checkboxes in these kinds of dialogs.  I hope that feature will flourish.

 

Bug first observed: 1980

 

Bug on list since: Jan 2005

 

Bug Name: Missing Confirmations

 

Reported by: Gordon Free

 

Duration: 20+ years

 

Supplier: Many

 

Alias: “As You Wish”

 

Product: Many many applications

 

Bug: Canceling lengthy operations is too easy.

 

You begin a lengthy operation.  Perhaps copying numerous files, or generating a video – anything that could take many minutes (or even hours) to complete.  As good design requires, the application provides a way to cancel the operation – usually by means of a cancel button.  Often, this button even has the input focus(!).  But they rarely ask if you really meant to cancel, so an accidental key press or mouse click can easily undo hours of work.

 

Class of Error: laziness

 

Principle: If it would take a long time for the user to recreate an operation, provide a way for the user to undo any actions (this includes confirming cancellation requests).

 

Proposed Fix: If the user wants to cancel (a non-trivial) operation, confirm that they really want to do that.  Oh, and when you ask for confirmation – don’t make the default choice be “Yes”!

 

Discussion: A timeout operation for the confirmation would be useful as well.  If no response from the user after a certain period, assume the cancel was unintended.

 

            The program is now performing a lengthy operation....

 

            [ CANCEL ]

 

            Are you sure you want to cancel this operation?  Any work done up to this point will be lost.             (Operation will automatically resume in X seconds...)

 

            [ No. Resume ]              [Yes, I want to cancel ]

 

Discussion by Tog: I changed Gordon’s above example to include the wordy buttons.  He had suggested a simple No/Yes.  When you are asking a question like this, which is inherently ambiguous, I prefer to err on the side of wordiness.  Habitual users will  only read the first word, so it slows no one down.

 

Bug first observed: Early 80’s

 

Bug reported to Supplier: 11/29/04

 

Bug on list since: Jan 2005

 

Bug Name: Cost/Benefit Calculation of Confirmation Dialogs

 

In choosing whether to supply a confirmation question, consider the cost of error.  If 10 seconds of a two-hour download have gone by, no confirmation is necessary (as long as the user is not left thinking the download is continuing). If one hour of a two-hour download has gone by, a confirmation is a good thing, although the ideal solution is to be able to pick up on the download where the user left off (a solution that is finally becoming widely available).

Another example is program-Exiting.  It may take more than a minute for the user to bring a program back up that they Exit accidentally, but it only takes five seconds to answer a secondary confirmation.  Does this indicate that you should be supplying a confirmation?  No.

To figure out return-on-time, compute not only how much time is required to recover with and without confirmation, but how often error will occur.  In the case of applications, my own experience is that I accidentally Exit an application perhaps once for every 1000 times I purposely Exit it.  In my observations of users over the years, I’ve never actually witnessed someone accidentally Exit an application, so 1:1000 is probably a fair assessment.  Plugging that value in we get:

 

60 seconds for the one Exit that would have been in error vs. 1000 confirmed Exits at 5 seconds each, or 5000 seconds. 

 

That means the user would spend, cumulatively, almost an hour and a half to save a single minute of reboot, if exit confirmation were required.  Add on top of that the very real possibility of defenestration by the user, which almost always results in data-loss, and requiring confirmation for program-exit begins to look downright foolish.

 

Data-loss is another matter, one much more difficult to quantify.  Often, re-writing the same long passage can take a fraction of the time and may even result in a better, tighter version.  On the other hand, a short passage may contain quotes and data from 10 different books or web pages, all now put away, and may take an extended period of time to reconstruct.  Therefore, with the rarest of exceptions, you should always require confirmation when the user is about to blow away his or her own work.

 

Of course, with Continuous Save, that brand-new concept from the 1970s, even this measure is not necessary.

 

The one exception users hate is when a document is completely empty and the stupid application wants to know whether the user wants to save it.  I gave her a call.  She doesn’t want to save it.  Just close and go away.  (It’s amazing how many applications still do this one.  Usually, they’re smart enough to close it if nothing was ever entered, but once the “dirty flag” is set, they demand confirmation, having never noted that the user later on deleted everything she’d done.)

 

Bugs: Time

Bug Name: Ridiculously long launch times

 

Reported by: Rob Wolsey

 

Duration: [in years]: Since the launch of Photoshop 5

 

Supplier: Adobe, Microsoft

 

Alias: Go downtown for coffee while we open this PDF file.

 

Product: Photoshop, Acrobat, Internet Explorer, Windows XP, et. al.

 

 Bug: Despite the ever-increasing speed of computers, the most commonly used apps take longer to launch with every new version.

 

Class of Error: Keep "improving" software that is already fine, so that you can sell it again.

 

Principle: If you insist on adding new features when none are needed, do it without forcing the 99.9% of users who will never use those new features to suffer through longer load times.

 

Discussion: My 66Mhz Pentium PC running Windows 98 boots up in a third of the time my P4 running XP does. When I click on a link for a PDF in IE4/Acrobat 3, the PDF file opens in the browser after a brief flash of the Acrobat splash screen. In IE6/Acrobat5, I first must wait through 15 seconds of nothing happening, followed by Acrobat launching and running through its extended startup. When I launch Photoshop 7, I am treated to an introduction to the entire programming team and their families, and a parade of hundreds of plug-ins I have never used. Who uses that "solarize" plug-in?

 

Rather than bloating these programs further with each new version, how about finding a way to make the existing versions faster and more stable? If most users will not be using a new feature, then that new feature should not be allowed to negatively impact performance of the software.

 

In the case of IE, Photoshop, Acrobat, and even XP, users should be allowed to select a quick-launching, stripped-down version. Ninety percent of users will never need to use the full versions.

 

Bug on list since: Jan 2005

 

Bug Name: Broken Time Indicators

 

Reported by: Mark Green

 

Duration: Since the mid-1990s

 

Alias: Frozen in Time

 

Supplier: Lots and lots of folks

 

Bug: Progress bars don't rise at a constant rate over time, or are seemingly lock at 100% (when further activity should have already resumed)

 

Class of Error: "If We Use User Friendly Widgets, That Must Make Us User Friendly"

 

Principle: The user should be informed as to how long a particular wait should be.

 

Discussion:

 

Most of the original progress bars that I remember did indeed rise at a constant rate over time.  Then, however, coders got lazy and started sprinkling their code with occasional "update progress bar" commands based on how far through the series of instructions the program had gotten, with no regard for how long each of those instructions might take to execute.  Unfortunately, in practice this is no use at all to any user who doesn't know the structure of the program and of the progress bar update calls.

 

Note from Tog: I recently had an application reach 100% after less than 5 minutes, then remain locked on 100% for more than five additional hours.  There was nothing wrong with the operation of the program: That’s how long the very last operation took with a really big file. (Well, it was perhaps not the most brilliant algorithm.)  The first three times, I rebooted the system after five to fifteen minutes, assuming the program had died.  The last time, I started the process, then forgot about it.  Five hours later, I noticed it was done. Nasty.

 

Proposed Fix:

 

Actually perform a time estimate of the task before starting, and use this to display the progress bar, rather than program milestones.  For the 100% problem, time for the OS and any underlying code must also be factored into the time estimate, estimating the time that will be taken to remove the progress bar from the screen, display any results, and perform any needed virtual memory management.

 

Bug on list since: Jan 2005

 

Bug Name: Instant Feedback lacking

 

Reported by: Brendan O'Brien, Dave Yost

 

Duration: 30 years

 

Supplier: Microsoft, Apple (lately), others

 

User response: "Hello. Hello. Can you hear me?"

 

Product: Nearly all of them

 

Bug: Not providing immediate feedback that some action the user is attempting to perform has begun

 

Class of Error: performance unbecoming a personal computer

 

Principle: All user actions must be acknowledged in less than one tenth of a second.  No exceptions.

 

Proposed Fix: Acknowledge all user actions within 1/10 of a second

 

Discussion by Brendan: When I began programming Macintosh's (1991) one of the cardinal rules was to provide feedback to the user first, then perform the action. This mantra has become lost along the way at Apple and has never been true at Microsoft. Worst, all the "new" GUIs fail to handle this, too (think KDE, Gnome, etc.). This is unforgivable, as it isn't even a difficult problem to solve. Part of the problem is that the frameworks people are using to build applications (VB, Swing, QT, etc.) don't have this built in as a fundamental characteristic and it can be difficult for users of these frameworks to force the correct behavior behind the frameworks’s back.

 

Discussion by Dave: OS process scheduling has traditionally tried to be sort of fair to all processes with no serious commitment to the VIP wielding the mouse.  That might be OK for time share systems of yore or for servers, but it’s not OK for a personal computer.

 

Every user input event should result in immediate visual feedback.  If any resultant processing takes more than, say, 200ms, this fact should be visibly clear in a standard way that gives you something to click to bring up a Pause/Resume/Cancel dialog.  An asynchronous progress indicator right next to the button you clicked could be the clickable object.  

 

This will not be so easy (but it will be worth it).  What will have to be done?  Rethink process scheduling, thread scheduling, event handling, application architecture, demand paging, and UI toolkits, from scratch with the goal in mind.  We’ll need a real time OS, preemptively-scheduled disk I/O, a separate event stream for user input, a separate application code segment for UI feedback, locked-down pages for UI feedback code, and high, preemptive priority for UI feedback code.

 

Discussion by Tog: The studies that established necessary response times were completed before the first commercial ever GUI appeared.  No excuse exists for violating this rule.  It reflects incompetent design or implementation, as well as incompetent quality assurance.  It reflects badly on an entire engineering organization.

 

Bug on list since: Jan 2005

Bug Name: Context sensitive menus fail to include "universal" options

 

Reported by: CHS

 

Duration: ever since IE came out.

 

Supplier: Came from MS, now all modern browsers are guilty.

 

Alias: "no back button for you!!" (say it with the soup nazi voice)

 

Product: IE, firefox, mozilla, netscape, etc.

 

Bug: in the old days of netscape, you used to be able to click on the web page you were viewing ANYWHERE, and get a nice menu with a selection of things you can do. the single most useful of these was "back". the web is a very visual medium for disseminating information, and the computer mouse is the interface of choice for working with this medium. people click links, and navigate the web very easily and fast with the mouse button. sometime around the release of IE however, someone decided that it would be a great idea to introduce "context sensitive menus" so that if you clicked on an image, you only got a menu with options relating to images. no "back" button, or any other extremely useful universal options. now, if you're using your mouse to navigate webpages you need to make sure you either go offpage up to the button bar and click on the "back" button (or forward, or reload, etc), or you have to make sure your mouse pointer is no hovering over a link, an image, a sound bite, etc.

 

Class of Error: Too literal: just because it is “context-sensitive” doesn’t mean it can’t also have general items

 

        Principle: The most important consistency is consistency with user expectaions

 

 Proposed Fix: include such "universal" options like 'back', 'forward', 'print', etc at the top or bottom of ANY browser context sensitive menu. if I am in a web browser and I want to go back, I shouldn't have to make sure my pointer is sitting on whitespace.

 

Discussion by Tog: Although CHS supplied this as a browser bug, it is far more universal.  I suspect it arises from lack of feedback: The developer makes an educated guess at what users would like, then fails to provide a mechanism for users to either modify the menu or feed back to the developer what options they would really like.

 

Bug on list since: Jan 2005

 

Bug Name: Non-resizable text boxes

 

Reported by: Scott Ba

 

[Sorry, the last name is "Bayes"; the previous text field was too short to display it.]

 

Duration: > 25 years

 

Supplier: Windows & Web Pages, occasionally OS X

 

User’s response: “I need my space, man!”

 

Product: any non-resizable dialog box containing long text lines, especially lists (e.g. filename lists)

 

Bug: you can't see the end of the line and you can't resize the box!  Sometimes there's a scroll bar—what a pain—other times not. Anyway, why should I need to scroll, just let me resize? Sometimes hovering will reveal a tool-tip (weak at best); other cases, it won't. Given that information like file path often occupies the whole visible area, but then the critical info like file name is at the end that you can’t see, this can turn simple "use this file" exercises into File Name Russian Roulette. Especially on Windows, where There Are No Second Chances (TANSC).

 

Class of Error: What was the designer thinking? Not about the Use Model, fershure.

 

Principle: pixels are cheap; use 'em

 

Proposed Fix: allow me to resize the dialog (and you be sure to resize the list when I resize the dialog!)

 

Discussion: the designers need to eat their own fog food before unleashing this on us poor puppies.

 

Bug first observed: Way back, Sherman, way back.

 

Bug reported to Supplier: never. Do you think they'd listen?

 

Bug on list since: Jan 2005

 

Bug Name: Needless Interruptions

 

Reported by: Daniel Boulet, Tim Sawlor

 

Duration: >25 years

 

Supplier: Microsoft is the guiltiest, but everybody

 

Alias: “Who Cares What You Want to Do?”

 

Products: Internet Explorer, et all

 

Bug: System needlessly interrupts you with a message box or undoes something you're trying to do because it thinks it has something tell you that's more important than what you want to do.

 

Class of Error: "You're not in charge; we are"

 

 Principle: Do not needlessly interrupt the user's train of thought about things that don't affect what he/she is currently trying to accomplish.

 

Proposed Fix (Boulet): If an application needs to get the user's attention then the application should attempt to get the user's attention in a manner which is proportional to the seriousness of the issue. An easy to use mechanism must be provided to allow the user to indicate the relative seriousness of potential issues.

For example, unless immediate attention is absolutely required (as opposed to "nice to have") then status areas, icon appearance changes and flashing lights (as a last resort) should be used to indicate that the user's input is needed.

 

Finally, every even remotely spontaneous popup window should include a way for the user to indicate what should happen the next time the event which triggered the window appears (e.g. "don't show this event in the future", "put this message in the status bar", etc).  The corollary is, of course, that it must also be easy for the user to indicate what should happen when "status bar messages" and the like appear.

 

Proposed Fix (Sawlor): On Mac OS X, Apple's current model of having the dock icon jump up and down to alert you that something is happening somewhere else is a MUCH better way.

 

Discussion (Sawlor): This occurs many places, Internet Explorer being my personal whipping boy. You typed in a URL, then decided that you don't really want to go there after all, so you start to type in another one. Well, the page finishes loading and assumes that you really would like the URL of the page you visited in the URL bar.

 

Another example: you're typing away happily, only to look up and realize that the last 200 characters you typed didn't go to where you wanted them to because another background application decided that it REALLY had something IMPORTANT to tell you, so it threw up a message box in front of your app.

 

 Bug first observed: >10 years

 

Bug on list since: Jan 2005

 

Bug Name: Applications won’t let go

 

Reported by: Max Bronsema

 

Duration: >20 years

 

Suppliers: Mac OS, Windows

 

Alias: Trashophobia

 

User response: “Can not delete? What do you mean I can't delete?

 

Products: OS-X and Windows

 

Bug: After you close a program and then try to delete a document on the desktop or in a folder, you are told that the file is “in use” by an unnamed program and you can not delete it.

 

Class of Error: Why fix a known, pernicious design bug when there are so many neat, cool things to implement?

 

Principle 1: Error messages should notify that something went wrong, supply full information about the problem, then go on to tell the user what to do about it.

 

Principle 2: Forget principle one!  Supply no error message when the original problem is a bug!  Instead, fix the original problem!

 

Proposed Fix: Root out what in the system is allowing these kinds of errors to occur, and fix it.

 

Discussion by Tog: This problem should have been addressed years ago.  There’s no excuse for applications to “put dibs” on documents that are not even open, preventing the OS from handling them.  Microsoft is particularly guilty of this—Office on the Mac displayed this behavior years before anyone else–but other suppliers have caught up.  Its’s time for everyone to review their code and stamp out these errors. 

It’s also time for the OSs to give usable dialogs when developers have failed to do what’s right.  These dialogs should announce the name of the offending application, along with how to drive a stake through its heart.

 

OSs should also give users a way to override, with proper warnings and at their own risk, when applications just won’t let go.  They should also provide feedback to the developer when the error arises.  A pre-recorded phone message to the home phone number of the idiot in charge should prove effective.

 

Bug first observed: 1980s

 

Bug on list since: Jan 2005

 

Bug Name: Failure to “sniff” keyboard

 

Reported by: Dale Crawford

 

Duration: >20 years

 

Supplier: Apple, Microsoft, Sun, Linux, and their developers, et. al.

 

Alias: “Talk to the Hand—I’m Busy!”

 

Product: All GUIs and many applications

 

Bug: Computer ignores user input such as “Cancel,” “Abort,” or the Esc key because it’s so busy in some subroutine that it has no time to evaluate user input.

 

 Class of Error: The task of processing the user’s data is treated as more imperative than responding to the user’s desperate pleas of “Oh no! I didn’t mean to press that button!” or “Oops, I meant to do one other thing.”

 

Principle 1: User efficiency is more important than machine efficiency

 

Principle 2: User comfort is more important than machine efficiency

 

Proposed Fix (by Tog): Check for user input at least once per second, even at the expense of overall efficiency. If the user indicates he or she wants to cancel, back out gracefully, leaving no harm.  In some cases, this may mean you revert to the original state.  In others, it means that you stop the process where it is, prepared to take up from there and reach a therefore speedier completion.  In still others, you should ask the user what to do now.  In any case, do whatever is in the user’s best interest, not the easiest to code.

 

Discussion: No matter what an application or OS is doing, its highest priority must be to accept user input and take immediate action on that input. All routines must have built-in escape hatches that allow them to fail gracefully if it becomes more important to a user to halt an operation than to allow it to complete.

 

I cannot count the number of times I’ve started a print job, saved a large file, fired off some massively long batch process, or ran a Photoshop filter, only to realize that I needed to make some additional change or worse, stop the computer from writing bad data in place of the only “good” version of a file on disk.

 

 In the Apple II and DOS days, you could essentially always interrupt any program. Sometimes you’d kill the program in the process, but you could stop it when you had to. Not so today. Every GUI treats its own routines as more important than user input. In a multi-threaded OS, there’s no excuse for treating user input as a secondary function. The mouse pointer is interrupt-driven, and it almost never fails to move when you move your mouse. It should be natural to apply this same priority to every UI element and key press that is designed to halt an operation in progress.

 

Discussion by Tog: The OSs should permit us to kill launching applications. I don’t know how often I’ve accidentally launched some bloatware, like Word or Photoshop, then had to wait the twenty or thirty minutes it feels like they take to load, just so I could exit them and open the app I actually wanted.

Of course, with today’s true multi-tasking OSs, applications should not be allowed to take over the entire system during boot-up anyway, which would permit us to start opening what we really had wanted right away.

 

Bug first observed: 1980

 

Bug reported to Supplier: 1984

 

Bug on list since: Jan 2005

 

Bug Name: No memory of previous user input

 

Reported by: Steve Keppel-Jones

 

Duration: [in years] >25

 

Supplier: Most high-tech software related firms

 

Alias: “No, I Can't Remember That For You”

 

Product: Many GUI and text applications and OS support code

 

Bug: System does not retain previous user input to provide starting point of subsequent selections

 

Class of Error: Laziness

 

Principle: Software should make the user's work easier

 

Proposed Fix: For any user interaction such as a dialog box, remember all previous fields and settings as defaults for the next similar interaction, whether during a run of an application or even (how complicated!) from one run to the next.  This might involve, perhaps, a file on disk, or some equally novel form of persistent storage.

 

Discussion: This is so easy to fix, and so annoying when not implemented, it is almost unthinkable that it persists after decades.  Not, of course, that programmers don't want to be lazy (they do), but that managers and QA teams let them get away with it.

 

A classic example from Mac OS-X is the file browsing dialog window, used by almost every single application to select files.  Can it remember from one instance to the next what directory I was in?  No.  Is this a strong disincentive to use carefully organized and relatively deep file storage hierarchies?  Yes.

 

Mozilla  et. al. offer to remember form field values whenever submitting an HTML form.  This is certainly a step in the right direction.  It is, however, the exception rather than the rule.

 

For certain types of fields, such as passwords, bank account numbers, social security numbers, etc., it may not be desirable to automatically remember values.  But for everything else it most certainly is!  If I export an image in JPEG format, please remember that, because I'll probably be exporting the next image in the same format!  If I print in black-and-white as landscape, remember that too, because odds are I'll print the same way next time too!

 

Bug on list since: Jan 2005

 

Bug Name: “Please wait” messages

 

Reported by: Steve Loudermilk

 

Duration: At least since 1980

 

Supplier: I'm most familiar with it in boot messages for UNIX systems.  But I've seen it everywhere in the computer world. 

 

Alias: "System is coming up.  Please wait". 

 

Product: 

 

Bug: The computer, which can do billions of operations a second, tells a human being, who has a life, to just "wait".  This should never happen. 

 

Class of Error: Non-descriptive wait messages

 

Principle: Thou shalt not bore thy user

 

Proposed Fix: Display something descriptive and informative for the user to read. 

 

Discussion: Why should we wait?  This is commonly used when programmers get lazy and don't want to tell the user what's happening.  If it's worth displaying anything on a video screen for a human to read, it should be informative.  There are lots of ways to summarize what a computer may be doing during an interval when it's not ready for the user quite yet.  "Checking the file system consistency", "Creating device files", "loading the kernel", "configuring the network interface",  "searching for data", etc. 

 

Even if you just display something like "Booting the operating system . . ." it would be better.  Just leave out the "Please wait" part for heaven's sake.  We want to develop confidence among users that computers are always doing a million useful things for us at any given moment; that they are much faster and more accurate than we are.  Otherwise, what's the point?

 

Discussion by Tog: I agree with everything Steve said except the, “leave out the Ôplease wait’ part.  I’m in favor of a touch of genteel politeness, and we do, after all, expect them to wait.

Some might be surprised to learn, however, that not only do I accept the idea of having flashing updates, such as “loading the kernel,” I actually embrace it.  First, it keeps the user engaged, and an engaged user is a happy user.  Second, it informs.  Yes, I’m aware that the only kernel most people are aware off is armed with eleven herbs and spices, but that’s because no one has ever introduced them to the UNIX/LINUX kernel.

In ancient times, before there was disk, we all used tape cassettes to store our applications. We could literally hear them as they loaded into the computer over a period of one to three minutes.  (Thank heavens today’s hard disks are a million times faster so that, for example, Excel can load in only a few microseconds.) One might assume the sound of a loading program would be indistinguishable from random noise, but that proved not the case.  Every application and every image had a unique signature.  After a while, we could tell if we’d started the wrong program just by the sound of its code.

 

Today, few modem users understand handshaking protocols, but they do become used to a familiar pattern of clicks and screeches indicating normal vs. abnormal connections.

 

If regular folk can come to “understand” on some level the sound of high-speed binary code, do you think they cannot absorb some lessons from being subjected to new terminology like “kernel,” etc.?  Such terms so often come to be useful, as when some system software programmer spits out some horrifying message like, “fatal execution of kernel.”  At least they won’t fear their supply of fried chicken is about to be cut off.

 

Entertain them.  Teach them a little something, even if it seems “way over their heads.”  At the very least, it will keep them awake and alert.

 

Bug first observed: 1984

 

Bug on list since: Jan 2005

 

Bug Name: Cryptic Icons

 

Reported by: Michael Woodhams

 

Duration: 15+ years

 

Suppliers: Myriad

 

Alias: "Let's play a game - can you guess what this means?"

 

Product: Eudora mail reader, Atria/Rational/IBM ClearCase revision control system.

 

Bug examples:

 

Eudora: The 'check mail' icon has a picture of an envelope and a "check" mark.

 

ClearCase: The 'check in' icon has a picture of a document, an arrow (in a direction arbitrarily ordained to be 'in') and a "check" mark.

 

Notice the use of the "check" mark to imply the English word "check". Not only is this going to be completely opaque to every non-English speaker, it is very murky to about half of the world's English speaking population also. "Check" is the American name for this mark, in British (and Australian, New Zealand...) English it is a "tick" mark. It took me two years before I realized why it was on Eudora's "check mail" button.

 

Class of Bug: “You had to be there” to get it

 

Principle: A word is worth a thousand pictures

 

Discussion: Icons are supposed to transcend language barriers - not to limit themselves to one dialect. A related bug are the highly stylized icons found on Swedish home appliances: circles, crosses, dotted arcs etc. These are quite incomprehensible without a manual, which likely has been lost. If they just wrote Swedish words, at least I can find a Swedish/English dictionary in my local library. Bug first observed: c1987, "Eudora" mail reader, c2000, Rational (now IBM) ClearCase.

 

Discussion by Tog: The larger problem is that icons are failing to communicate.  The above-mentioned principle was coined by the Apple Human Interface Team in 1985, when we determined that, with more than 100 icons then appearing on the Mac, people weren’t “getting it.”  They all were beginning to look a lot alike.

Twenty years later, things are worse, not better.  We now have thousands of icons, with many developers assuming that people need only glance at their particular set and will immediately know what to do.  They won’t.

 

If you need icons, have your graphic designer make up several sets on 3 inch by 5 inch cards (metric is also OK).  Then, show them to a series of users, asking them to identify what each icon means.

Likely, you will fail to find any set of icons that is immediately recognizable.  (That’s why iconic writing died out some time ago.)  However, don’t despair.  Wait two weeks and go back to the same individuals, asking them to identify the meaning of the icons again.  Your goal should be to at least assemble a set of icons that are memorable.

After all this, provide Tooltips, so the rest of us can figure out what you had in mind.  If they’re at least memorable, we won’t have to ask a second time.

 

Try to avoid the kind of “cutsey” plays on words of which Michael complains—icons, after all, aren’t words—and ensure that you don’t have pairs of icons that look almost alike, something that happens far too often.

 

Bug reported to Supplier: Reported to Rational c2000. They told me where I could find the bitmap file for the icon so I could edit it myself.

 

Bug on list since: Jan 2005

 

Bug Name: Mouse-required interface

 

Reported by: Scott Yates

 

Duration: 25 years

 

Alias: "I cant be bothered to test my application without a mouse"

 

Product: almost ALL

 

Bug: Application will not allow you to select buttons or navigate it purely with the keyboard.

 

Class of Error: Law-breaker

 

Principle: All users, including the differently-abled and the differently-minded, should be able to use the product or service

 

Proposed Fix: Develop a keyboard only interface that overlays the special, mouse-based interface.

 

Fix additions by Tog: Develop the mouse interface first, then add the keyboard interface on top of it.  A smooth spacial interface is far more difficult to achieve and may be impossible to make happen when the simpler, more abstract keyboard interface has already been fleshed out.

Test the keyboard interface using test subjects and a stopwatch.  Keyboard interfaces are subjectively much faster than mouse interfaces because of the intense cognitive engagement.  If the stopwatch proves the keyboard slower after your best efforts, warn users not to learn it unless they are unable to use the mouse.  Never depend on your own subjective “sense” of which is faster.

 

Discussion: Paint apps and the like are to some degree exempt, but most apps just should NOT require moving your hand from the keyboard to a mouse to select something or navigate.

 

Discussion by Tog: In general, people should be free to use the interface they want, even if it’s not the best.  The exception is high-productivity software developed for a client who is not the user.  If your client’s employees are expected to accomplish the most work in the least amount of time, you should may want to lock out options proven to slow them down, whether it be mouse or keyboard, with an override possible in case of injury, etc.

 

Bug first observed: 1980

 

Bug on list since: Jan 2005

 

Bug Name: Error messages w/o useful info

 

Reported by: Mike Homyack, Donald Varona, Bill Oehler

 

Duration: Since time immemorial, as far as I can tell

 

Supplier: Virtually every application I’ve ever used

 

Alias: Congratulations, you’re screwed

 

Product: Name one, it’s probably in there

 

Bug: I regularly come up against situations where a piece of software will tell me that something has gone wrong, but it won’t tell me in what way, or what might be done to remedy the situation.  These errors often appear when applications are doing things like trying to load internally maintained .ini file type data, or when they’re attempting to load up some sort of 3rd party extension—usually a file that the user has not personally instructed the application to load. 

I had an example of this issue just this morning with an Adobe Acrobat plugin and MS Word... Word kept popping open a message box that said “Compile Error in Hidden Module: AutoExec” That’s it!  No more info whatsoever.  It turns out that this was caused by some sort of issue with the PDFMaker plugin that Adobe uses to turn a Word document into a PDF, but there was no indication on either Word or Adobe’s part that this had anything whatsoever to do with the Adobe Plugin.  I had to seek out a MS tech bulletin on the error, which led me to temporarily removing the offending plugin from the Word Startup folder, which led me to running a diagnostic utility built into Acrobat, which pondered for a while then changed something and magically (to Adobe’s credit) fixed the problem. 

Unfortunately, this is the sort of thing that is commonplace in software—error messages that a programmer might find useful, but which are decidedly useless to an end-user finding their way onto the screen in a released product.

 

Class of Error: Laziness, I think

 

Principle: If you’re going to tell me that something is wrong, tell me enough about what’s wrong that I might have a prayer of remedying the situation.

 

Proposed Fix from Tog: Messages need to be clear and to the point, and to offer solutions, not just present the problem.  They must include all the information the user needs to be able to take appropriate action.  Designers and engineers should look upon the inclusion of an error message as a personal failure, reworking designs to avoid them wherever possible.  Messages should be composed by professional writers only.

 

Proposed Fix from Donald: Build an OS-level messaging subsystem that provides as much error context as is available.  This subsystem would be accessed when the error is detected, and the text message would be generated with as much context as possible for eyeball consumption, with additional detail provided to the caller.  Barring the availability of said subsystem, programmers should adopt a flexible error data library of their own that they use consistently for reporting problems.

 

Discussion by Mike: Error messages need to include some context.  Even a message that said “There was an error while loading the plugin PDFMaker.dot” would have been 1000% more useful than the one I got.  Better yet, how about requiring plugins like that to come with a manifest that might contain a proper name for the maker of the plugin and some contact info that you might use to ask them what the hell is wrong - something that the application could pop up for you when a particular plugin fails to load, perhaps?

 

Bug first observed: Probably within hours of getting my first PC... call it February of 1980.

 

Bug reported to Supplier:  Riiiight... like they care about that sort of thing...

 

Bug on list since: Jan 2005

 

Bug Name: Pluralisation (or pluralization if you are en_US.)

 

Reported by: A Hedges

 

Duration: Since the 1970s

 

Bug: Messages displayed like this:

 

"You have 1 emails"

 

or

 

"You have 1 moderation points"

 

There is of course the slightly better but still plain lazy variant:

 

"2 user(s) online"

 

Class of Error: “We want people to think our company can’t even speak English”

 

Principle: It is moderately important not to look like ignorant fools

 

Proposed Fix: Put in the single line of code necessary to determine plurality

 

Discussion: How hard is it to write an if statement to create the singular form of the noun? Not very...

 

Proposed Automated Fix by Tog: High-level environments, such as web page development applications, should perform this task for the developer with minimal input and no coding on the developer’s part.  Developers would highlight and declare nouns and verbs to be pluralized, based on the associated dynamic value.   The dictionary would handle the necessary spellings.

 

Bug first observed: 1977

 

Bug on list since: Jan 2005 

 

Bug Name: Computers still don’t “learn”

 

Reported by: A. Nuxoll

 

Alias: “Over and over again”

 

Bug: Computers remain maximally “stupid.”

 

Fix: Computers should not only detect that something has gone wrong, they should self diagnose *and* self repair.

 

Discussion: Have you heard the joke about the manager, the engineer and the computer programmer all riding down a mountain slope in a car when it's brakes fail?  The manager proposes that they have meetings to discuss the problem and pick the best course of action.  The engineer gets out his pocket knife and starts trying to repair the brakes.  The computer programmer suggests they push the car back up the mountain and try again...

 

For all the grand decline in the price of RAM, computers still have no memory.  They cheerfully make the same mistake again and again and again. It's time we moved beyond core dumps, binary patches and their ilk. 

 

Bug on list since: Jan 2005

 

Bug Name: Is it dead or thinking?

 

Reported by: Marcin

 

Duration: As long as GUI’s have been around. I first noticed this on my first computer in the early 90’s.

 

Supplier: Pretty much everyone who writes event driven software

 

Product: Too many to name

 

Bug: Doing too much work in a UI interface callback

 

Class of Error: Programmer laziness

 

Discussion: Some programmers, when writing event driven interfaces, especially GUI’s, do way too much work inside of the event handler. This nasty bug manifests itself when a user clicks on a button or some other UI component and the application window becomes unresponsive, unmovable, and sometimes its contents even get corrupted, such as when dragging another window on top of the one manifesting the bug. When this happens, the user is left in a dilemma; is the application merely busy and will eventually recover or is it dead and needs to be restarted?

 

This typically happens when the operation the user requests takes some time to complete, such as database queries or DNS lookups. The problem is that the lazy programmer has their event callback doing all the work that corresponds to the UI element that has been triggered and that the underlying OS/windowing system depends on an application to process events in order to remain responsive.

 

Possible fixes: Application writers can fix this problem by spawning a worker thread to perform the work and leaving the UI thread to maintain application responsiveness. Somehow, it must be communicated to the user that the application is “thinking” and is not ready for more input. How to do this is an exercise for a UI designer, which I’m not :-)

 

The underlying problem hopefully can be fixed by rethinking how the OS deals with user events. I don’t understand why a window must move itself after being told to do so, rather than being moved by the OS. Perhaps there is a way for the windowing system to make it clear that an application is busy while still allowing the user to move the window, minimize it, whatever. An especially evil culprit here is Windows, where sometimes ALL windows become unresponsive or respond extremely slowly when another application monopolizes the CPU.

 

So, what happens in the case where an application is really locked up? It would be nice to tell the user “Hey, something bad has happened, and I have locked up. Please report this bug”. This is a possible problem to solve, it just takes extra work. There is a concept in operating systems called the dead-man’s switch which solves this problem for threads in real time systems, perhaps in can be applied to interfaces.

 

Bug on list since: Jan 2005

 

Keyboard Shortcuts

Bug Name: Accidental Hotkeys

 

Reported by: Alexander Bailey

 

Duration: since 1981

 

Supplier: everybody

 

Alias: “WTF did I just do?” AKA Hotkey Hell AKA “Kitten on the Keys”, AKA “Kid on the Keys”

 

Product: you name it

 

Bug: Functions called by key combinations   often work invisibly.

 

Class of Error: A little too convenient.

 

Principle: The user should always know exactly what the computer is doing or has just done so he knows exactly what just happened after having to shove the cat off the keyboard.

 

Proposed Fix: Display an unobtrusive message in the status bar present in the GUI of most programs.  Indeed, some programs even briefly flash such information there, but that is inadequate.  A simple dropdown list of the last few commands, complete with what input was used to enter them (mouse, F-key, hotkey, etc).

 

Discussion: This has been a problem since the Mac featured that goofy “command” button, and has only propagated with Windows and its control key combinations.  Many computer users have horror stories about their kids going berserk on the keys and destroying hours or years of work, or of having dropped a donut on the mouse and “something” happened.  I had a programming instructor who lovingly called this the “Donut-Drop Theory” (another of a million corollaries of Murphy’s Law), where if there’s any way for a user to break a program, no matter how astronomically unlikely that anyone will stumble upon it, some dumb user will drop a donut on his mouse and find that break.  Most such “disasters” are easily reversed if only the user knew what just took place.

 

Discussion by Tog: My favorite for this is Microsoft Word.  They’ve “mined” every key combination possible.  I’ll be typing along, minding my own business, when all of a sudden the screen lights up with text zooming around everywhere.  I’ve apparently hit some modifier key quite by accident and launched one of their many “random shuffle” functions.  There is no way to know what I’ve done so I either a) won’t do it again or b) can turn the function off on the 47^th preference panel, third row down.

 

Hotkeys should be used sparingly and only if turned on by the user.  Furthermore, as studies back before there were GUIs proved, users should be able to chose/alter their own shortcut keys.

 

Bug first observed: 1981 (Apple Lisa computer)

 

Bug reported to Supplier: That’s not a bug!  It’s a feature!

 

Bug on list since: Jan 2005

 

Bug Name: Mapping common user actions to multiple keys

 

Reported by: Charles Y. Choi

 

Duration: Since at least 1981 or

 

Supplier: Everybody

 

Alias: “Muscle memory gave me RSI”

 

Product: Almost every PC keyboard

 

Bugs:

1. Common user actions such as cut, copy, paste, undo, and help are usually mapped to multi-key combinations.
2. Different platforms and/or applications all use different ones.

 

These bugs create learning curves that all too often are platform or worse, application specific.

 

Class of Error: “Gosh, there’s too much water under the bridge to ever change it now!”

 

Principle: Keep thinking this way and things will never change.

 

Proposed Fix: Create or reallocate dedicated keys for common user actions.

 

Discussion: Having to cut, copy, paste, undo, and find help will always be integral to using computers for editing tasks. Why make these operations second-class citizens on the keyboard?

 

Bug on list since: Jan 2005

 

Bug Name: The interminable laundry list

 

Reported by: Henry Lowengard

 

Duration: [in years] at least 20, probably more

 

Supplier: anyone using selection lists in a UI.

 

Alias: ”Oh, My Achin’ Mouse Finger!”

 

Product: all interfaces not running on teletypes.

 

Bug: If the UI presents you with a list with more than a screen’s worth items in it, it drive you nuts scrolling around to find what you want.

 

Class of Error: ”I’m giving you all the choices you need! Shut up and keep scrolling!”

 

Principle: Let the computer do the searching, sorting, selecting and sifting.

 

Proposed Fix: Selectable lists need to be a lot more useful and have a smarter back end. This goes for file lists, results from databases, anything that must be selected to continue. I’ve done this partly in a product I wrote - instead of a select popup, I made a list with 20 or so fixed slots, and very powerful ways to sort and select into those slots:

 

• alpha sort, forward and back (internationalized) - substring matches float to the top sort. This could be generalized to regex matches, at the risk of brain fever.
• most recently used to the top sort
• most frequently used to the top sort
• selected items to the top sort
• Ability to use those sorts on alternate related data (beside those usage ones mentioned).

 

 A currently used case of this is sorting is on Japanese word pronunciation, instead of the meaningless “order” of the characters. This could be generalized to either dynamically derived keys (like your aforementioned dropping of “a” and “the”), or parallel data (pronunciation might be a good thing in English, too!) Other sources of meta-organizing could be by project, so all non-relevant documents are hidden, by arbitrary keywords or “colors”, and by other meta data like length, duration, stat-like info, font metadata, etc....

 

Discussion: 

Once, I conked out the Finder on my old System 6 Mac just by opening a folder with 4000 files in it. It was trying to build this huge complicated list structure internally to show me stuff I didn’t even want to see.

 

It’s possible now to get thousands of lines of results in just a few milliseconds that you could never pore through.

 

Boomerang was an excellent product for the Mac back in the 80s when you were allowed to hack up the File Dialog. It called a certain number of recent files and directories, with the last file used always preset. As a result, I spent very little time finding the files I needed, because I was likely to have used them recently and would also be likely to create them in the same directories. Mac OSX has something like this, but it seems to be recent directories for everything, which is inappropriate.

 

The old NeXT text editor would use the directory of the current document as the place to start any open dialog, so if you wanted to look for a file, and you knew it was “near” a document you already had open, you’d select the old document and some of the navigating would have been done already for you! Again, it was really intuitive and probably involved no more than a line or two of code. Both of these solutions point a way to my more general one.

 

Discussion by Tog: I’ve included this bug not only because of the particular problem mentioned, but because it exemplifies a whole class of bugs: Things that worked when computers were small that have been overwhelmed by scale. We need to rethink a lot of solutions that worked OK thirty-five or forty years ago.  The mouse + bitmap display interface was invented in the early 1960s.  When are we going to graduate from wearing short pants?

 

Bug first observed: 80s.

 

Bug on list since: Jan 2005 

 

Bug Name: "Designed by Marketing"

 

Reported by: Herbie Robinson

 

Duration: 5000 BC

 

Supplier: Many

 

Product: The Apple Dock, et. al.

 

Bug: Companies often ship demos, instead of products

 

Class of Error: Failure to apply the science of design

 

Principle: Bright and shiny does not equal productive

 

Proposed Fix: When the creative design is done, put it through iterative interaction design and usability testing to make sure it’s not just pretty.

 

Discussion: IMO, "The Macintosh Dock" is but an example of a more pervasive problem": "Designed by Marketing".  It certainly is one of the best examples.

 

There are many such examples in OS X...  Such as every dialog box that uses more screen real estate for white space than useful data.

 

Discussion by Tog: This problem usually arises when the decision-maker doesn’t use the product.  It is particularly pernicious on the web, where highly-paid outside companies develop Flash-laden demoware, then show it off it to wide-eyed clients, while failing to point out that the entire demo site is resident on the demo machine.  When the site goes “live,” it suddenly takes 15 minutes for the content-free splash screen to load, but the client either never bothers to look, or does look, viewing it via the company’s T3 line.  The client later concludes that things just don’t sell all that well on the Internet and goes back to concentrating on bricks-and-mortar.

 

Bug on list since: Jan 2005

 

Bug Name: “OK” dismissal of “not OK” dialogs

 

Reported by: Seth Hollander.

 

Fix proposed by: Mike Kupietz

 

Duration: >20 years

 

Supplier: GUI OSs and applications thereon

 

Alias: ”I’m OK, you’re Outta Luck

 

Slogan: ”You’re going to do as I say... AND you’re going to like it!”

 

Product: MacOS 1.0-10.3.6 & and it’s various clones

 

Bug: When you try to do something that the computer does not allow for one reason or another, the computer pops up a  modal dialog box with a message saying you cannot do what you want, and offers you no response but hitting a button that says “OK”.

 

Principle: The human interface should be designed without losing sight of the fact that the technology is supposed to serve the user, not the other way around.

 

Proposed Fix: Dialogs indicating that the computer can not or will not do what a user has tried should have the dismiss button labeled “Sorry” instead of “OK”.

 

Discussion: Credit goes to my friend Seth Hollander, an astute observer of the human condition, for bringing this to minor but ubiquitous bug to my attention as he was getting familiar with his first Mac. He complained to me that whenever the computer was telling him that he could not do what he wanted, it then added insult to injury - and reinforced his distrust of technology - by forcing him to say it was “OK”.

 

As it is, users are coerced into tacitly accepting that their needs are subservient to the computer’s requirements, not the other way around. This doesn’t bother us techies much, but from a human behavioral standpoint it really sucks eggs. It suggests that users are expected to simply accept that the computer’s refusal to do what you choose is “OK”.

 

Seth pointed out that from a user standpoint, “Sorry” would be a much more appropriate label for the button on such a dialog, and I agree. A button that says “Sorry” acknowledges the needs of the user as the primary point of the computer’s functions, and suggests that the inadequacy lies in the computer’s inability to do what the user wants, rather than in the user’s inability to do what the program requires.

 

Even in a situation where the error dialog was prompted by ignorance or an accident on the user’s part, a deferential “Sorry” is just plain polite. It suggests that the interface was designed with the user in mind, not the technology.

 

Discussion by Tog: I like the concept, but the button shouldn’t say, “sorry,” the dialog should say “sorry.”  The button’s label is the user’s response to what the dialog has reported, and the user isn’t sorry, the user is angry.  Several buttons should be supplied.  One could still say, “OK,” as in, “I accept your apology.  Another could say, “Dammit!” and still another could say, “Screw you!”  They would all, of course, do the same thing, simply dismiss the dialog, but, like the “Close Door” button on the elevator—a “pacifier” (industry term) that is actually not even wired up 90% of the time (true!)—the latter two would make us feel a whole lot better.

 

Bug first observed: 1980

 

Bug on list since: Jan 2005 12//04

 

Bug Name: Copy & Paste Unreliable

 

Reported by: Sulka

 

Duration: Since 1980s

 

Suppliers: OSs, applications, browsers, websites.  Special mention: MS Office

 

User response: “What the...?”

 

Bug: Copy and paste fail to work properly

 

Class of Error: Poor design, poor implementation

 

Principle: System should either carry out the user’s commands or report errors in doing so

 

Proposed Fix:

• Have system copy stuff when user asks it to
• Have system paste stuff in a reasonable format when user asks it to

 

Discussion: How about copy & paste still not working properly? I'm on OS X and the OS is still haunted with:

 

• Occasionally copying items to clipboard fails silently (out of memory?)
• Pasting objects fails in many ways especially when pasting across applications, including
  • Object is pasted in unexpected format (happens especially with MS software) [covered in separate bug -tog]
  • Object pasting doesn't work at all
  • Data is pasted partially (some, but not all text formatting comes through)
  • When pasting text, there is no way to not paste formatting when needed

 

I've been haunted with the same thing for as long as I've used machines with cross-application copy/pasting and it's not gotten that much better in the time.

 

Discussion by Tog: Browsers are the worst.  You either can’t do selection, they pretend you have selected, but once you get to the target document, there’s nothing there, or you’re trying to select a word and they grab two-thirds of the entire site.  One particularly distressing one is the unpredictability of extended shift-selection. There are “work-arounds to this inherent browser bug,” since some web page contents can be properly selected and some can’t, but website developers have enough work to do without trying to avoid browser minefields.

 

Some of the problem across all classes of software is design.  A lot is just miserable engineering practices, including a complete failure to QA the products and take action when bugs are found.

 

Cut and paste are fundamental actions in GUIs.  Developers that screw it up are not only damaging their own products, they are undermining the perceived stability and reliability of the entire system.  Get it together!

 

Bug first observed:

 

Bug reported to Supplier:

 

Bug on list since: Jan 2005

 

Bug Name: Ignoring HCI guidelines/standards

 

Reported by: BarryD

 

Duration: > 25 years

 

Supplier: Microsoft, Apple, Adobe et al

 

Alias: ”We know better”

 

Product: Most applications, but the worst culprit has to be QuickTime for Windows

 

Bug: We are going to make our Windows product look and act like a Mac application

 

Class of Error: Belief that design matters more than functionality

 

Principle: It is your job as a UI designer/developer to design interfaces that work as expected, not ones that act like you believe they should

 

Proposed Fix: Follow the UI standards before you pretty up your interface.

 

Discussion: Both Apple and Microsoft have produced standards for designing software for their UIs. Very few “big name” programs stick to it. Apple produced software on Windows is probably the most guilty party, QuickTime does not look like a Windows application, it does not act like one, and the stupid click and drag wheel for volume is an abomination. Adobe comes a close second, but has the excuse of having to support users moving from the Mac to Windows and vice versa, but still the UI should follow the underlying OS standard and use the standard shortcuts. Microsoft just keep changing their mind with each release of Office over what the new standard will be, then never tell anyone.

 

Discussion by Tog: QuickTime has been a rogue application on both Mac and Windows since the boys from NeXT swaggered back into town.  It was their way of marking territory, of letting the Mac people know that the NeXT people could do anything they felt like.  They received an intense amount of flak and, grudgingly, backed off a few paces, at least on the Mac.

 

Apple may also have some method to their madness vis-ˆ-vis Windows: Making iTunes conform to the Mac interface is training a whole generation of Windows users in how to use a Mac, smoothing the way for future converts to the Mac fold.

 

The real culprit here is Microsoft, which spent the better part of two decades attempting to copy the Mac with the original sitting on their desks, staring them in the face, only to fail in their efforts.  Perhaps they “failed” on purpose.  Perhaps that raggedy interface people had to put up with before XP was just their way of spoiling, as they were doing so well with Java, etc., in the web space before the government finally stepped just a little way in.

 

There is no need for the spurious variations that Microsoft introduced into their GUI.  It is true that they have finally started to innovate, and innovate well, in the last few years, but before then, virtually everything they changed from the Mac original was provably worse.

 

Notwithstanding this nattering, your job, in designing software, is to make your users’ transition to your product as smooth and comfortable as possible, and that’s true whether it’s an OS, an application, or a website.  (The retribution for an ego-driven ecommerce website is particularly swift and sure.)

 

Bug on list since: Jan 2005 

 

Bug Name: Unusable Scales

 

Reported by: Steve Severinghaus

 

Duration: From antiquity

 

Supplier: Manufactures in far flung industries

 

Alias: “Stupid volume knob!”

 

Product: Computer, TVs, cars; even the kitchen sink

 

Bug: The scale at which you are forced to interact with an interface element does not correspond to the useful range of values for said element.

 

Proposed Fix: Develop scales based on studies of user-needs in realistic surroundings

 

Discussion: We are surrounded by objects suffering from this flaw. They are so ubiquitous that we are used to dealing with them, and the constant frustration averages out to a subtle discontent. A simple example in the computer world is the volume slider. The useful values of this control in most day-to-day environments (i.e. not a sound studio) are bunched up in the top 20% of the control’s range (excluding “mute”, of course). This, combined with the relatively small control size, makes it infuriatingly difficult to find a comfortable volume. The situation is compounded in digital contexts by typical discrete controls, where so often the ideal volume is between two notches.

 

This flaw has been passed down through the years from antiquity. The hand brake on my car has its only uses in the last 10% of its range of movement. The temperature dial for the air conditioner in my apartment is only useful on settings eight through ten out of ten. The faucet controls in — you guessed it — my kitchen sink give me no flow through 70% of their arc, making it exactly 3.3x harder than necessary to find the right position.

 

So who has gotten it right? A small, isolated example is the brush size controller in Adobe Photoshop 7.0 (and hopefully later versions!). Adobe has grasped the exponential nature of this tool. The slider has very high resolution in the lower end, making it easy to select small brushes precisely, while the high end ramps up quickly to make it easy to find the rougher large brush sizes.

 

Discussion by Tog: I have solved the volume problem in my own case by developing a very simple hack that lets me turn the controls, which normally stop at ten, up to eleven.  I’m surprised no one thought of this earlier....

 

(Please don’t write me; that was a literary allusion.)

 

Bug Name: Application in a Single Window

 

Reported by: Adam Silver

 

Duration: >10 years

 

Supplier: Microsoft, Apple, virtually every media player vendor, weblications, et. al.

 

Users’ plaintive cry: “How am I supposed to figure out what to do in this cluttered window?”

 

Product: Windows Explorer 98 and later, almost every Apple product released since Steve Jobs’s return, virtually every media player, an increasing number of others

 

Bug: Forcing every feature of a program into a single window intimidates new users and limits power users.

 

Class of Error: Amateurs confusing visual compactness with simplicity

 

Principle: The only way to test “simplicity” is by stepping through or using a product, not demoing it.  The quick observer’s visual clutter is often the long-time users’ rich information space

 

Proposed Fix (Adam): If you are suffering window-clutter, combine related features into fewer (but still multiple) windows and place them on screen in positions that make sense to users.  Do not attempt to crush everything into a single window.

 

Proposed Fixes (Tog):

 

• Examine how your competitors are doing things. 
• Build prototypes and do usability studies that prove out how product or service will work with ““real world” tasks.
• Do not listen to people who have never and will never use the product, like executives at your company.
• Do, however, listen to your sales force, then ensure that the product, no matter how complex, is demoable.
• Design, test, and iterate, until it works

 

Discussion by Adam: What focus groups say and what they mean are not always the same. For example, when people say a movie is too long, they really mean the movie is boring. (Titanic was over three hours long and some people still asked for a longer home video release.)

 

As software packages added more features, their designs became increasingly cluttered due to designers adding additional windows for new features. Users became overwhelmed by all the windows on screen and often didn’t know where to start or where to find the things they needed to do.

 

The increasingly common “solution” to this problem is forcing every feature of a program into a single window. Bad idea. This is just as cluttered and intimidating to new users and limits how much power users can do.

 

Discussion by Tog: Focus groups are the exclusive purview of marketing and might be vaguely useful for determining the demoability of a new product, as well as for generating lists of possible new features.  They are not useful for any other aspect of HCI design. 

 

HCI designers are schooled in the science of design and are able to make proper decisions in how many windows to use and in what the contents of those windows should be, proved out by their constant companions, usability professionals.  Having some random marketing person insert himself into the process, based on a one-hour focus group, can sink a project, as can an engineering manager or executive who reads an article that all applications/weblications should exist inside a single window, then throws his or her weight around.

 

If you are not working with an HCI professional, trained in the science of design, you are wasting your company’s money and your users’ time.

 

Bug first observed: 1998

 

Bug reported to Supplier: since 1998

 

Bug on list since: Jan 2005

 

Bug Name: Born in the USA

 

Reported by: Luca Accomazzi

 

Duration: [in years] since 1945...

 

Supplier: almost everybody

 

Product: (almost) every single piece of software ever made in the USA

 

Bug: The user interface is full of items named in a foreign language. [USA people. Listen up!  The “foreign language he’s talking about is English-Tog.] There are good translations available, but they can’t be localized because they are hardwired in the code at some level.

 

Class of Error: Either your mother tongue is English, or you are unable to use a personal computer. It used to be somewhat better in the classic Mac OS. You could even rename the System Folder (mine was “Cartella sistema”). But you couldn’t rename the Finder, it had to stay that way. It’s much worse in Windows and in Mac OS X.

 

Proposed Fix: 

 

Not a problem, unless you plan to sell that so-called operating system or application abroad. Oh, you do?

 

Discussion: 

 

Look at the left-hand strip of icons on any Finder windows in Mac OS X — Italian localization active. The first icon is titled “Network”. What’s a network? There’s a perfectly correct Italian word for this, “rete”. Then I have a “Desktop”, it seems. Hmm, should be a “Scrivania”, shouldn’t it?

 

The colleague in the cubicle on my right is working on his WinXP box. I see a “Start” button in the bottom left corner, so I guess things aren’t much different on that side of the fence.

 

Maybe I’m too bitter about this. I’ll just forget everything, go and buy some music from the iTunes Music Store, Italian edition. Let me see. How can I find Italian singers? Oh, look, they’re grouped under “world music”, together with Israeli, German, Chinese... Nice idea, unless they were planning to actually do business this way. Also, I didn’t know that the US didn’t think they weren’t a part of the world.

 

Bug first observed: It’s always been like this in computers. Think of the Fifties: computers were nothing more than some bulbs plus some primitive software punched on cardboards and written in... ASCII. The A stands for “American”. As in “you can’t even write the name of most people both outside the English-speaking countries”. And I don’t mean Chinese, I mean Mexican and Canadian too (there’s no – in ASCII and no ? either).

 

And it’s not only computers. Take a cartoon, a movie, a picture where you see Earth from space. There’s North America smack down the middle of the picture.

 

Retort by Tog: I feel compelled to respond to some of these scurrilous charges:

 

•  “I didn’t know that the US didn’t think they weren’t a part of the world.” The people in the US are so provincial they don’t even know there’s a rest of the world, although some have heard of Canada, along with a South American country called Mexico, mainly because we smuggle a lot of drugs across the border from them both. (The young people from Mexico, the old people from Canada.)
• “Either your mother tongue is English, or you are unable to use a personal computer.”  Most Americans believe this to be true.  They also believe we are the only people who are actually alive.

 

But, seriously, we are truly as provincial as any nation on earth.  Few Americans, by percentage, have ever traveled beyond our borders, and there is not sense of world community in our daily lives.  CNN, in the USA, makes faint reference to events elsewhere in the world only when they bear some connection to the folks back home.  This is in sharp contrast to CNN International, which truly speaks to the world community.

 

Because of our provincialism, we fail to appreciate foreign markets, then fail to plan for them.  Just as it’s easier to only support Internet Explorer, it’s easier to just consider the US market.

 

Localization begins at the beginning of a project.  It cannot be glued on at the end.  Architect the system and design the interface to support the eventual localization—never forgetting the expansion of such languages as German—and hire native speakers to do the actual text translations.  Get them in early enough so they can affect any data model, so you have slots for necessary extra or different data fields.

 

Bug Name: Pointless Help

 

Reported by: Duncan Watts

 

Duration: since 1984

 

Supplier: Many, many people

 

Example: "To load a file, go to the 'file' menu and select 'load' "

 

Bug: You can't quite work out how to do something so after looking through all the menus you resort to the help which tells you nothing about how to solve your problem. It just lists a sequence of operations which you already tried to perform. No hint as to what to do if this process isn't having the desired result. No mention of common mistakes to avoid, pre-requisites for performing the operation, related functionality, etc.

 

Class of Error: "We make it look like we're helping - but without putting any effort or thought into it".

 

Principle: Help should help

 

Proposed Fix: Either write real help or fuggedaboudit

 

Discussion by Tog: I’ve found multiple reasons for this problem:

 

• Marketing wants the checkmark on the side of the box, and engineering has no resources to do it.
• The person doing help has no idea how to use the product (a very common reason).
• The person doing help has a single user in mind, and usually it’s a brand-new one

 

The best manual I ever read was for my Texas Instruments SR-52 calculator, circa 1976.  The calculator handled around 225 programming step and stored programs on magnetic cards.  I learned how to program on it.

 

I was aided in learning this quite remarkable machine by a second, rather scruffy looking manual packed in with the slick original.  It had been written by a man who obviously dearly loved this machine, who had spent hours and hours exploring its every nook and cranny, and who, with obvious enthusiasm, wanted to give newcomers his hard-won knowledge.  This manual proved of little value during the first month, when the simpler, "To load a file, go to the 'file' menu and select 'load' ," was more in keeping with my needs.  But after that, it liberated me from the earth. I went on to cause it to do things it had never been designed to achieve, ultimately teaching it to spout poetry, turn out graphical patterns for leather-crafting, and to play music on a player piano.

 

When I went to Apple, I wrote a similar manual for the Apple II.  A number of people have come up to me in the years since and thanked me, telling me it inspired them to dive into that computer, remarkable for its time, and to make it do things for which it had never been intended.  They went on to making computers their career.

 

I’ve never seen a help system that did that and, given that help is all that’s left with the demise of written manuals, it is something most definitely needed.  Help is better than it was 20 years ago, but only in spotty cases.  It remains the poor stepchild of the software industry.

 

Bug on list since: Jan 2005

 

Bug Name: Inflexible entry parsing

 

Reported by: Many

 

Duration: from the beginning

 

Product: everything from OSs to websites

 

Bug: system fails to recognize form of the information outside a single, predetermined format

 

Class of Error: Inflexibility

 

Principle: Systems should be prepared to accept information in a variety of unambiguous formats

 

Proposed Fix: Spend the time to build flexible parsers.  This should be done at least at the system and browser levels, so that others can access standard tools.

 

Discussion: For example, Credit card numbers are in the form XXXX XXXX XXXX XXXX.  Try to find a website that will accept it that way.  Instead, the implementers are so lazy, they force users to crush it all together, maximizing their difficulty and odds of error, all to save the programmers 10 minutes work.

 

Their mamas would not be proud of them.

 

Users shouldn’t have to enter their credit card numbers five times a day, but as long as they continue to have to do so, at least make it easy.

 

Likewise, as reader David Phillip Oster points out, users should be able to type in expressions when prompted for numbers.

 

For example, I should be able to enter $37 X 52 when asked how much money I spend on Oreos per year, instead of having to pre-compute it.  Various systems have allowed such activities over the years.  It needs to be standard to each OS and browser toolkit.

 

Bug on list since: Jan 2005