wet-boew / wet-boew-styleguide

A style guide for the Web Experience Toolkit.
http://wet-boew.github.io/wet-boew-styleguide/index-en.html
36 stars 32 forks source link

Heuristic evaluation - Images #27

Open rubinahaddad opened 10 years ago

rubinahaddad commented 10 years ago

Please perform a heuristic review of the following component: Images 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.
rubinahaddad commented 10 years ago

@bsouster will review this

rubinahaddad commented 10 years ago

@bsouster are you able to complete this by Friday?

bsouster commented 10 years ago

@rubinahaddad Yes

bsouster commented 10 years ago

A. Please indicate which devices, browsers, and operating systems were tested (Desktop/Mobile/Tablet): Windows 7: IE11, IE10, 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? No hover state for linked images under “media list” and “media heading”. Only indicator is the hand cursor. The thumbnail examples have a sufficient hover state. (All responsive states excl. smartphone view)

Does the component give immediate, easy to understand feedback? N/A

Will the user have enough visual cues to easily complete the component’s tasks? Again, Media list and heading image links are not clearly identified as link. (All responsive states excl. smartphone view)

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 excl. smartphone view)

When users perform actions within the component, are the results they get what they would commonly expect? Yes. (All responsive states excl. smartphone view)

D. Apply standards and ensure consistency

  1. Have industry formatting standards been used consistently throughout? Yes. (All responsive states excl. smartphone view)

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

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

Is the experience consistent across screen sizes? I cannot test Smartphone devices properly due to a page viewport issue, but tablet works consistently with monitor view and looks very nice.

E. Help users recognize, prevent and recover from errors

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

  1. When using the component: a. Is the layout intuitive? Yes. (All responsive states excl. smartphone view) b. Are the interactions intuitive? Yes. (All responsive states excl. smartphone view)

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? N/A

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. (All responsive states excl. smartphone view)

Overall, are user interactions kept as simple as possible? Yes. (All responsive states excl. smartphone view)

Does the component use plain language? N/A

JxRath commented 10 years ago

Images: http://wet-boew.github.io/wet-boew-styleguide/new/design/images-en.html

A. Please indicate which devices were tested (Desktop/Mobile/Tablet): HP Desktop, Dell widescreen monitor (1920x1080), IE Windows 8.0.7601.17514 Apple iPhone 4 - Latest iOS 7 - Mobile Safari iPad mini – Latest iOS 7 – Mobile Safari MacBook Air, Mac OS X V.10.7.5 (Lion), Safari V.6.1.1

NOTE: None of the example images have an “alt tag” associated with them that shows up on-hover, but it is available in the code, so I will not list it as a deficiency.

NOTE: The “clickable” thumbnails all link to the top of the page. While images are sometimes used as a link, it is a more common expectation that on clicking a thumbnail, a larger version of the image will appear. In the WET standard, this would mean launching a lightbox with the large version of the image, an image title, and a close “X” as in: http://wet-boew.github.io/v4.0-ci/demos/lightbox/lightbox-en.html I would suggest that the launching of the lightbox/large image be added to the coding of the active clickable thumbnail components. I will not list this as a deficiency in all the clickable thumbnails below.

B. Provide status feedback

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

IE 8 – Cropping and Bordering Images: No. All of the images look the same (Squares) as IE does not support any level of rounded corners. The third image in the row has a white border around it and is non-clickable, though it looks identical to the clickable thumbnails in the examples below.

iOS 7, MacBook with Safari – Cropping and Bordering Images: No. The third image in the row has a white border around it which makes it look identical to the clickable thumbnails in the examples below. The first image has nicely rounded corners and the second image is a circle. Both of these were squares in IE 8.

IE 8 – Responsive Images – Thumbnails: No. Thumbnails do not look clickable. The user has to know enough to mouse-over the images. On mouse-over, the light grey 1 px border turns cyan and the cursor changes from an arrow pointer to a pointing hand, indicating that the object can be clicked. The thumbnails do not work in the proper “responsive” manner. The 4 images are stacked vertically and the white space around them expands to fill the width of the browser window. They do not “obey” the responsive grid resizing and re-flowing that WET uses. The images will eventually resize if the web browser window is narrowed by an excessive amount.

MacBook with Safari – Responsive Images – Thumbnails: No. As in IE 8 the images do not look clickable until the user rolls-over them causing the cursor change and the border color to change to cyan. The 4 images originally are displayed side-by-side in a horizontal row. (IE stacked them vertically). As the browser window is narrowed from the full-screen width the images reduce in size to maintain their horizontal row layout.

As the browser window is further narrowed, the images enlarge again and the layout changes from “4 in a row” to “2 up, 2 down”. The whitespace around the images is no longer even; it is wider on the horizontal margins.

If the browser window is narrowed even more, the 4 images become stacked vertically and the whitespace on the horizontal edges expands to the width of the browser window. Moving the browser window to its maximum “narrowness”, the extra whitespace padding the horizontal space around the images reduces, but the image remains the same size.

iOS 7 – Responsive Images – Thumbnails: No. The thumbnails do not look clickable. There is no roll-over effect, and since these are touch devices there is no change in the cursor (because there is no cursor) to indicate that the items are clickable.

On-click the user is taken to the target, in this case the top of the page. If the user scrolls back down they can see that the border on the thumbnail has turned cyan.

By default the images are laid out “2 up, 2 down” with a quadruple the amount of whitespace on the horizontal edges than the top edges. No amount of zooming in or out causes the layout to change. The iPad and iPhone do not have the ability to narrow the browser window as the MacBooks can do with a floating application window. The layout also remains consistent in portrait and horizontal modes.

IE 8 – Custom Thumbnail Content: No. Given that there are no visual cues to tell if a thumbnail image is clickable or not, users may try to click on the image to see an enlargement of it. If they do, nothing will happen. As with the “Responsive images” above the layout does not look good in IE 8, the 3 custom content examples layout in a vertical stack. The image is centered horizontally, and the text and buttons align to the left. It might look better if all of the elements were centered horizontally.

When dragging the browser window narrower, the image size reduces to keep the entire image visible to eliminate any horizontal scrolling (good). The Buttons and text remain the same size while the images get smaller (good).

MacBook with Safari – Custom Thumbnail Content: No. As in IE 8, the user may click on the thumbnail expecting it to expand but it does not. There are no visual cues to differentiate the clickable and non-clickable images without mousing-over them. The lack of cursor change lets the user know they are not clickable. The default layout on the MacBook is 3 across horizontally when the browser is the full width of the screen.

On narrowing the width of the screen, the thumbnails reduce in size to maintain the “3 across” layout. On further narrowing, the thumbnails enlarge again to their original size, but the layout changes to “2 up, 1 down”. On reducing the screen further, the layout shifts to stacking vertically with excess whitespace on the horizontal edges of the component (similar to the default IE 8 layout). On maximum “narrowness” the extra horizontal whitespace disappears and the thumbnail remains the same size as the original “3 across” dimension.

The Buttons and text always remain the same size while the images get smaller or larger.

iOS 7 – Custom Thumbnail Content: No. Same as MacBook and IE, the user cannot tell if the are clickable. The default layout is “2 up, 1 down”. As the user moves from portrait to horizontal the size of the entire component (thumbnail, text, and buttons) enlarges slightly, but the proportions and layout remain consistent.

IE 8, iOS 7, MacBook with Safari – Media Objects: No. As mentioned in the other examples the media objects do not look clickable. Unlike the clickable thumbnails there is no grey border and the edges of the object do not turn cyan on roll-over or on-click as they do in the “Default Thumbnail” example.

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

IE 8, MacBook with Safari: No. Clickable objects do not look clickable. There is also a lack of consistency in the behaviors of the objects that are clickable (cyan border on roll-over, on-click).

iOS 7: No. In iOS 7 there is no feedback at all for the clickable objects. (no roll-over, cursor change, on-hover or on-click effects.) After a clickable item is touched, the action associated with it will occur. In some cases this may be an unexpected surprise.

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

IE 8, MacBook with Safari: No. Due to the lack of initial visual cues to indicate which objects are clickable and the inconsistency in the coding of the clickable components the user could often be misled. Only on roll-over can users figure out which thumbnails are clickable and which are not.

iOS 7: No. In iOS 7 there are no visual cues at all for the clickable objects. (no roll-over, cursor change, on-hover or on-click effects.) The user may be unaware that they should touch the object to get an effect to occur.

  1. 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, MacBook with Safari: Not just by looking at the object. The user must roll-over the thumbnails in order to see if they are clickable or not. Sometimes the border changes to cyan on roll-over, sometimes it does not (responsive thumbnails vs. media objects). The cursor change from an arrow to a pointing hand is the only consistent indicator that an object is clickable.

iOS 7: No. In iOS 7 there are no visual cues at all for the clickable objects. (no roll-over, cursor change, on-hover or on-click effects.) The user may be unaware that they should touch the object to get an effect to occur.

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, MacBook with Safari: No. Common expectations are that clickable objects look clickable. Also roll-over, on-hover, on-click behaviors should be consistent within a UI. Also common expectations are when clicking on a thumbnail that it launches a larger version of that thumbnail. See comment above in the “NOTES”.

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

IE 8, iOS 7, MacBook with Safari: No. See comments above.

D. Apply standards and ensure consistency

  1. Have industry formatting standards been used consistently throughout?

IE 8, iOS 7, MacBook with Safari: No. See comments above.

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

IE 8, iOS 7, MacBook with Safari: No. See comments above.

  1. 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, MacBook with Safari: N/A. Language is writer/coder controlled.

  1. Is the experience consistent across screen sizes?

IE 8, iOS 7, MacBook with Safari: No. As mentioned above, the layout and size of the components change and re-flow based on the screen size. Most of the time (except in IE 8) the reflow or resizing works well and is not unexpected.

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, MacBook with Safari: No. Due to lack of initial visual cues and lack of consistency of roll-over, on-hover and on-click effects, the clickable elements may not be recognized as such.

  1. When there is an error, is it simple and informative? IE 8, iOS 7, MacBook with Safari: There are no error messages. The most likely error is that the user has no way of knowing which elements are clickable and which are not. The only way the user can tell is on-roll-over. This is especially an issue in iOS 7 where there is no cursor to change on roll-over; the only way to tell if an object is clickable is to touch it and see what happens.
  2. Does it provide information to fix or correct the error?

IE 8, iOS 7, MacBook with Safari: No.

F. Design for human interaction

  1. When using the component:

a. Is the layout/style intuitive?

IE 8, iOS 7, MacBook with Safari: No. See comments above.

b. Are the interactions intuitive?

IE 8, iOS 7, MacBook with Safari: No. See comments above.

  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, MacBook with Safari: Yes. With exceptions noted above.

  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?

IE 8 & iOS 7 & MacBook with Safari: 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 & MacBook with Safari: Yes. (Content is user determined) More visual cues could be added to indicate which objects are clickable.

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

IE 8 & iOS 7 & MacBook with Safari: Yes, though it could be improved – see comments above.

  1. Does the component use plain language?

IE 8 & iOS 7 & MacBook with Safari - Examples 1 & 2: Yes. Language within the component is entirely writer/coder controlled.

ballantr commented 10 years ago

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

Device OS Browsers
Windows 8.1 Laptop (24 inch Monitor) Chrome 33.0.1750.146 m

B. Provide status feedback

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

Hover highlighting is inconsistent.

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. Clickable images sometimes highlight on hover, but the highlighting is very subtle.

image

Other clickable images do not highlight at all.

image

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?

Yes.

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

Hover highlighting is not consistent.

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?

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?

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?

Yes.

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?

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.

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

Yes.

3. Does the component use plain language?

N/A

ballantr commented 10 years ago

Summary

Notes:

  1. IE does not support any level of rounded corners. All the images look square.

Priorities for fixing

The widget seems well executed in most respects. However there are challenges which will impact mobile users.

  1. Make it obvious that an image is clickable without having to hover. Clickable images look no different from non clickable images. Touch displays don’t support hover, so the user has no way of knowing if an image has a link embedded. Given that there is a convention for small displays that clicking on non-linked images is used to expand them users may get unexpected results unless it is predictable in advance what the result of a click/touch will be.
  2. Make hover behavior consistent and salient for all clickable images. Hover highlighting for clickable images is inconsistent (some do, some don’t), and not sufficiently salient when it does occur.

@rubinahaddad Neo Insight Summary

rubinahaddad commented 10 years ago

Thanks @ballantr !

For # 1 are there examples of common used patterns that makes it obvious that an image is clickable without having to hover? We are currently making sure any clickable image has link text associated to it. We also did suggest having a border around all clickable images, and on the hover/active/focus state the border colour would change to the same colour as the link hover colour (bright blue) to be consistent, but we couldn't find any good examples of sites that do this.

ballantr commented 10 years ago

Off hand I can't offer any. I link-color border would certainly help.