Heuristic evaluation - Links

[rubinahaddad]

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

[JxRath]

Will Review by Jan 31

[JxRath]

Links: http://wet-boew.github.io/wet-boew-styleguide/new/design/links-en.html

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

B. Provide status feedback

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

IE 8: No. The color change on the roll-over effect is too subtle. At 100% the user can barely tell that the effect is even there. If you zoom to 400% you can notice the color change on rollover because the thickness of the type increases. Also Visited Link coloring does not seem to work.

iOS 7: In iOS 7 there is no roll-over effect, but I wasn’t expecting one. Also Visited Link coloring does not seem to work.

1. Does the component give immediate, easy to understand feedback?

IE 8 & iOS 7: Act as a web standard link but needs to have the “visited” style added.

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

IE 8 & iOS 7: Yes. The Link is underlined and is a different colour so is obvious to those used to web standards.

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

IE 8 & iOS 7: Yes. The Link is underlined and is a different colour so is obvious to those used to web standards.

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

IE 8 & iOS 7: No. The visited link colour change does not occur.

D. Apply standards and ensure consistency

1. Have industry formatting standards been used consistently throughout?

IE 8 & iOS 7: No. The visited link colour change does not occur.

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

IE 8 & iOS 7: Yes. The Link is underlined and is a different colour so is obvious to those used to web standards. However it is inconsistent with the link style on the “Buttons” example page.

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

N/A

1. Is the experience consistent across screen sizes?

IE 8 & iOS 7: Yes.

E. Help users recognize, prevent and recover from errors

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

IE 8 & iOS 7: Yes.

1. When there is an error, is it simple and informative?

IE 8 & iOS 7: If the link is broken it will likely lead to a 404 or other error page.

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

IE 8 & iOS 7: The information that the broken link page provides may offer them a solution.

F. Design for human interaction

1. When using the component:

a. Is the layout/style intuitive?

IE 8 & iOS 7: Yes. It is a web standard format.

b. Are the interactions intuitive?

IE 8 & iOS 7: Yes, if the visited link style is fixed/added.

1. 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 & iOS 7: N/A

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

IE 8 & iOS 7: Yes.

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

IE 8 & iOS 7: Yes.

1. Does the component use plain language?

N/A

[LXP122]

CRA will review.

[matyeo]

Mike Atyeo of Neo Insight will review (Android, Firefox). Target date: 9Mar14

[matyeo]

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

Samsung Galaxy S2 Android 2.3.3 Firefox 27.0

B. Provide status feedback

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

Not always.

Links are underlined, which will help users recognize them in most situations – e.g. when links are in paragraph text. However, they could also be a brighter contrast with the standard paragraph colour, to be more easily recognized. There are also situations where ‘what is a link’ is obvious from its context (especially lists of links) and underlining may not be required (to reduce visual noise), but a consistent greater-contrast colour will assist recognition.

Visited links do not have a different colour. This distinction is sometimes used by people to help in situations when they are ‘lost’, to help prevent revisiting pages.

It appears that links to the current page are disabled, as they should be, but this depends on the usage guidance, rather than the component itself.

2. Does the component give immediate, easy to understand feedback?

Yes – links underline when touched/active. Of course, there is no rollover state on touch devices.

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

Yes.

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?

N/A

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

Yes.

D. Apply standards and ensure consistency

1. Have industry formatting standards been used consistently throughout?

For the most part, apart from the ‘live’ link font colour issue and ‘visited’ link colour.

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

Yes.

There is inconsistency in link presentation throughout the WET site, which should be cleared up once the latest standard is adopted.

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

Yes.

4. Is the experience consistent across screen sizes?

No – the touch targets are too small (on Samsung Galaxy S2/Android/Firefox). There could be situations where this issue could be addressed – for example, lists of links. But it may not be possible or desirable to deal with the issue in all situations – e.g. links in paragraphs. The trade-off is readability of text vs touch-ability of links.

E. Help users recognize, prevent and recover from errors

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

Touch target size too small – will generate user errors.

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

N/A

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?

N/A

b. Are the interactions intuitive?

N/A

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, except for touch target size.

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?

Yes, except for ‘live’ link font colour and visited links.

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

Yes.

3. Does the component use plain language?

Yes.

[ballantr]

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

Device	OS	Browsers
Laptop (24 inch Monitor)	Windows 8.1	Chrome 33.0.1750.146 m
Nexus 7	Android 4.3	Chrome 33.0.1750.136

B. Provide status feedback

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

No.

The links are not easy to recognize as links, particularly for folks with color or other visual deficiencies

2. Does the component give immediate, easy to understand feedback?

No. The hover highlighting is barely detectable.

Hovering over a link in the design guide list causes the link underline to disappear. This is confusing.

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

Link coloring cues are very subtle. They are also different from what users are expected to. Furthermore there is no visited Link coloring detectable. These problems will defeat the usability of the links.

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

Not applicable

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?

No. See D1.

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

Yes.

D. Apply standards and ensure consistency

1. Have industry formatting standards been used consistently throughout?

No. The link colors and underline behavior or nonstandard. Link coloring and underline behavior is not consistent across the page. Nor is it consistent with de facto standards. This will interfere with usability. Furthermore the visited-link coloring is not detectable.

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

No. The link colors and the underline behavior are not consistent across the page

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

Not applicable

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?

Not applicable

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

Not applicable

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

Not applicable

F. Design for human interaction

1. When using the component:

a. Is the layout intuitive?

Not applicable

b. Are the interactions intuitive?

Yes

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?

Not applicable.

G. Keep it simple

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

Yes.

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

Yes.

3. Does the component use plain language?

Not applicable.

[ballantr]

Summary: Links

Devices and Browsers Reviewed

Device	OS	Browsers
Laptop (24 inch Monitor)	Windows 8.1	FF 27.0.1
Nexus 7	Android 4.3	Chrome 33.0.1750.136
HP Desktop, Dell widescreen monitor (1920x1080)	Windows 8.0.7601.17514	IE
Apple iPhone 4	latest iOS 7
Samsung Galaxy S2	Android 2.3.3	Firefox 27.0

Priority items to correct

A. The consensus of the three reviewers that the links do not look or behave in the ways that users have come to associate with links. Specifically:

1. The color is not the regular blue, and does not contrast well enough with the regular text
2. The hover/rollover color change is too subtle to be detectable at smaller screen sizes, and/or by older viewers or those with moderate vision problems.
3. The visited links do not have a different color.

B. The links were inconsistent even within the demo page itself. It is not clear that all of the links on the page were intended to be compliant – but in case they were, this is a problem!

C. One reviewer found the touch targets on the Samsung Galaxy S2/Android/Firefox to be too small.

[rubinahaddad]

Thanks @ballantr

For

A.1 Which is the regular blue you are referring to? Are there studies showing that if you don’t use that blue colour as the default link, users don’t see them?

B. Based on your testing and research should all links be underlined on default and hover, or only underlined on hover states, or do they not need the underline?

[ballantr]

@rubinahaddad

By "regular blue" I refer to the default browser link color (which differs somewhat between browsers), or the blue used in the standard search engines (Google; Bing; Yahoo). These form the de facto standards. I don't know of formal studies on the topic, but as a general principle in UI design you are much safer going with the majority. Innovation is always a risk, and you need to decide what risks you are willing to take.

Links which look and behave most like what the user is used to will be most rapidly understood, and most reliably used.

There are two visual elements that are used in links: The color and the underline. I would say you need to do at least one of these consistently for the link to be well understood. In this review the two were not consistently used.

As to your second question: Underline on hover is increasingly popular. Given that there is no hover on touch devices, however, that adds to the usability risk. Note also that the fonts used in touch devices are often very small, and the smaller the font, the harder it is to tell its color! It is therefore increasingly important that the link have a very clear and contrasting blue coloration, in my opinion.

[pcwsmith]

So if I were to summarize, one solution =

default state: use "normal" blue, no underline. hover, active states: no colour change, add underline. visited state: use "normal" purple, no underline.

(NB additional formatting for links is possible, e.g. bold for links that are headers... and there are exceptions, e.g. links in navigation components, links that appear on dark BGs such as the home page carousel)

But I do like this approach to cover links used in the content area of the page. The underline to distinguish hovering - this is what Google seems to be doing; I think it's an appropriate change in response to my user action. In fact might be a more noticable difference than a blue/purple colour change.

I can see the possibility of project sponsors being dissatisfied with "normal" blue however - since top task links are so prominent in the design pattern for the main theme landing pages. e.g. http://canada.ca/en/services/jobs/index.html - note the headers to each top task in the 3x3 grid of links, followed by the two rows of promotional features where links are the only visible text.

@rubinahaddad @thomasgohard @masterbee @pjackson28 let me know your thoughts on this please.

[pcwsmith]

... and @cfarquharson and @laurawesley and anyone else who I'm forgetting...

[thomasgohard]

default state: use "normal" blue, no underline

I have to disagree with that one. Links are underlined. That's probably the most important indicator of a link. Even more than colour (which doesn't work for people who are colour-blind).

Yes, Google removed the underline recently. But only for a very particular context of use. Their search engine results pages are not content pages and pretty much everything on those pages are links. No so with content pages.

[JxRath]

I agree with @thomasgohard - for accessibility and a wider audience the underline is still the standard.

[pcwsmith]

good points. so all states would have underlines, then? or would removing the underline in hover/active be an acceptable approach? (rather than a colour change which can't be seen by folks with various levels of colourblindness)

ie the solution could become:

default state: use "normal" blue, underlined. hover, active states: no colour change, remove underlining. visited state: use "normal" purple, underlined.

[pcwsmith]

BTW right now on canada.ca visited links do not seem to change at all on hover (maybe its my browser, IE9)

[shawnthompson]

@pcwsmith neither do the WET visited links. I'm using Firefox on a Mac. http://wet-boew.github.io/v4.0-ci/theme/index-en.html

[thomasgohard]

I wonder if the disappearing underline would lead people to think that it wasn't a link after all?

Question: Do we need a hover state for content links? Especially considering touch users don't have a hover state?

[JxRath]

Didn't the link standard used to be: LINK: Blue (0000FF) underlined LINK HOVER: Red (FF0000) underlined LINK VISITED: Purple (800080) underlined

Though you don't see many people useing red as a hover anymore. Neilson does on his site, but he also breaks the consistant underline "rule" and also mixes underlined and non-underlined links. http://www.nngroup.com/articles/break-grammar-rules/

[bsouster]

Just saw this discussion. I think this belongs here: https://github.com/wet-boew/GCWeb/issues/647

[thomasgohard]

@JxRath I believe that was it.

Maybe we can change the visited colour to something with a greater contrast ratio against the blue though?

[JxRath]

@bsouster I see your point; it does relate to the carousel problem but this is the "Link" standard page so it also bleongs here :). I see the issue on the carousel, Purple for "visited" on Navy backgound does not work. There needs to be different link styling for body text on white backgrounds and a different style for "non-standard" text links as on the carousel, or on other dark backgrounds. The carousel is already using the "non-standard" color of white and underline for the link there, so a "non-standard" option for visited would make sense in that context. I also noticed that someone has changed the rollover color on Canada.ca The dull blue link color now gets visibly brighter on rollover, which I personally find to be less jarring than a shift to red. They may still be close in tone for the completely color blind (did anyone check this in greyscale?), but for most people the rollover should now be sufficient. Still no indication of a "visited link" color change though. Generally visited links use a duller color than active links. But Canada.ca active links are already a dull blue. So a dull purple for visited?

[thomasgohard]

@JxRath @bsouster The problem in https://github.com/wet-boew/GCWeb/issues/647 is unrelated. It's due to a lack of specificity in one of the Bootstrap overrides.

[JxRath]

@thomasgohard But would a global "visited link" color affect the carousel?

[pcwsmith]

Question: Do we need a hover state for content links? Especially considering touch users don't have a hover state?

While mobile/touch usage is clearly on the rise, we still have a majority of users accessing canada.ca via desktop/laptop setups - I'll dig out the data, but I'd say hover states still helpful.

[pcwsmith]

over the last month, the pattern of visits on canada.ca has been:

mobile devices - 8% tablet devices - 7% desktop devices - 85%

(based on approx 1.9M visits during the period 25 Feb - 27 Mar 2014)

[thomasgohard]

@JxRath A global visited link colour should not affect the carousel. I'm working on a fix for this issue.

[thomasgohard]

@pcwsmith I'm aware that we still have a majority of desktop users. My question was more: Does the hover state on standard links actually have a benefit?

I understand the benefit when a link doesn't look like a link (e.g., in a navigation menu). I'm not sure that same benefit exists for a standard link that looks like a link.

[dravas-nat]

i realize that I am late in the game but here are some comments for your consideration: i agree with previous comments made to staying along industry standards "To maximize the perceived affordance of clickability, color and underline the link text. Users shouldn't have to guess or scrub the page to find out where they can click." Source: Nielsen Guidelines for Visualizing Links: [http://www.nngroup.com/articles/guidelines-for-visualizing-links/] also using color only is not best practice re: color blind people may not perceive the text as a link. hence the need for underlining text as well. Nielsen Guidelines: "underlined links are important for low-vision users' accessibility, so retain underlines if accessibility is a priority for your site..." Also changing the color of visited links is a strong convention that people have come to expect and it helps orient themselves - it helps users understand where they've been, where they are, and where they can go.

since i don't know the conclusion of this review, i am hoping these suggestions are taken into considerations.

[thomasgohard]

@dravas-nat Thanks for that.

I think we're all in agreement that underlines are staying for links and that visited links should have a different colour.

Do you have any thoughts or research on the hover state? I'm wondering how useful it is when links actually look like links.

[dravas-nat]

@thomasgohard: based on Josh Clark, author of Tapworthy: Designing Great iPhone Apps, suggests that there are New Navigation Standards for the Desktop,and one of them is: "Treat hover as an enhancement, not a requirement." see also the article posted on the UIE website - interview with Josh Clark: [http://www.uie.com/uietips/online_uietips/uietips__03_19_14.html]

[thomasgohard]

@dravas-nat Yes. That's the direction I'm leaning to as well. Especially as even desktop-size devices are becoming touch-enabled, if not touch-only, hover cannot be relied upon.

This is leading me to conclude that, for standard content links at least, we do not need a hover state.

I'm also wondering if we should have a design sprint to look into where and how hover, globally, can be used, should be used and should be avoided.

[hsrudnicki]

@rubinahaddad can we close the issue? I agree with @thomasgohard, because, based on http://ux.stackexchange.com/questions/7064/when-should-hyperlinks-be-underlined,
1) "The fundamental guideline is users must be able to recognize links by visual inspection alone—they shouldn't have to hover over an object or click it to determine if it is a link." 2) WCAG 2.0 (1.4.1): Use of Color: Color is not used as the only visual means of conveying information, indicating an action, prompting a response, or distinguishing a visual element. So, this may be an underline and in a different color.