Virtual Developer Workshop: Containerized Development with Docker
Having a good user interface design is what separates the best web sites from the rest. Anyone can build a functionally sound web form. Building a web form that allows users to quickly and efficiently enter their data and move on is another story. Below are 5 common mistakes that often occur in ASP.NET web form development, as well as some general rules to follow in your web form design.
1. Incorrect Field/Label Alignment
A form usually consists of labels and input fields with a submit button. Probably the most common field/label alignment I see in use is left-aligned labels:
The problem with this alignment, as you can see, is that when a really long label is necessary, the input fields end up being extremely far away from the labels they are associated with. This may not seem like a big deal in the example above, but get a lot of fields on a really long form and it quickly becomes difficult for a user to determine which label goes with which input.
Another field/label alignment I often see is the use of top-aligned labels:
This solves the problem of the really long label causing a disassociation between label and input, but it presents another problem: a really long form. This alignment is fine for short forms with just a few fields, but for forms with a lot of fields, using this layout can cause your form to get long really quick.
My suggestion when creating web forms is to use right-aligned labels:
This solves both of the problems we saw with the previous two layouts. The right-alignment allows for a clear association between labels and inputs while helping to keep your form short.
2. Confusing Form Submission
Notice in all of the examples above that the input fields are vertically aligned, along with the submit button. This is the correct alignment. I often see submit buttons placed at the very left of the form or at the very right, sometimes even in the center of the page, but the best placement of the submit button is in alignment with the rest of the input fields. This allows users to focus their attention on the one straight vertical line of inputs instead of their eyes jumping around the screen.
In addition to correct button alignment, it is also best to help the user differentiate between the primary action on the page and the secondary action. You have several different options for this:
- Leave off the secondary action - this is my preferred method of handling submit buttons. In most cases, the secondary action on a form is a simple cancel button, which takes the user back to the previous page. If it's possible for the user to get back to the previous page in another way, either through the user of breadcrumbs or by closing out a modal popup window, I generally leave the cancel button off the form.
- Use different styles or colors of buttons - if having a secondary action on the form is absolutely necessary, use different colors and/or styles of buttons to distinguish between the primary and secondary buttons.
- Delete buttons should be different too - destructive actions, such as a "Delete" button, should be styled differently than both the primary or secondary buttons and should always be used with a confirmation popup message.
3. Required Field Confusion
Oftentimes, developers don't put much thought into marking required fields. I've often seen forms that have no indication of what fields are required until the user clicks the Submit button and the screen turns red with error messages. Other times, the screen is red when first opened because the majority of the fields on the form are required. Keeping in mind that our goal is to get users to quickly and efficiently move through the web form, the following rules help to minimize the initial markup on the screen while still providing the user with the necessary information to correctly complete the form the first time.
- Don't leave the user guessing - mark the required or optional fields when the page first loads. Mark whichever type there are fewer of. If most fields are required and few are optional, mark the optional fields. If most are optional and few are required, mark the required fields. A simple asterisk (*) next to the label as well as a message at the top of the form is usually sufficient to mark required fields ("* indicates a required field"). When marking optional fields, put the word "optional" in parentheses next to the label.
- If all fields are required, don't mark each field individually. Simply put a message at the top of the form that says "All fields required".
4. Vague Format Requirements
Again, with the goal of having users quickly and efficiently fill out a form, it is essential that we put some thought into input fields that require a certain format. One mistake I frequently see on web forms is relying on a Regular Expression Validator control to inform users when their input is not in a correct format. While Regular Expression Validators are nice and should definitely be used to prevent errors on the backend, it is also helpful to provide users with the knowledge they need to correctly fill out the application on the first try. This can be done in several ways:
- Limit the user's input - this is my preferred method of handling format requirements. There are so many ASP.NET Ajax-enabled controls out there that help developers with this kind of functionality that there isn't really an excuse to not use them. For things such as phone numbers or zip codes, use these controls to limit the user to only allowing data to be input in the correct format. In the examples below, the textbox controls would be Ajax-enabled to only allow numbers to be input.
- If you can't limit the user's input using Ajax-enabled controls, then you should make your control as flexible as possible. For instance, when asking for a phone number, you should accept phone numbers in as many formats as possible and deal with all of the different formats on the back end:
- 123 456 7890
Also, for fields requiring a specific format, you should always provide an example of a format that will work.
5. Over Reliance on Icons
Icons can be very helpful in a web form and can help dress up the screen, but one common mistake I see in web forms is relying too heavily on icons. While some icons are fairly well known across the web (e.g. a red X usually means delete), using icons only (and no text) for actions is generally a bad idea. A lot of times I will see web forms with icons used as action buttons where the action is only described in the tooltip when the user hovers over the icon. Again, keeping in mind the goal of allowing users to quickly complete our form, its best just to take the guessing out of the equation and always display words along with your icons. This prevents the user from having to take the time to hover each icon to find the desired action.
A good user interface can go a long way to improve the usability of your web form. The five common mistakes listed above are easily avoidable. Following the rules listed will improve your web form and the ease with which users complete it.