When I was initially developing the bridge application a couple years ago, I had set up the Close button on several forms to be the Cancel button. That way a user can just hit the Esc button to close the form, if they prefer to use the keyboard.
As the applications for various clients have been used, this feature had become more of a bane than a benefit. It turns out that users hit the Esc key to Undo what they have typed, but the application would close the file. This results in some records being incomplete, causing errors when the application is processing.
While you can try to anticipate the user's experience as much as possible beforehand, some bugs still show up.
No big deal. I just removed that functionality from every bridge application we have in use so that program behaves in a way that users expect it to behave.
Wednesday, March 7, 2007
When the feature became a problem
Subscribe to:
Post Comments (Atom)
2 comments:
Users inevitably bring their expectations and habits of use to the table. I like developers that just acknowledge the reality that Microsoft Office dominates the business user market so you might as well have your navigation and keyboard shortcuts be consistent with MS Word's - whether you like them or not (Ctrl+P isn't Paste, it's Print). One example is Igrafx Flowcharter, one of my favorite apps: they have been dilligent about mirroring the expectations users come to the table with.
From a true systems perspective, consider the user an Object in the application with certain Properties i.e. their habits and expectations.
Thanks for the comments, Frank! I like the idea of considering the user as an Object with his or her own properties.
And congratulations on achieving the CFA designation!
Post a Comment