Web Application Design Patterns- P2

Why Users may not want to fi ll out forms and provide personal information unless they understand the benefi ts they will get in return and how it helps them FIGURE 2.1 LinkedIn clearly l

CHAPTER 2 Forms

16

It ’ s important, however, to remember that web applications are developed using HTML and do not offer all the form controls available on popular plat-forms such as Windows and Macintosh Specifi cally, the interaction in web applications is limited to the following form elements: text fi elds (single line and multiline), radio buttons, checkboxes, dropdown lists, scrolling lists, but-tons (including image buttons), and a special control to browse fi les Some

of the missing controls are spin control, combo-box, tree control, and tabs Although these controls have been implemented using some clever combina-tions of HTML, CSS, and JavaScript, they are workarounds and not true con-trols because they are not available as part of the basic markup language

CLEAR BENEFITS

Problem When presented with a form, users may not understand how fi lling it out and submitting it helps them accomplish their goals and tasks

Solution When designing, clearly indicate benefi ts of fi lling out and submitting forms This is particularly important when users are creating a new account (i.e., regis-tration forms), which is the fi rst step before many web applications allow them access to their functionality ( Figure 2.1 )

Why Users may not want to fi ll out forms and provide personal information unless they understand the benefi ts they will get in return and how it helps them

FIGURE 2.1 LinkedIn clearly lists the benefi ts of registering in the section “ LinkedIn helps you … ”

achieve their goals In addition, they may be concerned about the security

of their personal information, since they may not know how it will be used

Clearly indicating benefi ts and addressing users ’ concerns about security and

privacy are the fi rst steps in ensuring that users will not abandon the forms

How

Users should be made aware of the benefi ts of fi lling out forms, even if it’s just

a one-fi eld form like signing up for email newsletters ( Figure 2.2 )

EXPLAIN THE BENEFITS OF REGISTERING ON LOGIN FORMS

When users view the login form, and if they are not registered application users,

it’s a perfect opportunity to describe registration benefi ts to them This makes it

easy for users to decide whether they want to register or not ( Figure 2.3 )

EXPLAIN THE BENEFITS BEFORE LEADING USERS

TO THE FORM

In many cases, users have to be led to a form If they don’t know the benefi ts,

they may not bother to click the link or button that leads them to the form

Therefore, it’s important that the form’s benefi ts are described before users

Clear Benefi ts

FIGURE 2.3 Blockbuster lists the benefi ts of signing up with Blockbuster.com and offers

a “ free ” trial period as an added incentive for registering

FIGURE 2.2 User Interface Engineering (UIE) lists benefi ts of signing up for their email

newsletter, “ UIEtips ”

CHAPTER 2 Forms

18

get to the form One way to accomplish this is with clear link labels, such as “ Transfer Money ” or “ Pay Bills, ” instead of generic link labels, such as “ Learn More ” or “ Continue ” When benefi ts may not be clear to users, it helps to describe them near the action ( Figure 2.4 )

Increasingly, web applications offer functionality and benefi ts that may be

dif-fi cult to explain with just a few statements Or, even when the benedif-fi ts are clear, users may want to learn more about how the benefi ts are realized when using the application To explain such functionality in detail, offer users options to learn more about how the web application works and reduce their anxiety about fi lling out any required forms ( Figures 2.5 and 2.6 )

Related design patterns For many complex web applications and those that require users to pay upfront, consider offering a “ CLICK-TO-CHAT ” option (see Web Appendix: Help), which allows users to ask questions directly to a qualifi ed company representative

SHORT FORMS

Problem The more information users provide, the easier it is to understand their profi les and tailor the application to better suit their needs and provide more relevant

FIGURE 2.4 Plaxo describes the benefi ts of becoming a member alongside the sign-up button, and for new and unfamiliar concepts, they offer users the opportunity to learn more through a demo or a tour

FIGURE 2.5 Prosper (a marketplace for money borrowers and lenders) provides information about how borrowing and lending works using “ How to Borrow ” and “ How to Lend ” links

and personalized information However, long forms increase the chance of

users not fi lling out the form or providing false information

Solution

Make forms as short as possible ( Figure 2.7 ) Do not ask users for any

informa-tion that “ may be useful ” in the future If addiinforma-tional informainforma-tion fi elds may

help and cannot be removed, offer them as optional and indicate them as such

(see the REQUIRED FIELD INDICATORS pattern later in this chapter for more

information)

Short Forms

FIGURE 2.7 Signing up with Crazy Egg requires users to enter only three pieces of

information and agree to the terms of use and privacy policy Furthermore, by integrating

the form with corresponding benefi ts, users clearly know what they are going to receive in

return

FIGURE 2.6 In addition to showing the benefi ts of blogging (publish thoughts, get feedback,

etc.), Blogger provides information about blogging through the “ Take a Quick Tour ” option

How Analyze each form element for its importance and the downside of not including

it in the form In addition, consider how easy it would be for users to provide the information If users have to think about how to respond to an item in the form, consider it as an obstacle to completing the form, and then consider removing it The most quoted “ simple ” form page is probably Google’s, which on its search page simply presents a text entry fi eld and search button ( Figure 2.9 )

Jottit is another example of the shortest and perhaps most effective form ( Figure 2.10 ) To create a Web page, users simply type in what they want on their page and click “ Create a Page ”

FIGURE 2.8 In a study reported by Relevant Ads, the conversion rate decreased with an

increase in the number of form fi elds ( Source: “ Form Conversion Analysis: Less Is More, ” www.relevantads.com/results/Form-Conversion-Analysis.aspx )

FIGURE 2.9 Google’s search form is the simplest and shortest Although it includes the “ I’m Feeling Lucky ” button, many people usually enter their search terms and click “ Google Search ”

or press “ Enter ” on their keyboard

DIVIDE LONG FORMS INTO MULTIPLE PAGES

WITH SHORTER FORMS

Group information in a long form so that each group is focused on a

sub-task, and present form elements related to each group on a separate page

( Figure 2.11 ) In addition, order groups so that the most important and

required information is presented fi rst and optional information later

Splitting forms makes fi lling out each page faster, and users are more likely

to perceive them to be shorter as compared to the entire form presented on

one page

Related design patterns

Once forms are made as short as possible, make them appear even more

man-ageable by indicating to users the required information (REQUIRED FIELD

INDICATORS), grouping and ordering form elements logically (LOGICAL

GROUPING), and ensuring that users are aware of the benefi ts of fi lling out

the form (CLEAR BENEFITS) In addition, consider using the WIZARDS

pat-tern for forms that are split into multiple pages (see Chapter 5)

Short Forms

FIGURE 2.10 On Jottit, to create a Web page, users simply enter text and click the “ Create a

Page ” button (a) Users then get their Web page and an option to edit it (b)

(a)

(b)

Solution Group form elements such that it is clear to users the type of information required by each group (e.g., shipping information, payment information, and

so forth; see Figure 2.12 )

Why Grouping information such that users can clearly see what is expected from each group and how form elements relate to their corresponding group can make forms appear easy to fi ll out and manageable Users are more likely to think of the form in terms of the smaller collection of groups instead of a larger collection of individual form elements

How Group form elements according to their functions such as shipping address, billing address, contact information, and so forth For each group, ensure that the order of elements matches users ’ mental model of how information should

be entered For example, for users in the United States, organize address-related form elements so that users are asked fi rst for street address, then city, and then

FIGURE 2.11 Meebo divides the registration form into several pages It shows the most important, the sign-up portion of the form, upfront and uses subsequent pages to help users set up their accounts and preferences

state and zip code, or for setting up account information, ask for username (or

email address) fi rst and then password ( Figure 2.13 )

Once groupings and form elements in each group are identifi ed, order

them according to user tasks and system requirements For example, in an

e-commerce checkout fl ow, it is better to ask for shipping information fi rst

because it can be used to calculate tax and shipping charges, so that on the

bill-ing page users can be shown the total price and an option to indicate that their

billing address is the same as their shipping address ( Figure 2.14 )

Logical Grouping

FIGURE 2.12 Yahoo! groups registration form elements and divides them into logical groups,

which makes the form appear manageable and easier to complete

FIGURE 2.13 Apple makes checkout forms appear more manageable fi rst by dividing them into several pages and then by logically grouping elements on each page

CHAPTER 2 Forms

24

Related design patterns Grouping form elements may suggest that the form be split up into multiple pages to make it appear shorter (SHORT FORMS) or that it be structured so that data entered by users in earlier groups prepopulate fi elds in later groups (SMART DEFAULTS) so that users don’t have to go back and refer to previously entered information

LABEL ALIGNMENT

Problem Labels and corresponding form elements need to be clearly associated with one another to make form fi lling easier and to minimize user input errors

Solution There are three acceptable placements for labels in relation to form elements: above the element, with their left edges aligned with the elements; to the left, with their left edges aligned with other labels; and to the left, with their right edges aligned to other labels ( Figure 2.15 )

FIGURE 2.14 Dell, like many e-commerce applications, presents shipping and payment information in separate steps to make forms appear shorter and allows users to focus on one chunk of information at a time

Label Alignment

Why

The faster users are able to associate labels to corresponding form elements, the

faster they will be able to fi ll out forms In an eye-tracking study, Penzo (2006)

found that users are able to easily associate labels with form elements with any

of the three common label placements shown in Figure 2.15 However, the

eye-tracking data showed that when fi eld labels are left aligned, excessive

dis-tances between some labels and their input fi elds (which happen because not

all labels are the same length —for example, “ Company Name ” compared to

FIGURE 2.15 The common placement for labels are above the form elements (a), left aligned

(b), and right aligned (c)

(a)

(b)

(c)

CHAPTER 2 Forms

26

“ City ” ) cause users to take more time to interact visually with the form When compared with left-aligned fi eld labels, the overall number of fi xations was reduced by nearly half with right-aligned fi eld labels, thus greatly reducing the cognitive load required for users to complete the task

The same study also demonstrated benefi ts of placing fi eld labels above form elements; this style had the shortest form-fi lling times One downside of plac-ing labels above form elements is the additional vertical space that it requires However, if the form is to be translated into different languages, it main-tains the layout’s visual integrity because different languages require different lengths for the same labels Placing labels above form elements thus allows for necessary text expansion of labels when localizing the application (see the EXTENSIBLE DESIGN pattern in Chapter 10)

How

To associate labels correctly with corresponding form elements (for languages that read left-to-right), place labels either to the left or above the form control (Penzo, 2006; Wroblewski, 2008) When placing fi eld labels to the left of form elements, right align the labels so that they are closer to each other ( Figure 2.16 ) When placing labels above form elements, it’s important to provide enough visual separation between the label for the next form element from the previ-ous form element (Penzo, 2006); Wroblewski (2008) recommends a separa-tion of about 50 – 75 percent of the height of a single input fi eld In addition, Penzo (2006) recommends using plain-text labels over bold-text labels because the latter are a little diffi cult to read ( Figure 2.17 )

USE EMBEDDED LABELS SPARINGLY

Embedded labels are acceptable for forms that have just a few input fi elds ically one) and when most users are expected to be familiar with the nature of the input such as search terms ( Figure 2.18 ) Because embedded labels are in the fi elds themselves and have to be removed when users focus on them, they are not visible once users have entered data in them Therefore, they are not

(typ-FIGURE 2.16 PriceGrabber places labels to the left of form elements but right aligns them

useful for long forms or forms where users are less likely to be familiar with

data they are expected to enter

Related design patterns

Labels in forms are generally accompanied by indicators for required

informa-tion (REQUIRED FIELD INDICATORS)

REQUIRED FIELD INDICATORS

Problem

Users must provide certain information to complete a task successfully For

example, when setting up an account, users often must provide email addresses

and passwords However, to improve user interaction, forms may ask for

addi-tional opaddi-tional information, which users may not want to provide or may not

know at the time Leaving out required information would lead to error

mes-sages and increase the time it would take users to accomplish tasks

Solution

Clearly indicate required information on forms so that users can complete

a task successfully and reduce the chance of encountering “ missing required

information ” messages ( Figure 2.19 )

Why

Not only does visually distinguishing required fi elds save users time from

deciding what information to provide, but it also saves them time dealing with

Required Field Indicators

FIGURE 2.18 Apple uses an embedded label for the search fi eld (a) The label disappears

when users click in the search fi eld or start entering search terms (b)

FIGURE 2.17 Basecamp uses plain-text labels above the input fi elds

do not rely on color alone to communicate information to users; because the asterisks have both shape and color coding, they are accessible to people with color-vision defi ciencies as well Other forms of indicating required information (e.g., making the fi eld label red and bold) is not preferred because often such visual styles are used to indicate errors within the page In addition, changing colors may not be accessible to screen readers, and people with color defi ciencies may have trouble distinguishing between required and optional information Although there may be other ways to indicate required fi elds with both shape and color encodings, using a red asterisk is recommended because most users ’ experience on other web applications have likely habituated them to associate red asterisks with required information; the asterisk’s color may be different depending on the page’s background color

TIP

On login pages, users know that both usernames and passwords are required Therefore, indicating them as required is not necessary

FIGURE 2.19 Dominos identifi es required information using red asterisks, thus making it clear to users that a cell phone number is optional It also indicates how providing a cell phone number would benefi t users

SHOW THE REQUIRED FIELD INDICATOR LEGEND

Although most Web users will recognize red asterisks next to fi eld labels as an

indication of required fi elds, some web applications use this symbol to indicate

optional information Therefore, it helps to be clear and indicate at the top of

the form that items marked with an asterisk (*) are required

PLACE REQUIRED FIELD INDICATORS CONSISTENTLY

ON ALL FORMS

There is no clear evidence about the effi cacy of required fi eld indicators ’

loca-tion in relaloca-tion to fi eld labels; they are found in any of the following areas:

after fi eld labels, before fi eld labels, before input form elements, and after

input form elements

However, considering that when fi lling out forms, users ’ eyes are near form

ele-ments, showing required fi elds closer to form elements makes the most intuitive

sense In addition, placing them in a consistent location helps users quickly scan

forms and identify required information This may be accomplished by placing

required fi eld indicators to the left of form elements when labels are placed to

their left and aligned right ( see Figure 2.19 ) For top-aligned labels, place required

fi eld indicators to the left of labels ( Figure 2.20 ), as they would then be closer to

both fi eld labels and form elements where users enter or select data; placing them

to the left of form elements may become confusing when showing checkboxes or

radio buttons, as users may feel that selecting that option is required

DO NOT INDICATE OPTIONAL FIELDS

In situations where a form has fewer optional fi elds, there is a tendency to

mark optional fi elds, as opposed to required fi elds, to reduce clutter This is

Required Field Indicators

FIGURE 2.20 TravelPost shows required fi eld indicators to the left of labels, which are

positioned above the form elements However, note that they make labels bold, which is not

recommended, since bold labels increase the time it takes to complete a form (Penso, 2006)

CHAPTER 2 Forms

30

a poor practice Because of users ’ familiarity with other applications, most of which use required fi eld indicators, they are more likely to consider them as required or at least be confused about what is expected of them

PROVIDE INSTRUCTIVE TEXT FOR REQUIRED SENSITIVE INFORMATION

If information asked of users is personal in nature, such as their birth date, der, or race, clearly indicate why the information is required In addition, provide

gen-a link to the “ Privgen-acy Policy ” informing users how their informgen-ation will be used

Related design patterns Even when a form clearly shows required fi elds, designers should still strive to minimize the total number of fi elds on a form—both optional and required

fi elds (SHORT FORMS) In addition, when users fail to provide required mation, show them a message on the same page as the form with the required information (ERROR MESSAGES)

SMART DEFAULTS

Problem With every additional form element, both the total time it takes users to fi ll out the form and chances of potential errors increase In addition, for multipart forms, if users have to reenter the same information, not only would it increase the time required to complete the form, but also require the application to check that the information was entered identically each time

Solution Use appropriate default values based on what users are most likely to choose

or enter; this may be based on their previous input or selections ( Figure 2.21 ) However, do not prepopulate form elements required for confi rmation (e.g., reentering password, or users agreeing to have read terms and conditions of use) or related to security (e.g., resetting password)

Why Providing good default values minimizes the need for users to enter or select data This decreases the total time to complete the task and reduces data input errors In some instances, using defaults may completely eliminate the need to fi ll out the form and reduce users ’ task to simply verifying informa-tion For example, on e-commerce applications, users who have previously provided shipping and billing information (and consented to saving the infor-mation) need not go through the entire checkout process Instead, they can

be presented with a review/confi rmation page with a “ Place Order ” button Because most users are not likely to change shipping and billing information