Estimating Time Requirements for Web Input Elements

Ludger Martin

Institute of Computer Science, Johannes Gutenberg-University Mainz, 55128 Mainz, Germany

Abstract. How do you know whether a website or Web application is usable?

What you need is statistics about how the website is used. Such statistics usually

include information about how much time a web user spends on a website. But to

know whether those dwell times are acceptable you will need reference values.

This paper provides such reference values based on a research study. After a

detailed discussion of the study’s results, a table is presented, which provides

reference values for any kind of HTML/HTML5 input elements. This table can

be used to estimate the time it will take a user to ﬁll in a form.

1 Introduction

Nowadays, statistics are maintained for almost every website on the Internet. Two of

the criteria that are monitored are the time a web user stays on a particular web page

and which web pages the user visits. Then the results are analyzed to see whether these

times are good or bad, and why.

This paper aims at providing criteria for more precision in assessing dwell times

by examining HTML and HTML5 input elements. A survey shall help to estimate the

time it will take a user to ﬁll in a form on a website. To this end, statistics about the

various types of input elements will be created. It is our aim to enable an estimation of

the average time it will take users to ﬁll in any Web form.

Using this data will help to assess the usability of websites and web applications.

The time required for ﬁlling in forms can then be supplemented with further values

obtained about a website. For example, the quantity, the readability and the main subject

of a text, as presented in [6, 5]. All of this information as a whole will help to understand

the statistics about a website.

The rest of the paper is structured as follows: In the chapter 2 the study and the

questionnaire used will be presented. Then, in chapter 3 the results of the study are

discussed. After presenting related work in 4 we conclude the paper with an outlook of

future work.

2 Survey Questionnaire

An online questionnaire has been compiled for this study. Test persons are asked to input

their answers to the various questions into the questionnaire. While they are ﬁlling in

the form, a JavaScript records the time the test persons spent on each question. To make

the time measurement more informative, the questions that are not currently dealt with

Martin L..

Estimating Time Requirements for Web Input Elements.

DOI: 10.5220/0004582400130021

In Proceedings of the 2nd International Workshop on Web Intelligence (WEBI-2013), pages 13-21

ISBN: 978-989-8565-63-1

 2013 SCITEPRESS (Science and Technology Publications, Lda.)

are grayed out. This method ensures that the test persons can read and answer only one

question at a time. It is the test person’s decision whether they want to use a desktop

browser or a mobile browser.

The questions do not require much contemplating, e.g. the ﬁrst question asks the

users to describe what they did after getting up in the morning. This is followed by

a choice of seven radio buttons about how the test persons came to work that day.

Then they are asked to enter their favorite food in a single-line text ﬁeld. Additionally,

statistical data is maintained about the person’s gender using three radio buttons. The

next question asks for another piece of text. This time, a word from the title of a book is

to be entered. As a rule, the type of input element is never the same as the one directly

before. The next four questions use check boxes. A further statistical question has the

form of a select ﬁeld. Here, age ranges are chosen. Six lines are displayed at the same

time. If users want to enter an age older than 34, they must scroll. The effect of scrolling

will be described in greater detail later on. In the next ﬁeld, the date of the day before

is required. If the browser supports HTML5, the appropriate HTML5 date ﬁeld will be

displayed, if not, a simple text ﬁeld. In our analysis we will look at these differences in

greater detail. If the browser supports them, the color ﬁeld and the range ﬁeld will also

be displayed. The form is completed with a simple submit button.

The other new HTML5-elements such as number, url or email are just short text

ﬁelds and are therefore not considered separately in this study.

3 Analysis

In January and February, 2013, a total of 80 test persons participated in the study. The

diagrams below show in round brackets the number of test persons who have ﬁlled in a

particular input ﬁeld. The differing numbers are due to the fact that not all test persons

ﬁlled in all of the input ﬁelds and, depending on the browser, not all of the HTML5

input elements were displayed. In the following examinations only the values of the test

persons who used a desktop browser were analyzed.

Figure 1 shows the input elements which can be selected using the mouse or the

keyboard. The four check boxes together required an average time of 15.4s. Compared

with the three radio buttons about gender, we note that these could be answered much

faster (5.8s). Even the seven radio buttons took less time. The reason for this is that

each check box requires an individual answer while the radio buttons belong together.

But the time required to deal with a group of radio buttons depends on the number of

group elements. The select ﬁeld for the person’s age is similar to the radio buttons,

as it required a similar amount of time. Entirely different is the range ﬁeld. Here, a

user is to choose a predeﬁned value. This ﬁeld seems to pose most of the problems as

it requires an average time of 13.3s. To facilitate applying the ﬁgures to a form you

want to analyze, we have recalculated the numbers for the individual elements also. For

example, it takes 3.0s to deal with a check box. The ﬁgure also shows that the standard

deviation varies considerably. We will look at this in greater detail later in this section.

Now we will take a closer look at the select ﬁeld. Figure 2 relates the time with the

options chosen. At the same time, the options represent the test persons’ ages. The ﬁrst

options show similar times and standard deviations. Only starting with option ’35-39’

all

one

seconds

check (67)

3x radio (67)

7x radio (68)

select (67)

range (16)

Fig. 1. Selection Input Elements.

does it become necessary to scroll down. This shows that if more scrolling was neces-

sary the required time increased considerably. The increase in time might be explained

by the higher age of the test person. But admittedly not many senior persons participated

in the study and therefore these values must be used with caution.

In the second part of ﬁgure 2 we have tried to create a formula for select ﬁeld usage.

For choosing an option without scrolling we assumed 5.6s. For each line that must be

scrolled we have added 2.3s. The ﬁgure shows this using the age list as an example,

where quite a good approximation can be seen. We have allowed extra time for the

standard deviations as well.

Next we will look at the three elements which require text entry using the keyboard.

The date ﬁeld is left out as no normal text is entered there. The angle brackets in the

ﬁgure 3 specify the average numbers of letters that were input. The times refer to one

character each. Interestingly, the question about a person’s favorite food was answered

more quickly than the question about a word from the title of a book. The test per-

sons obviously thought longer about the second question. Another observation was that

longer pieces of text can be entered signiﬁcantly quicker.

Before that, larger standard deviations had been noted. These are now compared to

the test persons’ ages. Figure 4 shows minor standard deviations within the age ranges.

The larger values were created by the senior test persons (60 or 70 and older) as also

observed in the ﬁgure 2. If you know the age of a website’s target group, then only the

average values for this age group are to be used. This paper continues to look at all age

groups.

After examining the age, now we want to look at the gender. In addition to the check

boxes and the text area, the ﬁgure 5 lists three age groups with the majority of test

all

one

seconds

check (67)

3x radio (67)

7x radio (68)

select (67)

range (16)

Fig. 2. Selection and Scrolling.

seconds

favorite dish [11.3]

book [8.6]

textarea [43.2]

Fig. 3. Text Input Elements.

persons. Notably, with the female test persons there were fewer standard deviations.

This may be due to the fact that fewer women participated in the survey. Hardly any

difference can be seen between the female and male test persons at least in the age

groups ’20-24’ and ’30-34’. The big difference in the text area of the age group ’25-29’

may be explained by the small number of test persons.

check

7x radio

short text

textarea

seconds

20-24

25-29

30-34

35-39

40-49

50-59

60-69

70 and older

Fig. 4. Effect of Age.

One novelty in HTML5 standard is, among others, an input ﬁeld for a date. In ﬁgure

6, this date ﬁeld is compared to a ﬁeld where the date must be typed in. The date ﬁeld

includes a calendar from which the date can be chosen. With two clicks you can select

a date. In a text ﬁeld, however, 10 characters must be entered. The ﬁgure 6 shows this

extra effort. Date ﬁelds are about double as efﬁcient as a text ﬁeld where the date must

be entered. Another new HTML5 is the color ﬁeld. An average time of 13.5s could be

determined for that ﬁeld. However, only three people ﬁlled in this ﬁeld.

So far we have only evaluated data for desktop browsers. The ﬁgure 7 compares

the test persons who used a mobile browser to those who used a desktop browser. For

date ﬁelds or color ﬁelds no data was available. Apart from the range ﬁeld there were

no big differences. The range ﬁeld had already been different in desktop browsers and

this proved even more true using mobile browsers. This makes us question the usability

of the range ﬁeld. Text ﬁelds hardly showed any differences. With longer texts the time

spent per character was slightly more. This can be explained by the fact that typing on

mobile devices is less convenient.

The form is sent off using the submit button. We did not examine these buttons

as they are only pressed once to submit the form. Measuring time is hardly possible,

especially as every form is submitted using this button and users don’t spend much

time on this kind of button.

The table 1 shows a summary of all times we ascertained. We calculated only one

value for all of the check boxes and one for all of the radio buttons. For mobile browsers

we could not determine values from scrolling a select ﬁeld, as too few participants were

available. For the texts, as before, we only speciﬁed the input times for one character.

The times shown in the table 1 shall be used to estimate the time it will probably

take to ﬁll in the entire form. Finally, as an example we will use these times for the

20-24 check

25-29 check

30-34 check

20-24 textarea

25-29 textarea

30-34 textarea

seconds

female

male

Fig. 5. Effect of Gender.

seconds

Date Versus Text Input

date input (5)

text input (73)

Fig. 6. Comparison of Date and Text Input.

form in the study. In table 2 you will ﬁnd a calculation based on a desktop browser. If

there are any optional ﬁelds in a form, we need a maximum (if all optional ﬁelds were

ﬁlled in) and a minimum value (if no option was chosen). For the maximum value the

estimated times must be included in the calculation, while for the minimum value they

should be left out. The calculation of time to be spent on our form is 144.22s (see ﬁg.

check

3x radio

7x radio

select

range

favorite dish

book

textarea

seconds

desktop

mobile

Fig. 7. Comparison Desktop/Mobile.

Table 1. Selection and Scrolling.

desktop mobile

check 3.84s 3.54s

radio 1.60s 1.97s

select 5.76s 10.60s

select scroll 1.30s -

range 13.28s 28.96s

short text 2.12s 1.97s

text area 0.99s 1.49s

date 6.90s -

color 13.50s -

2. If you calculate the real value from looking at the ﬁrst element until submitting the

form, you will get a value of 142.30s. Thus, the estimation is very close to the time that

is really required.

4 Related Work

We could not ﬁnd any studies that dealt with similar estimations about form elements.

This is why we here present related studies which deal with web usability and web

statistics in general.

Atterer et al. [2] built a system to track all user interactions with a browser page

including mouse pointer, text input, and page scrolling. Similar to our approach, the

interaction is tracked by a JavaScript but the data is transmitted using an image object.

The web pages are modiﬁed automatically by a proxy server to enable the tracking. The

Table 2. Time Estimation.

text area ca. 40 characters 40 ∗ 0.99s = 39.60s

radio group with 7 buttons 7 ∗ 1.60s = 8.60s

text with approx. 10 characters 10 ∗ 2.12s = 21.20s

radio group with 3 buttons 3 ∗ 1.60s = 4.60s

text with approx. 10 characters 10 ∗ 2.12s = 21.20s

4 check boxes 4 ∗ 3.84s = 15.36s

select ﬁeld with 5 scroll options 5.76s + 5 ∗ 1.30s = 12.26s

date ﬁeld (as text) 10 ∗ 2.12s = 21.20s

sum = 144.22s

proxy server also protocols the usage data. The mouse-over event is recorded for every

HTML element in the same way as in our study.

The tool Wusab is presented in [1]. Atter claims that automated usability valida-

tion is one of Wusab’s features. During the website development the validation runs

at regular intervals. In our tool the usability is checked on the request of the usability

engineer. The Wusab tool downloads and analyzes HTML code. The analysis is done

using guidelines such as images should have alt text. Our tool also analyzes the web

page but offers more complex criteria such as the input elements used, readability [5],

or subject [6].

Another tool is Google Analytics [3] which is very powerful analysis tool. It works

with its own database, whereby statistics can be provided independently of the web

server used. The integration into a web application is done using JavaScript. The tool

collects various items of information and sends them to the database by loading an in-

visible picture. Whereas Google Analytics provides many different statistics concerning

users, sources, contents and goals, no information, however, is available on the visiting

paths of the users. Furthermore, Google Analytics does not analyze the website itself.

5 Summary and Future Work

In this paper, using a study we have examined how long it takes test persons to ﬁll in

single input elements of a form on a website. The times spent by 80 persons to ﬁll in

the input ﬁelds were discussed in detail. As a result, the table 1 has been created, which

enables the estimation of the average time needed by one user to ﬁll in any web form.

In [4] we presented a tool which can be used to analyze how people use a website.

This tool is able to recognize paths that a single user or groups of users have taken.

Additionally, the tool determines the corresponding dwell times. These dwell times can

be validated by calculating the times described above for the forms offered. However,

websites do not consist only of forms but they also have other content. In [5] we have

collected further information on websites.

Our next aim is a case study which is to demonstrate that the average times calcu-

lated here will be useful for estimating the usability of forms on websites. To do so, we

will examine websites and web applications with different forms.

References

1. Richard Atterer. Model-Based Automatic Usability Validation - a Tool Concept for Improving

Web-Based UIs. In Proceedings of the 5th Nordic conference on Human-computer interac-

tion: building bridges, pages 13–22, New York, NY, USA, 2008. ACM.

2. Richard Atterer, Monika Wnuk, and Albrecht Schmidt. Knowing the User’s Every Move -

User Activity Tracking for Website Usability Evaluation and Implicit Interaction. In WWW

’06: Proceedings of the 15th international conference on World Wide Web, pages 203–212,

New York, NY, USA, 2006. ACM.

3. Google. Google Analytics. http://www.google.com/analytics/, accessed March 2013.

4. Ludger Martin. A Tool to Estimate Usability of Web 2.0 Applications. In 11th IEEE Inter-

national Symposium on Web Site Evolution, September 2009.

5. Ludger Martin. Gathering Information About Web 2.0 Applications for Usability Engineer-

ing. In Seventh International Conference on the Quality of Information and Communications

Technology, pages 482 – 486, September 2010.

6. Ludger Martin. Subject classiﬁcation of web pages. In IADIS International Conference

WWW/Internet 2012, pages 298 – 306, October 2012.