On the Label, Label, Label

Our server is OTL right now after an attack, heavy sigh, but while others were doing some of the heavy lifting at various times, I had a few extra minutes to do some reading. Yesterday I decided to dive into details of interest to me related to html forms. Forms are the face of web pages from a data processing perspective or data processing from a web design perspective.

Regarding the design of forms, I had made a number of decisions early on based on research at the time. These include:

Tabs for Large Forms: Perhaps the most controversial of the decisions is that we would handle large forms by splitting the form fields into logical sections on multiple tabs in a single page. The tabs in any given page are not necessarily just different parts of a form, they could be tabs where the user makes a selection from a table too, for example. The key of this design is not to dump a ton of fields into a single tab, in general, but to split them up to make for a good user experience.

I just filled out a form on a new site where after I filled out one part they popped up another section. It was very cool and rather disconcerting. I had no idea what or how much would pop up. There are advantages to seeing named tabs in front of you, even ones you cannot yet access (at various times).

One of the first responses we got from a developer looking at an early build was that we should have an entire form on a single tab to streamline the user experience. Rats. I’ve been working on that module a lot lately to nail down a good workflow, among other things. Once we are ready for real user experience testing, maybe you will be willing to give feedback on whether the tabs work for you. If they don’t, well, uh, we will work on how to make them work rather than ditching them.  Decisions regarding the overall site navigation strategy, which is likely also controversial, would be easier to change than our tabbed approach.

Labels above input fields, left justified: I did about 1 hour of reading on this tiny topic of where to locate the label, which some of you think was way too much, I’m guessing. I chose labels above, rather than to the left of, input fields. I also decided on no colons after the label text. I spent less than 10 seconds on that decision. A graphic designer chose the font, font size, and font colors that I implemented with css. I will spend no more minutes on these decisions before we are live d.v. A textarea in one of our forms looks like:


Input field lengths all the same: There are some exceptions, but having the start and end of each input field be along the same vertical lines as the other input fields helps to minimize visual noise in a form. The alternative is that each length is determined by the developer based on what data is usually placed in the field or perhaps based on some fixed maximum length for the field. Having them all the same has the downside of giving no visual cue as to the anticipated length of a field.

There is another downside. I have spent well over 20 hours, I suspect, trying to get IE and FF input field lengths the same, to no avail. Apparently our toolkit which generates pages with no DOCTYPE, tossing browsers into quirks mode, is just plain not gonna get us there with the packaged components, although there are enhancements in the works that might help. The issue at hand is the dreaded IE box model combined with the old-fashioned table-based layout.

The added problem is that if I get the textareas (such as Street above) and single line of text input areas to have the same length in one browser, they are different lengths from each other in another browser. So it is not just that the lengths are different in different browsers, but that I have to choose one to be both right and left justified and the other to have input controls that have a jagged right hand side. Argh.

From my research yesterday, I have added to these decisions the following:

Labels in sentence-case rather than title-case: Currently our labels are mostly in title case like First Name. We have plenty that are still in developer form like the camel case of FirstName or whatever label the developer feels like putting on a field at the time they code it. So, we need to go through and review all field labels. That is why I decided to study this detail again. I decided to go with what seems to be an ISO standard (who knew?) of using sentence case, such as First name. OK, decision made now on that, but it will require this minor change to most of our labels, so while we are at it, better think about the following too.

Labels as short phrases instead of simple nouns: This is the more complex question for me. Is it a better user experience, resulting in more conversions (as marketing types would say), to have a form label of Enter your password for this site, Password for this site, or Password? I know it would be a better user experience never to ask for any password, but that is beside the point. I read a little and did a few experiments with myself as the user (yeah, I know), and decided that short phrases might very well give a better user experience. Hmmm.

No decision on this yet, but the examples of Street and First name show up a problem with short nouns like this. Even among the English-speaking world, these are not completely clear labels. When you translate such nouns, the problem is compounded. Making a phrase in each language that provides for more clarity might be a good plan.

We can put the power of an entire 1970’s computer room for a large business into a cell phone, but we don’t have names and addresses licked from a data processing perspective. That’s a topic for another day, but speaking of names and addresses, here’s what would seem to be a no-brainer, but is the most important of label standards.

Make trustworthy labels: I’m going to go out on a limb and suggest that we want to be sure that users can trust our labels. Below is a form I filled out early last week with dates from this past weekend (which  I can no longer select, so I’m showing it with next weekend dates). I had July 20 as my Resume Date and had the Post Office delivers accumulated mail checked. When my mail had still not been delivered by 4pm on the 21st, I drove to the Post Office. I told them I was expecting it to be delivered the previous day. They said “Oh, yeah, we don’t do that because you might not be home yet and then it just builds up.”

Of all the various issues with forms and labels, I’m thinking that whether there is a colon or not really doesn’t compare to the issues of labels and fields that give you a completely false impression of what will happen. I’ll have to give the award for my Worst Web Form Experience of the Summer so far to the US Post Office. Their form made a commitment, but they did not deliver.

Hard to see the problems with this form, but...

Hard to see the problems with this form, but they didn't deliver

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s