Forms vs. People
What do users dislike most about the Web? It’s almost certainly filling out forms. And by a crazy coincidence, what do Web developers find the most challenging aspect of their work? Forms must certainly rank high on the list.
Forms are that locus in the interface where the differences between humans and computers come to a head and must be reconciled. The website needs to acquire data from user. But the human mind doesn’t have data, but rather, facts, feelings, opinions, preferences, questions, and a host of other kinds of information which are anything but data. Data is what you end up with when the required information has been captured successfully.
Using an MVC paradigm, form challenges can be outlined thus:
Challenges for the model
- Data must be logically arranged for quick retrieval and meaningful reports.
- Data must meet business logic requirements.
- Data must be ‘clean’, accurate, and ready for storage or manipulation.
Challenges for the controller
- Data must be cleaned to prevent against possible attacks.
- Data must be of the correct type, i.e, strings, dates, integers, etc.
- Data must collected in such a way that it can be parsed, combined, and stored easily.
Challenges for the user interface
- Forms for gathering data must be easy to understand and easy to use, for all potential users, including those with disabilities, slow connections, and all supported platforms and browsers.
- Forms must be long enough to capture the required information, but not so long that the user tires and quits without submitting information.
- Forms must anticipate what cannot possibly be known with certainty: How to best prompt the user to share the necessary information so the site can convert it to data.
As a UI developer, I have the most experience with the last three issues. The last one is by far the point which businesses are most likely to get wrong, and yet assume they’re actually doing it right. It’s where users can fall through the cracks.
Prompting the user
“Prompting the user” for this information comes with a slew of difficulties.
Quite naturally, the UX/UI team (and by this I mean all persons involve with creating the UX/UI — graphic designers, product planners, and developers) might assume the user is just like them, and design the form so that it would prompt them to enter the correct information.
A graphic designer’s first instinct is naturally to design a form that looks good. Product wants a form that will funnel desired information into business data, and UI developers want a form that will be simple to build and reasonably future-proof. Note that no one’s first thought has been about how the user will understand and interact with the form.
If this doesn’t sound like a recipe for disaster, it should. The times and ways in which this approach does not work can be extremely costly, and difficult to detect, although they can easily be avoided.
The way to avoid this is:
- Know your users
- Test the form
- Ask for feedback
- Think of who might fall between the cracks
Numbers 1-3 above are well-known, though not always well-practiced. However, the fourth point seems to me rarely thought of. An assumption is that if the form is working, it’s working for everyone, as long as online tests and focus groups (you do have focus groups, right?) show no complaints.
But it’s precisely the fourth point that might have the most bang for the development buck. Think about who might be falling through the cracks.
Clouding the issue
Take, for example, this screenshot I took years ago from a survey form on the Borders website. The first page had no problem, but the second page presented me with this train wreck:
In case you’re wondering where’s the horrible usability issue, the problem is that the form is asking me to make what I found to be an impossible choice. I’m a book lover, and I was buying books from many different sources: Amazon, Borders, B & N, and my local independent store as well.
My specific recommendations would depend on which friend (or colleague) this was, and their own priorities regarding the particular item they’d be interested in, e.g. cost, convenience, immediacy.
The key problem here is that subtle, but needless complexity comes into the question. Borders probably wanted to ask me something like “Would you recommend Borders to a friend? If not, which of these options would be your first choice?” And if put that simply, the answer would have been a simple “yes” to Borders.
But instead, the fuzziness of the question caused me to overthink the possibilities. I ended up abandoning the form, writing a blog post about it, and within months, Borders was no more. (I’m not saying this was cause-and-effect, but hey.)
A fact about forms and the transmutation of information into data is that unlike a name or telephone number, many kinds of user information can be vague, difficult to describe, and changeable. A prime case in point is the religion question, which appears on many social media sites. On American web forms it’s usually presented something like this:
Select Your Religion
- No religion
There are more ways a customer could fall through the cracks with these choices than I care to think about. Hindus and Buddhists might resent being relegated to “Other.” Ditto for Eastern Orthodox Christians and Mormons. Furthermore, anyone who’s a member of multiple religions, or is questioning their religion, or prefers to say nothing about their religion, might well abandon the form if they cannot skip the question.
A better solution might be something like this:
Describe Your Religious Views
(Check all that apply)
- Other Christian
- Spiritual, not religious
- No religion
- Something not listed above
- Prefer not to say
With only a few more choices and the presentation of checkboxes instead of radio buttons, the user can express a very wide variety of religious affiliation. Note also that changing “Other” to “Something not listed above” takes us away from the possible perception that minority religions are not worth distinguishing, to the understandable fact that the website cannot list all possibilities.
Forms can also cause users to fall through the cracks when developers assume limitations on form data without checking to see if those limitations are valid.
Is your website likely to be used in Indonesia? Better not make both “First Name” and “Last Name” fields required; Millions of Indonesians just have a single name.
Are you going to have East Asian users? Try using “Family Name” and “Given Name,” because in China, Taiwan, Korea, and Japan, the family name usually is first. “Family Name” ensures that the surname goes into the correct field.
Do you require at least two letters for a name? You just invalidated U Thant, former Secretary-General of the United Nations. And Kenny G and Mr. T won’t fare any better with your form.
Email validation occasionally shows the assumptions of the coder rather than the actual requirements of a valid email address. For example, when I signed up for service with my current ISP, I was informed via an error message that I needed to enter a valid email address instead of the one I had been using for over ten years to receive tens of thousands of messages! Apparently the coders for this national(!) ISP were under the impression that a username had to be at least three characters long. Mine was simply two characters followed by my domain name. I ended up using a different email address, but not before writing a complaint to the company, and a public blog post excoriating the form for its erroneous error message. Developers, please don’t trust a regex validation without consulting the actual specifications.
A Better Web
We can make the Web a little bit better for everyone, by making forms better. The key is for everyone who influences the design and workings of the form, including product designers, graphic designers, and web developers to ask and research, “who might fall through the cracks?”
There’s probably something worse out there somewhere, but I certainly haven’t seen anything this bad in a long time. This is the bottom nav bar on all the pages at Roget’s Hyperlinked Thesaurus.
You actually have to use almost all the sections of the site before the navigation starts to make sense. Oh, and that group of three circles second from the end? That’s an “i” for information. But of course you knew that, right?
Have you seen worse? Comment and let me know!
I just learned that an email address I’ve been using for ten years, and through which I’ve received thousands of messages is invalid—at least according to this ISP’s validation script!
Here’s the output I received (of course, I’ve changed my address for this post):
Invalid? Really? A username with only alphabetical characters, followed by an “@” sign, followed by a domain name, a period, and the world’s most popular top-level domain? I realized the only possible reason (and not a good one) was that the programmer assumed no one could have a two-letter username. Poor guy probably just signed up for Gmail and ended up with something like
email@example.com because all the other joeschmoes were already taken.
Fine and good, but it is a gross error to force your assumptions on users. There are any number of sites which offer email validation scripts and regular expression filters for what actually are valid and invalid addresses. Just making a guess with a less-than-complete ass is inexcusable for a company that provides Internet service to thousands.
Testing my hypothesis, I added a random letter:
Voilà! Satisfied that I was no longer a devious two-letter miscreant trying to slip past the wise validator with bogus credentials, it happily let me continue. I wouldn’t have been so surprised if it were a small online boutique, but from this company?
As the old joke goes, when you assUme, you make an ass out of u and me.
For many reasons, thinking about web forms in User Interface / User Experience has generally concentrated on the flow of thought, guiding the eye, visibility of elements, navigation, security and of course, accessibility.
However, one thing that’s often overlooked is just as important, and will stop some people in their tracks from completing a form: stupidity.
Take, for example, this extract from a survey form from an affiliated site a major bookseller. Although I generally have many better things to do than click on links on my email to fill out online surveys, this was a lazy Sunday, so what the heck? First page, no problem. Second page presented me with this train wreck, such that I not only couldn’t continue, but had to post this to vent my frustration:
In case you’re baffled, wondering where’s the horrible usability issue, the problem is that the form is asking me to make an impossible choice. I’m a book lover, and I buy books from many different sources: Amazon, Borders, B & N, and I try to support my local independent stores as well, (which I wish I did more often). My specific recommendations would depend on which friend this is, and their specific priorities regarding the particular item they’d be interested in, e.g. cost, convenience, immediacy.
The key problem here is either/or choices are being forced upon the user, when the user may not necessarily think of the situation as being remotely exclusive, but as subtle, nuanced, and inclusive of many factors.
Check boxes would be what the doctor ordered here. This is a glaring problem on many forms. Users cannot give detailed, meaningful feedback on how they see things, if the form presumes to know a priori how they see things. This applies to more things than one might initially suspect.
Take the common fieldset “Select Your Religion” that you see on many social sites. Invariably the user is presented with list of popular choices (usually ending in “Other”) and a slew of radio buttons. This design undoubtedly works for many people, but it doesn’t for those who are questioning their religion, leaving it, changing it, or seriously exploring another without intending to make a complete conversion. These people might be better served by something more like: “Please Indicate Your Main Religious Preference(s)” and choices marked by checkboxes.
Is this overly picky? I think not. In the case of the choice of religion on a social networking or dating site, inappropriate either/or choices may indicate a bias against unconventional choices, particularly if the list is short.
In the case of the bookseller mentioned above, it conveyed a sense of not wanting to understand my preferences, which implies to me that they’re also not really interested in changing to help meet my needs and gain more of my business.
Bottom line: If you want honest, detailed feedback from users, or to make a positive impression on them, do not try to force the user’s mind to fit your form. Mold your form to allow them to express their mind.
I wrote an article for the new online Web design magazine, 13things, entitled “Horizontal Flow: The Magic of Row-Based Design.” In it, I examine what the effect of column-based design has been, advantages of using rows to recapture the organizational effects of the grid that were largely lost when we abandoned table-based layouts, and some novel ways of ordering content into rows. Hope you enjoy it.
Working on a new MacBook is like worshipping in the temple of the Goddess of Beauty.
Ok, I’ve got to admit that Chrome has lost a bit of its luster as far as I’m concerned. For instance, for one of my projects, I need to use Central Desktop, an excellent project management site. Unfortunately, it’s one of several sites that Chrome can’t handle. Not that Safari or even Opera can either. I’m revising my earlier assessment of Chrome. I now regard it as a souped-up version of WebKit, that still has most of the flaws that Safari does. That’s not to say it’s a bad browser by any means… it’s superb. But for my browsing as well as my Web development, I’m relying on Firefox again.
However, Chrome offers a lot of promise. According to marketshare.hitslink.com, Chrome seized 0.78% of the worldwide browser share in less than a month on the scene, a phenomenal achievement. If the Google staff commits to really developing it, with full plug-in capability, solidness in handling intensive Flash-based Web apps. and fixing the long-standing problems with WebKit (such as the alternate stylesheet issue), Chrome will undoubtedly go far. (Unfortunately, it will also probably go far if they do nothing and leave it at version 0.2 for three years. They’re Google, after all.) I really do want to see the Web improve and browsers improve, and Chrome can offer a lot.
Since downloading Chrome two days ago, I’ve had the chance both to work and play with it, and I must say I’m tremendously impressed.
Chrome is fast. Very fast. The difference is especially noticeable on high-bandwidth connections. (On my DSL connection at home, it’s fast, but not breathtakingly so.)
At first, I thought, “Great, Chrome is nice, sleek, and fast, a great Web-surfing tool, but only Firefox has what I need for development.” Well, I was wrong. The “Inspect Element” feature of Chrome (accessed by a right-click) is like a simplified, more intuitive Firebug, combined with the best of Aardvark and most of the best of the Web Developer Toolbar. CSS infomation can be seen for every single element, including default styles and declared styles, and you have the option of showing inherited styles as well. In addition, styles that are overruled are indicated as such by a strike-through, and every declared style affecting the element has its precise location shown.
“Metrics” gives a diagram of the box model on any block-level element, with the rendered padding, border, and margin in pixels. If you select the Resources button and reload the page, it will generate a beautiful chart listing every file loaded and diagraming when it began and finished loading with its order in the entire assembly. The HTML is also be automatically validated. The flip side: The “Size” button is entirely non-functional. No file size or image dimension info is available. Also,there’s nothing that has the functionality of the “Edit CSS” option of Firefox’s Web Developer Toolbar. I miss the capability of a simple right-click to view background images.
Yet overall, Chrome’s development tools are impressive and eminently usable even at this initial level.
A few aberrations in Chrome’s behavior have been noted. Chrome doesn’t like Facebook much. For instance, clicking on “Join this group” simply refreshes the page. Also, apparently Chrome misbehaves regarding some alternate stylesheets. It doesn’t with the alternate stylesheets on my other site, so I’m not sure what is the exact syntax that triggers it.
As a diehard Firefox user, the lack (thus far) of any plugins for Chrome is a definite minus. Different people will have different gripes, but here are mine:
- Chrome is ugly! Please let me skin you!
- I really, really, really want to be able to use my del.icio.us bookmarks in a sidebar.
- Edit CSS and a quick-and-dirty View Background Image, please.
I thought another gripe would be not being able to change search engines in a single click as with Firefox, but with a wonderfully simple and quick hack, you can actually switch search engines faster in Chrome.
Chrome uses the same box for searches and typing URLs. To work with other search engines, right-click in the location bar and choose “Edit search engines…” If you simply want to make a different engine your default search tool, select the “Make Default” option. But it you want to be able to switch to a different search engine on the fly, click the “Edit” button and abbreviate its keyword. On my computer, I abbreviated yahoo.com to just “y,” and amazon.com to “am.” To instantly change the search engine, just type the keyword, a space, and your search term. This is actually much faster than selecting the desired search engine from a dropdown box as in IE7 and Firefox.