MyPage is a personalized page based on your interests.The page is customized to help you to find content that matters you the most.


I'm not curious

Top 5 mistakes Developers make while designing forms

Published on 12 May 15
2818
0
1
Top 5 mistakes Developers make while designing forms - Image 1
Good user interface design is what distinguishes a best web sites from the rest. Building a web form is easy and anyone can build it, but building a web form that allows users to quickly and efficiently enter their data and move on is idealistic.

Here are 5 common mistakes that Web Programmers often make in web form development:
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:

Top 5 mistakes Developers make while designing forms - Image 2

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:

Top 5 mistakes Developers make while designing forms - Image 3

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:

Top 5 mistakes Developers make while designing forms - Image 4

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.

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.

Top 5 mistakes Developers make while designing forms - Image 5

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.

Top 5 mistakes Developers make while designing forms - Image 6

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.
Required Field Confusion
Often at times, 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 mark up 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".

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 back-end, 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 text box controls would be Ajax-enabled to only allow numbers to be input.

Top 5 mistakes Developers make while designing forms - Image 7

  • 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
123.456.7890
123 456 7890

Also, for fields requiring a specific format, you should always provide an example of a format that will work.

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 tool tip 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.

Conclusion
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.

Source: http://www.codeguru.com/csharp/article.php/c18493/Mistakes-in-Designing-a-Web-Form.htm




























Top 5 mistakes Developers make while designing forms - Image 1

Good user interface design is what distinguishes a best web sites from the rest. Building a web form is easy and anyone can build it, but building a web form that allows users to quickly and efficiently enter their data and move on is idealistic.

Here are 5 common mistakes that Web Programmers often make in web form development:

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:

Top 5 mistakes Developers make while designing forms - Image 2

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:

Top 5 mistakes Developers make while designing forms - Image 3

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:

Top 5 mistakes Developers make while designing forms - Image 4

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.

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.

Top 5 mistakes Developers make while designing forms - Image 5

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.


Top 5 mistakes Developers make while designing forms - Image 6

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.

Required Field Confusion

Often at times, 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 mark up 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".


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 back-end, 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 text box controls would be Ajax-enabled to only allow numbers to be input.


Top 5 mistakes Developers make while designing forms - Image 7

  • 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

123.456.7890

123 456 7890

Also, for fields requiring a specific format, you should always provide an example of a format that will work.

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 tool tip 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.

Conclusion

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.

Source: http://www.codeguru.com/csharp/article.php/c18493/Mistakes-in-Designing-a-Web-Form.htm

This blog is listed under Development & Implementations Community

Post a Comment

Please notify me the replies via email.

Important:
  • We hope the conversations that take place on MyTechLogy.com will be constructive and thought-provoking.
  • To ensure the quality of the discussion, our moderators may review/edit the comments for clarity and relevance.
  • Comments that are promotional, mean-spirited, or off-topic may be deleted per the moderators' judgment.
You may also be interested in
Awards & Accolades for MyTechLogy
Winner of
REDHERRING
Top 100 Asia
Finalist at SiTF Awards 2014 under the category Best Social & Community Product
Finalist at HR Vendor of the Year 2015 Awards under the category Best Learning Management System
Finalist at HR Vendor of the Year 2015 Awards under the category Best Talent Management Software
Hidden Image Url

Back to Top