Linked by Thom Holwerda on Sun 11th Nov 2007 15:52 UTC
Graphics, User Interfaces This is the fifth article in a series on common usability and graphical user interface related terms [part I | part II | part III | part IV]. On the internet, and especially in forum discussions like we all have here on OSNews, it is almost certain that in any given discussion, someone will most likely bring up usability and GUI related terms - things like spatial memory, widgets, consistency, Fitts' Law, and more. The aim of this series is to explain these terms, learn something about their origins, and finally rate their importance in the field of usability and (graphical) user interface design. In part V, we focus on modes.
Permalink for comment 284049
To read all comments associated with this story, please click here.
Mode of application
by DonQ on Sun 11th Nov 2007 22:10 UTC
DonQ
Member since:
2005-06-29

Slightly off-topic (in context of user interface usability), but real-world story:

We develope an accounting software. In one sunny day we got very irritating support call from one of our customers:
"I did enter many documents into database and all these are missing, only the last one is present!"

What happened actually?

In new version, we allowed our software users just overwrite document contents without any explicit mode change command. In old version, users were forced to hit NEW button before entering new document (eg invoice) or hit EDIT button to edit old document.

Users, not seeing old version of our software, didn't have any problems - they did know that like everywhere in Windows, overwriting something destorys old content. But some users of old version, having accustomized to explicit mode changes, assumed somehow that overwriting old content creates new one.

We solved this problem easily - we included one (optional) button/command to force user into edit mode. This way old users had two commans - EDIT or NEW, which changed interface mode to "edit mode" and there was no more problems with document overwriting.

Interestingly, this approach created big annoyances for developers and testers ;) I had many times entered screenful of data in attempt to repeat customers problem - just to notice, that particular database has this "expilicit mode change option" turned on and all my input went into nowhere ;) Well, solution to this problem was easy enough - when our application detected that it was run under IDE (debugger), this option was disabled automatically ;)
--
What I wanted say with this comment - user interface (or application) mode is really important, especially in multitasking/windowed environment. In old DOS (commandline) times, there was no such problem present - entire user interface was usually straightforward, there were no possibilities to break program flow.
--
What about CAPS LOCK key - there's only one key worse than it - I mean NUM LOCK key. I've recieved many calls about "I can't enter any numbers into Excel datasheet", hitting NumLock has resolved all these problems ;)

Reply Score: 1