Usability and Mode Errors
What’s a mode error or a modal error? In usability speak, that’s when the user confuses the mode they’re currently in, causing a wrong or ineffective action. For example, when I click on a contact’s note on my Windows Mobile OS (which has a very low overall usability), and I open up the keyboard to enter a note with my stylus pen, I can’t – I’m in read-only mode (indicated by the lack of a blinking text cursor inside the note field). Only after I hit “edit” at the bottom will I switch to edit mode to be able to enter something. I committed a “mode error.”
Here are some more examples of mode errors:
- You hit “paste” but didn’t focus the input field, so nothing will be pasted.
- You hit Ctrl+Z on Windows (the “undo” short-cut) but the application doesn’t keep a history, and thus doesn’t support undo’s.
- You want to paint some pixels on a photo but you selected the “lasso” tool; the mode was indicated by a different cursor, but you didn’t notice.
- You sub-consciously “think” Ctrl+Z when you make an error writing with a pen on paper (hands up, who had this happen to them?).
As application developer, you know your interface needs optimization if users commit too many modal errors! For example, your mode indicator may be too subtle (e.g. the title bar of your application’s window turns from light gray to dark gray when it’s activated, a color change that’s easily missed). Or you’re introducing unnecessary modes: the “enter something into field 1” mode which uses different short-cuts from the “enter something into field 2” mode, even when field 1 and 2 seem to be related! (This is often a problem with Flash applications on the web, as they only emulate the OS modes up to a point, but don’t get things – like short-cuts or scroll behavior – completely right.)
But that doesn’t mean modes are always bad. If the system you’re working with can make an educated guess about what it is you may want to do at the moment, it can help you with your input to speed up the task. To list something annoying from Windows Mobile again: when you’re in your contacts list and you want to input a number into the phone number field, you’re offered the standard stylus keyboard. Now to enter a number, you need to hit the tiny keys emulating the top number row on a keyboard – these are so tiny because the whole keyboard, including letters from A-Z, are represented on the screen. But actually, you don’t need to enter A-Z in a phone number field, so it would make some sense for this application to switch into a “number optimized” input mode, displaying larger fields to click on.
As you can see with the Windows Mobile examples, in the first case the application makers delivered one mode too many: a read/ write distinction where it’s not crucial to have such (you can read a note while also being able to directly edit it). In the second case, the app makers did not provide a worthwhile mode distinction between number input and letter input (you can enter the letters A-Z into a phone field though you don’t need to, at least not in common circumstances).