Skip to main content

Table 5 Error handling

From: A usability design checklist for Mobile electronic data capturing forms: the validation process

 101. If pop-up windows are used to display error messages, do they allow users to see the field in error? [13]

 102. Does the tool show error signals and marks on the actual field that has an error and needs to be changed? [5]

 103. Are users prompted to confirm commands that have drastic, destructive consequences? [13, 34] e.g. deleting the form

 104. Is there an “undo” or “redo” function during data entry in the form or after completing a task or group of tasks? [14, 28]

 105. Are users able to leave an unwanted state without having to embark on an unwanted user interface interaction? [28]

 106. Does the tool warn users if they are about to make a potentially serious error? [13]

 107. Does the tool prevent users from making errors whenever possible? [13]

 108. Do data entry fields and dialog boxes indicate the number of character spaces available in a field? [13]

 109. Do fields in data entry screens and dialog boxes contain default values when appropriate? [13]

 110. Is the data specific format or input type expected of the respondent indicated where applicable before they attempt to enter text in a given field?

 111. Are the data format requirements put inside or outside of the text box?

 112. On the form, is the location of positive button (e.g., OK button, next button) on the right and negative button (e.g., cancel button, back button) on the left? [5, 13]

 113. Are touchable areas sufficiently big? [13, 32]

 114. Are the touchable objects e.g. buttons in the screen placed too close? [5]

 115. Is crowding targets avoided? For example when targets are placed too close to each other, users can easily hit the wrong one [13, 32]

 116. Are the data input types appropriate for the type of information being entered in the field e.g. use number input type for numeric information [5]

 117. Although the visible part of the target may be small, is there some invisible target space that if users hit that space, their tap will still count? [13, 32]

 118. When signalling an input error in a form, is the field that needs to be changed specifically marked? [14, 32]

 119. Does the tool preserve users’ work in order to correct errors by just editing their original action instead of having to do everything over again? [35]

 120. Does a back button simply return the form to a previous view without loss of data? [28]

 121. Does the tool reduce the work of correcting the error? Does it guess the correct action and let users pick it from a small list of fixes? [21]

 122. If an error is detected, does the tool tell the user what happened, why and how to fix it? [28]

 123. Does the system provide an example input for format-specific or complex information? [5]