Hindawi Publishing Corporation
Advances in Human-Computer Interaction
Volume 2011, Article ID 202701, 8pages
Working towards Usable Forms on the World Wide Web:
Optimizing Date Entry Input Fields
Javier A. Bargas-Avila, Olivia Brenzikofer, Alexandre N. Tuch,
Sandra P. Roth, and Klaus Opwis
Department of Psychology, Center for Cognitive Psychology and Methodology, University of Basel, 4055 Basel, Switzerland
Correspondence should be addressed to Javier A. Bargas-Avila, email@example.com
Received 15 February 2010; Revised 13 May 2011; Accepted 7 June 2011
Academic Editor: Armando Bennet Barreto
Copyright © 2011 Javier A. Bargas-Avila et al. This is an open access article distributed under the Creative Commons Attribution
License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly
When an interactive form in the world wide web requires users to ﬁll in exact dates, this can be implemented in several ways. This
paper discusses an empirical online study with n=172 participants which compared six diﬀerent versions to design input ﬁelds
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 ﬁeld and placing the format requirements left or inside the text box led to faster completion time and higher user
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 ﬁlling 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 diﬃcult to
use, it may even lead to customers aborting the transaction,
resulting in loss of proﬁt . A successful revision and rede-
sign of a suboptimal online form may result in an increased
completion rate in the range of 10%–40% . The eBay User
Experience and Design Group reported that a redesign of
the eBay registration form made a signiﬁcant contribution
to eBay’s business and user success .
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 ﬁeld is
increasing, there are still many open questionswhen 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 inter-
action: (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 re-
sults within these areas. This study will explore aspects within
the area of “input types”.
Form Content. There are many diﬀerent 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 . If users are familiar with a concept in
real life, it is probable that they will also understand this con-
cept 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. state
that users’ preferred input types for providing answers online
are textboxes. A demonstration by Nielsen  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 ﬁeld because they were used to entering
the street type into the textbox for the address. Miller and
2Advances in Human-Computer Interaction
Jarrett  recommend not using too many diﬀerent input
types in one form as this can cause confusion, and Beaumont
et al.  suggest keeping an intuitive order of the questions,
for example, ﬁrst ask for the name, then the address and, at
the end, for the telephone number.
To keep forms simple and fast, Beaumont et al. rec-
ommend 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 an-
noy users and require more time to ﬁll in the form. On the
other hand, these questions may provide insight into the
user population and may be helpful for marketing purpos-
es. In this case, users must be enabled to distinguish between
required and optional ﬁelds [8,9]. Nowadays, this is often
realized through the use of asterisks. Pauwels et al. ex-
amined whether highlighting required ﬁelds by color coding
leads to faster completion time compared to an asterisk
next to required ﬁelds. Participants were faster, made fewer
errors, and were more satisﬁed when the required ﬁelds were
highlighted in color. Tullis and Pons  found that people
were fastest at ﬁlling in required ﬁelds when the required and
optional ﬁelds were separated from each other.
Form Layout. Penzo  examined the position of labels
relative to the input ﬁeld 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 ﬁxations needed with
right-aligned labels was halved. The fastest performance,
however, was reached with top-aligned labels, which required
only one ﬁxation to capture both the label and the input
ﬁeld at the same time. As a result of this study, Wroblewski
 recommends using left-aligned labels for unfamiliar data
where one wants users to slow down and consider their an-
swers. 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 inﬂuence placement of the
input ﬁelds. Based on an eye-tracking study, Das et al. 
recommend right-aligned labels in the context of forms with
multiple columns. Finally Jarrett  emphasizes, that the
question of label placement is secondary, as long as users
know what to ﬁll in the ﬁelds, 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  recommends
that a form should not be divided into more than one col-
umn. A row should only be used to answer one question.
Concerning the length of input ﬁelds, Wroblewski rec-
ommends matching the length of the ﬁeld tothe length of the
expected answer. This provides a clue or aﬀordance to users
as to what kind of answer is expected from them. Christian
et al.  examined the date entry with two separated text
ﬁelds for month and year. Participants gave more answers in
the expected format (two characters for the month and four
for the year) if the ﬁeld for the month was half the size of
the one for the year. In another study by Couper et al. ,
people gave more incorrect answers if the size of the input
ﬁeld did not ﬁt 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.  recommend using textboxes as often as possible.
However, if the number of possible answers has to be restrict-
ed, radio buttons, checkboxes, or drop-down menus can be
used . 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 but-
tons, Miller and Jarrett  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 ,
it can be theoretically calculated that interaction with a drop-
down menu takes longerthan 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
 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
aﬀect the overall time to ﬁll in the whole questionnaire.
Hogg and Masztal  could not ﬁnd any diﬀerences in
the time needed to select answers between radio buttons
and drop-down menus. Heerwegh and Loosveldt found
that people needed signiﬁcantly more time to select options
from drop-down menus than from radio buttons, but these
ﬁndings could not be replicated in a second study. Concern-
ing the drop-out rate, no diﬀerences between radio buttons
and drop-down menus could be found [19–21]. According
to Miller and Jarrett , 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.  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. show
that checkboxes (instead of list boxes) enhance usability and
user satisfaction—at least when a smaller number of options
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 diﬀerent ways of designing
input ﬁelds for date entries and many possibilities for how
they have to be completed. Christian et al. examined
date entries where the month and year ﬁeld 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
ﬁeld led to fewer correct answers. Linderman and Fried 
Advances in Human-Computer Interaction 3
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 diﬀerent versions. Concerning the formatting
of other answers, accepting entries in every format is recom-
mended, as long as this does not cause ambiguity . This
prevents users from having to ﬁgure out which format is re-
quired 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
 and Linderman and Fried  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 also
advises never deleting the completed ﬁelds after an error has
occurred, as this can be very frustrating for users. Bargas-
Avi la et al.  compared six diﬀerent ways of presenting an
error message, including inline validation, pop-up windows,
and embedded error messages. People made fewer consecu-
tive errors when error messages appeared embedded in the
form next to the corresponding input ﬁelds or one by one
in a pop-up window. This was only the case if the error
messages showed up at the end after clickingthe send button.
If the error messages appeared at the moment the erroneous
ﬁeld was left (inline validation), the participants made signif-
icantly more errors completing the form. They simply ig-
the appearing error messages without reading them.
Form Submission. At the end of the ﬁll-in process, the form
ton with an action label. Linderman and Fried  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 oﬀer 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 conﬁrm 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 ambigu-
ities, especially in global context. In most European coun-
tries, dates are written in the format day/month/year, where-
as in the US the day follows the month. In an online environ-
ment, where a date is ﬁlled into an input ﬁeld, 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 .
to be formatted. A study by Christian et al. examined
date entry using two separate input ﬁelds for month and year.
They placed above the corresponding input ﬁelds 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 ﬁeld was twice as long as the month
ﬁeld. Their study also showed that the way the question was
asked, namely, “when” versus “what month and year”, had
no inﬂuence on the number of correct answers. Also, the
position of the symbols—left, above, or right of the corre-
sponding input ﬁelds—did not change the percentage of cor-
rect answers. Using a half-size month-box, separating the
month— from the year-box, and grouping a symbolic in-
struction with the corresponding input ﬁeld 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 ﬁelds
for date entries with formatting requirements, for example,
using one ﬁeld and placing the requirements next to or inside
the ﬁeld. There are even ways where no formatting require-
ments 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.1. Error Categorization. When entering dates in forms,
there are two diﬀerent 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 ﬁrst 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 insuﬃcient
communication of the applied format restrictions or
from users overlooking the instructions.
(2) Wrong dat e. The user enters the wrong date. This usu-
ally happens if the wrong keys are pressed on the key-
board or the wrong entries are selected in a menu or
4.2. Design. This study was conducted as online experiment,
where six diﬀerent 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 ﬁeld(s), one where the dates
were entered with drop-down menus, and one design pro-
vided a calendar widget. The six designs used as independent
variables are illustrated and explained in Figure 1.
As dependent variables, the following metrics were as-
(i) Wrong format: date entries in a wrong format (see
Section 4.1 for a deﬁnition).
4Advances in Human-Computer Interaction
Version 1 (separate). Three separate input ﬁelds are used for day, month and year and symbols above of the
corresponding input ﬁeld state how many digits have to be entered. The year ﬁeld is twice the size of the month
and day ﬁeld.
Version 2 (drop-down). Three separate drop-down menus are used for day, month and year. The menu for the
year includes dates from 1900 to 2007.
Version 3 (left). Only one input ﬁeld is used. The formatting requirements are stated in form of symbols to the
left of the input ﬁeld.
Version 4 (inside, permanent). The formatting requirement is placed inside the input ﬁeld. It stays visible when
the user clicks inside the ﬁeld and has to be overwritten.
Version 5 (inside). The formatting requirement is placed inside the input ﬁeld. It disappears when the user clicks
into the input ﬁeld.
Version 6 (calendar). A calendar pops-up when the icon right to the input ﬁeld is clicked.
Figure 1: Design versions used as independent variables: input types for date entries (translated by the authors).
(ii) Completion time: time needed to ﬁll in the dates.
(iii) Wrong dat e: dates that did not correspond to the ones
required (see Section 4.1 for a deﬁnition).
(iv) User satisfaction: a satisfaction questionnaire meas-
ured whether entering the date was perceived as being
comfortable and eﬃcient.
4.3. Participants. A total of n=172 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 (SD =12.07), 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 Shuﬄe
or one out of 10 USB memory sticks.
4.4. Procedure. The study was conducted online. The authors
selected ﬁve arbitrary dates that were used for the experi-
ment. Each of these ﬁve dates was presented to each partic-
ipant in all six design versions. This leads to a total of 30
cycles for each participant (5 dates ×6designs).Allcycles
were presented to participants in random order to counter
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.
Advances in Human-Computer Interaction 5
Welcome Instruction Questions 1/30 Evaluation Demography Thank you
DD MM YYYY
Figure 2: Example of how a task was presented to users (translated by the authors).
After acknowledging this instruction, the study started. The
presentation on each screen consisted of a date to ﬁll in and
the corresponding input ﬁeld. Figure 2 shows an example for
version 1 (separate). The task was to ﬁll in the date presented
in the input ﬁeld 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
could ﬁll in the date quickly and eﬃciently” 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.
All data were checked for outliers (diﬀerence larger than
three standard deviations), normal distribution, and linear-
ity. For a better ﬁt to these criteria, response time was log-
transformed. To analyze the diﬀerences between the six ver-
sions, the mean for the dependent variables of the ﬁve 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 (n=126; it was possible
to enter the date without using the calendar by typing
directly into the date ﬁeld). The outlier analysis revealed that
one subject took an abnormally long time to answer ver-
sion 2 (drop-down). Therefore, this subject was excluded
from further analyses. An alpha level of .05 was used for all
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 diﬀered in the number of answers that were
giveninanwrongformat(seeSection 4.1), a non-parametric
Friedman ANOVA was used. Results indicate that there were
signiﬁcant diﬀerences between the six versions, χ2
168.864, p<.001. As shown in Tab l e 1, version 2 (drop-
down) and version 6 (calendar) performed signiﬁcantly
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
diﬀerence 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 diﬀerences between the six versions for the time
needed to ﬁll in the dates, a one-way ANOVA for related
samples was conducted. Because the sphericity assumption
was violated, degrees of freedom were adjusted using Green-
house-Geisser. Again, for version 6 (calendar) only data
where the calendar was used were included into the analysis.
The global analysis revealed signiﬁcant diﬀerences in the log-
arithmic transformed mean response time, F(2.72, 339.49) =
112, 07, p<.001, with version 2 (drop-down) and 6 (calen-
dar) requiring more time to be ﬁlled in than the other four,
F(1, 125) =290.90, p<.001. The fastest performance was
reached with versions 3 (left) and 5 (inside), which were both
faster than versions 1 (separate) and 4 (inside, permanent),
F(1, 125) =72.88, p<.001. Mean values for the time needed
to ﬁll the dates are shown in Ta bl e 2 .
5.3. Errors: Wrong Dates. Data did not meet assumptions of
distribution and sphericity. Therefore, again a nonparamet-
ric Friedman ANOVA was applied to compare the number
of wrong dates entered. Tabl e 1 shows the mean values for
all groups. The six versions diﬀered signiﬁcantly, χ2
126) =76.63, p=.001. Post hoc analysis revealed that in
version 6 (calendar) more dates that diﬀered from the ones
required (wrong dates, see Section 4.1) were entered than in
the other ﬁve versions (see Tab l e 1).
5.4. Satisfaction, Eﬃciency, and Conformance Ratings. Con-
cerning the question whether the action of entering the
dates was perceived as being comfortable, the global analysis
revealed signiﬁcant diﬀerences between the six versions
r(5, N=121) =69.622, p<.001, with version 4 (inside,
permanent) being perceived as signiﬁcantly less comfortable
than each of the other versions. There was no signiﬁcant dif-
ference between the other ﬁve versions regarding perceived
comfortableness (see Tab le 3 ). Signiﬁcant diﬀerences were
found between the six versions for the perceived eﬃciency
of entering the dates, χ2
r(5, N=116) =78.016, p<.001.
Again, version 4 (inside, permanent) was perceived as being
less eﬃcient than the other versions. Version 2 (drop-down)
was perceived as being less eﬃcient than versions 3 (left) and
5 (inside). In addition, version 3 (left) was rated signiﬁcantly
more eﬃcient than the calendar (see Ta bl e 4 ).
6Advances in Human-Computer Interaction
Tab le 1: Statistic parameters for number of errors: entries in a wrong format and wrong date.
Vers i o n Wrong format Wrong date
M(%) SD M(%) SD
Version 1 (separate) 18.5 30.5 3.0 8.1
Version 2 (drop-down) 0 0 2.1 7.6
Version 3 (left) 22.3 33.5 1.6 5.6
Version 4 (inside, permanent) 22.3 32.8 1.7 5.7
Version 5 (inside) 25.7 32.5 1.9 7.5
Version 6 (calendar) 0 0 18.3 29.7
Tab le 2: Statistics for time needed to ﬁll the dates.
Vers i o n Time needed (s)
Version 1 (separate) 3.68 2.69
Version 2 (drop-down) 6.94 2.88
Version 3 (left) 3.61 2.82
Version 4 (inside, permanent) 4.15 2.49
Version 5 (inside) 3.41 2.32
Version 6 (calendar) 5.03 5.40
6.1. Discussion of the Findings. The results show that no for-
matting errors occurred with the drop down and calendar
entry options. However, this beneﬁt 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-oﬀ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 ﬂight 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 ﬁelds 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 ﬁeld 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 ﬁeld per
screen, and tabbing was not possible or necessary. Version 1
(separate), which has been proposed by Beaumont et al. 
and Christian et al. , did not lead to fewer formatting
errors and took more time to be ﬁlled in than versions 3
(left) and 5 (inside). Version 4 (inside, permanent) was rated
as being signiﬁcantly less comfortable and eﬃcient than the
other versions. As it does not seem to prevent formatting
errors any better than other versions, using this type of date
entry ﬁeld should be avoided. Tab le 4 gives a performance
overview for the tested versions.
Concerning the diﬀerence between drop-down and cal-
endar 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 ﬁeld 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 ﬁve 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
ﬁeld. 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 ﬂights
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 ﬁndings 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 ﬁeld. In this case, it should also be tested as to whether
the formatting advice should be associated with the label or
the input ﬁeld.
6.2. Limitations. This study helps to clear up an important
question regarding the design of usable forms: how should
date entry input ﬁelds be presented to reduce errors and
processing time, and to increase user satisfaction? At the
same time, it must be stressed that the presented ﬁndings
have to be regarded as a ﬁrst step. The study was conducted
in a rigorous laboratory setting. First, all chosen tasks were
artiﬁcial: 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.
Advances in Human-Computer Interaction 7
Tab le 3: Subjective evaluation of the six versions.
Vers i o n Comfortableness Speed/Eﬃciency
Version 1 (separate) 3.75 1.71 3.80 1.71
Version 2 (drop-down) 3.65 1.85 3.30 1.74
Version 3 (left) 4.04 1.44 4.23 1.44
Version 4 (inside, permanent) 2.66 1.38 2.72 1.39
Version 5 (inside) 3.95 1.39 4.10 1.50
Version 6 (calendar) 3.70 1.82 3.35 1.73
6-point Likert scales, 1 =does not apply; 6 =applies.
Tab le 4: Performance overview of the six versions.
Avo id wro n g form a t Avo id wro n g dat e Ti m e eﬃciency User satisfaction
Version 1 (separate) 0 + 0 0
Version 2 (drop-down) + + −0
Vers i o n 3 ( l e f t ) 0 + + +
Version 4 (inside, permanent) 0 + 0 −
Version 5 (inside) −+++
Version 6 (calendar) + −−0
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 ﬁndings is therefore low. Fourth, we instructed
the participants to enter the dates as quickly as possible. This
performance oriented setting may diﬀer 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 applica-
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 exam-
ple, Web 2.0, have led to new ways of implementing interac-
tions 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 speciﬁc aspect
or interface element to ﬁnd the optimal solution. Usually
this is done in a laboratory situation, using abstract forms
with artiﬁcial 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.
 L. Wroblewski, Web Form Design: Filling in the Blanks,Rosen-
feld Media, 2008.
 J. Herman, “A process for creating the business case for
user experience projects,” in Proceedings of the Conference on
Human Factors in Computing Systems, pp. 1413–1416, ACM,
New York, NY, USA, 2004.
 J. Bargas-Avila, O. Brenzikofer, S. Roth, A. Tuch, S. Orsini, and
K. Opwis, “Simple but crucial user interfaces in the world wide
web: introducing 20 guidelines for usable web form design,” in
User Interfaces (INTECH ’10), R. Matrai, Ed., pp. 1–10, 2010.
 A. Beaumont, J. James, J. Stephens, and C. Ullman, Usable
Forms for the Web, Glasshaus, Birmingham, UK, 2002.
 J. Garrett, The Elements of User Experience,NewRiders,
Indianapolis, Ind, USA, 2002.
 J. Nielsen, “Drop-down menus: use sparingly,” 2000, http://
 S. Miller and C. Jarrett, “Should I use a drop-down? Four
steps for choosing form elements on the web,” 2001, http://
 M. Linderman and J. Fried, Defensive Design for the Web: How
to Improve Error Messages, Help, Forms, and Other Crisis Points,
New Riders Publishing, Thousand Oaks, Calif, USA, 2004.
 T. Wilhelm and C. Rehmann, “Nutzergerechte formula-
rgestaltung,” 2006, http://www.eresult.de/studien artikel/for-
 S. L. Pauwels, C. H¨
ubscher, S. Leuthold, J. A. Bargas-Avila,
and K. Opwis, “Error prevention in online forms: use color
instead of asterisks to mark required-ﬁelds,” Interacting with
Computers, vol. 21, no. 4, pp. 257–262, 2009.
8Advances in Human-Computer Interaction
 T. Tu l l i s a n d A. P o n s , “ D e s i g n at in g r e q u i r e d vs. o p t i o n a l i n p u t
ﬁelds,” in Proceedings of the Conference on Human Factors in
Computing Systems, pp. 259–260, ACM, New York, NY, USA,
 M. Penzo, “Label placement in forms,” 2006, http://www.
 S. Das, T. McEwan, and D. Douglas, “Using eye-tracking to
evaluate label alignment in online forms,” in Proceedings of
the 5th Nordic Conference on Human-Computer Interaction:
Building Bridges, pp. 451–454, ACM, 2008.
 C. Jarrett, “Label placement in forms: what’s best?” in Proceed-
ings of the 22nd British HCI Group Annual Conference on People
and Computers: Culture, Creativity, Interaction-Volume 2,pp.
229–230, British Computer Society, 2008.
 D. Robinson, “Better web forms,” 2003, http://www.7nights
 L. M. Christian, D. A. Dillman, and J. D. Smyth, “Helping
respondents get it right the ﬁrst time: the inﬂuence of
words, symbols, and graphics in web surveys,” Public Opinion
Quarterly, vol. 71, no. 1, pp. 113–125, 2007.
 M. P. Couper, M. W. Traugott, and M. J. Lamias, “Web survey
design and administration,” Public Opinion Quarterly, vol. 65,
no. 2, pp. 230–253, 2001.
model for user performance time with interactive systems,”
Communications of the ACM, vol. 23, no. 7, pp. 396–410, 1980.
 B.Healey,“Dropdownsandscrollmice:theeﬀect of response
option format and input mechanism employed on data quality
in web surveys,” Social Science Computer Review, vol. 25, no. 1,
pp. 111–128, 2007.
 A. Hogg and J. J. Masztal, “Drop-down, radio buttons, or
ﬁll-in-theblank? Eﬀects of attribute rating scale type on web
survey responses,” in Proceedings of the ESOMAR Congress—
Marketing Transformation (ESOMAR ’01), Rome, Italy, 2001.
 D. Heerwegh and G. Loosveldt, “An evaluation of the eﬀect
of response formats on data quality in web surveys,” Social
Science Computer Review, vol. 20, no. 4, pp. 471–484, 2002.
Opwis, “Working towards usable forms on the worldwide web:
optimizing multiple selection interface elements,” Advances in
Human-Computer Interaction, vol. 2011, Article ID 347171, 6
 J. Nielsen, “Error message guidelines,” 2001, http://www.useit
 J. A. Bargas-Avila, G. Oberholzer, P. Schmutz, M. de Vito, and
K. Opwis, “Usable error message presentation in the world
wide web: do not show errors right away,” Interacting with
Computers, vol. 19, no. 3, pp. 330–341, 2007.
Opwis, “Enhancing online forms: use format speciﬁcations for
ﬁelds with format restrictions to help respondents,” Interacting
with Computers, vol. 23, no. 1, pp. 33–39, 2011.