Usability Rant: When bad design decisions become standards

John is in a crotchety phase today
Crotchety Mood
@1914 Andy Rooney

Prior to starting this blog a few months ago, I rarely had occasion to write much more than a few paragraphs in a browser based editor. In this short time, I am starting to understand why most serious bloggers seem to write their posts offline in traditional word processing software. Despite the best efforts of web developers, the browser platform is a usability nightmare fraught with peril for innocent users and their precious data.

Forgive my Andy Rooney impression, but what has me in a crotchety mood is the behavior of the backspace key in modern browsers. I understand how convenient it seems that browsers have a function to navigate backwards and there is a handy over-sized key with the word “Back” printed right on it, but sorry that key had a meaning that predated personal computers and far-predated browsers.

My Mental Map says, “Backspace = delete the last typed character.”

“But,” my tormentors would say, “you can still use backspace that way when you are in a text field. We’ve just overloaded it so that you can also use it to navigate to the previous page.”

angryuserThat is true, but it is very common for a browser to rip focus away from the edit control unexpectedly, invisibly, and unapologetic ally. –I’ll save that rant for another day– If you hit the backspace key after the focus drifts away…BAM…you wind up on on another web page and will never get back that insightful three page retort to that ignoramus who thinks Piccard was better than Kirk and the world of literature will be diminished for its loss.

Giving the user the ability to irrevocably wipe out a big chunk of their work with a single key press violates a number of the fundamental principles of usability engineering, most importantly:

User input is sacred, protect it at all costs!

Your problem is right here, m’aam.

The core problem here is the inappropriate use of modes. Application modes turn friendly UI elements and device controls into two faced bastards that promise one thing and do another and then pin the blame on you because you didn’t catch the context switch. Modes are especially evil in situations like my example of the backspace key because they turn a  harmless action (delete one character) into a catastrophic one (exit without saving).  It is like having a button on a soda machine explode instead of dispensing a Dr. Pepper because it is Sunday and that is just how they roll in Waco.

I”m not saying that modes have to be avoided at all costs, just that you should recognize that they incur a debit against usability and they should be demoted to a fallback option where there are simply more functions necessary than controls available to map them to. But don’t take my word for it.  Don Norman also recognized the danger of relying on context based function mapping in his awesome exploration of the interaction between humans and machines…

“Mode errors are inevitable any time equipment is designed to have more possible actions than it has controls or displays, so the controls must do double duty. [They] are especially likely when the equipment does not make the mode visible…”
The Design of Everyday Things – Donald A. Norman

Mitigation Strategies

If you find that a modal approach is the only option, at least implement it responsibly.  Follow these best practices when implementing a modal interface to minimize the potential for leading your users into annoying mode errors:

  1. Make it obvious to the user which mode they are in at all times. For example by changing the label on controls.
  2. Mode changes should be initiated as an intentional act by the user, not the software or as a side effect of an unrelated action.
  3. If #2 isn’t possible, at least make the mode switch obvious, but unobtrusive. That is, don’t ask them to confirm it.
  4. Recognize that mode errors will happen despite your best efforts. Anticipate them and make it easy to fix their consequences.
  5. Don’t use a mode as an excuse to force the user to memorize arbitrary and illogical control mappings.

The Legacy of The Browser Backspace Atrocity

Evil Backspace

Unnecessary Modes Are Evil

As best I can tell, though I haven’t yet confirmed it. This behavior originated in Internet explorer and has since spread to all of the popular browsers. I have confirmed the mapping of the backspace key to the back-navigation function on Windows in IE7, FireFox 3, and Google Chrome.  I suppose it is a standard now at least for Windows. Peachy.

Meanwhile, there is a growing cadre of browser users who LIKE this “feature”, are requesting it be added to other browsers, or even trying to hack it back into browsers that haven’t implemented it.

That said, a quick Google search indicates that a considerable number of developers are also trying to hack it OUT of the browser for their sites. Ultimately, the behavior has existed long enough that it will be politically impossible to undo and will force web developers who know something about UI design to continue to work around it for the sake of their users.


Usability: Don’t Force Old Dogs to Learn New Tricks

This old dog

I learned a few tricks this week for working with one of the oldest interfaces since punch cards, the command line. More specifically, I found a few shortcuts and features of the console UI provided by Windows, also known as “The Command line”, or inaccurately as a “DOS Window.” It turned out to be one of those rare gems that you stumble on that immediately make you more efficient.

If you are interested in the trick I found that inspired this post, check out the article I wrote about it, “Windows Console Tricks and Shortcuts”.

A Deeper Understanding of Canines

Indirectly, I also learned a lesson about how extreme familiarity with an interface creates blind-spots that inhibit discovery of new features. If my experience is typical, it appears that over time users settle into an application and tend to stop looking as aggressively for ways to use it more efficiently. In fact, I would contend that there exists a tipping point in the learning curve with a user interface beyond which the idea of changing the way a user performs a task in the interface, even if it is simpler, creates anxiety and consequently resistance.

Another possible explanation for how these features are so effectively hidden in plain sight is the tendency of a user’s UI pattern memory to fade quickly when it isn’t reinforced. If a standardized technique falls into disuse, it can’t easily be resurrected to encourage users to discover features in places that used to be familiar. This is particularly evident in Raymond Chen’s recent eulogy for the obscure Windows affordance of left-click menus on system tray icons.

I’m not sure exactly what the take-away is from this epiphany except perhaps that adding new UI elements to accomplish existing tasks in a mature product  is unlikely to create many converts among veteran users.  As a corollary to that, there seems to be a discrete window of time during which it is safe to make extensive modifications to existing UI elements without stressing (e.g. pissing off) your existing user-base. Once that window has elapsed, it is probably safest to keep the old UI available and find a way to encourage new users indoctrinated on using the updated UI.

Applying the Lesson

Several years ago, I found myself on the other side of the discussion.  During my routine debriefings from the sales team, it was communicated to me that  some of our competitors were using advanced search functionality as an effective differentiator against our flagship product, a Web-based document repository for litigators. Naturally, we endeavored to close the gap in the search-UI arms race and quickly began to conceptualize an upgrade to our software.

The application had already been in use for years and had accumulated a loyal following of veteran users who could rightfully claim to be experts on it. Also, the search interface had changed very little since I originally designed and built it back when I was still bootstrapping our product development team. The search interface was simple, but functional, and more importantly the venerable UI was very familiar to the existing user-base.

Existing Search Interface

Existing Search Interface

Key issues indicated  in the user stories and requirements.

  1. Advanced Searching: Need the ability to run more complex Boolean queries like “Letters dated May 5th, or Reports from any day in 1993”
  2. More Sorting Options: Need the capability to sort on more than one field and specify the sort direction.
  3. Optimization:  Avoid querying the contents of the drop-down controls until it is clear that the user intends to use them.

The first requirement had the greatest potential to be disruptive to the familiar layout of the existing search screen. It would require significant rework to enable users to group search terms and specify an AND or OR operator. As you can see below, the new version was indeed markedly different visually.

New Search Form

New Search Form


During beta testing, existing customers were appreciative for the new capabilities, but were hesitant to accept the new screen layout. They found the new version confusing and expressed concern about the number of clicks required to do single-field searches. Some couldn’t express exactly what they didn’ t like about the new screen, they just felt uncomfortable with it. Interestingly, users unfamiliar with the old search screen did not register any complaints.

Back to the Drawing Board

Ultimately, I drew the conclusion that the problem wasn’t so much that it was a badly designed UI, although I have since reconsidered the layout, but rather that I was effectively devaluing the time investment that longtime users had made to learn how to use the software. Recognizing this, we took the following approach to keep our loyal customer-base happy, but encourage the gradual transition away from the old interface .

  • Add an updated version of the existing screen (shown below) that addressed as many requirements as possible without a major visual change.
  • Label the new screen in the UI as “Advanced” (powerful) to encourage its use.
  • Label the old screen in the UI as “Classic” (Outdated) to discourage its use.
  • Add a toggle link to enable easy switching between the screens (indicated by red arrows in the screen-shots).
  • Add a setting to allow the user to specify their default search screen.
  • Configure existing users to continue using the old screen by default.
  • Configure new users to default to the new screen.
Updated Version of Existing Search Form

Updated Version of Existing Search Form


It has been several years and many releases since the events of this story and we are still supporting the dual search interface. My plan to get everyone to switch to the new screen and silently kill off the “Classic Search” interface didn’t pan out .
It seems that although most of the new users, and quite a few of the veterans eventually transitioned to the new interface, a third class of users has emerged that likes to toggle between the screens depending on the complexity of the search they are running.
I suppose life is full of these valuable lessons, but as long as our users are content, I can’t complain.

Pop Quiz!

Consider Microsoft’s decision to scrap the most familiar group of UI elements for most Windows users, the toolbar/menu interface, and replace it with the new “Ribbon” control. Should the negative reaction it engendered have been predicted?

What do you think MS could have done differently to honor the investment of their customers in learning their “classic” interface assuming that they had valid usability research showing that the new UI was superior?

Office 2007 Ribbon. Why, Microsoft, Why?

Office 2007 Ribbon. Why, Microsoft, Why?