Bug Name: Hidden "important" modal dialogues
Reported by: Zach Toups
Duration: At least three years...
Alias: "Why did my browser lock up?...(oh...there was a hidden update box...)"
Product: Adobe Acrobat Reader (for Windows XP?)
Bug: Acrobat Reader tells you that it can't find any new updates to itself...but it hides this fact...and won't let you work without find it.
Class of Error: Mean programmers who don't know how to program for the platform they're using?
Principle: Keep status information up to date and within easy view
Proposed Fix: Bring the dialogue box to the front...or better yet, just inform me when there IS an update...or best...just install the update and let me know in a non-intrusive manner!
Discussion: Modern software systems should have simple and intuitive update procedures that have a minimum of interaction with the user (unless the user WANTS that interaction). Many pieces of software come with nice interfaces for checking if there is an update to the software (some of these even nicer, since they're automatic) and some will actually UPDATE on their own...most don't bother you if there's no update to be had.
Adobe took a different approach to this with Acrobat Reader (specifically one interfaced with Microsoft's Internet Explorer on Windows XP) which automatically checks for updates. If there are no updates, it happily informs you of this...behind the window you're working on...it also kindly doesn't let you interact with that window until your clear the window...which is behind the window you're working on. Generally, this results in forcing the browser to quit, at which point you find the dialogue box.
Bug first observed: Sometime in 2001
Bug reported to Supplier: November 2004
Bug on list since: Jan 2005
Bug Name: The dreaded Adobe website button
Duration: About 5 years, maybe more.
Product: Adobe Creative Suite, formerly Photoshop, Illustrator, Indesign, etc.
Bug: Large, unnecessary button that causes unwanted action is just a few pixels away from the two most important tools in the toolbox
Bug first observed: 2000
Observer: Michael, and also every graphic designer on the face of the earth.
Class of error: Complete disregard for Fitts' law and user's interest, probably due to intervention of PR/money people who have an interest in the user visiting the website.
Principle: In order to avoid clutter, use icons for needed functions only. Size objects by importance. Provide space between icons for easier mouse usage.
Bug Fixed: Not yet.
Fix: Remove the graphic or provide a way to disable it.
Discussion: A relatively large graphic (larger than the size of two icons) leading to Adobe's website is positioned just a few pixels away from the two most important tools in the toolbox, the marquee and the move tool. At least two or three time a day, a small inaccuracy in mouse pointing will result in the accidental opening of a web browser with adobe's website. The button leading to the website is of course completely useless to the user - the only time I have actually used the button was to look for Adobe's bug report page and complain about this behavior.
This type of design is common in shareware products in which you download the trial version for free and the software maker is trying to get you to pay for the "pro" version by providing easily accesible buttons to their online store. However, Adobe CS has cost me (well, the company I work for) close to $1000. From a product in this price range, I expect more.
Bug on list since: March 2005
Bug Name: Backwards Click
Reported by: Tog
Alias: “two if by land, one if by sea”
Bug: The entire world uses one click to change the name, two clicks to activate the icon. Adobe Photoshop does just the opposite
Class of Error: Meta
Principle: Consistency of interpretation of user-commands is paramount
Proposed Fix: Layers dialog needs to conform to every other labeling system on the planet: One click to change the name, two clicks to select the layer, or, better yet, one click to select the layer, right-click to change the name.
Discussion: timed-out click cycles are bad to begin with, but they at least have a standard definition of the single- and double-click. Adobe has flipped that definition around. Because users “know” through habit which action to take, normally no conscious though process takes place when a label is encountered. Throwing in a backwards interpretation of their behavior not only makes Photoshop difficult to use, it causes users to then make errors when in the file handler, as well, as they unconsciously “correct” the error in the wrong environment. This kind of bug damages the whole developer community.
Bug first observed: 1990s
Bug on list since: Jan 2005
Bug Name: Dumb significant figures
Reported by: Paul W.
Supplier: All spreadsheet makers
Alias: Insignificant Figures
Product: All spreadsheets to date
Bug: Applications have not facility to automatically display significant figures
Class of Error: “Gee, we never thought of that!”
Principle: Shadow users and find out where they are spending their time performing actions the computer could optionally perform on its own.
Proposed Fix: Allow user to set an option to have the application detect and display only significant figures
There is no concept of 'significant figures' in data spreadsheets. While any high-school chemistry/engineering/science student can figure out with little effort how many significant figures are in a number, spreadsheet software (MS-Excel, Apple products, database software) seems unable to have this option.
I can set the number of decimal places (either globally, or locally in individual cells), but when it comes to setting significant figures, no programmer ever seems to have understood the concept.
To refresh, a number such as 0.00345 has three significant figures: the '345' part of the number, and the associated implied error of the number is +/- 0.000005. You ignore the leading zeroes for numbers such as this. A number such as 3.45 has the same number of significant figures, with an implied error of +/- 0.005. A number as 3.45000 however, has a total of six significant figures with an implied error of +/- 0.000005.
One algorithm is to convert to scientific notation, and then use a +/- half unit in the last decimal place, but this doesn't work for the third example when there are trailing zeroes that are significant figures.
If I had to give a cause for this, it'd be that computer programmers think that all decimals relate only to money and accounting software.
Bug on list since: Jan 2005
Bug Name: Stupidly Sticky Slashes
Reported by: Dan Manes
Duration: Since the advent of word wrap
Supplier: Pretty much everyone
Alias: “That slash would be a good place to break up this word so let’s not do that.”
Product: Any text handling application
Bug: You have several words separated by slashes and the text wrapping algorithm thinks it’s all just one big word.
Class of Error: Laziness, tradition, lack of innovation from “innovative” companies
Principle: Word wrap should work the way reasonable people expect it to.
Proposed Fix: Allow the user to easily specify whether a slash is “breaking” or “non-breaking” and program the word wrap so that slashes default to “non-breaking” when fractions or dates are involved and “breaking” otherwise.
Discussion: Words separated by slashes often get lumped together as one long text string. If the string stretches all the way to the right margin, the whole mess gets sent to the next line, leaving an unightly gap on the original line. Even worse, when working with a narrow column of text or typing in the cell of a table, individual words can end up getting broken up at random locations as there simply isn’t enough room for the whole string on one line. Any attempt to fix this problem by inserting manual line breaks could backfire if any preceding sentence is edited.
Bug first observed: Too long ago to remember.
Bug reported to Supplier: Reported to Microsoft on several occasions.
Bug on list since: Jan 2005
Bug Name: Lack of Version Tracking
Reported by: Greg
Bug: Changes in instantiations of the same document must be tracked manually
Imagine that you create a document at work, copy it to your laptop and make some changes, email a draft to a friend who sends back comments embedded in the same document. You happen to read his email on your home machine and make some comments there. Over the next few weeks, you have ideas at different times and carelessly make note of them in whatever copy of your document happens to be close to you at the time. Bad user! You now have multiple versions of the same document, none of which can be said to be the most recent one.
Solutions have existed for years, but they require the user to take action in advance to track changes in his documents. If the application in question does not store the document in a plain-text format, it can be very difficult for the user to recover from this basic lack-of-planning mistake.
File version tracking should be a feature of the files system and OS. Applications should make use of these capabilities to store documents in formats that are readily comparable, and provide built-in difference options that the user can run two compare different revisions of the "same" document. The application should also tag all document edits with the time, date and current user at the time they were made, and the differencing feature could make use of that metadata when displaying conflicting sections to the user. Of course it should be easy for the user to select which version of each conflict should be incorporated into the final version of the document.
Proposed Additional Fix by Tog:
Fix the Internet and finish building the infrastructure, so we can all have a safe, personal repository, so that most often, no matter where we are, we can work on the same instantiation of the document.
Discussion by Tog: Even if we’re off the net, by virtue of being under the sea or something, we will have to surface eventually. With luck, our latest changes will automatically find their way to our information vault before we work on them with a separate machine. Of course, upon occasion, we may leave our computer behind under the sea for a few days, so Greg’s fix also needs to be implemented.
Bug first observed: 1978
Bug on list since: Jan 2005
Bug Name: My app is more special than the others
Reported by: Aaron
Duration: > 10 years
Alias: Ooooh, shiny!
Bug: Programmers part from the OS interface standard
Class of Error: Arrogance
Proposed Fix: Use OS supplied/standard widgets and design guidelines.
Discussion: A lot of programmers want their application to look special and different. This is an understandable desire, however it makes using applications very difficult at times. Is this is close box? What mouse button does what? What things can I click on? You don’t know until you mess around with the interface for a while, and perhaps there are many things you never realize are possible.
The user already is expected to learn how to perform the specifics of each task in each new application. They shouldn’t also have to relearn the standard interface to those tasks with each new app they encounter.
Bug first observed: 1992
Bug reported to suppliers: 1993-present
Bug on list since: Jan 2005
Reported by: Oz Solomon
Duration: since the 1970s
Bug: Ugly shards of the programmer’s world popping up into the user’s world
Class of Error: Indistinct boundaries between the user-illusion and the underpinnings
Principle: The user model is an illusion should be kept separate and distinct from the world inhabited by the applications programmer, a world that is, btw, also in illusion
Proposed Fix: As new features or capabilities are added, design them, don’t just grow them, then ensure that they fit smoothly into the overall design of the application.
Discussion: Many programs directly or indirectly expose users to their underlying object/programming model. This is in contrast to keeping the user within the user’s mental model of how things should work.
For example, in “somewhat” popular word processor (MS Word), there are more than 5 ways to create a border around something. Each one is created through a different UI (not necessarily a bad thing, but thats not what I’m talking about). The problem is that they each *behave* differently.
For example, if you put a border around something by using the drawing tools, you can then click on the border to select and delete it (programmer guess: a drawing object is in fact an internal object and it supports selection in the UI). If you put a border around a block of text using the Borders and Shading dialog, you cannot select the border (programmer guess: this kind of a border is internally considered a property of the block it is bordering and doesn’t get represented as its own thing in the UI).
Bottom line is when my wife gets a document that has a border around something and she wants to get rid of the border, she doesn’t understand what’s going on. “Why can I click on this one but not on this one”. Bug.
I guess this one can also be classified as a UI consistency bug, but I’d say that this goes beyond one type of border against another. Why can she select *some* items and can’t others?
I’m lucky that, coming from a programming background myself, I can understand how these things came to be and have the ability to better cope with them.
Full disclosure: I find myself fighting this design bug on my own projects because it just too damn easy to commit...
Bug Name: Menu items too close
Original Name: “Save As” too close to “Save”
Reported by: Rick Starbuck
Duration: since 1980
Supplier: Too many to mention
Slogan: “You’re just a twitch away from data oblivion”
Product: Nearly every app with a “File” menu
Bug: The menu items “Save” and “Save As” (typically under the “File” menu) are adjacent to one another and almost identically labeled although they do very different things in practice.
Class of Error: Organize items based on what they DO, not what they’re called
Principle: The interface should be safe and forgiving
Discussion: How many users have opened up a file to use as a template and inadvertently “saved over” it by hitting “Save” instead of its neighbor “Save As”? This is often exacerbated by being at the tail-end of a bleary-eyed working session in the wee hours of morning.
Proposed Fix (Rick Starbuck): Put at least one other menu choice BETWEEN them.
Proposed Fix (Tog): Supply Undo not for just restoring a few words, but restoring entire files. Why do we think it’s not OK to protect a single character, but it’s just fine to wipe out an entire book? Truly weird.
Same is true of tabbed browsers. The really bad ones like Safari give no warning when you've accidentally chosen "Close All Tabs," which they've placed right next to "Close Tab." Even the good ones give you one of those, "Did you mean it? dialogs. Best is a simple Undo which would restore the missing tabs.
The original Mac had 128k of memory, a single floppy disk drive, and no way to add a hard disk. Why do we continue to emulate every horrible compromise that was necessary to make that crude first system work?
Bug on list since: Jan 2005
Bug Name: Do things only my way
Reported by: Keith Moore
Duration: probably as old as computers
Supplier: most recently, Microsoft and Apple, but before that - IBM, Digital, Burroughs, pretty much any vendor whose computers I’ve ever used. Apple currently seems worse about this than Microsoft.
Subtext: “Don’t ever leave me!”
Product: numerous. iTunes happens to be the example at the moment.
Bug: This assumes that all users have similar needs and similar levels of sophistication, and that all users should therefore use an app in the same way, and for similar purposes. (sometimes part of the problem is that the app has some sort of lock on its functionality that makes it difficult for other apps to compete - thus there’s a strong incentive to use that app even though it doesn’t do the job well, because other apps are prevented from doing the job)
Example: when an app assumes that the files it manipulates (which are in a well-defined format and are potentially usable by multiple apps) should reside in a particular directory, or be named in a particular way, or be organized in a particular fashion that might conflict with and/or impair the ability of other apps to manipulate the same files. This leads to a situation where it’s difficult for multiple apps that manipulate those files to coexist or share data. This further leads to a demand that all apps that manipulate such data provide all possible functionality, which in turn produces apps with bloated user interfaces with obscure corners (features that users find difficult to use or even discover) rather than user interfaces that are clean.
Specific example: iTunes. It really wants to “own” your music. It wants you to put your music in its directories. It will grudgingly allow you to play music in other directories, but it wants to incorporate that music into its own playlists whether this makes sense or not. It doesn’t want you to organize your music in files and directories and browse them according to the directory structure even though this is a useful way to organize things, especially if you want to share those files with other apps or other systems.
It doesn’t make it easy to play a single tune from its GUI. (you can play a single tune from the Finder, but that’s not a very good interface for browsing tunes). It doesn’t provide any way to play all of the songs in a directory without first building them in a playlist. It doesn’t provide a good way of organizing playlists in a hierarchy or of narrowing down the set of playlists that you’re considering. It doesn’t let you select multiple playlists to play in sequence.
It would be one thing if iTunes just had poor capabilities for organizing tunes and playlists (which it certainly does). But it’s worse than that. It takes away the file system’s (admittedly limited) way of organizing information and replaces it with something that’s not only foreign, it’s even less functional except for the limited use cases that its designers anticipated.
Class of Error: Excessive control
Principle: The user is in control
Proposed Fix: The file system should have primary control over all documents. Applications should exert limited control only at the user’s specific instruction.
Discussion by Tog: This problem has been with us right along, sometimes recognized, sometime so ingrained we haven’t even notices. Examples of the latter are email systems that clump all our email together into giant, proprietary monster-documents, making movement from one email system to another as difficult as possible. Therein lies one of the motives for this problem: They want to make it difficult. These developers may not always even be consciously aware of this motivator, seeing themselves, instead, as merely trying to control the environment to help their users out.
Another causative factor is the thirty year old architecture of our operating systems that see everything other than themselves as applications, ships floating on top of the OS ocean. Instead, applications like iTunes and the various photo sorting apps should be services, able to embed themselves directly into the file system, giving users new views and new capabilities.
iTunes at least does allow you to take your music with you in a reasonable fashion, since it mimics much of what such a service would do, by sorting your music into real folders in the file system, instead of into some one-off database structure. Many of the photo sorters, however, go way too far, seducing users into laboriously categorizing their photos inside proprietary systems that cannot be transported anywhere. The day will come when all 10 or 20 thousand photos will have to be completely resorted from scratch. I’ve chosen to maintain my photos entirely within the file system, divided among normal folders.
Bug first observed: in systems written in the mid 1960s, but certainly occurred before that
Bug on list since: Jan 2005