11.2 Usability, Meaningful Error Messages, and Input Validation vs. Verification
Key Takeaways
- A meaningful error message says what went wrong and how to fix it in plain language, such as "Enter a whole number from 1 to 12," instead of "Error 42" or "Invalid input."
- Usability improves with clear prompts, sensible defaults, immediate feedback, confirmation before destructive actions, undo, and not making users re-enter data that was accepted.
- Validation checks that input is reasonable: type, range, format, length, presence, or membership in an allowed list.
- Verification checks that input is the value the user intended, for example by typing a password or email address twice or by clicking a confirmation link.
- Accessibility features in code include text alternatives for images, captions, full keyboard operation, labels read by screen readers, sufficient contrast, and never using color alone to convey meaning.
What this competency asks
Two ETS competencies are combined here:
- Be familiar with usability and user experience (for example, ease of use and accessibility): identify code that improves on given code in terms of usability or user experience, identify meaningful error messages, and identify features that improve accessibility.
- Understand programming techniques to validate correct input and detect incorrect input: identify effective input validation strategies, compare data validation (proper range and format) and data verification (for example, password verification), and identify improvements to code for which data validation is required.
Usability and user experience
Usability is how easily people can use software to accomplish their goals. User experience (UX) is broader and includes how the whole interaction feels. Common usability qualities include learnability, efficiency, memorability, protection from errors, and satisfaction.
| Feature | Improves usability because… |
|---|---|
| Clear prompts that state the expected format | Users know what to enter: "Enter date (MM/DD/YYYY)" |
| Sensible defaults | Common cases need fewer steps |
| Immediate feedback | Users know that an action worked: "Saved" or a progress bar |
| Confirmation before destructive actions | Prevents accidents: "Delete all 32 grades? This cannot be undone." |
| Undo | Mistakes are recoverable |
| Keep accepted input after an error | Users fix only the bad field instead of retyping everything |
| Consistent layout and wording | Knowledge carries over from screen to screen |
| Limit choices to valid ones | A drop-down list of months cannot produce "Febtember" |
Meaningful error messages
| Poor message | Why it fails | Meaningful message |
|---|---|---|
| "Error 0x3F" | A code with no meaning to users | "The file could not be saved because the disk is full. Free some space and try again." |
| "Invalid input" | Does not say what is wrong or how to fix it | "Quantity must be a whole number from 1 to 99." |
| "You entered it wrong!" | Blames the user and gives no help | "That email address is missing an @ symbol." |
| "NullPointerException at line 88" | Technical detail meant for developers | "We couldn't load your class list. Please refresh the page." (Log the details for developers.) |
A meaningful message is specific, written in plain language, polite, placed next to the problem, and tells the user how to recover.
Accessibility features in code
Accessible software works for people with visual, hearing, motor, and cognitive disabilities (Section 2.2). Features a programmer can add:
- Text alternatives for images and icons (alt text), and labels on form fields that screen readers announce
- Captions and transcripts for audio and video
- Full keyboard operation with a visible focus indicator
- Sufficient color contrast, and meaning that never depends on color alone (add text or icons to red and green status)
- Resizable text and layouts that reflow when text is enlarged
- Adjustable or no time limits, and pause controls for moving content
- Error messages that are announced to screen readers, not only shown in color
Input validation
Input validation checks that data are acceptable before the program uses them. It prevents crashes (such as a runtime error from converting "abc" to a number), prevents wrong results, and protects security, since unvalidated input enables attacks such as SQL injection.
| Check | Question it asks | Example |
|---|---|---|
| Type | Is it the right kind of data? | Age must be an integer |
| Range | Is it within limits? | 0 ≤ age ≤ 120; 1 ≤ month ≤ 12 |
| Format | Does it match a pattern? | Email has one @ and a domain; ZIP code is 5 digits |
| Length | Is it too short or long? | Password at least 12 characters |
| Presence | Is a required field filled in? | Last name is not empty |
| Allowed values (lookup) | Is it one of the permitted choices? | Grade level is 9, 10, 11, or 12 |
| Consistency | Do related fields agree? | End date is not before start date |
Validating in code
int month ← readInt ( )
while ( ( month < 1 ) or ( month > 12 ) )
print "Month must be a whole number from 1 to 12. Please try again."
month ← readInt ( )
end while
The loop re-prompts with a meaningful message until the value is valid. The condition describes the invalid values, which is the negation of the valid range 1 ≤ month ≤ 12 (De Morgan, Section 7.4).
Where validation is required: any place external input enters the program, including keyboard input, files, sensors, network messages, and form fields. Look especially at values used as divisors, array indexes, loop bounds, file names, and parts of database queries. On the web, validate on the server as well as in the browser, because browser checks can be bypassed.
Validation vs. verification
| Validation | Verification | |
|---|---|---|
| Question | Is the data reasonable: the right type, range, and format? | Is the data what the user intended, or does it match the true value? |
| Example | Rejecting a birth year of 3025 | Asking the user to type a new password twice and checking that the two entries match |
| Another example | Checking that an email address has the right format | Sending a confirmation link to that address |
| Can it catch a plausible typo? | No: 1986 typed as 1968 passes range checks | Yes: double entry exposes mismatches |
Validation cannot guarantee correctness. A valid value can still be wrong. Verification confirms that the entered value is the intended one, commonly through double entry or confirmation. ETS gives password verification as the example.
Checking a login password against the stored (hashed) password is also a verification, of identity. That is authentication, covered in Section 16.6.
A user types "thirteen" into a field that asks for the number of items to order. Which error message is most meaningful?
A registration form asks users to type their new password twice and rejects the form if the two entries differ. What kind of check is this?
The segment reads a number of students and computes the average score by dividing a total by that number. Which improvement adds the most important input validation?
int numStudents ← readInt ( )
double avg ← totalPoints / numStudents
A quiz app marks correct answers in green and incorrect answers in red, with no other indication. Which change best improves accessibility?