This section is still under construction
List of KLM-FA Assumptions
- Sequence of Elements: KLM-FA assumes that the modeled user fills the selected elements sequentially.
- Starting mouse position: top left of the screen.
- Focused element: an element with cursor or the mouse pointer on it (ready to accept keystrokes if it is editable).
- Links inside a form: are omitted when navigation occurs using mouse. For keyboard-based navigation, special KLM-FA elements called "tab holders" are used (each one is equivalent to a tab key-press required to reach a form field).
- Manipulation issues regarding Drop-down Lists: Currently, KLM-FA assumes that the modeled user wants to select the middle item of the list (future versions of the tool will allow the user of the tool to input the item to be selected in the list). Given that the scrollbar of the control appears for more than 20 items, the scrollbar is included in the KLM-FA calculations only when the list is populated with more than 40 items (in order to move to the middle of the list).
- Manipulation issues regarding Radio Buttons: KLM-FA assumes that the modeled user looks for the middle item of the radio buttons. Both Radio buttons and check boxes are fixed size (20px X 20px).
- Calculation of P using Fitts' Law: KLM-FA assumes that pointer was left on the middle of the previously manipulated element.
- Browsing of a file assumes that the target file is positioned in a visible area in the current window. Currently, P is calculated with a fixed value of 1.1.
Calculating Manipulation Time in Text Fields
KLM-FA analyzes each form element in order to produce a sequence of required actions (KLM operators) so as to first reach it (Reach Time) and then to manipulate it (Manipulation Time). While Reach Time can be calculated given some details about the previous element and the current element type, Manipulation Time depends mostly on the type of the current element. However in text fields Manipulation Time requires the semantic of each text box since the tool has to be aware of the number of keystrokes that a user has to perform in order to fill the element.
In this context, an open list of known text fields that usually appear in web forms has been created [figure 1]. The list contains pairs of fields names and keystrokes count indicating the number of the keystrokes that need to be pressed in order to fill the text field. For example the pair “password – 8” indicates that for password fields the calculated number of keystrokes in the KLM analysis will be 8. In this way, the evaluator easily maps each element of the form to an existing field of the list and makes KML-FA aware of the exact required keystrokes for each text element in the form (figure 2). This process may be automatically supported in a future version of the tool.
In general, the number of keystrokes in text elements affects the Manipulation Time for the particular elements. However, in some use cases in which the evaluator performs comparative studies keeping the same text elements, the number of keystrokes does not play critical role since the focus will be on time differences and not on the actual estimated time of one form. Thus, depending on the evaluation goal, the evaluator may update the field list and set specific keystrokes numbers (e.g. using her/his particular person’s info, using maximum allowed characters for each field, or using some domain specific averaged keystroke numbers).
KLM-FA comes with a predefined list of fields that are paired with keystroke numbers for general purpose use cases based on the literature. This means that these numbers have to be the universal average number of keystrokes for each field. Unfortunately, in the context of our research, these numbers cannot be scientifically documented in all cases, thus they have been set according to our experience. Below, a table that depicts the on-going research on defining the appropriate average keystroke numbers is presented. Keeping in mind that in many cases the keystroke numbers are domain specific, this task will be an open issue.
KLM-FA comes with a predefined list of fields that are paired with keystroke numbers for general purpose use cases based on the literature. This means that these numbers have to be the universal average number of keystrokes for each field. Unfortunately, in the context of our research, these numbers cannot be scientifically documented in all cases, thus they have been set according to our experience. Below, a table that depicts the on-going research on defining the appropriate average keystroke numbers is presented. Keeping in mind that in many cases the keystroke numbers are domain specific, this task will be an open issue.
No | Field Name | Keystrokes Number |
Documention | Comments |
1 | address | 40 | Our Assumption | |
2 | address_two_parts | 20 | Fixed: Address / 2 | |
3 | answer_secret_question | 10 | Based on Both Our Experience and Yahoo, http://help.yahoo.com/kb/index?locale=en_US&y=PROD_ACCT&page=content&id=SLN2031 | Yahoo answers vary from 4 to 23. |
4 | blog_title | 20 | Our Experience | Usually Max used is under 70 (70 is the max length of a browser title) |
5 | captcha | 6 | http://coding.smashingmagazine.com/2011/03/04/in-search-of-the-perfect-captcha/ | |
6 | city | 10 | http://www.geodatasource.com/world-cities-database | This is the result from an AVG of STRLEN of cities in the list. However a more accurate approach would be to investigate the distribution of cities' population. |
7 | comments | 30 | http://thenextweb.com/twitter/2012/01/07/interesting-fact-most-tweets-posted-are-approximately-30-characters-long/ | We took as an example tweet posts. |
8 | day | 2 | Fixed | |
9 | 25 | http://baymard.com/blog/form-field-usability-matching-user-expectations:
25 http://www.eph.co.uk/resources/email-address-length-faq/#emailavglength 23 http://janusz.slota.name/blog/2009/05/email-length/ 23 |
||
10 | fullname | 18 | Our Assumption | Sum up of: name+space+middle name+space+lastname |
11 | graduation_school | 25 | Our Assumption | |
12 | job_department | 30 | Our Assumption | |
13 | month | 2 | Fixed | |
14 | name | 5 | http://www.cse.iitk.ac.in/users/ankitkr/projects/phoneme/report.pdf | A study on a Database of Indian Names |
15 | password | 8 | M. Zviran
and W. J. Haga. Password security: an empirical study. Journal of Management
Information Systems, 15(4):161{185, 1999. [6] http://www.tandfonline.com/doi/pdf/10.1080/10658980601051318 [7-8] |
First reference is too old . Nowdays it seems that 8 is most common. |
16 | phone | 15 | http://blog.stevenlevithan.com/archives/validate-phone-number | Is international fixed. |
17 | postal_code | 5 | Fixed | |
18 | surname | 7 | http://www.census.gov/genealogy/names/dist.all.last [6-7] | USA Names |
19 | title | 3 | Our Assumption | Mr/Mrs/Miss/Ms/Dr/Rev/Sir/Lady/Lord/Dame/Prof |
20 | unknown | 10 | Our Assumption | |
21 | username | 12 | http://www.eph.co.uk/resources/email-address-length-faq/#emailavglength 12 | |
22 | webpage | 30 | http://www.theopenalgorithm.com/correlation-data/domain-name-seo/ | 15 domain.name + username + extra chars |
23 | year | 4 | Fixed | |