Linked by Thom Holwerda on Sun 11th Nov 2007 15:52 UTC
Permalink for comment 284049
To read all comments associated with this story, please click here.
To read all comments associated with this story, please click here.
News
Linked by Thom Holwerda on 05/21/13 15:53 UTC
Linked by Thom Holwerda on 05/20/13 22:43 UTC
Linked by Thom Holwerda on 05/20/13 21:50 UTC
Linked by Thom Holwerda on 05/19/13 23:15 UTC
Linked by Thom Holwerda on 05/19/13 23:11 UTC, submitted by Drumhellar
Linked by Thom Holwerda on 05/18/13 21:06 UTC
Linked by Thom Holwerda on 05/18/13 7:37 UTC
Linked by fran on 05/18/13 1:38 UTC
Linked by Thom Holwerda on 05/17/13 23:35 UTC, submitted by kragil
Linked by MOS6510 on 05/17/13 22:22 UTC
More News »
Sponsored Links



Member since:
2005-06-29
Slightly off-topic (in context of user interface usability), but real-world story:
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

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
--
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