Open rubinahaddad opened 10 years ago
@bsouster will review this
@bsouster are you able to complete this by Friday?
@rubinahaddad Yes
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
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
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
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
Overall, are user interactions kept as simple as possible? Yes. (All responsive states excl. smartphone view)
Does the component use plain language? N/A
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
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.
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.
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.
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
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”.
IE 8, iOS 7, MacBook with Safari: No. See comments above.
D. Apply standards and ensure consistency
IE 8, iOS 7, MacBook with Safari: No. See comments above.
IE 8, iOS 7, MacBook with Safari: No. See comments above.
IE 8, iOS 7, MacBook with Safari: N/A. Language is writer/coder controlled.
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
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.
IE 8, iOS 7, MacBook with Safari: No.
F. Design for human interaction
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.
IE 8, iOS 7, MacBook with Safari: Yes. With exceptions noted above.
IE 8 & iOS 7 & MacBook with Safari: N/A.
G. Keep it simple
IE 8 & iOS 7 & MacBook with Safari: Yes. (Content is user determined) More visual cues could be added to indicate which objects are clickable.
IE 8 & iOS 7 & MacBook with Safari: Yes, though it could be improved – see comments above.
IE 8 & iOS 7 & MacBook with Safari - Examples 1 & 2: Yes. Language within the component is entirely writer/coder controlled.
Device | OS | Browsers |
---|---|---|
Windows 8.1 | Laptop (24 inch Monitor) | Chrome 33.0.1750.146 m |
Hover highlighting is inconsistent.
Yes.
No. Clickable images sometimes highlight on hover, but the highlighting is very subtle.
Other clickable images do not highlight at all.
N/A
N/A
Yes.
Yes.
Hover highlighting is not consistent.
N/A
N/A
N/A
N/A
Yes.
Yes.
Yes.
N/A
Yes.
Yes.
N/A
The widget seems well executed in most respects. However there are challenges which will impact mobile users.
@rubinahaddad Neo Insight Summary
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.
Off hand I can't offer any. I link-color border would certainly help.
Please perform a heuristic review of the following component: Images example.
Performing a heuristic evaluation