When the feature became a problem

Posted by Daniel Johnson, Jr.
March 7, 2007

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.

bridge application, lessons learned, peo, programming

Did you enjoy this post? Why not leave a comment below and continue the conversation, or subscribe to my feed and get articles like this delivered automatically to your feed reader.

  • Frank Galea

    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.

  • Daniel

    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!

blog comments powered by Disqus