Tag: HTML Forms

Eight Rules for Effective Web Forms

If you’re looking to collect information from your users, there isn’t a much easier or more straightforward method than a Web form. If designed well, Web forms provide valuable information; if not, they may scare users away. With this in mind, here are a few key tenets of Web form design that every designer should know.

1. Build Conservatively and Design With a Purpose
Let’s face it: No one likes spending a long time filling out a form. Keep it short and simple and eliminate elements that aren’t absolutely necessary or that don’t offer a tangible benefit. Make sure every part of your form is pulling its weight, and your users will thank you.

The structure of your form should serve just as much of a functional purpose as its elements. When laying out your form, keep in mind that, at least in the Western world, people read from top to bottom and left to right. They also often use the Tab key to move around the form. Your design should reflect this through intuitive labeling and natural placement of elements. And, of course, your form should never look scattered or haphazard — make sure everything is evenly spaced and neatly arranged.

2. Tailor Your Form to the Situation
Every form you make should be tailored to the specific situation it addresses. When you’re planning the design of your form, ask yourself the following questions: What are you asking? Why? What does your Web design look like with and without the form? Is the form something users want to fill out, or is it something they’re required to fill out? Your answers to these questions should help dictate the layout and content of your form.

3. Use What You Need
When deciding whether to add an element to your form, ask yourself if you could do without it. If the answer is “yes,” don’t use it.

One element that’s almost always unnecessary is the Reset button. These relics still make an appearance now and then, but they should be avoided. Think about it: When you want to change information on a form, it doesn’t matter if the field is already filled out or not, so why would you even need to erase all the information? The only thing the Reset button is good for is accidentally clearing all the information your user just entered and aggravating them enough that they’ll go somewhere else instead of taking the effort to fill out the form again.

4. Use Short, Clean Descriptions When Necessary
You may need to explain why you are collecting certain information on your form, especially when users are loathe to share it, like with phone numbers or e-mail addresses. This not only helps reduce user confusion, but also ensures that the data is accurate and correctly formatted.

Any descriptions and comments should be clean and concise. You may also want to format them with different colors, sizes, or styles to help set them apart. Just be sure not to overdo it — after all, you don’t want your descriptions to look tacky or drown out the rest of your form.

5. Be the First to Communicate
Make sure the wording in your form is friendly and user oriented. Here’s a simple trick for writing conversational copy: Pretend you’re actually talking with your user.

If you want to know someone’s name, you aren’t going to stare them in the eyes with a rigid expression and demand, “Full name.” That would just be creepy. If you were looking to garner a positive response from this person, you would instead open with a smile and say, “Hi, what’s your name?”

6. Divide the Form Into Bite-Sized Sections
Communication involves the exchange of ideas in small, manageable sections. You introduce yourself, and the other person does the same. You mention what you do for a living, and the other person has a comment or question. You remark back, or answer, and this prompts another response. In a good conversation, the information is a steady, back-and-forth flow.

A form, being another method of communication, should be the same way. You may be asking for quite a bit of information, but that doesn’t mean you have to throw it all at the user in a huge block. Try using horizontal rules, colored bars, meaningful images, or headings that match the design of your site to separate the information into small, easily understood chunks. If all else fails, spread your form out across multiple pages and add a progress bar across the top so users know about how much they have left.

7. Include Meaningful Contextual Error Messages
Your error messages should be helpful and clear. Specify in the message which field caused the error, and highlight the label and/or the field itself. After all, no one likes hunting through a form for an elusive field they overlooked the first time around.

8. Release the User
When the user clicks the Submit button, they think they’re done, and they’re ready to move on. They’re basically saying, “Here’s the info you wanted. Talk to you later!”

In a real conversation, you’d give them a wave, say, “Bye,” and walk off, or give them some other way of acknowledging that the communication is done. Your form should be no different. Have your form programmed so it sends the user to a custom page that tells them something like, “Thank you for your submission! You’ll be hearing from us shortly.” There should also be a link back to the main page of your Website.


HTML the Foundation of the Web

HTML is hot again. Some time ago the HTML5 promo machine got up to speed, causing a little mini-fuss. In a parallel universe, others are still putting a lot of time and effort into the development of xHTML2. This (public) renewal of interest in HTML caused plenty of discussion, revealing several blank spots in the general knowledge of HTML. This article will hopefully plug one of the most notorious holes shut.
For many front-end developers, HTML remains mostly an excuse. It is viewed as a language of hooks, constructed for adding javascript, css and other enhancements to web documents. In recent events, this kick-started a small semantics debate again, where people were reminded about the semantic value of HTML. A reminder voiced by raging standardista, still fired up from previously fought debates and awareness battles.
HTML != Semantics
Everyone with a passion for front-end development will recognize the importance of the standardista when it comes to HTML awareness. Yet this doesn’t mean that their methods should go totally uncriticized. With all the attention they raised for the semantic function of HTML, some people have started to see HTML as a purely semantic language. Which it is not.
Evidence of this can be seen in the “divitis” issue that followed the early rise of web standards. When front-end developers were urged to switch from table-based layouts to div-based layouts, some took the advice a bit too literally. They turned everything into divs, ignoring the semantic purpose of the elements at hand. This triggered an ever bigger reaction of the standardistas and led to demonization of the div element. Divitis was considered the AIDS of front-end development and using divs became almost taboo. Only when absolutely necessary were they allowed.
Enter Minimal HTML
The fear of purely structural elements (divs and spans) branched off a new movement. A group of people that didn’t believe in the absolute need for structural elements and tried to build pages with purely semantic elements as much as possible. They banished extra divs when used for styling but forgot about the original function of the div and span along the way. In the end, they made HTML a poorer language than it was supposed to be.
Consider the following two basic page layouts. A simple layout consisting of four main areas. The context area gives contextual information on the main content area. A layout like this (not considering any graphical design enhancements) could easily be made with four divs. This is setup A, preferred by minimalists. Setup B shows a situation where the layout is build using five divs. Take a moment to think which setup you prefer, purely on a structural basis.
HTML = Semantics + Structure
HTML is more than just semantics, it’s also about structuring your document. The main difference between both type of elements is that semantic elements explain the purpose of an element, while structural elements explain the relation of its content to the content of other elements within a document.
In setup A we have four separate divs, structurally all on the same level. This tells us all divs are related in the same way, only the order of appearance will indicate some sort of relationship. In setup B the main content and context area are grouped in a content div. This is an indication that the relation between context and main content is a lot stronger or at least different than the relation to the other element. And on the other hand, the content area shares a similar relation with header and footer.
Structurally, setup B not only holds more information about the relationship between the separate areas, it’s also more correct. This makes it the better implementation of the two. The extra div used to group main content and context is not useless, but adds useful meaning to the document.
The Future of Structuring
Luckily, the people working on HTML5 have understood this and added a couple of extra structural elements to the language. Instead of leaving us with a simple div and span, two elements with a simple structural meaning, they added elements like footer, header, article, section and aside to help us better define structures in HTML documents.
The fun thing about these elements is that they not only hold structural meaning but also semantic meaning. Instead of simply structuring a document they hint at the relationship elements bear to other elements or the page in general. Tags like footer and header not only contain a section of a document, they also hint at the function of the contained elements and the relation to the other elements on the page.
Hopefully this will give the opportunity to those suffering from divitis or minimalitis to write better structured code while keeping the document as semantic as possible. Until then, just know that a div has more power than simply adding a rounded corner or border to the graphical design. Structural elements are there to reveal relations between elements, a sometimes forgotten power of HTML.

HTML is hot again. Some time ago the HTML5 promo machine got up to speed, causing a little mini-fuss. In a parallel universe, others are still putting a lot of time and effort into the development of xHTML2. This (public) renewal of interest in HTML caused plenty of discussion, revealing several blank spots in the general knowledge of HTML. This article will hopefully plug one of the most notorious holes shut.

For many front-end developers, HTML remains mostly an excuse. It is viewed as a language of hooks, constructed for adding javascript, css and other enhancements to web documents. In recent events, this kick-started a small semantics debate again, where people were reminded about the semantic value of HTML. A reminder voiced by raging standardista, still fired up from previously fought debates and awareness battles.
HTML != SemanticsEveryone with a passion for front-end development will recognize the importance of the standardista when it comes to HTML awareness. Yet this doesn’t mean that their methods should go totally uncriticized. With all the attention they raised for the semantic function of HTML, some people have started to see  HTML as a purely semantic language. Which it is not.

Evidence of this can be seen in the “divitis” issue that followed the early rise of web standards. When front-end developers were urged to switch from table-based layouts to div-based layouts, some took the advice a bit too literally. They turned everything into divs, ignoring the semantic purpose of the elements at hand. This triggered an ever bigger reaction of the standardistas and led to demonization of the div element. Divitis was considered the AIDS of front-end development and using divs became almost taboo. Only when absolutely necessary were they allowed.

Enter Minimal HTMLThe fear of purely structural elements (divs and spans) branched off a new movement. A group of people that didn’t believe in the absolute need for structural elements and tried to build pages with purely semantic elements as much as possible. They banished extra divs when used for styling but forgot about the original function of the div and span along the way. In the end, they made HTML a poorer language than it was supposed to be.

Consider the following two basic page layouts. A simple layout consisting of four main areas. The context area gives contextual information on the main content area. A layout like this (not considering any graphical design enhancements) could easily be made with four divs. This is setup A, preferred by minimalists. Setup B shows a situation where the layout is build using five divs. Take a moment to think which setup you prefer, purely on a structural basis.
HTML = Semantics + StructureHTML is more than just semantics, it’s also about structuring your document. The main difference between both type of elements is that semantic elements explain the purpose of an element, while structural elements explain the relation of its content to the content of other elements within a document.
In setup A we have four separate divs, structurally all on the same level. This tells us all divs are related in the same way, only the order of appearance will indicate some sort of relationship. In setup B the main content and context area are grouped in a content div. This is an indication that the relation between context and main content is a lot stronger or at least different than the relation to the other element. And on the other hand, the content area shares a similar relation with header and footer.

Structurally, setup B not only holds more information about the relationship between the separate areas, it’s also more correct. This makes it the better implementation of the two. The extra div used to group main content and context is not useless, but adds useful meaning to the document.

The Future of StructuringLuckily, the people working on HTML5 have understood this and added a couple of extra structural elements to the language. Instead of leaving us with a simple div and span, two elements with a simple structural meaning, they added elements like footer, header, article, section and aside to help us better define
structures in HTML documents.

The fun thing about these elements is that they not only hold structural meaning but also semantic meaning. Instead of simply structuring a document they hint at the relationship elements bear to other elements or the page in general. Tags like footer and header not only contain a section of a document, they also hint at the function of the contained elements and the relation to the other elements on the page.

Hopefully this will give the opportunity to those suffering from divitis or minimalitis to write better structured code while keeping the document as semantic as possible. Until then, just know that a div has more power than simply adding a rounded corner or border to the graphical design. Structural elements are there to reveal relations between elements, a sometimes forgotten power of HTML.


  • Pages

  • Update by Date

    May 2012
    M T W T F S S
    « Jul    
     123456
    78910111213
    14151617181920
    21222324252627
    28293031  
  • make money with your web site

    Copyright © 2010 DESIGN Web Outsource. All rights reserved.
    Theme created by DESIGN Web Graphic | Powered by DESIGN Web Outsource