Abstract
When an interactive form in the world wide web requires users to fill in exact dates, this can be implemented in several ways. This paper discusses an empirical online study with n = 172 participants which compared six different versions to design input fields for date entries. The results revealed that using a drop-down menu is best when format errors must be avoided, whereas using only one input field and placing the format requirements left or inside the text box led to faster completion time and higher user satisfaction.
1. Introduction
Most websites use interactive online forms as the main contact point between users and the company. The design of these forms can be a crucial factor for the success of online transactions. Users do not visit a website with the intention or goal of filling in a form. Focusing on the example of online shopping: once users have chosen the items that they wish to buy, they want to complete their shopping as quickly, easily, and safely as possible. In this context, a form may often be perceived as a hurdle. If they are difficult to use, it may even lead to customers aborting the transaction, resulting in loss of profit [1]. A successful revision and redesign of a suboptimal online form may result in an increased completion rate in the range of 10%–40% [1]. The eBay User Experience and Design Group reported that a redesign of the eBay registration form made a significant contribution to eBay's business and user success [2].
A growing body of research and guidelines have been published on how to make online forms more usable (e.g., [1, 3, 4]). Some of these have been empirically tested; others instead have been derived from experience and best practice of usability experts. Although the knowledge in this field is increasing, there are still many open questions when it comes to designing an online form.
2. Theoretical Background
In the last decade, many aspects of online forms have been explored. There are several aspects of usable form interaction: (1) form content, (2) form layout, (3) input types, (4), error handling, and (5) form submission. The following section provides a brief summary of the most important results within these areas. This study will explore aspects within the area of “input types”.
Form Content
There are many different aspects to consider when designing web forms. One of the basic guidelines of user-centered design is to map the natural environment, which is already familiar to the user, as closely as possible to the virtual one [5]. If users are familiar with a concept in real life, it is probable that they will also understand this concept if it is applied to the online environment. In the case of web forms, this may, for example, be achieved by using a layout analogous to paper forms. Beaumont et al. [4] state that users' preferred input types for providing answers online are textboxes. A demonstration by Nielsen [6] showed that providing a separate drop-down menu for entering the street type (e.g., road, street, and avenue) caused people to turn back to the previous field because they were used to entering the street type into the textbox for the address. Miller and Jarrett [7] recommend not using too many different input types in one form as this can cause confusion, and Beaumont et al. [4] suggest keeping an intuitive order of the questions, for example, first ask for the name, then the address and, at the end, for the telephone number.
To keep forms simple and fast, Beaumont et al. [4] recommend asking only those questions that really need to be answered, for example, the shipping address in the case of an online shop. Other “nice-to-know” questions only annoy users and require more time to fill in the form. On the other hand, these questions may provide insight into the user population and may be helpful for marketing purposes. In this case, users must be enabled to distinguish between required and optional fields [8, 9]. Nowadays, this is often realized through the use of asterisks. Pauwels et al. [10] examined whether highlighting required fields by color coding leads to faster completion time compared to an asterisk next to required fields. Participants were faster, made fewer errors, and were more satisfied when the required fields were highlighted in color. Tullis and Pons [11] found that people were fastest at filling in required fields when the required and optional fields were separated from each other.
Form Layout
Penzo [12] examined the position of labels relative to the input field in a study using eye-tracking. He compared left-, right- and top-aligned labels and came to the conclusion that with left-aligned labels people needed nearly twice as long to complete the form as with right-aligned labels. Additionally, the number of fixations needed with right-aligned labels was halved. The fastest performance, however, was reached with top-aligned labels, which required only one fixation to capture both the label and the input field at the same time. As a result of this study, Wroblewski [1] recommends using left-aligned labels for unfamiliar data where one wants users to slow down and consider their answers. On the other hand, if the designer wants users to complete the form as quickly as possible, top-aligned labels are recommended. Another advantage of top-aligned labels is that label length does not influence placement of the input fields. Based on an eye-tracking study, Das et al. [13] recommend right-aligned labels in the context of forms with multiple columns. Finally Jarrett [14] emphasizes, that the question of label placement is secondary, as long as users know what to fill in the fields, whether they are willing to reveal the information, and whether the validations do not prevent them from entering the answers of their choice. The literature review shows that there is little consensus when it comes to label placement.
In terms of form layouts, Robinson [15] recommends that a form should not be divided into more than one column. A row should only be used to answer one question. Concerning the length of input fields, Wroblewski [1] recommends matching the length of the field to the length of the expected answer. This provides a clue or affordance to users as to what kind of answer is expected from them. Christian et al. [16] examined the date entry with two separated text fields for month and year. Participants gave more answers in the expected format (two characters for the month and four for the year) if the field for the month was half the size of the one for the year. In another study by Couper et al. [17], people gave more incorrect answers if the size of the input field did not fit the length of the expected input.
Input Types
Another question in web form design relates to which input type should be used. As mentioned, Beaumont et al. [4] recommend using textboxes as often as possible. However, if the number of possible answers has to be restricted, radio buttons, checkboxes, or drop-down menus can be used [8]. These input types are also recommended to avoid errors, prevent users from entering unavailable options, and simplify the decision process. Radio buttons and drop-down menus are used for choosing only one option (single choice); with checkboxes, users can select as many options as they like. Concerning the use of drop-down menus and radio buttons, Miller and Jarrett [7] see the advantage of radio buttons in the fact that all options are visible at once whereas the advantage of drop-down menus lies in the saving of screen real estate. With the help of the Keystroke-Level Model [18], it can be theoretically calculated that interaction with a drop-down menu takes longer than interaction with radio buttons, mainly because of an additional point and click (PK) needed to open the drop-down menu. In an empirical study, Healey [19] found that on the single-question level, radio buttons were faster to choose from than drop-down menus, but the use of drop-down menus instead of radio buttons did not affect the overall time to fill in the whole questionnaire. Hogg and Masztal [20] could not find any differences in the time needed to select answers between radio buttons and drop-down menus. Heerwegh and Loosveldt [21] found that people needed significantly more time to select options from drop-down menus than from radio buttons, but these findings could not be replicated in a second study. Concerning the drop-out rate, no differences between radio buttons and drop-down menus could be found [19–21]. According to Miller and Jarrett [7], radio buttons should be used when two to four options are available; with more than four options they recommend using drop-down menus. When drop-down menus are used, Beaumont et al. [4] suggest arranging the options in an order with which the user is already familiar (e.g., for weekdays, the sequence Monday, Tuesday, etc.). Where there is no intuitive sequence, an alphabetical order should be considered. If users are required to indicate multiple options, Bargas-Avila et al. [22] show that checkboxes (instead of list boxes) enhance usability and user satisfaction—at least when a smaller number of options are provided.
A frequent issue concerning data input is the design of date entries. With date entries, it is important that they are entered in the expected format to avoid confusion between month and day. There are many different ways of designing input fields for date entries and many possibilities for how they have to be completed. Christian et al. [16] examined date entries where the month and year field consisted of two separate text boxes. Their study revealed that 92.9%–95.8% provided their answer in the correct format when symbols (MM and YYYY) were used to state the restrictions. Positioning the date instructions to the right of the year field led to fewer correct answers. Linderman and Fried [8] suggest using drop-down menus to ensure that no invalid dates are entered. There are other ways of designing date entries and their format requirements, for example, placing the requirements inside the answer boxes or using a single text box. Currently no studies are known to the authors that compare these different versions. Concerning the formatting of other answers, accepting entries in every format is recommended, as long as this does not cause ambiguity [8]. This prevents users from having to figure out which format is required and avoids unnecessary error messages.
Error Handling
It is important to guide users as quickly and error-free as possible through forms. Errors should be avoided from the start by explaining restrictions in advance. Often, errors cannot be avoided; in this case, it is important to help users to recover from them as quickly and easily as possible. To assure usable error messages in the web, Nielsen [23] and Linderman and Fried [8] state that an error message must be written in a familiar language and clearly state what the error is and how it can be corrected. Nielsen [23] also advises never deleting the completed fields after an error has occurred, as this can be very frustrating for users. Bargas-Avila et al. [24] compared six different ways of presenting an error message, including inline validation, pop-up windows, and embedded error messages. People made fewer consecutive errors when error messages appeared embedded in the form next to the corresponding input fields or one by one in a pop-up window. This was only the case if the error messages showed up at the end after clicking the send button. If the error messages appeared at the moment the erroneous field was left (inline validation), the participants made significantly more errors completing the form. They simply ignored or, in the case of pop-up windows, even clicked away the appearing error messages without reading them.
Form Submission
At the end of the fill-in process, the form has to be submitted. This is usually realized through a button with an action label. Linderman and Fried [8] suggest disabling the submit button as soon as it has been clicked to avoid repeated submissions due to long loading time. Some web forms also offer a reset or cancel button in addition to the submit button. Many experts recommend eliminating such a button as it can be clicked by accident and does not provide any real additional value [1, 8, 15]. After a successful transaction, the company should confirm the receipt of the user's data by e-mail [1, 8].
3. Goal of the Study
In date entry on the World Wide Web, there can be ambiguities, especially in global context. In most European countries, dates are written in the format day/month/year, whereas in the US the day follows the month. In an online environment, where a date is filled into an input field, it is therefore important to tell users in which format the date has to be entered to avoid confusion. Prior studies have shown that providing format restrictions to users in advance lowers error rates and increases user satisfaction [25].
There are many ways of stating how the date entry has to be formatted. A study by Christian et al. [16] examined date entry using two separate input fields for month and year. They placed above the corresponding input fields the words “Month” and “Year” or the characters “MM” and “YYYY”, respectively. They found that people provided more correct answers using characters. Another factor that decreased errors was when the year field was twice as long as the month field. Their study also showed that the way the question was asked, namely, “when” versus “what month and year”, had no influence on the number of correct answers. Also, the position of the symbols—left, above, or right of the corresponding input fields—did not change the percentage of correct answers. Using a half-size month-box, separating the month— from the year-box, and grouping a symbolic instruction with the corresponding input field led to a rate between 92.9% and 95.8% of participants reporting the date in the desired format.
There are more possibilities for designing input fields for date entries with formatting requirements, for example, using one field and placing the requirements next to or inside the field. There are even ways where no formatting requirements need to be stated, namely, drop-down menus and pop-up calendars. Because no studies are known that had tested the performance of these possibilities, an online experiment was conducted to shed more light into these options.
4. Methods
4.1. Error Categorization
When entering dates in forms, there are two different types of errors that can occur.(1)Wrong format. The user enters the correct day (e.g., his/her birthday), but chooses a wrong format. This can happen for instance when the required format is month-day-year, and the user enters first the day and then the month and year, or when two-digit numbers are enforced, but the user enters the date using single-digits. Format errors stem usually from insufficient communication of the applied format restrictions or from users overlooking the instructions. (2)Wrong date. The user enters the wrong date. This usually happens if the wrong keys are pressed on the keyboard or the wrong entries are selected in a menu or calendar widget.
4.2. Design
This study was conducted as online experiment, where six different date entry designs were compared using a one-way related design.
We chose four designs that required users to enter the dates using variation of entry field(s), one where the dates were entered with drop-down menus, and one design provided a calendar widget. The six designs used as independent variables are illustrated and explained in Figure 1.
As dependent variables, the following metrics were assessed.(i)Wrong format: date entries in a wrong format (see Section 4.1 for a definition). (ii)Completion time: time needed to fill in the dates. (iii)Wrong date: dates that did not correspond to the ones required (see Section 4.1 for a definition).(iv)User satisfaction: a satisfaction questionnaire measured whether entering the date was perceived as being comfortable and efficient.
4.3. Participants
A total of subjects participated in the study. Fifty-three of the participants were male, 113 were female, and six did not specify their gender. The mean age was 30.33 years (), with the youngest person being 15 and the oldest 68 years old. All participants were recruited through the University recruitment database and contacted by e-mail. In this database, people interested in participating in user studies can leave their contact address. As incentive, they had the chance of winning an iPod Shuffle or one out of 10 USB memory sticks.
4.4. Procedure
The study was conducted online. The authors selected five arbitrary dates that were used for the experiment. Each of these five dates was presented to each participant in all six design versions. This leads to a total of 30 cycles for each participant (5 dates × 6 designs). All cycles were presented to participants in random order to counter learning effects.
First the participants received a short introduction and instruction. They were told that they would see 30 tasks, where a date is presented, and they will need to copy this date as fast as possible with the provided input mechanism. After acknowledging this instruction, the study started. The presentation on each screen consisted of a date to fill in and the corresponding input field. Figure 2 shows an example for version 1 (separate). The task was to fill in the date presented in the input field as quickly as possible and to click on the button to proceed to the next screen. In line with the stated format requirements, dates had to be entered using two digits for the day and the month and four digits for the year.
At the end, a post-test questionnaire appeared where each design version was presented again on the same screen, with the questions “Filling in the date was comfortable” and “I could fill in the date quickly and efficiently” placed under each version. Participants had to answer these questions for each design on a six-point Likert scale (scale: 1 = does not apply; 6 = applies). Finally, participants were asked for their age and gender and thanked for their participation.
5. Results
All data were checked for outliers (difference larger than three standard deviations), normal distribution, and linearity. For a better fit to these criteria, response time was log-transformed. To analyze the differences between the six versions, the mean for the dependent variables of the five dates was calculated for each input type. In version 6 (calendar), where there was the possibility of choosing the date via the pop-up calendar, only data where the calendar was used were included into the calculation (; it was possible to enter the date without using the calendar by typing directly into the date field). The outlier analysis revealed that one subject took an abnormally long time to answer version 2 (drop-down). Therefore, this subject was excluded from further analyses. An alpha level of .05 was used for all statistical tests.
5.1. Errors: Wrong Format
The number of format errors was not normally distributed and the assumption of variance homogeneity was violated. Therefore, to test whether the six design versions differed in the number of answers that were given in an wrong format (see Section 4.1), a non-parametric Friedman ANOVA was used. Results indicate that there were significant differences between the six versions, , . As shown in Table 1, version 2 (drop-down) and version 6 (calendar) performed significantly better than the other four versions. They both had zero entries in a wrong format, because these versions make it impossible to enter a date in a wrong format. There was no difference between the other four versions; they all led to the same number of incorrect date formats.
5.2. Response Time
Response time data were not normally distributed and therefore log-transformed. To test whether there were differences between the six versions for the time needed to fill in the dates, a one-way ANOVA for related samples was conducted. Because the sphericity assumption was violated, degrees of freedom were adjusted using Greenhouse-Geisser. Again, for version 6 (calendar) only data where the calendar was used were included into the analysis. The global analysis revealed significant differences in the logarithmic transformed mean response time, , , with version 2 (drop-down) and 6 (calendar) requiring more time to be filled in than the other four, , . The fastest performance was reached with versions 3 (left) and 5 (inside), which were both faster than versions 1 (separate) and 4 (inside, permanent), , . Mean values for the time needed to fill the dates are shown in Table 2.
5.3. Errors: Wrong Dates
Data did not meet assumptions of distribution and sphericity. Therefore, again a nonparametric Friedman ANOVA was applied to compare the number of wrong dates entered. Table 1 shows the mean values for all groups. The six versions differed significantly, , . Post hoc analysis revealed that in version 6 (calendar) more dates that differed from the ones required (wrong dates, see Section 4.1) were entered than in the other five versions (see Table 1).
5.4. Satisfaction, Efficiency, and Conformance Ratings
Concerning the question whether the action of entering the dates was perceived as being comfortable, the global analysis revealed significant differences between the six versions , , with version 4 (inside, permanent) being perceived as significantly less comfortable than each of the other versions. There was no significant difference between the other five versions regarding perceived comfortableness (see Table 3). Significant differences were found between the six versions for the perceived efficiency of entering the dates, , . Again, version 4 (inside, permanent) was perceived as being less efficient than the other versions. Version 2 (drop-down) was perceived as being less efficient than versions 3 (left) and 5 (inside). In addition, version 3 (left) was rated significantly more efficient than the calendar (see Table 4).
6. Discussion
6.1. Discussion of the Findings
The results show that no formatting errors occurred with the drop down and calendar entry options. However, this benefit came with the cost of longer input times. Concerning the other four versions, none of them outperformed another regarding the mean number of registered formatting errors. There is a trade-off in the number of formatting errors and completion time. If it is crucial that the requested date is entered in the correct format (e.g., the date for a flight when buying an online ticket), either the calendar or the drop-down version can be used at the expense of more time. If, on the other hand, completion time is a more important factor than correctly formatted answers (e.g., optional fields like one’s date of birth), one of the other versions can be considered. When analyzing completion time, versions 3 (left) and 5 (inside) performed best and received the highest satisfaction ratings. Therefore when formatting errors are secondary, these two versions can be recommended. In version 5 (inside), where the format advice disappears as soon as the field is activated, users might accidentally delete the format requirement using the tab key. This is a legitimate argument, which could not be tested in this study as there was only one input field per screen, and tabbing was not possible or necessary. Version 1 (separate), which has been proposed by Beaumont et al. [4] and Christian et al. [16], did not lead to fewer formatting errors and took more time to be filled in than versions 3 (left) and 5 (inside). Version 4 (inside, permanent) was rated as being significantly less comfortable and efficient than the other versions. As it does not seem to prevent formatting errors any better than other versions, using this type of date entry field should be avoided. Table 4 gives a performance overview for the tested versions.
Concerning the difference between drop-down and calendar version, using the drop-down menu to ensure that fewer errors occur might have some advantages. With the calendar interface, more incorrect dates were registered (see Section 5.3). With calendars, it is usually possible to enter the date manually in the field without using the calendar. Therefore, it may happen that people either do not see the calendar icon or decide not to use it. In this study, 28% of participants never used the calendar and only 25% used it for all five dates that they had to enter. If a designer wants to force the use of the calendar, it has to be implemented in such a way that the calendar automatically pops up when clicking into or activating the corresponding input field. Also, the calendar is the only interface element that requires the usage of a mouse: in situations where a mouse is unavailable (e.g., mobile applications) or the form is used by handicapped user population, this version might bear some serious disadvantages compared to regular drop-down menus. A calendar that can be activated by the user can be very helpful for date entries where it is important to know the exact weekday of the date. This type of calendar is, for example, commonly used on travel websites to book flights and hotels. However, in cases where the required date lies far in the future or past, it is often not practical to use a calendar to enter a date, because it will require many clicks to arrive at the desired timeframe.
The reported findings should be tested in a complete form to see whether these rules also apply in a “natural environment”. The interaction with the labels should be taken into account, especially in version 3 (left), where the label and the formatting advice are placed to the left of the input field. In this case, it should also be tested as to whether the formatting advice should be associated with the label or the input field.
6.2. Limitations
This study helps to clear up an important question regarding the design of usable forms: how should date entry input fields be presented to reduce errors and processing time, and to increase user satisfaction? At the same time, it must be stressed that the presented findings have to be regarded as a first step. The study was conducted in a rigorous laboratory setting. First, all chosen tasks were artificial: participants had not to enter real dates they had to retrieve from their memory. They simply had to copy dates from an instruction into a user interface—it remains to be seen if these results scale to more realistic settings. Second, the tasks were very repetitive, something that is usually not found in online form. Third, the interactions were not embedded in a realistic setting, like for instance a shopping or registration process. The ecological validity of the presented findings is therefore low. Fourth, we instructed the participants to enter the dates as quickly as possible. This performance oriented setting may differ from a more relaxed, natural task setting.
To overcome these limitations, future studies may vary interface elements within a real setting using real tasks. Another question is whether these results can be generalized beyond web forms to, for example, forms in mobile applications.
6.3. Future Outlook
Regarding the future outlook, there are many open questions concerning usable forms that must be answered. In recent years new developments, like for example, Web 2.0, have led to new ways of implementing interactions on the Internet. Nowadays for example, users get more and more accustomed to receiving immediate feedback in webforms through the use of AJAX technology. It remains to be seen if these technologies can be used to enhance date selection in online forms.
There is a growing body of empirical research and best practice recommendations by usability experts to achieve usable forms on the World Wide Web. Most studies—like the one presented here—choose to explore one specific aspect or interface element to find the optimal solution. Usually this is done in a laboratory situation, using abstract forms with artificial tasks. In the near future, this knowledge needs to be consolidated in practical guidelines. These guidelines must be empirically tested using real forms in realistic user situations, to see whether they really lead to better usability, manifested in faster form-completion time, fewer errors, higher user satisfaction, and reduced dropout rate.