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

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

Oops!

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

Retrospective

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?

Filed under: Usability | Tagged: Design, lessons learned, programming, software, UI, Usability |