How to make Web Forms the perfect friendly user interface

Last week we introduced the first part of our survey of Web Forms. The main purpose of the research is to provide some theoretical basis for designers and developers who can judge the effectiveness directly. We also introduced guidelines for how to make Web forms a perfect friendly user interface.

We focus on the registration form by separating more key forms (such as validating forms). We then complete the registration form for each selected site and analyze the design methods of those forms. Here we introduce the second part of the study-the results of 100 popular Web Forms.

Please note that this article is not about validating the form-that's another topic for discussion, and we're going to look at it as an article that's about to be discussed independently. We would like to thank Wufoo for providing us with a framework to guide our investigation.

3, the function of the form

In the first part of the study, we have carefully considered the layout and visual representations of the registration link and the registration form. But if the form does not work correctly, the design is not good, the completion rate of the form is still very low. Let's now consider the typical issues of registry functionality and how to design them.

3.1.hover,active,focus-effect in use?

Obviously, to improve the completion rate of the form, designers try to avoid various distractions and provide a clear and simple Web form. That's why any visual effects need to be used very properly.

• 84% of Web Forms do not have any kind of hover, active, or focus effect.
• 16% the effect of using very subtle mouse moves.

3.2. Help, support, tool tips: static or dynamic?

Sometimes, the label for the input area is not clear enough, but the user needs to understand enough to provide this information. What character format does the user name apply to? What is the limit of the number of characters in a password? Does the email address that is provided automatically become the login name used?

The user minimizes the number of times the input box is reconsidered by helping with suggestions and tricks. And there's nothing more annoying than the fact that the input box doesn't look exactly right, but it's not acceptable. To avoid this problem, designers (usually) use unobtrusive but clear hints of advice.

57% of the Web Forms in the survey report have only "static" help hints, which are just a few of the previously presumed user-related hints that are obviously placed next to the input box. 10% of the action tips usually occur after a few help icons are clicked or when the user enters information.

3.3. Help, support, operation tips: Where should I put it?

When providing help to your users, be sure to help them simply and easily be found and understood. This is the determining factor in making sure that the user does not make the form wrong by helping the prompts. To achieve this goal, you need to know where the user wants these help to appear. So where do these help and hints usually fit into the form?

If help hints appear, they will appear in ...

• Under the input area (57%)
• On the right side of the input area (26%)
• Above the input area (13%)
• On the left of the input area (4%)

We notice a strong trend that the cue information is placed directly below the input box. Usually this kind of help hints have slightly different colors, most of which are lighter than the main content.

3.4. Input confirmation: Static or Ajax dynamic?

Last year, many websites seemed to be full of Ajax apps to interact with users, but Ajax still hasn't managed to reach a tipping point in popular web services. Surprisingly, we can't recognize the trend of Ajax. The "classic" confirmation technology that users have entered all the information click submit button is still more popular than the real-time confirmation of JavaScript.

According to our research:

• A 30% form displays an error message at the top of the form. (no indication of which input box is problematic)
• 29% of the form will prompt the appropriate action help next to the input box (no error message is provided at the top)
• 25% of the form uses both error messages and input box hints.
• The 22% form is prompted with real-time validation of Ajax.
• 14% use JavaScript for error reminders.
• The 1% form is a reminder with system information and gives a "back" link.

3.5. Design of error messages

As you can see, we have identified 6 different kinds of error prompts. Obviously, 14% of the forms still use the JavaScript error window to communicate the problem (for example, YouSendIt, Mail.ru, Newsvine, Clipmarks, Yandex, see the screenshot below), but only 22% Use AJAX acknowledgement (usually used to confirm the validity of the username). Of course, it is also obvious that no site has any confirmation.

Newsvine uses the JavaScript error window to communicate the problem.

Usually the designer tries to report the wrong way of using it. A, after clicking the Submit button to display the error message, B, in the visual high light "incorrect" input box. The first error condition is usually displayed as a piece of information at the top of the page (before the form). The second scenario is usually to light the border color of the wrong input box and the imported label (mostly red and red background colors).

Sometimes designers combine two techniques and take advantage of input areas for high light error messages. For example, take a look at the Ning combination of the two technology registration form (see screenshot below)

Typically, red is used to mark errors, but in this case it is not necessary. When the form is complete, tickspot, mixx.com, and furl use yellow to indicate the problems encountered.

However, if there is any color to indicate the success of the registration, it should be green, 97% of the site that the success of the vision is to use green.

3.6 Is it necessary to confirm the email?

Only 18% of sites need to confirm email (for example, Odeo, Ning). To be honest, we really don't have any reason to allow users to repeat the email address, after all, users can see what they're losing because the area of the email address doesn't look like a password region, does it?

3.7 Is it necessary to confirm the password?

It's a good reason for users to be aware of input when they don't see what they're losing (they see an asterisk instead). But many web sites take two of confirmation steps to shorten the time it took to complete the registration form.

72% is necessary to confirm the password, but many sites such as Facebook,friendster,linkedin, StumbleUpon, pownce, and Twitter do not require a confirmation password.

3.8. Do you need to use a checksum code?

If the check code is removed, the user must be happy, but in fact the check code is necessary, because the site needs to prevent the garbage registration software to create a lot of garbage accounts, otherwise they need to keep the database filter out these accounts.

According to our investigation,

• 52% of websites do not use parity codes.
• 39% of the Web site can not refresh the page without refreshing the checkout code in real time, this is really in the usability of a very bad thing.

But we still can't see whether the registration form requires a trend to check the code. In any case, if you use a checksum code, make sure that it is readable, or that the user can refresh the checksum code in real time in an unreadable situation. Some sites do not provide real-time refresh check code functions, in addition to Digg,aol, Slashdot, Google and so on. FM is able to make the check code can be heard, when it is difficult to identify the time.

3.9. Do you need to use the Cancel button?

When we think about the design of the form of some of the problems we thought we would encounter, we expect the registration form does not cancel the button, because after all, all the options have been filled out, for the user does not have much meaning to exit the form. However, we are in some way wrong.

Only 8% of the cases use the Cancel button, and some of the cancellation buttons appear just below the terms and conditions of the agreement (for example, Zoho Writer). So if the user does not agree to the terms of service, they will exit the process. On the other hand, some services provide a payment scheme (for example, Crazyegg) before registering. In this case, when the user chooses the wrong payment scheme, they need to use the Cancel button to return and select another better payment scheme.

Besides: We still don't understand why Dzone put the cancellation button on the left side of the registration form.

If you use the Cancel button, 4% of the situation is placed on the right side of the submit button. Observed in these sites, the cancellation and submission buttons do not have a very strong visual distinction and are also being caught together. From the usability point of view, it is more meaningful to distinguish between the main action and the secondary action visually and to distinguish them with clear gaps.

3.10. The alignment of the submit button

Considering the style of the form, it is meaningful to align the submit button to the left, right, or middle. 56% of the designers put the submit button to the left, the second is 26% to the center of the button alignment.

Right-aligned submit buttons are still more prevalent (17%), but are generally indicative of the need for next steps. In these cases the submit button is often titled "Continue" or "next". The reason: Usually the "Next" button in desktop software is on the right.

3.11. Thank you for your information

A few years ago, most services offered a simple, basic thank-you message (usually with a login link) after a successful registration, and now most sites are trying to motivate users to explore their services immediately.

• 45% of websites require users to provide more information after they have completed their registration, find their friends on their websites, or invite their friends to use their websites.
• 33% of the form will use a friendly and appealing tone to point out "where to go Next" (Web Site feature exploration).
• The 4% website provides a basic "thank you" message.
• 2% is a direct jump to the home page.

More discoveries

• The tag index is used in 99% of cases (except HABRAHABR)
• The 24% form uses a conversational tone that attempts to reach the user's needs through a marked conversation. In this environment, it is often used like "What's your name?" "," your email please tell me? "or" I want to ... "and other informal statements.
• 38% of the Web site rather resolutely choose the formal business tone, friendly to let users fill in the required information. (For example, "Your username", "Confirm password", and so on)
• 38% of Web sites use system language, users are required to "log in", "User password", "address" and so on.

Profile

Let us make a brief review and summary of the above research. Please remember that we only consider registering the form.

• The registration form does not have any hover,active or focus effects (84%).
• Hints and help whether static (57%) or dynamic (33%) appear below the input box (57%) or to the right (26%).
• Status confirmation is as popular as dynamic validation. Of course Ajax is not a trend
• 82% No Email confirmation required
• 72% Password Confirmation required
• Check code available (48%) can not be used (52%)
• 92% No Cancel button
• The Submit button is left-aligned (56%) or center-aligned (26%)
• Thanks for the information to inspire users to continue to explore the site's services (45%)