Developer.com content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
In the world of software, we often measure ourselves by our ability to innovate. It is at the very core of our being that no matter what something is, we know we can and should do better. The longer something has been done a particular way, the more we see it as something in need of disruption.
Although this general worldview is great when applied to most things; when applied to basic data entry applications results can be an endless funhouse of user disappointment.
The Universal Language of Boring Data Entry
The core data entry widgets are made up of textboxes, checkboxes, radio buttons, and drop-down lists. These core widgets have a set of behavior that is understood by as nearly universal of a group of users as can be imagined. Adding to this core set is a fairly common set of second-tier widgets that most users are familiar with including datepickers, sliders and combo-boxes. Most users can also use these fields without any kind of issue.
If your data entry form is comprised of nothing but those classic widgets, you are highly unlikely to trip up a novice user who is attempting to complete your form. The behavior of these input widgets is very well understood by even the most novice users.
There are some widgets that have existed for a long time that many users still don’t know how to use correctly because they are non-essential to how they use computers including the multi-select list, shufflebox and pop-up look-up field. Although all three of these widgets have existed for a very long time; time and again when I see casual users presented with these fields they don’t understand how to really work them.
Many users don’t know that they can hold “CONTROL” to choose more than one item in a multi-select. They click an item on the shufflebox and don’t intuitively know that it isn’t really selected until it is moved to the right-side box because the shufflebox looks very similar to a multi-select box. They don’t understand that clicking the magnifying glass that pops a dialog is supposed to have them search on and pick something for the main form.
Most users can use these widgets but there is a non-trivial portion of the general public that will be baffled by them.
This Problem has been Solved. Let’s Unsolved it.
All of the standard widgets have a clearly understood contract for how they should behave. If a user sees a square box with a downward pointing arrow on the right side of it, they have an expectation that they should be able to click that box or arrow and be presented with a list of options where they can choose one item.
Over the last several years as browsers have become more capable, an increasing number of web applications have implemented non-standard widgets that utilize complex JavaScript to create behavior that doesn’t match with user expectation.
If a designer comes up with a new and novel method of data entry, when a user sees the widget on the form they have no pre-conceived notion of how to interact with it. In effect, the designer is demanding the user learn this new thing to complete this form. Even if the new widget is brilliantly designed, some number of users won’t figure it out and some number of users won’t realize it’s a data entry widget at all because it doesn’t exist in their vocabulary of data entry fields.
This is made more problematic when the non-standard behavior is done applied to a standard looking widget. For example, imagine the user sees a checkbox on a page. The expectation is set that they should be able to click that checkbox to select or deselect the item. Imagine the user’s surprise when a menu appears when they check the box! Many users would see the menu and interact with it as the designers imagined, some will work with it but be annoyed by the behavior not matching expectation and some users won’t see the menu at all because they weren’t expecting it and have moved on down the form.
Skinned to Death
When Flash first allowed developers to aggressively style form widgets, many designers went absolutely nuts. They creatively made form widgets that looked like a Mac no matter what OS the user was on. They made standard form widgets look like no OS in existence. Some even went as far as re-skinning checkboxes into smiley faces indicating checked and frowned faces indicating not-checked. Fairly quickly, these early users of Flash learned that just because Flash allowed an unlimited amount of skinning doesn’t mean all that power should be used. Heavily skinned forms went from being all the rage to something more muted in order to improve accessibility to the general population.
We are now seeing a second wave in web design of aggressively skinning standard form input widgets until they only remotely resemble the widgets natively found on the operating system the user is using. Although younger users will typically adapt well to changing user interface trends, older users or users that don’t spend the majority of their time using web applications will run into challenges with non-standard skinning being applied to standard elements.
A dropdown list must be immediately recognizable as a dropdown list, a textbox as a textbox, a checkbox as a checkbox, etc. The less a widget looks like the standard version of the widget the user’s OS, the more likely they are to misunderstand it.
Innovation is Dead. Long Live Innovation.
None of this is to say that there aren’t many welcome innovations being done in the user interface world. UX in general is a hotbed of exciting innovation and cool concepts. Likewise, there are many creative things that designers can do to make applications more efficient to operate for skilled or trained users.
All of that said; when designing data entry applications for the general public, fear innovation. Be innovative enough to be boring.
About the Author:
David Talbot currently works as a Principal Architect at EverBank. He has over 15 years of experience in the software industry and specializes in building rich UI web applications. He is also the author of Applied ADO.NET and numerous articles on technology. He can be reached at david@legendarycode.com
