Do the Wrong Thing
There’s a disturbing belief found throughout the programming community that it’s OK for an application to do the wrong thing by default, as long as there’s a way for the user to do the right thing. Stated that blatantly, it’s obviously false; and yet I keep running up against this belief time and time again in widely separated areas. Here are just a few:
Apache XML-RPC 2.0 ships with a parser that does not correctly implement the XML specification. This isn’t just a bug. MinML advertises its nonconformance right on its home page. Anyone using this parser will have problems with documents containing internal DTD subsets and likely other legal XML constructs. (Parser vendors rarely like to advertise the features of the XML spec they don’t implement; but other problems usually include CDATA sections, processing instructions, comments, and basic well-formedness checking.) Yet when I filed a bug on this behavior I was told, “I am not so keen with MinML either and share your opinion, that a modern XML parser and preferably the JRE’s parser should be default. However, as already pointed out, this can easily be achieved and you are by no means forced to use MinML. “
Microsoft Word has for years insisted that whenever I reapply a style to the selection that I want to change the style definition to match the current formatting:
Has anyone ever wanted to do this? I know I haven’t. In over a decade of using Word I have never once wanted to redefine the style. The reason I’m picking a style is that I want to apply the style to the existing selection. The default here is exactly backwards. Worse yet, Word offers me the option to make the wrong behavior the default in the future. It offers no option to make the right behavior (where right is defined as the behavior I want every single time I pick this) the default. However, even offering that option would be insufficient. There’s no reason for Word to ask me. I doubt anyone has ever used this “feature” to define their styles. Word shouldn’t ask me at all. It should just do the right thing. For the rare occasions when I do need to redefine a style, there should be a separate tool and a separate menu item.
Here’s another example. I use BBEdit as my HTML editor of choice. However it’s got some really bad user interface problems. Suppose I want to create a paragraph. BBEdit <sarcasm>helpfully</sarcasm> asks me to fill in various information:
Now on rare occasion I do want to add an ID or a class or a style to the paragraph; but at least 99 times out of 100 I don’t, and I just click OK or hit return to dismiss the dialog. That dialog gets in my way for no good reason. I reported this as a bug to Bare Bones and was told that I could option click the paragraph button to bypass the dialog. That’s not a solution. Showing the dialog is the wrong thing. It is unnecessary 99 times out of 100. Not showing it should be the default. That I can take an extra action is not a solution to the problem. This behavior needs to be changed.
Almost as annoyingly, BBEdit is inconsistent about this. Occasionally I use it to insert an abbr or acronym tag. For instance, <acronym title="Java Specification request">JSR</acronym>. This way the browser will display a nice little tool-tip explaining the acronym when the mouse hovers over it. This is a nice touch. The only reason I ever use an acronym or abbr tag is to provide that tool tip. The tool tip doesn’t work unless I include the title attribute. In other words, I need to add a title attribute to 100% of my abbr and acronym elements, but does BBEdit give me a dialog when adding an abbr or acronym element? You know I wouldn’t be writing this if it did. BBEdit just inserts the tag and relies on me to manually type in the attribute like any other text.
Programs and APIs should not give users the choice of doing the wrong thing. In cases where the right thing is obvious, the program should just go ahead and do it. Excessive configuration options are confusing and lead to exponential growth of program complexity. Resist the urge to add every option because someone, somewhere might need it. Strive for simplicity first, and only add extra options if they prove to be needed in practice. Most of your users will never miss the complicated options.
Sometimes a few users do need strange options. If that’s the case, offer them but don’t mix them with the simple tools. Use different tools and different menu items to choose the more unusual behavior. Make the common, ordinary uses as simple as they can possibly be. Sometimes you really do have a case where half the time a user goes one way and half the time they go another. If so, you might really want to ask the user what to do each and every time. However, this isn’t nearly as common as most developers initially think. Usually one branch is taken far more often than the other. Failure to identify and design for this is lazy programming and lazy design. And by all means, whatever you do, when you make a mistake and a user reports a bug or a design flaw in your program, don’t resolve it as “Won’t Fix” just because the user can flip a switch to make it do what it should have done in the first place. If the default behavior is wrong, then the application is broken and it needs to be fixed.
January 12th, 2006 at 2:04 pm
Defining what the right thing is takes experience. Programmers hot in the middle of coding may recognize the ambiguity of a user’s action but not know what the “regular” user will be doing when they make the ambiguous request. So, the simplest answer is just to code in a dialog or a setable option and be done with it. The people answering bugs are rarely the firm’s HCI specialists. No wonder their respones is “live with it” – They don’t know enough to understand the issue. Open source programmers usually take the attitude, “it sort of works like I coded it, if you want to change it fine, I’ll take your submission”. Which is fine if you are a coder who wants to change it enough that you will spend the time to learn the system to a level where you can change it. Usually I just live with it.
January 12th, 2006 at 8:48 pm
The problem is not confined to open source software however (take ERH’s examples of BBEdit and MS Word). And though I agree “the wrong thing” may not be so obvious at coding time, it should become obvious fairly quickly once the product begins to take shape. I think that is the crux of what is being said: if something is obviously wrong, the program should not supply the option to do it by default.
Take the example given for Word – there is one user action (selecting a style) which has a different default function depending on something quite arbitrary (whether the selection has already had that style applied). It’s a fairly basic UI principle that this should not be the case. Whoever designed the behaviour this way realised that there were two seperate functions, so why were the two functions not given two seperate UI components? (“apply style” and “adjust style”).
January 27th, 2006 at 10:40 am
Of Microsoft Word’s option to modify a style by reapplying you ask, “Has anyone ever wanted to do this?” I do it often. It’s a convenient way to edit the style. However, as you point out, they’ve made the least frequently used case the default. The truly weird thing is not that they made that mistake in the first place, but that they introduced that mistake 10 years ago (or more) and still haven’t corrected it.