Heuristic evaluation - Badges

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

Performing a heuristic evaluation

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.
Use the heuristic template to guide your evaluation.
Make sure that you review all responsive states of the component.
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.

@bsouster will review this

@bsouster are you able to complete this by Friday?

A. Please indicate which devices, browsers, and operating systems were tested (Desktop/Mobile/Tablet): Windows 7: IE11, Chrome 32, Firefox 26 iOS7 (iPad): Safari iOS7 (iPhone): Safari, Chrome (Mobile view not working!) Android: Chrome (Mobile view not working!)

B. Provide status feedback

Does the component always let users know about its current status? N/A
Does the component give immediate, easy to understand feedback? Yes. (All responsive states)
Will the user have enough visual cues to easily complete the component’s tasks? Yes. (All responsive states)
If some part of a component is hidden, can users see something that allows them to bring it in and out of view? N/A

C. Match real world conventions

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. (All responsive states)
When users perform actions within the component, are the results they get what they would commonly expect? Yes, depending on whether the badges are used in correct context. (All responsive states)

D. Apply standards and ensure consistency

Have industry formatting standards been used consistently throughout? Yes. (All responsive states)
Is there a logical and consistent usage of elements throughout the component? When the badges are floating to the right on a pill that’s very wide with a white background, it’s hard to make the visual connection without hovering to bring the background in. Either way, the examples under “Adapting to active nav states” is a poor example, but in any normal situation, the text and badge would hopefully not be so far apart. (All responsive states)
Is there a consistent usage of language that is clearly understandable, relevant, concise, current and to the point throughout the component? Yes. (All responsive states)
Is the experience consistent across screen sizes? Yes. Assuming yes on Smartphone screens, but unable to properly test due to page issue. (All responsive states)

E. Help users recognize, prevent and recover from errors

Does the component help to prevent users from making errors whenever possible? N/A
When there is an error, is it simple and informative? N/A
Does it provide information to fix or correct the error? N/A

F. Design for human interaction

When using the component: a. Is the layout intuitive? Yes. (All responsive states) b. Are the interactions intuitive? Yes, assuming its use is exclusive to hyperlinks. (All responsive states)
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. (All responsive states)
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

Does the component display only the information needed by the user at any given point in time? Yes. (All responsive states)
Overall, are user interaction s kept as simple as possible? Yes. (All responsive states)
Does the component use plain language? Yes. (All responsive states)

Badges: http://search.gc.ca/rGs/s_r?st=s&s5bm3ts21rch=x&num=10&st1rt=0&langs=eng&cdn=canada&q=grants

A. Please indicate which devices were tested (Desktop/Mobile/Tablet): IE Windows 8.0.7601.17514, HP Desktop, Dell widescreen monitor (1920x1080) Apple iPhone 4 - latest iOS 7, iPad mini – latest iOS 7

B. Provide status feedback

Does the component always let users know about its current status?

Default Badge – IE 8: No. IE 8 shows a blue underline under the “42” in the grey box indicating that it is a clickable link (appears and disappears with “compatibility toggle” in IE). On roll-over the cursor changes from an arrow pointer to an “I-beam” text insertion tool. On-click the I-beam briefly changes to a pointing hand and the link works. The code needs to be fixed. With compatibility view off, the blue underline is removed from the 42 on the grey box, but there is no visual cue that the number box is clickable. There are no roll-over or on-click effects. On roll-over the arrow pointer does change to the pointing hand so the user will know it is a “clickable” element. There is no on-hover effect to explain what the 42 represents (read messages, unread messages, etc.).

Also the code needs to add a Non-linked space between the “Inbox” link and the “42” badge. The space between the elements is created by adding an extra space after the work “Inbox”. The issue is that the supposedly blank space is underlined with blue and does not provide a true separation. The “Inbox” link is formatted and works like a normal link, but the “visited” state does not work, and the colour change on roll-over is too subtle to be effective.

Default Badge – iOS 7: No. In iOS the badge has rounded ends instead of being a square box as in IE (and looks nicer). The badge does not look clickable and most users would assume that it is a “Status” indicator and not a clickable element. The “Inbox” link is formatted and works like a normal link, but the “visited” state does not work.

Adapting to Active Nav States – IE 8 & iOS 7: Most of the same comments as “Default Badge”. Plus: The white number “3” on the grey background looks bolder than the blue “42” on the white background. Also in this example the underline denoting links status for the words disappears on roll-over and on-click which goes against the WET link standards. On roll-over for “Profile” and “Messages” the underline disappears and a light grey box appears to indicate the clickable area. This example goes against the WET “Button” standard, which defines a 1px border for white buttons. Also the Grey roll-over colour is extremely light; the contrast could be improved.

Adapting to Active Nav States – iOS 7: Most of the same comments as “Default Badge”. Plus: No roll-over, on-hover, or on-click effects. For the three buttons in a horizontal row, iOS 7 displays the “Messages 3” on a light grey background. This light grey background makes the button look “greyed-out” (non-active) however; on click the link is active. The grey background is extremely light and needs to have better contrast. In IE the grey only appeared on roll-over. For the three button bars that span the width of the page, this grey background is missing.

Does the component give immediate, easy to understand feedback?

Default Badge – IE 8 & iOS 7: No. The badges do not look clickable and are missing roll-over, on-hover and on-click effects.

Adapting to Active Nav States – IE 8 & iOS 7: No. In the example where the button bar spans the width of the page, it looks as if there are two clickable items (assuming the user is now aware that they can click on the badge) the word link (Home) and the Badge link (42). Instead, the entire bar is clickable and acts as one link which may not be the feedback or action that the user would be expecting.

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

IE 8 & iOS 7: No. The numbered badges do not look clickable. Also see other comments above.

If some part of a component is hidden, can users see something that allows them to bring it in and out of view?

IE 8: Some of the items show roll-over states or underlines which indicate “clickability”. The use of the roll-over is inconsistent in the examples and goes against other WET standards.

iOS 7: There are no roll-over effects that work in iOS 7, so if the user is not aware that the badges are clickable there is nothing obvious to lead them to that conclusion.

C. Match real world conventions

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

IE 8 & iOS 7: No. Goes against other WET Standards for links and buttons and is missing the working “Visited” link status.

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

IE 8 & iOS 7: No. See comments above.

D. Apply standards and ensure consistency

Have industry formatting standards been used consistently throughout?

IE 8 & iOS 7: No. See comments above. In iOS many numbered badges are attached to icons which can enhance their meaning. For example; “42” on its own can be vague - “42” on an envelope icon can mean 42 new emails.

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

IE 8 & iOS 7: Yes, with exceptions noted above.

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

IE 8 & iOS 7: Any use of language or numbers would be writer/coder generated.

Is the experience consistent across screen sizes?

IE 8 & iOS 7: Yes. . E. Help users recognize, prevent and recover from errors

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

IE 8 & iOS 7: The lack of styling and roll-over effects may cause errors as the user might not realize that the badge is a clickable element.

When there is an error, is it simple and informative? IE 8 & iOS 7: N/A.
Does it provide information to fix or correct the error?

IE 8 & iOS 7: N/A. No Error messages.

F. Design for human interaction

When using the component:

a. Is the layout/style intuitive?

IE 8 & iOS 7: No. See comments above.

b. Are the interactions intuitive?

IE 8 & iOS 7: No. See comments above.

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?

IE 8: Yes.

iOS 7: At 100% in the Default badge example the elements are too close together in a mobile (especially in portrait mode) environment to be separate touch targets.

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?

IE 8 & iOS 7: N/A.

G. Keep it simple

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

IE 8 & iOS 7: Yes. If there are no results to show the badge is hidden.

Overall, are user interactions kept as simple as possible?

IE 8 & iOS 7: Yes.

Does the component use plain language?

IE 8 & iOS 7: Language is writer/coder controlled.

Badges: http://wet-boew.github.io/wet-boew-styleguide/v4/design/badges-en.html#default

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

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 Rollover highlighting.

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

Yes. Too much in my opinion.

4. If some part of a component is hidden, can users see something that allows them to bring it in and out of view?

N/A

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?

I don’t believe there are “common expectations” of badges yet, nor do I think these will be routinely recognized for a while. The nearest likely expectation is just a bracketed number. Like “Inbox (42)”.

Guess-ability will depend on semantic context (“Inbox (42)” is more guess-able than “Home (42)”, and perhaps on visual context (I think we’ll find light badges on a darker background more recognizable than grey badges because they look a bit like disabled buttons).

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

I suspect not.

The badges look distinct from the associated text (like “Inbox”), and folks would expect distinct behaviour. If I click an object which is distinct from the things around it, and that object has the text “42”, I’ll expect to get a result specifically about “42” (like maybe a page that starts: “You have 42 items in your inbox…”). To not be interpreted as distinct entities, I think badges need to not look like distinct objects.

D. Apply standards and ensure consistency

1. Have industry formatting standards been used consistently throughout?

Yes

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?

Yes

E. Help users recognize, prevent and recover from errors

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

N/A

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

No issue

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

N/A

F. Design for human interaction

1. When using the component:

a. Is the layout intuitive?

No. I don’t believe the widget is intuitive

b. Are the interactions intuitive?

No.

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?

No. The required information is “42”. The badge concept seems to add a whole lot of graphical and semantic meaning that is unhelpful.

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

Yes

3. Does the component use plain language?

N/A

Summary

Badges: http://wet-boew.github.io/wet-boew-styleguide/v4/design/badges-en.html#default April 14, 2014

Devices and Browsers Used in Evaluation

Device	OS	Browsers
Unknown	Windows 7:	IE11
Unknown	Windows 7:	Chrome 32
Unknown	Windows 7:	Firefox 26
iPad	iOS7 (iPad)	Safari
iPhone	iOS7	Safari
iPhone	iOS7	Chrome (Mobile view not working!)
Unknown	Android	Chrome (Mobile view not working!)
HP Desktop, Dell widescreen monitor (1920x1080)	Windows ?	IE Windows 8.0.7601.17514
Apple iPhone 4	latest iOS 7	Unknown
iPad mini	latest iOS 7	Unknown
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

A. Bugs and similar

JxRath noted that in IE 8 in compatibility view, on roll-over the cursor changes from an arrow pointer to an “I-beam” text insertion tool.

B. Overview

In general the widget did not attract a lot of criticism beyond the common issues of inconsistent Link behaviour

C. Link-related issues

Issue: Link appearance, rollover, and “Visited” behavior is not consistent across the examples.

Priority: Medium-High

Solution: All link text should follow one standard. Everywhere.

Issue: There is no Tooltip on hover & and badges communicate no meaning.

Where the badge is associated with an item that does not have an obvious count, the meaning is unclear. Some method of making the meaning clear to the naive user is highly desirable. As JxRath noted: In iOS many numbered badges are attached to icons which can enhance their meaning. For example; “42” on its own can be unclear - “42” on an envelope icon can mean 42 new emails.

Priority: Medium-High

Solution: Tool tips.

D. Standards issues

Issue: Link appearance, rollover, and “Visited” behaviour is not consistent across the examples.

Priority: Medium-High

Solution: All link text should follow one standard. Everywhere.

E. Other Visual Issues

Issue: Gray badges look disabled.

Priority: Low-medium.

Solution: Any color other than gray would help

Issue: The visual separation in Pills makes it unlikely folks will associate the Caption and the Button

Priority: Low-medium.

Solution: Always place badges near to the text they apply to (or touching the icon they apply to, as applicable)

Issue: The space between the text element and the badge is underlined. This looks messy

Priority: Medium

Solution: Remove the after the text.

F. Clickability issues

Issue: Badges Don’t look Clickable

Two reviewers observed that it is not clear that Badges are clickable in their own right. It is my belief that this is not a problem. Anything which in any way suggests that the badge is distinct from the link or other object with which it is associated will introduce confusion.

wet-boew / wet-boew-styleguide