David Raneburger
email: raneburger@ict.tuwien.ac.at

David Alonso-Ríos

Roman Popp
email: popp@ict.tuwien.ac.at

Hermann Kaindl
email: kaindl@ict.tuwien.ac.at

Jürgen Falb
email: falb@ict.tuwien.ac.at

A User Study with GUIs Tailored for Smartphones

Keywords: Usability, device-tailored GUI, small touchscreen, user study

des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

Schmiedl et al. showed in an experiment that users completed tasks on small mobile devices 30-40% faster on Websites tailored for such devices than on Websites designed for desktop PCs [START_REF] Schmiedl | Mobile phone web browsing: a study on usage and usability of the mobile web[END_REF]. Smartphones and PCs have two major differences in this respect: size and input method (i.e., touch vs. fine-grained mouse pointing). What is then the best approach for tailoring Web-based GUIs for touch-based smartphones? Web-based usability guidelines typically agree that unnecessary scrolling [START_REF]User Experience and Interaction Guidelines for Windows 7 and Windows Vista[END_REF][START_REF] Nielsen | Usability Engineering[END_REF], and in particular horizontal scrolling [START_REF] Bevan | Guidelines and standards for web usability[END_REF], should be avoided on desktop devices. Recently published guidelines for touch-based devices, in contrast, state that scrolling is part of such a device's user experience and, therefore, not bad at all [START_REF]iOS Human Interface Guidelines[END_REF][START_REF]Windows 8 User Experience Guidelines[END_REF]. The different user experience originates in the more "natural" swiping gesture, in comparison to dragging a scroll-bar with a mouse, or turning its scroll-wheel. These guidelines, however, do not contain hints on whether vertical scrolling is preferable to tabs. Since we are not aware of any empirical studies that investigate these questions, we designed and performed a user study evaluating an intentionally simple Web-based GUI using different layout approaches for a process-oriented application (flight booking). Our focus is on vertical scrolling vs. tapping, while two-dimensional scrolling and horizontal browsing is out of scope. Based on the collected data, we present both a statistical and a subjective evaluation of the results.

Related Work

Different GUI designs and input methods for touch-based mobile phones are investigated in [START_REF] Balagtas-Fernandez | Evaluation of user interface design and input methods for applications on mobile touch screen devices[END_REF], focusing on overall interface layout (scrollable vs. tabbed GUI), input mode (keyboard vs. tapping through a modal dialog) and menu access (device menu vs. context menu). The two GUIs under study in [START_REF] Balagtas-Fernandez | Evaluation of user interface design and input methods for applications on mobile touch screen devices[END_REF] differed in all these characteristics, which were investigated through an assigned task. Nevertheless, it is hard to prove that only the investigated characteristic accounts for slower performance and that there is no influence from other characteristics. Our study, in contrast, is based on GUIs that differ only in one characteristicthe layout. In addition, our GUIs are HTML pages rendered on Web browsers, which display them similarly on different devices. This helps to minimize the influence that familiarity with specific devices may have on users' perceptions of usability and correlated time-on-task [START_REF] Suzuki | Variation in importance of time-on-task with familiarity with mobile phone models[END_REF].

Recently, Lasch et al. investigated touchscreen scrolling techniques and their effect on car driver distraction [START_REF] Lasch | Designing browsing for in-car music player: effects of touch screen scrolling techniques, items per page and screen orientation on driver distraction[END_REF]. Their results indicate that swiping was less distracting while driving than traditional scroll buttons or kinetic scrolling. The latter uses the same gesture as swiping, but it accelerates the menu. The menu stops automatically after deceleration or if the user taps on the screen. So, this work investigates three different ways of scrolling in a context where distraction is a safety risk. Our primary concern, in contrast, is to achieve good usability in a context where the user concentrates on a specific task. Therefore, we investigated whether scrolling was preferable to tabbed panels, or vice versa. Nevertheless, the results of both studies complement each other.

Comparable user studies have also been performed in the past, but only with desktop devices [START_REF] Harms | Usability engineering methods for the web: results from a usability study[END_REF][START_REF] Baker | The impact of paging vs. scrolling on reading online text passages[END_REF][START_REF] Peytchev | Web Survey Design: Paging versus Scrolling[END_REF], old cell-phones [START_REF] Buchanan | Improving mobile internet usability[END_REF] or PDAs [START_REF] Kim | Web design issues when searching for information in a small screen display[END_REF], so their results are not necessarily valid for current smartphones. Previous user studies on touch-based devices (e.g., PDA or smartphone) assumed that the user does not like to scroll and, therefore, primarily focused on investigating strategies to avoid or minimize scrolling [START_REF] Jones | Improving web interaction on small displays[END_REF][START_REF] Kaikkonen | Navigating in a mobile XHTML application[END_REF][START_REF] Churchill | Learning object design considerations for small-screen handheld devices[END_REF]. Jones et al. [START_REF] Jones | An evaluation of integrated zooming and scrolling on small screens[END_REF] found that users preferred vertical over two-dimensional scrolling on small screens. Our results extend these findings for current touch-based devices through the comparison of two different layouts tailored for smartphones.

User Study Design

In order to evaluate the different GUIs, we combined quantitative data (task completion time and error rate) with subjective data (user questionnaires) like Jones et al. [START_REF] Jones | Improving web interaction on small displays[END_REF] and Buchanan et al. [START_REF] Buchanan | Improving mobile internet usability[END_REF].

In our study setup, we tested two different layouts for an otherwise identical user interface. Both layouts were tailored for a small device each (a 320×480px iPod Touch / iPhone up to version 4S, which all show the GUI in the same way), more precisely in portrait mode. However, they followed different approaches (tabs vs. vertical scrolling). The application was a simplified flight-booking scenario consisting of HTML pages as follows:

 Screen 1. Origin and destination airports, flight date.  Screen 2. List of flights available on that date.  Screen 3. Billing information.

Fig. 1 shows screenshots of these screens, where Screens 1 and 3 are the ones tailored, while Screen 2 is identical for both layouts, as it is small enough to fit perfectly. Due to space limitations, Fig. 1 shows Screen 1 only in its form for vertical scrolling, and Screen 3 only in its tabbed form. During the test each layout was, of course, the same from the beginning to the end of the taskthere were no changes of layout in the middle of a task. We split the participants into two groups, reversing the order in which the two layouts were tested. At the end of each test, we collected their subjective opinions through a questionnaire and, sometimes, a brief and informal interview. Overall, we hired 30 participants as summarized in Table 1.

Table 1: Participant Details.

Age:

18-39 years Gender:

3 female and 27 male Educational level:

28 students and 2 assistants with doctoral degrees Use of mobile devices: 56.7% regular, 40% sometimes but never owned one, 3.3% never Online flight booking: 20% regular, 40% sometimes and 40% never At the beginning of each experiment we informed the participants about the content of the study and the procedure. We emphasized that the point was to test the GUIs, not the skill of the participants. We asked them to fill in some background data and to give their consent to filming their hands operating the iPod Touch (for subsequent video annotation) and recording their voices. We fixed the iPod Touch to the table, setting it in portrait mode for the following reasons: the GUIs have been tailored for this mode; we wanted all the participants to use the same mode; filming would have been difficult if the participants were holding the iPod Touch.

We gave the following scenario description to the participants: We left a printed version on the table, where it could be easily seen, so that participants did not have to remember the information. We emphasized the urgency of the task, so that the participants would concentrate on the task and finish it quickly and realistically.

"
After the participants completed both tasks, we collected their subjective opinions on several usability-related issues through a questionnaire and finally asked them if they had further comments, in which case we made a brief interview.

For our analysis, we were primarily interested in the correlations between task time / error rate and the type of layout. An independent variable was the GUI, with these possible values: tab-based (T-UI) and vertical scroll-based (V-UI). This variable is dichotomous, as we only compared two GUIs per run. A second independent variable was the order in which the two layouts were tested. The dependent variables were adjusted task completion time and error rate. For the adjusted task completion analysis, we measured the total time spent on a screen. We also measured the time needed for text input, screen loading, form submission, validation alerts and error messages, which are all layout-independent and may introduce bias into the results. Therefore, we subtracted all these times from the total time, resulting in adjusted task time.

For the error rate analysis we measured the number of errors each participant made on a given screen. Errors in our study occurred when the participant hit "submit" without entering some required information.

As the type of GUI is dichotomous and the calculated time is on an interval scale, we calculated the point-biserial Pearson correlation coefficients. Our tests also showed that the variables are nearly normally distributed and thus satisfy the prerequisites of the point-biserial Pearson correlation. Note that the difference to the more common t-test is that the correlation covers coherence, while the t-test deals with differences of means. The corresponding null hypotheses are correlation hypotheses as follows:

 NH VT,T : There is no statistically significant correlation (p-value = 0.05) between the adjusted task time and the type of GUI: V-UI and T-UI.  NH VT,E : There is no statistically significant correlation (p-value = 0.05) between the error rate and the type of GUI: V-UI and T-UI.

In order to extract task completion times and error rates from our video recordings of the tests, we used the video-annotation tool Anvil1 , and converted the files to CSV in order to analyze the data with SPSS.

The participants were also given a subjective usability questionnaire for collecting information on how they perceived usability. With some adaptations, our definition of usability was based on [START_REF] Alonso-Ríos | Usability: A critical analysis and a taxonomy[END_REF], which aims to synthesize the best-known usability definitions in the literature. We discarded those usability characteristics that were either not relevant or identical on all layouts (e.g., security) and tried to phrase the usability criteria as short and self-explanatory questions, for which we also consulted the USE Questionnaire2 , the W3C's WAI 3 , the Software Usability Measurement Inventory 4 (SUMI) and the Cognitive Dimensions framework [START_REF] Blackwell | Cognitive dimensions of notations: Design tools for cognitive technology[END_REF].

For each question, the participant had to state the preferred layout on a Likert scale with preference being "extreme", "strong", "moderate", and "equal". The participants were explicitly asked to focus on the differences between layouts, rather than evaluate the usability of each layout independently. The reason is that for our study, which compares different layouts, their difference is relevant. Measuring usability on an absolute scale is more difficult and not necessary for our study.

Results

Table 2 summarizes the statistical results for the adjusted task time analysis. The positive correlations in Table 2 show that vertical scrolling performs better than the tab-based layout, with highly significant results. The sum of times for all screens (minus typing time, etc.; see above) is on average 25.81 seconds for the vertical scrollbased GUI (V-UI) and 36.79 seconds for the tab-based GUI (T-UI). The null hypothesis NH VT,T can be rejected for this experiment, i.e., the adjusted task time using V-UI is significantly smaller than using T-UI in Screen 1 and Screen 3. In fact, it took 54% longer to operate T-UI.

Table 3 shows the correlation between the error rate and the two layouts (V-UI and T-UI), together with the average number of errors for each screen. For Screens 1 and 3, the error rate is significantly smaller. On Screen 2, however, there were no errors, thus no correlation could be calculated. So, the null hypothesis NH VT,E can also be rejected for this experiment. That is, the error rate for V-UI is significantly smaller than that of T-UI in Screens 1 and 3. Actually, there were no errors for V-UIall the errors can be attributed to the participants hitting "submit" before changing tabs, so this could be an argument against using tabs. 4 presents the results of the subjective questionnaire. In their overall assessment (i.e., the last questionnaire item), the majority (60%) of the participants preferred the vertical scroll-based GUI, but 30% preferred the tab-based GUI. The answers to the other questions varied much. There was only one criterion for which T-UI was widely preferred: visual attractiveness.

The error rate result was confirmed by participants in interviews, where they stated that it is easy to forget to switch tabs before hitting "submit" even when they were aware that there were two tabs. As for V-UI, the questionnaire shows that it was considered much more intuitive to navigate and to interact with, and slightly less demanding and more efficient to use in general. However, opinions were sharply divided on which GUI made information more visible and which GUI lent itself more to how the participants like to work. It is worth noting that, whenever opinion was divided, analyzing the data showed no clear relationship between the answers and the background of the participants, including whether they owned such a device or not.

Conclusion and Future Work

This paper reports on a user study with GUIs specifically tailored for smartphones. We used task time analysis, error rate measurement, subjective questionnaires and interviews. Participants performed significantly better when scrolling vertically, as opposed to tapping on widget elements (tabs). This preference was also reflected in their subjective opinions. The study also suggests that minimizing the number of taps is important on a smartphone. We conjecture that our study results are not limited to such a simplified flightbooking application as the one used for two reasons. First, we defined a scenario that reduced the user task to entering pre-given data, without having to decide about actually booking a particular flight or not. Second, we used a very simple prototypical application that allowed only for exactly the interaction that was required to complete the given task, without alternatives. This also helped to keep the user focus on the interaction and allowed all users to complete the task successfully.

In future work, we plan to investigate related issues, and e.g., to study variablesized lists, since it is not clear if vertical lists of any length are necessarily better than a tab-based layout. There may be a balance involved between motor performance and understanding the content.

( a )Fig. 1 .

 a1 Fig. 1. Screens tailored for iPod Touch / iPhone up to version 4S.

  Imagine it is Tuesday 14/02/2012, 11:55am and your boss Mr. Huber tells you to book a flight ticket for his wife as quickly as possible. Mrs. Huber is already waiting at the airport! Book a flight from Munich to Atlanta on 02/14/2012 at 1pm for Mrs. Anna Huber (age 47). Pay for it using her husband's (Max Huber's) VISA Credit Card with the number: 1258 8569 7532 1569 (validation code: 354) and the expiration date 12/14."

Table 2 .

 2 Correlation between adjusted task time on a screen and its layout.

	Pearson Corr.	Sig. (1-tailed) V-UI av. time T-UI av. time
	Time Screen1 × GUI 0.35	0.003	12.79s	17.98s
	Time Screen2 × GUI 0.12	0.189	8.17s	9.50s
	Time Screen3 × GUI 0.43	0.000	4.85s	9.31s

Table 3 .

 3 Correlation between the number of errors on a screen and its layout.

	Pearson Corr.	Sig. (1-tailed) V-UI av. errors T-UI av. errors
	Errors Screen1 × GUI 0.363	0.002	0	0.23
	Errors Screen2 × GUI -	-	0	0
	Errors Screen3 × GUI 0.285	0.014	0	0.2
	Table

Table 4 .

 4 Subjective Questionnaire Results.

	Question	V-UI preferred	equal	T-UI preferred
		extreme strong moderate		moderate strong extreme
	Which interface makes in-	3.33% 33.33%	10%	6.67%	30%	13.33% 3.33%
	formation more visible?
	Which interface makes	13.33% 26.67% 26.67%	30%	3.33%	0%	0%
	interaction more intuitive?
	Which interface makes it	20% 36.67%	20%	10%	10%	3.33%	0%
	easier to figure out what to
	do next?
	Which interface makes it	0% 13.33%	30%	53.33% 3.3%	0%	0%
	clearer how to use it?
	Which interface lends itself	13.33% 23.33% 13.33% 23.33%	10%	13.33% 3.33%
	more to how you like to
	work?
	Which interface requires less	6.67% 20%	26.67% 26.67% 13.33% 6.67%	0%
	manual interaction?
	Which interface demands	3.33% 13.33% 16.67% 56.67%	10%	0%	0%
	less precision on your part?
	Which interface demands	13.33% 10%	26.67% 33.33%	10%	6.67%	0%
	less time from you?
	Which interface makes	10% 6.67% 26.67% 33.33% 16.67% 6.67%	0%
	interaction more efficient?
	Which interface is more	0%	0%	6.67%	10%	40%	23.33% 20%
	visually attractive?
	Overall, which interface	16.67% 20%	23.33%	10%	10%	13.33% 6.67%
	would you use to book a
	flight?

http://www.anvil-software.org/

http://www.stcsig.org/usability/newsletter/0110_measuring_with_use.html

http://www.w3.org/WAI/EO/Drafts/UCD/questions.html

http://sumi.ucc.ie/en/

Acknowledgments. David Alonso-Ríos's research was funded by the University of A Coruña (Spain) through the "Axudas á Investigación" programs of 2011 and 2012, and also in part by the Xunta de Galicia through projects CN2011/007 and CN2012/211, both projects also partially supported by the European Union ERDF.


Christos Katsanos
email: ckatsanos@eap.gr

Nikos Karousos
email: nkarousos@eap.gr

Nikolaos Tselios

Michalis Xenos
email: xenos@eap.gr

Nikolaos Avouris
email: avouris@upatras.gr

KLM Form Analyzer: automated evaluation of web form filling tasks using human performance models

Keywords: Web form design, task efficiency, user performance time, automated tool, human performance models

Filling forms is a common and frequent task in web interaction. Therefore, designing web forms that enhance users' efficiency is an important task. This paper presents a tool entitled KLM Form Analyzer (KLM-FA) that enables effortless predictions of execution times of web form filling tasks. To this end, the tool employs established models of human performance, namely the Keystroke Level Model and optionally the Fitts' law. KLM-FA can support various evaluation scenarios, both in a formative and summative context, and according to different interaction strategies or modeled users' characteristics. A study investigated the accuracy of KLM-FA predictions by comparing them to participants' execution times for six form filling tasks in popular social networking websites. The tool produced highly accurate predictions (89.1% agreement with user data) in an efficient manner.

Introduction

Usability of interactive web forms is a critical aspect of the overall user experience. Form filling is a data entry task, and thus user efficiency is of particular importance in the design of web forms. Current design practices are mostly empirical and rely on guidelines derived from experimental studies comparing alternative designs and usability experts' experience or observations. For instance, the type of form elements as well as their positioning in the form layout significantly affect users' performance [START_REF] Bargas-Avila | Working towards Usable Forms on the Worldwide Web: Optimizing Multiple Selection Interface Elements[END_REF].

One may argue that theoretically-based approaches have had a limited impact on web form design practices. Unlike desktop [START_REF] Soukoreff | Towards a Standard for Pointing Device Evaluation, Perspectives on 27 Years of Fitts' Law Research in HCI[END_REF] or mobile interfaces [START_REF] Myung | Keystroke-Level Analysis of Korean Text Entry Methods on Mobile Phones[END_REF][START_REF] Maragoudakis | Improving SMS usability using Bayesian Networks[END_REF], GOMS [START_REF] Card | The Psychology of Human Computer Interaction[END_REF] and its simplified version Keystroke-Level Model (KLM) [START_REF] Card | The Psychology of Human Computer Interaction[END_REF][START_REF] Card | The Keystroke-Level Model for User Performance Time with Interactive Systems[END_REF], have been rarely used to guide web form design or evaluation. In addition, if field size and position on the form layout are not taken into account in such model-based techniques, superficial results may arise. For instance, interaction with a dropdown menu theoretically takes longer than interaction with radio buttons. This is due to an additional point and click needed to open the dropdown menu. However, in one study the latter hypothesis was confirmed [START_REF] Healey | Drop Downs and Scrollmice: The Effect of Response Option Format and Input Mechanism Employed on Data Quality in Web Surveys[END_REF] and in another it was rejected [START_REF] Hogg | Drop-down, Radio Buttons, or Fill-in-the-blank? Effects of Attribute Rating Scale Type on Web Survey Responses[END_REF].

As a result, there is a need to bridge HCI models, such as KLM, with design and evaluation practices. Previous research [START_REF] John | Predictive Human Performance Modeling Made Easy[END_REF] resulted in the development of CogTool, a tool that can produce quantitative, model-based predictions of skilled performance time from tasks demonstrated on storyboard mockups of a user interface. CogTool-Explorer [START_REF] Teo | CogTool-Explorer: towards a Tool for Predicting User Interaction[END_REF] builds upon CogTool to predict a user's goal-directed exploratory interaction with a website. Currently available model-based tools require non-trivial manual work to examine forms. In addition, if a large scale summative evaluation is needed, the evaluator has to repeat the same process without any particular assistance. Furthemore, the plethora of available functions and generic modeling nature of existing tools can overwhelm and discourage practitioners who, in most cases, need a simple tool focused on the problem at hand.

To tackle the aforementioned problems, in this paper a novel tool entitled KLM Form Analyzer (KLM-FA) is presented. KLM-FA extends the capabilities of existing modeling tools for practitioners by focusing specifically on automating the analysis of web forms. The paper is organized as follows: The tool functionality and usage is delineated in the next section, along with its internal architecture and reasoning. Finally, a validation study comparing KLM-FA results to human performance data is presented and discussed.

2

The KLM Form Analyzer Tool

The main objective of KLM-FA (available at http://klmformanalyzer.weebly.com) is to support design and evaluation of web forms in an effective and efficient manner. The tool employs web parsing algorithms, coupled with KLM and Fitts' modeling to estimate the time required to fill a web form according to different interaction strategies (e.g. using tab to move across the elements) or users' characteristics (e.g. age and typing expertise). Figure 1 presents the main interface and functionality of KLM-FA.

KLM-FA Typical Usage Scenario

First, the evaluator inputs the URL of the web form to be evaluated or selects a previously evaluated form. Next, the evaluator selects a set of analysis preferences related to the modeled user profile (typing ability, age), usage (or not) of Fitts' law in the calculations, and hypotheses about the interaction, such as initial cursor position and whether the user moves across form elements using the mouse or the keyboard. The evaluator can also assign a predefined field type to text elements (e.g. username, email) to easily specify their number of keystrokes. The tool provides an editable list of field types that covers most of the elements used. The default typical field entry lengths rely on empirical data available in the literature (e.g. mean password length [START_REF] Cazier | Password Security: An Empirical Investigation into E-Commerce Passwords and Their Crack Times[END_REF]) and a dataset of our own with 839 registered web users' personal data. Next, KLM-FA runs an algorithm which parses the evaluated form, produces the sequence of predicted user actions (KLM operators) based on the evaluator's selected analysis preferences and estimates task completion time based on a set of analysis parameters related to KLM and Fitts' law calculations. Based on empirical data [START_REF] Kieras | Using the Keystroke-Level Model to Estimate Execution Times[END_REF][START_REF] Olson | The Growth of Cognitive Modeling in Human-Computer Interaction since GOMS[END_REF], the tool provides a set of default values for the analysis parameters, which can be easily modified through appropriate dialogues. The internal architecture and algorithms employed by the tool are delineated in the next section. The output of the tool is an interactive web form preview synchronized with a results list: when an element is selected in the web form preview it is highlighted in the results list and vice versa. Depending on the evaluation scenario, mental operators can be added or any element can be excluded from the analysis by simply unchecking it from the results list. In all cases, the tool updates the results in real time. Furthermore, KLM-FA provides an option that elaborates the underlying KLM modeling for each element in a tooltip. In this way, one can trace step-by-step the KLM modeling analysis by simply selecting the sequence of the form elements either in the web preview or in the list. Each evaluated form can be saved and/or subsequently modified. In addition, KLM-FA can employ mass scale summative evaluations by selecting a set of saved projects. Then, the tool runs an analysis of all the selected forms using the same settings for all projects and saves the results in an XML file.

Internal Architecture and Reasoning

The KLM-FA internal architecture comprises two conceptual layers: the user interface layer, responsible for the interaction with the tools' user, and the KLM analysis layer (named KLMKernel). The latter handles the elements identification through Parsing Module. It is responsible for parsing a provided webpage to identify existing forms and their elements. To this end, it employs two separate algorithms: a) form identifier, and b) element identifier. The form identifier parses the HTML DOM loaded in the internal browser and finds all forms. It filters out forms that cannot be eligible for analysis (hidden) and presents a "select form" dialogue if two or more forms are found. Then, the element identifier parses the selected form, identifies and stores visible fields in the internal ElementList. Currently, the tool cannot identify fields when either Flash or AJAX is used. However, KLM-FA provides support to manually add fields and specify their properties in a straightforward manner (e.g. clicking on unidentified field registers its position and size). The following pseudocode sketches the element identifier algorithm which produces an updated ElementList. Analysis Module. This module performs the KLM modeling and related calculations. It takes as input the ElementList along with the following parameters:

GetFormElements

 evaluator-defined preferences concerning modeled users' typing proficiency and age, mouse or keyboard usage for navigation and manipulation of the elements, Fitts' Law activation, and initial position of the user's hands and cursor,  predefined time values for KLM operators and Fitts' constants,  paired list of [fieldname-keystrokes] that is used for text entry calculations, and  set of KLM analysis rules regarding placement of mental operators, and other specific modeling assumptions (e.g. manipulation of dropdown lists with keyboard).

For each form element the algorithm produces the sequence of required actions (KLM operators) to first reach it (ReachTime) and then manipulate it (ManipulationTime). This distinction enables flexible modeling of various user interaction strategies (e.g. tab-based navigation). In addition, the algorithm creates an explanatory text of the KLM modeling rationale which can be displayed as a tooltip in the web preview form. Concerning Fitts' law, the analysis module calculates the pointing operator by storing the previous position of a simulated mouse cursor and updating it whenever the modeling process requires its movement to a new position. The MacKenzie-Shannon formula and constants [START_REF] Soukoreff | Towards a Standard for Pointing Device Evaluation, Perspectives on 27 Years of Fitts' Law Research in HCI[END_REF] for Fitts' law are the default selection for modeling pointing device movement time. However, given the lack of consensus on the Fitts' formula [START_REF] Drewes | Only One Fitts' Law Formula Please![END_REF], the tool offers additional options (e.g. Welford's formulation [START_REF] Soukoreff | Towards a Standard for Pointing Device Evaluation, Perspectives on 27 Years of Fitts' Law Research in HCI[END_REF]) and it is also easy to add further formulas or modify constants values.

Finally, KLM-FA sums up the results and produces a sequence of operators and the predicted form completion time for the provided analysis preferences and parameters. The entire form analysis concludes to an updated ElementList that can be saved, reanalyzed with a different set of parameters or exported to an XML file. In addition, the form analysis algorithm can be executed for a set of saved forms (ElementLists) to rapidly produce massive KLM modeling results for the same set of analysis parameters. The following pseudocode sketches the form analysis algorithm.

Analyze(ElementList){

TypeElement prev_el; foreach element in ElementList if (is_active(element)) prev_el = ElementList.GetPreviousActiveElement (element, nav_using_mouse()); if (Fitts_Law is_enabled() and nav_using_mouse()) estimate_FittsP_Reach(element); analyze_element_reach(element, prev_el); analyze_element_manipulation (element); }

Validation Study

The aim of the study was to investigate the accuracy of the results obtained by using KLM-FA. The study compared the KLM-FA predictions with user testing data for three signup forms of popular social networking websites: facebook, twitter, and myspace. For each form, two interaction strategies were investigated: a) mouse-based, in which a user is assumed to interact with the form using the mouse, except for input in text entry fields, b) keyboard-based, in which form fields are reached using the tab key and manipulated only through the keyboard. In both interaction strategies, users were assumed to fill the fields following the form layout. All in all, times for a total of six form-filling tasks (3 forms x 2 interaction strategies) as calculated by KLM-FA and measured through user testing were compared.

Fifteen University students, 12 male, with a mean age of 27 (sd=5.8), a mean of 14 years of QWERTY keyboard usage (sd=4.2) and a mean typing speed of 42 corrected words per minute (sd=16) took part in the study. First, participants completed a short online demographics questionnaire and a typing speed test. Next, they were asked to perform 10 trials for each of the six tasks and their behavior was monitored by an inhouse web-based software developed for the needs of the study. Ten trials have been used in similar studies [START_REF] Luo | Predicting Task Execution Time on Handheld Devices Using the Keystroke-Level Model[END_REF] to allow users' to reach skilled performance. In this study, participants were allowed to perform additional trials if their tenth trial was not errorfree (max number of trials observed = 12). Task execution times were derived from participants' last error-free trial.

In each trial, participants were first presented with an instructions webpage, followed by the actual form which appeared when they clicked on a link. In the instructions page, they were asked to familiarize themselves with the form registration data and were instructed to strictly employ a specific interaction strategy (i.e. mouse-based or keyboard-based) in order to fill the form as fast and correct as possible. In the form webpage, participants were first required to press a start button located in the top-left of the screen, which started logging of actions and ensured the same starting cursor position for all. The presentation order of both the forms and interaction strategies were counterbalanced to avoid serial order effects. Participants used an HP standard keyboard, an HP 3-button optical mouse and a TFT 17" screen with a resolution of 1280x1024. User sessions lasted about 75 minutes.

In KLM-FA, the following assumptions were used: a) the user was a poor typist (40 wpm) and aged below 40, b) system response time was negligible, c) the cursor's initial position was at the top-left corner of the page, d) tool defaults for all analysis parameters were used, apart from field entry lengths that were appropriately adjusted for each task, e) the user's hand began on the main device of each interaction strategy, and f) Fitts' law calculations were enabled in KLM-FA. KLM-FA analyses were also conducted on a TFT 17" screen with a resolution of 1280x1024. The process to evaluate all six tasks using KLM-FA required approximately 10 minutes.

Table 2 presents participants' task execution times and KLM-FA calculated times for each form and interaction strategy combination, along with the KLM-FA error rate. The error rate was calculated as the participants' mean task time minus the KLM-FA predicted time, and this difference divided by the participants' mean task time. Results show that the mean error of KLM-FA predictions was 10.9% (sd=6.4%), which is well within the 20% margin of error reported in the literature for KLM predictions in other contexts [START_REF] Card | The Keystroke-Level Model for User Performance Time with Interactive Systems[END_REF], [START_REF] Ivory | The State of the Art in Automating Usability Evaluation of User Interfaces[END_REF]. The lowest and highest KLM-FA error rate values were 4.5% and 17.6% respectively. In general, KLM-FA tended to slightly overestimate (16.7% on average) and underestimate (5.1% on average) task time in the mouse-based and keyboard-based interaction strategies respectively.

Conclusions

This paper presents KLM-FA, a tool that employs predictive models of human performance to estimate execution times of web form filling tasks. In addition, a study is presented that demonstrates the accuracy of KLM-FA predictions by comparing them to human execution times for the same six form filling tasks. KLM-FA extends the capabilities of existing general modeling tools for practitioners, such as CogTool [START_REF] John | Predictive Human Performance Modeling Made Easy[END_REF], by focusing specifically on web form interaction. In this way, KLM-FA increases automation of evaluation tasks, minimizes the required effort and achieves increased simplicity and flexibility, thus increasing the chances of its adoption in actual practice. As a result, practitioners can rapidly evaluate alternative web form design approaches using a variety of scenarios. In addition, the ability of KLM-FA to evaluate keyboard-based interaction with web forms can be valuable in automated accessibility testing. KLM-FA can also be used to produce benchmark data of form completion times for specific web domains, such as social networking or e-commerce. Finally, the tools' step-by-step tracing of the KLM modeling supports learning through examples and thus can be valuable for both educators and students.

Investigating the effect of KLM-FA adoption on the learning outcome, while educating students in KLM, constitutes a future research goal. In addition, we plan to conduct additional studies that compare KLM-FA predictions with human performance data. An additional future research goal is to incorporate enriched models of KLM [START_REF] Holleis | Keystroke-Level Model for Advanced Mobile Phone Interaction[END_REF] in order to support design of web forms that enhance users' efficiency in mobile interaction contexts.

Despite the advantages of the presented automated approach, it only addresses task efficiency which is one aspect of the web user experience. Other tools that automate different aspects of web design are also available [START_REF] Katsanos | A Survey of Tools supporting Design and Evaluation of Websites based on Models of Human Information Interaction[END_REF]. However, all such approaches should be used in conjunction with user-based methods.

Fig. 1 .

 1 Fig. 1. Overview of the KLM-FA interface and functionality: (a) Mass scale evaluation, (b) Analysis rules and parameters, (c) Analysis preferences, (d) Tooltip explaining KLM modeling for the selected field, (e) Semantic mapping of a text-entry element to a number of keystrokes

  the KLM modeling calculations. The fundamental data structure of the KLM-FA is the Element class, which is used to represent each element.

Table 1 .

 1 Table1presents its main data members. The KLMKernel first parses a given form to produce a structured list of Elements (named ElementList) and then performs the KLM analysis and updates the ElementList with the results. Data members of the Element class, the fundamental data structure of KLM-FA.

	Data member	Brief Description
	TagName	HTML form tag (e.g. <select>) or special KLM-FA tag (e.g. tabholder)
	Type	HTML type of <input> tag (e.g. password, text, radio etc.)
	Name	Value of the HTML name attribute
	Choices	Number of choices for radio buttons and drop-down lists
	MappedField	Semantic mapping of a text-entry element to a number of keystrokes
	Position	X and Y coordinates of the element position in the form layout
	Size	Width and height of the element
	MentalExtras	Mental operators manually added or removed
	Active	Flag to denote whether the element is included in the calculations
	ReachTime	Predicted time required to reach the element
	ManipulationTime Predicted time required to manipulate the element
	KLMexplanation	Explanatory text describing the rationale of the derived KLM operators

Table 2 .

 2 Study results showing means and, in parenetheses, standard deviations.

	Signup	Interaction	Participants'	KLM-FA predicted	rates of KLM-
	form	strategy	task time (ms)	time (ms)	FA predictions (%)
	Facebook Mouse-based	30739 (6742)	35320	14.9%
	Facebook Keyboard-based 27306 (7752)	25640	6.1%
	Myspace Mouse-based	33201 (6341)	39050	17.6%
	MySpace Keyboard-based 29641 (9310)	28320	4.5%
	Twitter	Mouse-based	22478 (5146)	26420	17.5%
	Twitter	Keyboard-based 23144 (6108)	24240	4.7%

Acknowledgements

This work has been partly funded by the European Territorial Cooperation Operational Programme "Greece-Italy 2007-2013" under the project Intersocial.