Heuristic evaluation - Date picker

[rubinahaddad]

Please perform a heuristic review of the following component: Date picker example.

Performing a heuristic evaluation

1. Post a comment on this issue indicating that you will perform a heuristic evaluation of the component. If you see that at least three people have already indicated that they are performing a heuristic evaluation, consider reviewing another component.
2. Use the heuristic template to guide your evaluation.
3. Make sure that you review all responsive states of the component.
4. Once you have completed your evaluation, post the results as a comment on this issue as follows:
   • For each heuristic, display the heading containing the letter of the section, and the number of the heuristic. Below each heading, provide the results of your evaluation of that heuristic. (e.g., B. Provide status feedback 1. Your result).
   • Make sure you specify which responsive state each result applies to. If a result applies to all responsive states, specify that it applies to all responsive states.

[nschonni]

Note that this is a polyfill for a native element, and there is no way to change the behaviour or appearance in Chrome's native appearance. Mobile devices will also likely have native versions that we do not control.

[jakeU]

Description and Intended Usage The following list represents an evaluation of the date picker component. The purpose of this evaluation is to to identify use conditions (design patterns) where the date picker is an effective and efficient method for users to enter dates into online forms. This evaluation is based on: • Predictive modelling (using keystroke-level modelling software to predict how long humans typically take to enter dates using the calendar) • Moderated usability test (with volunteer participants) • WET Heuristic evaluation template

Recommended usage: For keyboard and mouse interactions, use the date picker when: • The user needs to view a calendar in order to identify a date, that is: o a specific day (for example, the first Monday in April), or o a sequence of days (for example, the last two weeks in August). • The user needs to enter a date within the current week or calendar month.

For keyboard and mouse interactions, do not use the date picker: • for Date of Birth; • when dates to be entered are (or could be) months or years distant from the date picker’s default date (for example, April 4, 2020); • as an optional control (with the intent of offering the user a secondary method of input); • if entering a wrong date can result in irreversible errors.

Recommendation rationale: The keystroke model predicted that the date picker would be much quicker than other methods of entering dates, but only for dates within the current month or an adjacent month.
The moderated usability test validated the pattern that task times increased for dates that were distant from the current/default date picker date. However, the usability test showed that distant months/years took much longer to select than predicted and occasionally resulted in re-tries and user errors. Other date entry methods (such as a single text field, “YYYY-MM-DD”, or a series of drop down menus, “YYYY” “MM” “DD”) did not result in user errors.
Those longer task times were caused by the variety and complexity of the controls as well as errors while manipulating the Previous and Next arrows and the Go To link, as well as expecting the calendar to be updated when the month or year was changed in the drop down menus. (i.e., via the Go link). Further testing to explore these issues is recommended. Participants’ behaviour show that it would not be appropriate to offer the date picker as an “alternative choice” for the user. Users are not able to make an ‘informed’ choice between the calendar icon or date field because they expect the calendar to be most efficient for all conditions, but they are unaware of the conditions under which the calendar takes longer to use and can lead to user errors.

Quick Compliance Checklist A. Please indicate which devices, browsers, and operating systems were tested (Desktop/Mobile/Tablet): Desktop - Windows 7, IE8

B. Provide status feedback

1. Does the component always let users know about its current status? --Yes
2. Does the component give immediate, easy to understand feedback? --No. Users sometimes don’t notice they have selected the wrong date.
3. Will the user have enough visual cues to easily complete the component’s tasks? --No. Some date-entry conditions can be difficult (distant months or years)
4. If some part of a component is hidden, can users see something that allows them to bring it in and out of view? --Yes C. Match real world conventions
5. Do parts of the component match what you see, hear (if any) and touch (if any) meet common expectations and are they easily recognizable? --Yes
6. When users perform actions within the component, are the results they get what they would commonly expect? --No. The calendar is not as efficient as expected for distant months/years. D. Apply standards and ensure consistency
7. Have industry formatting standards been used consistently throughout? --Not evaluated
8. Is there a logical and consistent usage of elements throughout the component? --Yes
9. Is there a consistent usage of language that is clearly understandable, relevant, concise, current and to the point throughout the component? --n/a
10. Is the experience consistent across screen sizes? --No E. Help users recognize, prevent and recover from errors
11. Does the component help to prevent users from making errors whenever possible? --No
12. When there is an error, is the messaging simple and informative? --No
13. Does it provide information to fix or correct the error? --No F. Design for human interaction
14. When using the component: a. Is the layout intuitive? –No. Users sometimes don’t notice the “Go” button or “Go To” link. b. Are the interactions intuitive? – Sometimes; Day selection=yes; month/year selection=not always.
15. Is the layout designed so that various input methods (touch, keyboard, mouse, gesture) and screen sizes can easily interact with things like input fields, sliders and buttons? -- not evaluated
16. If the task can't be completed in one session, does the user have an option to save and return to it at a later time? --No G. Keep it simple
17. Does the component display only the information needed by the user at any given point in time? --Yes
18. Overall, are user interactions kept as simple as possible? --No
19. Does the component use plain language? --Yes

[matyeo]

This item and issue #17 are now inextricably linked - to be treated as one item :-)