If you were plowing a field, which would you rather use? Two strong oxen or 1024 chickens?
The first brewery in America opened in 1642 in Hoboken, New Jersey
- Blog Categories
- Software (29)
- Music (11)
- Life (4)
- Cars (3)
- Randomness (4)
-
Web Form Usability
After about 20 minutes of really trying to register at AMD's support site, I've come to the conclusion that it's just not possible. No matter what values I place into the form, I am always brought back to the same page with the *=required field message. I finally broke down and called them on the phone. Of course, I wasn't able to talk to a real person until an automated message walked me through all of the great, easy, convenient, and time-saving features available at their newly re-designed web site.
I have a feeling that I'm not alone in my frustration.
Web forms should be easy. There is no excuse for a web designer (or a developer given the task of designing the usability and look of a form, which too often is the case,) to design something like this. This is not 1995. We have tools, we have experience, heck - we're even getting paid more than ever (OK, not as much as 1999, but you know what I mean.) Did these people not try their final product? Did something else break that's causing the application to act stupid? Maybe I'll never know the answer to these questions, but I now keep this experience in the back of my mind when I'm given the task of designing a web form.
Feeling the need to write something about the simple usability of web based forms seems a bit odd to me, as we have all been using them for the past 10 years. But apparently, this type of writing is still warranted, as non-usable forms like those found at AMD are still being developed today. And we all know that AMD of all people should have their shit together.
What's missing from AMD's forms?
Well, besides the fact that they don't work, the user isn't given any feedback. Feedback is the most essential element when trying not to frustrate a user. Keep in mind though, that too much feedback is almost as bad as no feedback at all. So we need to find a happy median. A simple combination of textual and, more importantly, visual feedback will have our users keeping their heads on straight.
Textual feedback
This one is easy. Just give the user a list of things that's wrong with the form. This requires that each field is given a label (a good idea anyway.) Let's set up an example form that loosely follows a typical account creation form:
Now, some would argue that some instruction is warranted at this point. For example, letting the user know that the e-mail address must be in the xxx@xxx.com format, or that the telephone number must be in xxx-xxx-xxxx format. Let's see how something like that would look:
Admittedly, some of these examples are a bit extreme (like the 100 character limit,) but the point is that this clutter is simply not necessary. If they enter the e-mail address in the wrong format, we'll let them know at that point. 99% of the time, we won't get to that point. The only place I feel this is warranted in our example here is the password field. Since the higher-up, figure head, pointy haired people come up with the craziest requirements for what they see as an acceptable password, we should let the user know ahead of time what will fail validation.
Imagine the following situation:
It's pretty obvious what's going on here. The user is notified of the exact problem locations. This is good. A lot of sites fail to even get this far.
Visual Feedback
On our simple form, the textual description might be enough for the user to find and correct the problem in a short amount of time. But what if the form was complex (think IRS 1040.) How can we make the location of the problem incredibly obvious? How about this:
If you can't figure out what the problem is now, then its hopeless. This is where we want to be. To the point where the user simply has no doubt how to proceed. I'm sure there are many alternatives to what I've described above that will have the same effect. Just make sure your form is dummy-proof. It's easy. It's cheap. And it will make for a much more enjoyable on-line experience for your users.
p.s. I do realize that this post has a complete disregard for any and all accessibility issues (like color blindness.) I have no experience in this area, and am not one to give advice regarding it.
Monday, April 10, 2006 11:45 PM EDT0 Comments Filed in: Software -
Error Styling in Struts
In light of my last post, I'd like to discuss a new facility available in Struts to apply error styling to your form fields. Since Struts 1.2.5, all form elements now have the optional errorStyle, errorStyleClass, and errorStyleId attributes. These are meant as a means to define the styling of particular form elements that have failed validation (which I think is a pretty good idea.) Imagine the following form definition:
<html:form action="/processForm">
User Name
<html:text property="userName">
Password
<html:text property="password">
<html:submit>
<html:form/>
Now, lets suppose we wanted to place a 2 pixel red border around each text field that fails validation. This can be accomplished by adding the desired error style attribute to the text fields, and defining the corresponding style. In our example here, we'll use the
errorStyleClassattribute, which means that the framework will apply aclass="fieldError"attribute to the rendered input field. Alternatively, we could use theerrorStyleIdanderrorStyleattributes, which will apply theid="fieldError"andstyle="given style rules"attributes respectively.<html:form action="/processForm">
User Name
<html:text property="userName" errorStyleClass="fieldError">
Password
<html:text property="password" errorStyleClass="fieldError">
<html:submit>
<html:form/>
And in your css file:.fieldError { border:2px solid red; }Now, lets suppose the password field has some crazy requirement that is has to be between 4 and 5 characters, the first two characters must be digits, the third character must be a 'special' character, and the remaining characters can't be digits. (I know, its a bit of an exaggerated example.) The user has forgotten all of these rules and enters an invalid password. The following html will be rendered:
<form action="/processForm.do">
User Name
<input type="text" name="userName">
Password
<input type="text" name="password" class="fieldError">
<input type="submit">
<form/>Thus applying the fieldError style rule to the password field and drawing a 2px border around it. Simple right? Yes its simple. It's too freaking simple! I'd like to vent a bit about the following frustrations I have with this:
- - The error style attribute has to be applied to all individual fields
-
At first, I thought this must be a mistake. I'm sure the following question has crossed at least some of your minds upon reading this post: You mean I have to add
errorStyleClass="fieldError"to ALL of my form elements? Yes, you do. And yes, ITS RIDICULOUS! I just want all failed validations to include theclass="fieldError"attribute when rendered. Is that so much to ask? Why can't I applyerrorStyleClassto the top level form element and have ALL the fields on the form inherit this attribute (like thedisableattribute?)A possible solution to this might be to add a custom implementation of the struts html tags that will apply this class for you. I personally don't think that this is a good idea, but it would work.
- - The
errorStyleClassandstyleClassattributes are mutually exclusive -
That's right boys and girls. If you apply a style to your form element using the
styleClassattribute, they will be forgotten in favor of yourerrorStyleClassdefinition upon failed validation. COME ON! There is no reason why the struts developers couldn't have simply added the class definitions given in theerrorStyleClassattribute to the list of classes given in thestyleClassattribute. This must be a product of 'design by committee'. Because of this obscure behavior, we now have to use unique error style class names for each element that already defines a style class. Not to mention duplicating the style rules across both class definitions.If you take the above approach to alleviate yourself from adding the
errorStyleClassattribute to every form element, it may also help in this situation. Your custom implementation could check if a style class or list of style classes was given, and simply add the error style class to the list. Again, this is possible and will work, but I'd hate to be the one to maintain it and explain it to new developers.
0 Comments Filed in: Software