-
Get a monthly update on best practices for delivering successful software.
Nothing is more frustrating than having your software beep at you when you’re trying to do something you *know* it can do, and you’re flummoxed as to why it’s resisting your every effort to continue on with your work. All attempts are met with the same impersonal beep, whereupon you conclude that (a) the software hates you and (b) your only recourse is to begin swearing with enough proficiency and creativity to make a sailor blush. You just might be the victim of a mode error.
While modeless design may be an achievable goal for certain types of software, this approach isn’t always feasible for every project, to wit: not all data should be editable and when it is, not every user should have permission to edit the data. As software designers, then, we need to make our users aware of their current mode so they’ll know which actions are available to them. In addition, if the users have permission to switch modes, we need to make them aware of that as well.
In this vein, providing a mode distinction at the UI layer can help prevent wrong or ineffective actions from being taken. A mode distinction, that is to say a *worthwhile* mode distinction, should not be so subtle that it’s overlooked. Conversely, it shouldn’t be so distracting that it overtakes the page. And between these two points stand a wide range of solutions (which is why having visual designers on a team is not a luxury but a necessity). Having this distinction visible, however, helps to avoid the unexpected and undesired responses, minimizes user confusion and improves the usability of your software. All worthy goals.
Related posts:
Topics: Design, Design Patterns, Interaction Design, Usability