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!”