Usability Hall of Shame – AutoCorrect

Cupertino, we have a problem.

Q: How do you know when your software has a usability problem?

A: When someone creates an entire humor site dedicated to mocking it.

Okay, you might have said something involving reports from the usability testing, or maybe even some axiomatic list of UX smells. However, if you ever find that a piece of software you wrote has inspired an entire new category of parodic humor, there just might be a problem.

How has it come to this?

The emergence of this UX gaffe leaves me incredulous for a number of reasons. First, one of the biggest offending implementations is baked into iOS, a product of a company that gets a lot of respect for designing great interfaces. Secondly, and more importantly, most of the Mobile OS platforms with this issue have gone through several major upgrades and not fixed the problem despite all the bad press about it.

Fail x 439,000

What’s the Problem?

So to reel this conversation back in, and make it instructional and not just another ranting voice on the Internet that the developers of this software will ignore, let’s talk about what it is about the auto-correct feature on your cell phone that makes it such a usability disaster.

The core problem is that it violates the usability principle that the user should always feel like they are in control of the software.

The users of your software should be the drivers, not the passengers. Ask Toyota how their ‘users’ felt about their products deciding independently that more speed might be nice .

If you are going to make your spelling checker jump in and autonomously decide it knows what the typist meant to say, it had better be right 100% of the time.  Is that bar too high? Well then stop making your app take over the controls. A well behaved app is heard and not stomping all over my carefully written prose and/or review of the wing place where I am currently receiving inferior service.

Not only does this implementation of auto-correct make the user feel impotent, it also violates the usability commandment that the user’s input is sacred. Violations of this principle contribute mightily to the computer-phobic person’s notion that the machine is going all SkyNet on them.

Extra Credit: Why do you think applications like MS Office that move your menu items around by usage frequency so infuriating? How about browser pop-ups?

Reinventing the Wheel – Let’s try square this time!

This would all be more excusable if a perfectly user-friendly auto-correct interface didn’t already exist. What’s more aggravating is that the existing workable system is so close to the new broken version that it is inconceivable that the designers of the new version weren’t familiar with the existing one.

Consider for a moment how auto-correct is implemented in MS Office, Blackberry OS, and the Firefox spell-checker. In almost identical fashion it gives you a list of suggested alternatives for the suspected misspelled word.  The key difference is that it SUGGESTS, but doesn’t CORRECT the user’s text unless the user takes affirmative action. This puts the user fully in control of the system, which makes them happy. Sure some typos may slip by the user, but if you are giving good enough visual indicators that should be minimized.

If only auto-correct had an anti-troll feature...

Is Anyone Listening?

Perhaps I’ve completely missed the point here, and there is a good reason why something that was routine on my old Blackberry is nigh impossible on the other smart phone platforms. If you have any inside scoop, or just have a convincing theory to share I’d love to hear about it in the comments. If you just want to complain about it, that’s fine too, maybe we can make this square wheel squeaky enough to get some satisfaction.

SQL Injection Prevention Fail

Well, at least they know that SQL Injection is an issue….

I just hope for the sake of the customers who bank at Sacramento Credit Union that the programmers responsible for this web site aren’t relying on blacklisting certain strings and/or characters as the sole means of protecting their system from SQL Injection attacks, but I’m not optimistic.

Regardless, this is also a classic example of taking a programming problem and dumping it in the user’s lap. If I’m a user of this site I would definitely be thinking, “Thanks for the lesson in cyber security, propeller head. Now can I just get on to finding out my checking account balance? I don’t really have time to do your job for you today.”

SQLInjection Fail

Here is the highlighted text, in case it is  difficult to read in the image:

Why are the Security Questions used?
The first time you login and enroll in Protection Plus, you will be asked to enter five Security Questions and corresponding answers. The Security Questions are used if you do not want to register the computer you are currently using. With the Security Questions, we can make sure it is you logging in when you use different computers, such as, a internet bar computer.

The answers to your Security Questions are case sensitive and cannot contain special characters like an apostrophe, or the words “insert,” “delete,” “drop,” “update,” “null,” or “select.”

Why can’t I use certain words like “drop” as part of my Security Question answers?

There are certain words used by hackers to try to gain access to systems and manipulate data; therefore, the following words are restricted: “select,” “delete,” “update,” “insert,” “drop” and “null”.

Computer Alcoholism

Ignore for a moment the sins of grammar and the promotion of “Security Questions” to a proper noun with all initial caps due thereto. What in the wide world of sports is a “bar computer?”

Are they referring to those video poker machines at bars? Are they implying it is not safe to use those machines to do my banking?

Oops – Inadvertent Demonstration of a Usability Problem

A few of you may have noticed an extremely off-topic political humor post yesterday on Software++.  It was actually intended for my a humor blog, The Prehensile Mind,  that I’ve been experimenting with lately. Sorry about the mistake.

What happened?

As it happens, it was a classic example of a special category of slip called a mode error.  A mode error arises when we perform an action appropriate for one mode, but we are mistakenly in another. It is easy to see how this could happen given the WordPress UI as it appears when you are managing multiple blogs under one account as shown below.

WordPress Mode Ambiguity

Which blog does the New Post button refer to?

Learning from our mistakes, and indirectly from other’s

In his book, The Design of Everyday Things, Donald Norman asserts that modes are evil, but a necessary evil where it is impractical to provide a 1-1 mapping of controls to functions. I suppose the takeaway here is the importance of caution when designing a user interface with multiple modes and communicating unambiguously to the user what mode they currently inhabit.

Other Surprises

In the comments, now deleted along with the errant post, I had one irate reader who threatened to remove Software++ from his RSS feed because he saw my “true colors.” I found it utterly shocking that someone would be so dogmatic about their ideology and hold their political heroes so sacrosanct that they’d find it unpalatable to read a blogger who didn’t share their own worldview. I was certain that I’d eventually lose some readers over my platform preferences or other technical opinions, but this shocked me a little.

I’d hate to lead any of my other readers on. So, despite the fact that it has nothing to do with this blog, I’ll be up front about it. I’m a Libertarian leaning conservative who doesn’t care much for the current administration, but is also sick of having to choose between two parties who continually play a game of good-cop/bad-cop so you can feel good about voting for one of them despite the fact that they are virtually indistinguishable from one another.

There. It’s out there.  Accidents aside, politics are going to stay on my other blog except where there is an angle germane to software development.

The Edge Case Usability Conundrum

blackberry_8820_911

A Usability quirk that is going to get me arrested one day

My blackberry has a button for “Place Emergency Call” on the front screen when the device is locked.  I can understand why it doesn’t require unlocking the device with my password to use it. Perhaps I’d need to call 911 using my elbows in the event that  severed all my fingers.

However, the downside is that I have more than once “pocket-dialed” 911 and recently while grabbing the phone, accidentally mashed some of the buttons, and it made a previously unfamiliar strange kind of beep. The display said “Emergency Callback mode” to which I freaked out and pulled the battery out so the cop couldn’t find his way over to tase me.

Insufficient Idiot Proofing

My first instinct was to write critical post about the poor UI design, but as proof of my subtle progress towards maturity as a blogger, and the fresh lessons learned from my overly hasty with criticism of DVD authoring software,  I took a step back and looked at the issue more objectively.

The authors of the BlackBerry firmware did put some effort into addressing the accidental 9-1-1 call.

  • Confirmation prompt must be dismissed before Emergency call is placed.
  • The default is “No” on the confirmation prompt.
  • It makes an obnoxious and distinct tone when you start an Emergency call.
  • The screen clearly displays “Emergency Callback Mode” when dialing so you don’t have to know the meaning of the auditory warning.

In the case of my button mashing, these precautions were effective. They alerted me the situation and guided me without confusion to a course of action to remedy the situation. However, it isn’t hard to come up with scenarios that could easily thwart these protections:

  • Pocket Dialing in a noisy environment
  • Child/Pet playing or chewing on the phone

Apparently I’m not the only clutz in the word either:

Suggested Design Improvements

Conflicting requirements is a key reason why it is so difficult to design effective Human-Device interaction. Here, the device needs to provide quick and easy access to the emergency call function while making it difficult to accidentally trigger it.

In this case it is clear to see that a compromise was necessary and the downside of not being able to get help in an emergency was clearly worse than an inadvertent emergency call, though still objectionable.  However, I do still see some room for improvement.

Idea 1:  Add a dedicated emergency call button to the physical device with a sliding door that clicks closed

Whenever the consequences of accidental activation of a feature are especially undesirable, I prefer a strong forcing function to a weak one like a confirmation dialog. Overloaded controls are inherently weak implementations of forcing functions because they don’t zap the user into a higher state of awareness that is necessary for doing big scary things.

That is exactly why the launch missile buttons have little acrylic covers on them. Unlike hitting a Y or N in response to a confirmation prompt, which the user is likely to blaze through out of habit because they have been pecking at they keyboard all day, the need to open the cover forces the user to engage in an activity that is markedly different to jar their brain into an attentive mode. Launch Button

This also works well, for prevention of accidental activation, which makes it relevant to the emergency call feature of the cell phone. In fact, I’d argue that it is a good fit whenever the following are true:

  • Very Undesirable Consequences
  • Infrequent need to activate functionality.

Idea 2: Get Rid of the Keyboard Shortcuts on the Confirmation screen

Shortcut keys have a very specific purpose, to speed up frequently used operations and thus make the operator more efficient. For the hypochondriac or drama queen, perhaps I would recommend a JitterBug or LifeAlert device instead. Adding multiple ways to confirm a function with big consequences is just asking for trouble.

Idea 3:  Make it vibrate when initiating an emergency call

This helps to solve the problem of pocket dialing in a noisy place.

Idea 4: Add a ten second countdown after activating emergency call mode

This would give the user time to react to the beeping and vibrating device and abort before any damage is done.

Why is DVD authoring software so horrible?

 I started to write this article as a usability critique after attempting to use NCH Software’s Express Burn software for DVD authoring. I fumbled about with it trying to memorialize my wife’s recent performance in “Wonderland” at the Bastrop opera house.

I kept insisting to myself that there is no way that any software company would let a UI out that required the user to watch the entire movie in real-time to insert the chapter labels. That’s right. No rewind, no fast forward. If you click too slow, well buster, you are starting over.

My wife finally got it to work and explained to me that “all I had to do” was burn a copy of the DVD as an image to the hard drive, then watch the movie using its unique timeline, dutifully write down each time-stamp when a chapter should start, save that into a file and then import the file into the software. Simple!

It made me want to get a management job at NCH software and fire everyone responsible for this software on my first day.

Update:  Turns out I was a bit hasty in derriding the design choices of this program on this particular element. It looks like it is merely a bug in the software and not the intended functionality (as evidenced in the help file) so I’ll cut them a little slack. However, my point about  this type of software being particularly crashy, freezy, and otherwise annoying stands.

Lowering the bar

Apparently this problem is so systemic that even the reviewers are making excuses for the software vendors.

DVD authoring software is computer system intensive and program shut downs are not uncommon. We looked for software that crashed less frequently and still created great DVD videos.
http://dvd-authoring-software-review.toptenreviews.com/index.html

 

Abstractions? What Abstractions?

Another area where this class of software seems to underperform is protecting its abstractions. I have to know too freaking much about the DVD formats and options at a technical level to use this software, for example:

  •  The nuanced differences between DVD-R, DVD-RW, DVD+R, DVD+RW, BD-R, BD-RE, BD-R DL, and BD-RE DL.
  • Whether PAL or NTSC make more sense for my video.
  • Data CD, Movie CD, or Movie on a Data CD?

Granted, some of these answers I know. However, why should I *Have* to?

Couldn’t all of these options be presented in a wizard that asks questions like “Different countries have different DVD formats, so I need to ask: What country will this DVD be used in?” They could even provide an expert mode where the acronym savvy guys who were in the A/V club in high school can get hyper-specific to their heart’s content.

Working Theories

I am working on a theory of why this general class of software is universally horrid and crash prone and my best theories so far are:

* The same buggy OEM software is built into all the major DVD authoring software.
* This is consumer grade software (meaning low priced) to do professional grade tasks. When cost cutting is afoot, it isn’t hard to see who typically feels it first. “Why are we wasting valuable resource on QA when our last three releases of the software didn’t have any major bugs?”

 

Appeal To Those in the Know

I’ve got to have at least one reader with inside knowledge of software companies that make this type of application. Do you work with this type of software or know someone who does? Am I missing some major reason that no one can create a stable platform to burn a DVD?

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

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

Updated Version of Existing Search Form

Retrospective

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?