Heuristic evaluation - Calendar: Date picker

[rubinahaddad]

_Note: This interface is dependant on the core device or platform components (ex. keyboards, dropdown rendering etc). This component may require additional testing on platforms such as iOS, Android, Blackberry._

Please perform a heuristic review of the following component: Calendar: 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.

[nrustand92]

A. Laptop (Chrome) B. Provide status feedback

1. Does the component always let users know about its current status? Quite so. If no date is picked, the format is dd/mm/yy. Except for Start Date where the year for the example has been set to 2013
2. Does the component give immediate, easy to understand feedback? As Steve Krug says, “Don’t make me think,” in his famous usability book. The downward arrow button next to the dd/mm/yy makes me think a little bit about what it is. The IE version is better, where there is a calendar icon in place of the arrow.
3. Will the user have enough visual cues to easily complete the component’s tasks? Yes, but they have to “play around” just a tiny little bit. E.g., need to highlight dd or mm or yy and clicking the up/down arrow will change the date, month, and/or year, respectively
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 (downward arrow) 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? See B2, the IE version is slightly better
6. When users perform actions within the component, are the results they get what they would commonly expect? I imagine the answer is yes in the finalized version. In this working example, they have to work within the confines of the coded mix and max dates/months/years. D. Apply standards and ensure consistency
7. Have industry formatting standards been used consistently throughout? I believe for this, the Chrome native support takes over??
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? Yes
10. Is the experience consistent across screen sizes? Yes E. Help users recognize, prevent and recover from errors
11. Does the component help to prevent users from making errors whenever possible? Yes. The year’s start date is set to 2013 (can’t be clicked) shows that if there are date restrictions, users can be prevented from picking the wrong date/month/year
12. When there is an error, is it simple and informative? If the feature I discussed in E1 is implemented, then yes. Otherwise, perhaps there could be a message that says, “You have picked the date of xx/yy/zz,” continue? Just to give user a double check.
13. Does it provide information to fix or correct the error? If error is detected, it’s easy to fix. User places cursor in the date box or click another date from calendar F. Design for human interaction
14. When using the component: a. Is the layout intuitive? Could be better. In calendar mode, (when downward black arrow is clicked), one can change month/year with the left/right arrows. There’s also another tiny downward arrow next to the (Month, year) label when clicked, it shows the months in a year. One user tested (my dad) thought it would be for the next month and my mom doesn’t even get it at all. If it wants to show a list of months, then the downward arrow should be put next to the month, not the year b. Are the interactions intuitive? Similar to F1a above, could be better
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? Yes in my case
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? N/A (?) ---without context it’s hard for me to say. If this is part of filling out a form, will the gov allow for the picked dates to be saved? 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? See B2 & C1, otherwise it is simple
19. Does the component use plain language? Yes

[LXP122]

CRA will provide feedback on this widget

[rubinahaddad]

@LXP122 are you able to complete this by Friday?

[LXP122]

Yes. Targeting this Friday.

From: Rubina Haddad [mailto:notifications@github.com] Sent: January-27-14 2:24 PM To: wet-boew/wet-boew-styleguide Cc: Patterson, Lowell Subject: Re: [wet-boew-styleguide] Heuristic evaluation - Calendar: Date picker (#17)

@LXP122https://github.com/LXP122 are you able to complete this by Friday?

— Reply to this email directly or view it on GitHubhttps://github.com/wet-boew/wet-boew-styleguide/issues/17#issuecomment-33410742.

[LXP122]

Yes we will complete this evaluation by Friday Jan 31.

Thank you / Merci! Nathalie Savard Tel.: 613-941-9363 NEW | Fax: 613-954-9222 Visit the Usability Resource Center sitehttp://infozone/english/r2424161/solutions/bpagol-peagel/dc-ce/org2/urc-e.asp Learn about Usability and User Interface Designhttp://infozone/english/r2424161/solutions/bpagol-peagel/dc-ce/org2/uidu-e.asp Design & Development Centre - Centre de la conception et du développement System Engineering and Development Support Division - former Development Center Solutions Architecture and Integration Directorate - former BPA and GOL directorate Solutions, ITB, CRA / DGI, ARC From: Jakob Nielsen’s Alertbox: February 17, 2013 “It’s much better to bake-in usability from the very start—before you’ve even begun to design anything—than it is to wait until there’s a near-final design and then subject it to “validation” in user testing. Early focus on usability also vastly boosts ROI http://www.nngroup.com/articles/usability-roi-declining-but-still-strong/ ; it’s 100 times cheaper to fix a design flaw on the drawing board than after product launch.”

From: Rubina Haddad [mailto:notifications@github.com] Sent: January 27, 2014 2:24 PM To: wet-boew/wet-boew-styleguide Cc: Patterson, Lowell Subject: Re: [wet-boew-styleguide] Heuristic evaluation - Calendar: Date picker (#17)

@LXP122https://github.com/LXP122 are you able to complete this by Friday?

— Reply to this email directly or view it on GitHubhttps://github.com/wet-boew/wet-boew-styleguide/issues/17#issuecomment-33410742.

[dravas-nat]

A. Please indicate which devices, browsers, and operating systems were tested (Desktop/Mobile/Tablet): Firefox 21.0 on Windows 7 Desktop. B. Provide status feedback

1. Does the component always let users know about its current status? Not always. When a date has been picked and the user returns to calendar view to change it, it doesn’t indicate which date has been selected (unlike some commercial sites). Nothing was ‘in focus’ when the calendar view opened.
2. Does the component give immediate, easy to understand feedback? Yes.
3. Will the user have enough visual cues to easily complete the component’s tasks? No. a) The underlined dates indicating available dates in the calendar is not a recommended design re: links usually indicates that users will navigate somewhere else not a selection. An alternative design should be similar to the JQuery date picker example below; the dates that are unavailable for picking should be clearly displayed as ‘disabled’.

Current WET4 widget JQuery Date picker example

b) It was unclear what would happen if user was to click the link on the month-Year. Using drop down list for Month and Year gives the user clear cues that these values can be changed quickly. The JQuery example above displays the dropdown list continually and dynamically changes the calendar when a drop down entry is selected. The JQuery example is an example of simple and clear user interaction.

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? No. See comments in section B-3a) and b).
6. When users perform actions within the component, are the results they get what they would commonly expect? No. See comments in section B-3a) and b). D. Apply standards and ensure consistency
7. Have industry formatting standards been used consistently throughout? Not always. See B3a+b. Plus the black and white schema seems ‘harsh’ and inconsistent with numerous popular commercial sites.
8. Is there a logical and consistent usage of elements throughout the component? No. When I see underlined text, I expect to navigate somewhere or displaying additional information.
9. Is there a consistent usage of language that is clearly understandable, relevant, concise, current and to the point throughout the component? Yes.
10. Is the experience consistent across screen sizes? Not tested. E. Help users recognize, prevent and recover from errors
11. Does the component help to prevent users from making errors whenever possible? Yes to a certain extent. This widget should not be used for date of birth entry field..
12. When there is an error, is it simple and informative? N/A.
13. Does it provide information to fix or correct the error? N/A. F. Design for human interaction
14. When using the component: a. Is the layout intuitive? Yes. b. Are the interactions intuitive? Improvements are highly recommended as indicated in section B-3a) and b).
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? Only desktop tested.
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? N/A. G. Keep it simple
17. Does the component display only the information needed by the user at any given point in time? No. Needs to explicitly show that the year and month can be changed when first displayed. See comments in section B-3a) and b).
18. Overall, are user interactions kept as simple as possible? No. Too many steps to change the year and month. See comments in section B-3a) and b).
19. Does the component use plain language? Yes.

[dravas-nat]

link to JQuery example for comments related to Section B-3a) and b): http://jqueryui.com/datepicker/#dropdown-month-year

[LXP122]

Please note that the datepicker rendering in Firefox likely has a bug. The underlined 'Goto' link does not appear when the datepicker is first presented as it does for IE8. Instead the month, is underlined. While having the 'Goto' link makes the datepicker polyfill slightly more usable, it is not immediately obvious that users have to click on 'Goto' in order to be able to select a calendar view for a different year and/or month and then 'Go' in order to select a day from that calendar. This requires too many clicks and a calendar polyfill should not require instructions!

[dravas-nat]

see review of the calendar date picker from jakeU on March 11, 2014 with results and recommendations based on usability tests: [https://github.com/wet-boew/wet-boew-styleguide/issues/73]

[matyeo]

Thanks for pointing to the @jakeU review, @dravas-nat. Note that I'm querying the relationship of this item #17 to item #73 with @rubinahaddad @pjackson28 @laurawesley and others.

[pcwsmith]

looks like #73 represents the third HE for the date picker - probably should have been posted as a comment in this thread. but now that it's extensively been linked, we're all good! thx

[ballantr]

Review of Calendar/Date Picker

http://wet-boew.github.io/v4.0-ci/demos/datepicker/datepicker-en.html 17 April, 2014

This review was undertaken because the previous reviews did not round out the Devices and Browsers fully

A. Please indicate which devices, browsers, and operating systems were tested (Desktop/Mobile/Tablet):

Device	OS	Browsers
Laptop (24 inch Monitor)	Windows 8.1	IE 11.0.3
Laptop (24 inch Monitor)	Windows 8.1	FF 27.0.1
Laptop (24 inch Monitor)	Windows 8.1	Chrome 33.0.1750.146 m
Nexus 7	Android 4.3	Chrome 33.0.1750.136
Nexus 7	Android 4.3	FF 28
iPhone 4	iOS 7	Safari

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?

Yes, except for dates that are out of range.

For Windows Desktop/IE and Windows Desktop/FF it seems to just delete invalid typed in dates (or accept them without protest, I can’t tell.)

For Windows Desktop/IE and Windows Desktop/FF, using the calendar widget, the strategy of (a) not allowing scrolling to invalid months and years is OK, but the strategy of showing invalid days, but not underline/linking them is too obtuse.

For Windows Desktop/Chrome the fixed “2013” (only that year allowed) is hard to make sense of (at least when there is nothing to predict that that year is the only valid one), and the font color difference is too subtle to be useful.

For Android/FF, it is possible to select invalid dates. When I press the Submit button a message flashes up for about 300 ms and then disappears. The message only reliably reappears if I re-focus the field by, e.g. trying to edit the date.

?Bug? For Android/Chrome it is possible to select the day BEFORE the valid range

3. Will the user have enough visual cues to easily complete the component’s tasks?

For simple date entry, the several UIs I looked at are all different, but I think they are all largely OK, with the following exceptions:

The date-range limiting behaviour is unintelligible - The Desktop FF & IE strategy of showing invalid days, but not underline/linking them is too obtuse.

The Desktop/Chrome frozen and gray "2013" Begin date will not be understood, but it likely does not impact usability.

Chrome has this mess of icons/features, and I suspect many will just avoid them and have to type in entire dates:

Windows Desktop/Chrome: the “Year/Month” picker, and the “Today’s date” picker (dot) are not clear (and the dot does not work correctly when the Year/Month picker is activated and pointing to another year.

Windows Desktop/Chrome: In the snap below, at the right it says March (and the March dates are bold), but the body of the display is actually showing the entire month of .April. This is confusing.

In the snap below the valid dates in the calendar area (April 1-) are greyed out, and the invalid dates (All of March) are black (albeit with a grey background)

Whereas all the other browsers I looked at had some visual element at the right of the field, in Android/FF there is none. Not a big problem, but could be better.

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

1. Do parts of the component match what you see, hear (if any) and touch (if any) meet common expectations and are they easily recognizable?

They are all rather different from what I have got used to, but apart from the issues mentioned, they are OK.

2. When users perform actions within the component, are the results they get what they would commonly expect?

Except for the date-limiting aspects, and the validation problems mentioned, yes.

D. Apply standards and ensure consistency

1. Have industry formatting standards been used consistently throughout?

Not sure there are effective standards.

2. Is there a logical and consistent usage of elements throughout the component?

Yes

3. Is there a consistent usage of language that is clearly understandable, relevant, concise, current and to the point throughout the component?

N/A

4. Is the experience consistent across screen sizes?

Not consistent across devices or browsers

E. Help users recognize, prevent and recover from errors

1. Does the component help to prevent users from making errors whenever possible?

Yes, except for the fact that you can select invalid dates as detailed in B2, and the circumstance that Chrome will display the wrong month (also detailed in B2)

2. When there is an error, is the messaging simple and informative?

Not visible in Android/FF or Windows Desktop/IE and Windows Desktop/FF.

3. Does it provide information to fix or correct the error?

See above

F. Design for human interaction

1. When using the component:

a. Is the layout intuitive?

Barely in Android implementations

b. Are the interactions intuitive?

Acceptable

2. 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?

Yes

3. 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?

N/A

G. Keep it simple

1. Does the component display only the information needed by the user at any given point in time?

OK

2. Overall, are user interactions kept as simple as possible?

Mostly

3. Does the component use plain language?

Yes

[ballantr]

Summary: Date Picker

http://wet-boew.github.io/v4.0-ci/demos/datepicker/datepicker-en.html 17 April, 2014

A. Devices and Browsers Used

Device	OS	Browsers
Laptop		Chrome
Desktop	Windows 7	Firefox 21.0
Laptop (24 inch Monitor)	Windows 8.1	IE 11.0.3
Laptop (24 inch Monitor)	Windows 8.1	FF 27.0.1
Laptop (24 inch Monitor)	Windows 8.1	Chrome 33.0.1750.146 m
Nexus 7	Android 4.3	Chrome 33.0.1750.136
Nexus 7	Android 4.3	FF 28
iPhone 4	iOS 7	Safari

B. Overview

In general the reviewers found the Date picker usable, though they were not very positive, and some issues were raised by all.

Two of the reviewers used only a single device/browser, so they did not see the fact that the user experience is different between browsers. At least 4 different UIs were observed by this reviewer. This is not in itself a big problem as folks using more than one browser or device are likely to be more sophisticated users. However it suggests a rather random approach to development. Given the so-so reviews, I would recommend trying again to find one good control that meets all the requirements, and is consistent across devices.

The fact that only one reviewer saw the UI on a variety of devices makes it clear that that the widget is under-reviewed.

C. Bugs etc.

For Android/Chrome it is possible to select the day BEFORE the valid range.

Android/FF, it is possible to select invalid dates. When I press the Submit button a message flashes up for about 300 ms and then disappears. The message only reliably reappears if I re-focus the field by, e.g. trying to edit the date.

It is not clear that if validation operates at all with Windows Desktop IE & FF. Nothing happens when invalid dates are entered or submitted.

D. Issues

Validation delay

• Problem: In several of the UIs it is possible to select or to enter invalid dates. However validation is postponed until the user submits.
• Priority: Medium
• Suggestion: Validate ASAP. At latest when the control loses focus. Report validation errors in a way that is consistent with the validation standard.

Chrome Month/Year picker not clear

• Problem: Two reviewers noted that the in Windows Desktop/Chrome: the “Year/Month” picker, is not clear. One reviewer tested two older people, both of whom had some issues with it.
• Priority: Low-Medium (there are other ways to accomplish the task)
• Suggestion: Use a different control

Day selection in Desktop FF & IE is unclear

• Problem: Two reviewers had issues with the Desktop FF & IE strategy of showing invalid days, but not underline/linking them is too obtuse. Using underlines is in any case not recommended as no navigation is entailed. One reviewer recommended the jquery date picker as a better solution.
• Priority: Low-Medium
• Suggestion: Use a different control

Day-Month-Year v Year-Month-day

• Problem: In Android/FF the field wants ‘YYYY-MM-DD’, but the picker control presents the choices in Day-Month-Year order. (It does the same for Android/Chrome, but that field displays them in Day-Month-Year order. See elsewhere. )
• Priority: Low
• Suggestion: Use a control which presents them in consistent and regionally appropriate order.

Date Ordering

• Problem: Different devices display different date formats. Android Chrome shows MM/DD/YYYY, but FF on the same device shows YYYY-MM-DD.
  
• Priority: Low
• Suggestion: Use a control which presents them in consistent and regionally appropriate order.