This comment from ApplesAndOranges misses the point:
What your companies app wants: full tax details as required by the government so we tax you the correct amount.
If your app wanted something as simple as google (a none specific set of words) you’d only have one input box and a button too.
To which I reply…that’s not really what this comic is about. A comic is not a literal statement of fact. Did you really think I was claiming — or even remotely implying — that a data-entry application can be written with a single field and button?
Using the specific example of tax forms, there are many competing tax software packages. Although all must collect the same data, their usability and efficiency varies widely. There is much more to this puzzle than a 1-to-1 mapping from data entry fields to database fields.
And using Apple as another example, contrast their MP3 player user interfaces with competing products. Again, all of these devices perform the same tasks and have the same data behind the scenes. Yet the Apple product is simpler and more efficient. We can apply many of the same design principles to tax software.
If you need to collect ten pieces of data, that is an essential complexity. But most GUIs are littered with accidental complexity. That is what the comic is about.
By and large, companies do NOT create good user interfaces. These apps do not need:
- Cluttered, sloppy GUIs.
- Poor keyboard navigation.
- Modal dialog after modal dialog. Modality is a cheap and lazy programming fix and is frequently abused. This locks users out when they need to browse to some other screen for research while in the middle of a data entry task.
- Bad scrolling, forcing users to reach for the mouse to see essential data.
- Weird data entry fields that interfere with “normal” typing. Avoid weird custom components that attempt to do auto-completion for things like dates and decimals unless they are PERFECT. Anything less interrupts the flow.
- Sluggish performance, such as making long server calls on the EDT.
- COBOL-like presentation that converts EVERYTHING TO ALL CAPS. (ick…ok, that’s just a pet peeve)
- 12 “extra” fields to capture unrelated data that some committee decided was important. (The truth is, there probably isn’t a committee. Instead, features creep in one-by-one from various interests throughout the company)
It is easy to tack on features. It takes focus and discipline to create exactly what you need, and no more. Sure, if your tax form needs N pieces of data, you’ll need N fields. But few corporate apps are that efficient.
And another comment from Steve Bennett:
(by the way, thank you for using your real name — I use mine)
Your company’s app is probably industry specific and will be used by a smallish number of people for hundreds or thousands of hours to do their job. Power, flexibility and efficiency become far more important than intuitiveness, beauty and user-friendliness.
I don’t think most custom apps are flexible, efficient, or powerful. How many times have you ordered something at a fast food restaurant and watched as the poor cashier struggled with a horrible GUI? I fail to understand how it requires 37 keystrokes to order a taco without lettuce.
Ease of use is a competitive advantage! If thousands of stock brokers spend thousands of hours using some proprietary tool, a quality GUI is damn important. I’ll even argue that fade-ins, animations, drag-and-drop, and overlays are also important, effective ways to convey additional information without cluttering the GUI.
But that’s pie-in-the-sky stuff. For the most part, I think typical apps don’t even get the basics right.