Heuristic evaluation - Tabbed Interface

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

A. Please indicate which devices were tested (Desktop/Mobile/Tablet):

Tested on Apple MacBook Air (OS 10.9), with Firefox 26.0, Safari 7.0 (9537.71) and Chrome 30.0.1599.101

Tested on Apple iPod Touch (4th Gen) with iOS 6.1.5

B. Provide status feedback

Does the component always let users know about its current status? Yes (Desktop and iPod)
Does the component give immediate, easy to understand feedback? Yes (Desktop and iPod)
Will the user have enough visual cues to easily complete the component’s tasks? For the most part yes, but for people with cognitive disabilities (e.g. dyslexia), literacy issues or a different primary language speaker, the indication of the current active tab could be improved with a physical state change of the active tab (e.g. denote the current active tab by increasing the physical height and a bolding of the tab heading). For example, adding similar to the active tab CSS - border-top: 5px solid #aaa; (Desktop - refer to WCAG guideline 1.4 Distinguishable)

Yes. (iPod)

Note: On desktop, also tested with CSS turned off.

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

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 (Desktop and iPod)
When users perform actions within the component, are the results they get what they would commonly expect?

Note: with CSS turned off on Desktop, tabbing between links (li a) and panel content (i.e. content within accompanying class="tgl-panel”) was not always made visible. This may be low priority issue as user would have to disable CSS first.

Steps to replicate issue:

Disable page CSS
Tab key to active Tabbed interface
Hit Enter key and focus is gained on accompanying Tabbed Interface panel content
Tab key to next Tabbed Interface panel content (all good so far)
Toggle between panel content (in Tabbed Interface) using arrow keys
Reverse tab to List Anchors (li a) - note the panel content now change stage to closed toggle (indicated with toggle arrow facing fight)
Now tab key back to a close panel content and cannot get closed panel content to toggle open.

D. Apply standards and ensure consistency

Have industry formatting standards been used consistently throughout? Yes (Desktop and iPod)
Is there a logical and consistent usage of elements throughout the component? Yes (Desktop and iPod)
Is there a consistent usage of language that is clearly understandable, relevant, concise, current and to the point throughout the component? Yes (Desktop and iPod)
Is the experience consistent across screen sizes? Yes (Desktop and iPod)

Tested at: 1920 x 900 1280 x 900 980 x 1280 800 x 600 600 x 800 768 x 1024 360 x 640 320 x 480

E. Help users recognize, prevent and recover from errors

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

F. Design for human interaction

When using the component:

a. Is the layout intuitive? Cannot see any major barriers to understand the layout.

b. Are the interactions intuitive? Cannot see any major barriers to understand the interactions.

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 (Desktop and iPod)

Note: Tested with VoiceOver turned on for iPod accessibility interactions.

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?

G. Keep it simple

Does the component display only the information needed by the user at any given point in time? Yes (Desktop and iPod)
Overall, are user interactions kept as simple as possible? Yes (Desktop and iPod)
Does the component use plain language? Yes (Desktop and iPod)

Awesome @DesignbagGT :+1: Thanks!

Will Review by Jan 31

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

Desktop PC: Windows 7 Enterprise, 1440x900, Firefox v26.0 & IE v8.0.6 Mobile Tablet: Apple iPad 3rd gen 2048x1536 & iPad rMini 2048x1536, iOS7.0.4, Safari Mobile Hand-held: Apple iPhone5, iOS7.0.4, 1136x640, Safari

B. Provide status feedback

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

Before the Tab demo example update: Desktop Firefox (v26.0): No, not always. When users first encounter this tab element, it is not readily identifiable that the supposedly ‘highlighted’ active gray tab is associated with its corresponding text below it. This may be due to the delineation or separation of a graphic line element between the gray tab itself along with its associated text box. Instead, the actively selected or highlighted tab colour background should match the same coloured background as the body text “folder”. Same affordance. However, seconds later after initially viewing the tab element, it may become clearer to web-savvy users that the gray tab is indeed related to the text box below it. This may be an implementation issue. Also, the provided example may not be a good example because the darker grayed-out tab colour is usually reserved and associated with a non-selectable option status. False affordance. This could be misleading for users. In order to accentuate a status more prominently, the active tab may incorporate bold and/or larger text besides a highlighted background colour to differentiate itself from the surrounding elements.

Before the Tab example update: Desktop IE (v8.0.6): No, not always. In IE 8 compared to the Firefox version above, the highlighted gray tab text is repeated again within the boxed body text below the tab as a header. The text is carried over and repeated. As such, users can see that there is a commonality or relationship with the two text items and therefore they can associate them together as one – even with a divided line between the tab and box. However, the redundancy may be viewed as unnecessary even though it reinforces the tab element itself. Also, by selecting the black triangle pointers within the body text, the text box is removed. This may be an implementation issue and may be out of scope of the tab parameter heuristic. Also, see above.

After the Tab demo example update: Desktop Firefox (v26.0): No, not always. Status itself may rely on relative situational awareness in surrounding environmental context for users; positioning is important. In order for this to be noted, we need to draw attention to this fact. As such, ideally, the element or text within the tab should draw attention to the users’ eye. In other words, a focal point is may be necessary, but not required, to help improve the cognitive state of differentiating between similar elements that are close in proximity together with one another against the same or similarly coloured background. Especially, in this case whereby all text are black in colour, plain roman and using the same identical size and character attributes as each other. “What’s the status difference”, users may ask. To increase and improve the status probability for users, text within active tabs should be bold and/or perhaps slightly enlarged (like a header) to declare intention that it is indeed active = current status. This could serve as the active ‘button’ state status. Furthermore, the forefront gray-coloured borderline could also be solid black in colour. This will help to draw users’ attention to an active status state in order to produce separation against an inactive gray-coloured borderline tab status in the background. Implementations may vary. Also, in the revised example, the passive tab colours provide a better affordance as they are a lighter gray value. However, the roll-over state still uses a darker gray value which may still be interpreted as a non-active selection even though there is an obvious state change during a roll-over action. Use another colour.

After the Tab example update: Desktop IE (v8.0.6): Same as above.

Tablet, iOS7.0.4: Same as above desktop and similar to below smartphone, but with touch target mechanics. There is no on-touch state. Media query should enable.

Smartphone, iOS7.0.4: The ‘tab’ triangle pointers are a good representation of content status by pointing to it when the accordion ‘tab’ menu is both collapsed and expanded. However, this accordion framework and implementation style may not be the ideal approach as the “tabs” continually stack as more tabs are used. As a result, this could possibly cause user fatigue when scrolling. Especially, when there is a lot of body text. Create and set guidelines. Further, there is no visual mapping of how many tabs are represented as a status indicator. For example: “(2 of 7)” could be placed on the far right-side of the active accordion tab, etc. Also, there should be a physical distinction between tab header and body text and between active tab status versus inactive tabs.

Does the component give immediate, easy to understand feedback?

Before the Tab example update: Desktop Firefox (v26.0): No, not always. Once this tab element is engaged from an interactive perspective (clicking on tabs), it becomes clearer to users which tab is associated with the text box below it. Also, the roll-over states for the tabs successfully and clearly identify and provide user feedback regarding target areas while concurrently the text box visually changes. However, the roll-over states should not be the same colour density level as a highlighted active tab state (or vise-versa); this may lead to possible confusion. Especially for usability reasons, the two states (roll-over tab state and selected/active tab states) have the same identical tonal values which may delay cognitive feedback responses for the visually impaired. This may be both an implementation issue and usability issue. As per #1 above, dark gray is not a viable colour choice for active tab selections. Use button state protocols.

Before the Tab example update: Desktop IE (v8.0.6): Same as above.

After the Tab demo example update: Desktop Firefox (v26.0): No, not always – due to the return usage of gray colours in the provided example still. Typically, something that is grayed-out signifies something that is inactive and non-selectable. In many circles, this is generally the accepted and understood use case scenario. Otherwise for the most part, yes. Progressive discovery (vs. disclosure), engaging and interacting with the tabs reveals a valid visual feedback roll-over state to users. However, the roll-over state is still gray in colour which may possibly be perceived as an inactive feedback selection, per above. Currently, since there is no down ‘button’ state for tab feedback, this may be misinterpreted as reinforced feedback to a grayed-out inactive selection – even though a down state and active tab state produces a visible and enduring area selection box (should be removed) on the tab itself that won’t go away until another tab is selected. Then the action and cycle is repeated again for each tab.

After the Tab example update: Desktop IE (v8.0.6): Same as above.

Tablet, iOS7.0.4: Same as above desktop with same layout. Similar to below smartphone (different layout) using touch interfacing for feedback.

Smartphone, iOS7.0.4: Other than the usage of the above grayed-out colours, No. Regarding the ‘tabs’ themselves, there is no on-touch state feedback or active state feedback for the accordion tabs other than having the appropriate drop-down text appear. Adequate differentiation is required to separate the two actions and states as a proper user feedback response and mechanic. This should correspond somewhat with its desktop counterpart for consistency. Implement an on-touch state and active state for the accordion ‘tabs’. For additional user feedback, tab colours could be applied with appropriate tonal values for the impaired, to represent component states. No haptic; see individual device Accessibility.

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

Before the Tab example update: Desktop Firefox (v26.0): Yes, for the most part, just enough if the provided example used another tab colour other than gray. Tasks may be completed through user exploration, discovery and curiosity if they attempt to select and click-on the ‘grayed-out’ tabs in the provided example. However, the base mechanics are sound. Minor issue: the target area for tab selection is a noticeable 1 pixel smaller than the IE version. As such, mileage may possibly vary with different platforms, operating systems and devices. Also, see above with regards to the use of tab colour levels and roll-over states and selected states. Use button state protocols.

Before the Tab example update: Desktop IE (v8.0.6): Same as above.

After the Tab example update: Desktop Firefox (v26.0): Yes, but not necessarily in a good way. In the revised demo example version, the ‘tabs’ themselves are separated by a white space gap in order to give it a more physical, realistic and conventional tab folder structural appearance in the real world (see below ‘C’ Real World Conventions). As such, this visual cue is perhaps more readily recognizable and thus may possibly help users to complete their tasks easier and faster. However, this may not be necessarily better depending on the level of the user. As user levels ramp up in our electronic day-of-age, this type of implementation may not be necessary in a long-term strategy and may possibly be viewed as “old fashioned” and out-dated in an always evolving landscape. To compare, for space savings and modern day usage, for example, web browser like IE, Firefox, Opera and Safari, etc. eliminate the white space tab separation while Chrome uses a tab gap variant. Likewise, MS Office uses another variant in the tabbed ribbon implementation. Also, see ‘C.1’ below for rounded corners on tabs as another visual cue to assist task completion.

After the Tab example update: Desktop IE (v8.0.6): Same as above.

Tablet, iOS7.0.4: Tablet uses the same visual desktop layout; see above. Partial review.

Smartphone, iOS7.0.4: Currently, yes, for the most part. For the initiated, the triangle drop-down content pointers provide adequate visual cues to reflect the nature of component interaction. Discovery and progressive disclosure may be applicable. Partial review.

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

Desktop Firefox (v26.0): Yes. But may not be applicable. All tabs are visible – even though they appear ‘grayed-out’ (however light), in the provided example.

Desktop IE (v8.0.6): Same as above.

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?

After the Tab example update: Desktop Firefox (v26.0): Yes. The tabs themselves appear recognizable as selectable folder structure elements that are common in the real world. However, the implementation of the faint or light-gray coloured border lines does not do it any justice as this may be indiscernible to certain viewers and users (i.e. visually impaired). As a result, this may not be recognizable and may become a usability issue that puts form over function design-wise. Especially, on various users’ monitors that have differing colour gamuts. Same applies to mobile or laptop usage in medium sunlight conditions – the thin light gray lines will either appear faded or possibly disappear altogether rendering the tabbed interface less compelling or less feasible during practical applications. Also, as tabs are generally associated with folders in the real world (but not always), most tabs have rounded corners (but not always). Therefore, certain users may possibly expect rounded corners on electronic tabs in order to form a faster association (see various web browsers and applications: i.e. IE, Firefox, MS Office, etc.; but not to be overdone, i.e. Chrome). Cognitively, forming faster associations generally results in quicker task completions for many users while matching real world conventions. If used appropriately, a possible 2 or 3 pixel corner radius may be sufficient; flat no bezel. However, if the blank spacing between the tabs are removed the rounded corner usage may become discretionary depending on context.

After the Tab example update: Desktop IE (v8.0.6): Same as above.

Mobile Tablet: See above mobile comments. Partial review.

Mobile Hand-held: Accordion 'tabs' may not necessarily appear to be recognizable or would they necessarily reflect real world conventions. Partial review.

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

After the Tab example update: Desktop Firefox (v26.0): Yes. Using a common folder mental model, actively selecting various tabs brings the corresponding folder structure page to the forefront and the rest of the content behind. However, the interferring area selection box on the tabs (per above), should be removed.

After the Tab example update: Desktop IE (v8.0.6): Same as above.

Mobile Tablet: See above mobile comments.

Mobile Hand-held: Yes, for the most part due to the fact that the drop-down triangles function as expected. Partial review.

Desktop Apple iMac with latest OS and Safari: There appears to be the same highlighted area selection bounding box on the tabs whenever users select a tab, on this platform. The blue-coloured selection still remains on the mouse-up state. It should be removed.

D. Apply standards and ensure consistency

Have industry formatting standards been used consistently throughout?

Desktop and Mobile: Yes, it appears so. Minor issue: layout design-wise, the body “folder” text may appear tight to the box top – too close to the tabs – as text generally requires “breathing” space and an entry point for users to properly peruse and read. Also, see below ‘D.3’ regarding consistent usage of text box sizes and tabs.

Mobile Hand-held: The tab touch target areas may appear to be too small and too close in proximity with one another -- even though it appears to meet minimum standards and requirements. As such, this may possibly affect users with larger fingers, etc. Also, the smaller target formatting may affect users in colder temperature climates/situations where there may be a physiological effect on usage (i.e. shivering or shaking when attempting to select a small tab). Excludes conductive gloves; out of scope. Likewise, smaller target formats may be prohibitive and also affect the user when in motion (i.e. subway, train, etc.). Therefore a larger tab format, especially for mobile, can better accommodate more users in many more situations. Increase tab heights to improve navigation for risk mitigation.

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

Yes. All tabs, text, background colour, cell placement, etc. appears to be consistently used in context -- even though the provided demo example is still using grayed-out tab options. False affordance. Also, see below ‘D.3’ regarding consistent usage of text box sizes and tabs. Create and set guidelines.

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

A design guide needs to be implemented specifically for this tabbed interface (as well as for other components) as long character titles may possibly make the tab longer in length while increasing its size and prominence vs. other possibly shorter tabs. As such, a consistent usage of a character count limit should be identified and incorporated for tabs. The same is true for the corresponding body text. Also, the body text ‘folder’ bounding box should use the same consistent sizing for all and not bounce the user around with heavy paragraph text for one tabbed description while another tabbed description may use a single sentence, etc. and resizes the box. Use consistency.

Mobile Hand-held: Of course, the ‘folder’ text box resizing is not necessary and would not apply to hand-held mobile usage as it is completely acceptable to maximize real-estate space on the smaller screen. Additionally, the use of language and character counts become more apparent and evident on smaller screen sizes and for mobile usage. Create and set guidelines. Follow web writing guides. Use latitudinal consistency when applying wording conventions, taxonomy, etc. Apply to media query. For example: a desktop version tab may be titled, “The Great Norsemen Exodus”, while the hand-held mobile version may be titled “Norsemen Exodus” or simply “Exodus”, etc. Using a mobile first approach, the desktop in turn may instead use the hand-held mobile text for language consistency.

Is the experience consistent across screen sizes?

Yes, for desktop IE and Firefox using the above specs. Responsively simulated on desktop Windows using various break points.

Mobile Tablet and Mobile Hand-held: Responsively simulated on desktop Windows: No. GoC uses an accordion style approach for smaller screens sizes. All break points have not been true tested or reviewed yet. Transitioning to an accordion style framework and interface may appear to be a mismatch and disconnect for users of the same site. Mental model lapse. This may possibly affect memory recall patterns on usage. As such, this may also affect the completion of user tasks across screen sizes -- all things being equal (i.e. same OS, etc.).

E. Help users recognize, prevent and recover from errors

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

Not seen or observed.

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

No errors were produced. Therefore, no recovery indicators.

Does it provide information to fix or correct the error?

No errors were produced. Therefore, no corrective information.

F. Design for human interaction

When using the component:

a. Is the layout intuitive?

Desktop Firefox (v26.0): Yes. The tabbed interface is easily identifiable and the tabs themselves are apparent as selectable options for user navigation.

Desktop IE (v8.0.6): Same as above.

Tablet, iOS7.0.4: Same as above.

Smartphone, iOS7.0.4: No. The accordion style may possibly be viewed as an awkward solution due to the stacking effect when users are presented with numerous “tabs”. For risk mitigation, create a design guide and set boundaries for implementation. Also, see above.

b. Are the interactions intuitive?

Yes. They appear natural on approach.

Mobile Hand-held: Yes, for the most part. Appears awkward on approach considering that it is using an accordion framework. The tab triangles are helpful in walking the user through the process by using visual cues.

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?

After the Tab example update: Desktop Firefox (v26.0): Yes, for the most part. Aside from the above indicated grayed-out tab interpretation: 1. A passive tab state appears light in colour. 2. Then, the roll-over selection state for the tabs display a darker colour tone. 3. There is no down state for tabs. 4. An active tab state appears with no colour = white to correctly match the text below it. As a result, the sequential steps may appear unusual and non-intuitive as users are going from a light colour to a dark colour to no colour and then to white colour state(s). Recommend using proper sequencing techniques and proper button protocols for input methods. Use progressive colour stepping for proper usability while keeping in mind visually impaired challenges. Suggest making the passive tabs darker in colour and tonal value range to denote a background object that is farther away (like in the real-world). Then in this context, progress lighter in tab colour as users get closer to making the final active selection which contains a white-coloured background that correctly matches the body text “folder”.

After the Tab example update: Desktop IE (v8.0.6): Same as above.

Tablet, iOS7.0.4: Same as above.

Smartphone, iOS7.0.4: No. Tab touch target area may appear to be too small. See 'D.1' above.

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. All tabs are accessible and visible to the user in one session.

G. Keep it simple

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

Yes. The active tab correctly displays the corresponding text below it.

Overall, are user interactions kept as simple as possible?

Desktop: Yes. Even without a down state for the tab, it still works seamlessly and effortlessly. Design layout is nice and simple.

Mobile hand-held: Yes. It is basic and minimalistic. However, also see above status, feedback and interaction comments.

Does the component use plain language?

Yes. Per above, a design guide would need to be implemented for the tabbed interface.

End.

Tabbed Interface: http://wet-boew.github.io/v4.0-ci/demos/tabs/tabs-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

Does the component always let users know about its current status? IE 8: No.

IE 8 has issues with this version of a tabbed interface. At first glance it seems to work. When the page first loads there is a “selected” tab (Example 1) that shows a darker tab than Example 2 & 3.

IE 8: Bug. IE 8 does not render the rounded corners of the tabs.

IE 8: Bug. If, in “Example 1”, the user clicks the link in the body of the text to “Example 3” it does not work.

IE 8: Big Bug. In each of the tabbed areas the first thing the user sees is a Black Triangle pointing down, followed by the text “Example 1”. Underneath this in the light grey 1px outlined tab area is the block of text. If the user mouses over the Triangle or anything in that top row, the area highlights in a grey rollover indicating that it can be clicked. If the user clicks, the entire body of the tabbed box disappears, leaving only the 3 tabs with nothing underneath them. They now appear like a row of buttons rather than tabs. If the user clicks on any of the three tabs, the text area does not appear underneath them and the tabbed box remains broken. Reloading the page causes the tabbed interface to “fix” itself and works as long as the user never clicks on the first row in the text box.

IE 8 & iOS 7: The 1px line will be difficult for many visually impaired users to see as it does not provide enough contrast. Also the very light grey used in the other two tabs may be too light causing them not to appear as tabs at all.

iOS 7: In iOS 7 the horizontal tabbed interface changes to a stacked accordion model which may not be desirable in some instances.

iOS 7: For visually impaired individuals, if they cannot see the 1px light grey border they may see this as a bulleted list and not as a tabbed interface. They may not find the information that is hidden in the accordion.

iOS 7: The flat interface does not necessarily look like a “clickable” object, but since this is now an iOS convention for many buttons and clickable elements the flatness should not be an issue.

Does the component give immediate, easy to understand feedback?

IE 8: Not Necessarily. In many (most?) UIs the selected tab is the same colour as the body of the text area it is associated with. It “bleeds” into the content area to show association. This example uses dark grey to indicate that the tab is selected. Many users may associate the grey button with an item that is “greyed-out” or non selectable. The grey visually separates the tab from the content and in IE 8 is surrounded by a 1px dotted black line. If the user clicks elsewhere on the page, the dotted line disappears.

iOS 7: The full-width accordions with rounded corner boxes and black triangles look clickable enough to lead a curious user to engage with them. Only one accordion can be opened at a time, which is not necessarily a bad thing, it follows the idea of a tabbed interface which can only show one tab & content area open at a time.

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

IE 8: Yes. Unless they click on the top row and “break” the component.

iOS 7: Yes. Generally iOS users will be sophisticated enough to correctly interpret this component.

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: Yes. The roll-over and on-click styles help the user determine that the tabs can be clicked.

iOS 7: Yes. There is the right pointing triangle which is generally recognized as something, when clicked, will show more information.

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: Somewhat. Tabbed interfaces are common on the web, but many use the opposite color/contrast usage than what is employed here. Generally the selected tab matches the color of the body of the text block associated with it. Also lighter colors/tones are perceived to be “in front of” darker colours or tones which recede or are “behind” the lighter ones. This example uses the opposite paradigm.

iOS 7: There is no color change in iOS 7. The right pointing triangle “twists” to point downward when clicked while at the same time expanding the accordion area and displaying more content. When clicked again it reverts to its original state.

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

IE 8: Yes. Unless they click on the top row and “break” the component.

iOS 7: Yes. Other than the fact that in iOS it becomes an accordion set rather than a tabbed interface.

D. Apply standards and ensure consistency

Have industry formatting standards been used consistently throughout?

IE 8: No. Generally the selected tab matches the body of the text block associated with it. iOS 7: Yes. Other than the fact that in iOS it becomes an accordion set rather than a tabbed interface.

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

IE 8 & iOS 7: Yes. It is internally consistent.

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: Tab text should follow a writing style, with labels that are concise and descriptive.

Is the experience consistent across screen sizes?

IE 8 & iOS 7: No. The interface mode changes from a tabbed interface on the web to an accordion interface on iOS 7.

E. Help users recognize, prevent and recover from errors

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

IE 8: No. The bugs will cause errors or non-functionality that can only be partially recovered from by reloading the page.

iOS 7: Yes. Only one accordion can be opened at a time. The text link in Example 1 worked properly, linking to Example 3

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

IE 8: No. There are errors, but no error messages.

iOS 7: N/A. No errors found.

Does it provide information to fix or correct the error?

IE 8: No. There are errors, but no error messages.

iOS 7: N/A. No errors found.

F. Design for human interaction

When using the component:

a. Is the layout/style intuitive?

IE 8: No. Generally the selected tab matches the body of the text block associated with it.

iOS 7: Yes. It follows proper accordion conventions but is not a tabbed interface which may cause other issues.

b. Are the interactions intuitive?

IE 8: Yes. Excluding the bugs mentioned, once the user interacts with it the interactions are intuitive.

iOS 7: Yes. It follows proper accordion conventions but is not a tabbed interface which may cause other issues.

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: No. Links do not seem to work within the component. Further research on whether other components (like input fields, sliders and buttons) will work within the tab body.

iOS 7: Yes. It seemed to work normally.

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?

IE 8: Yes. The tabbed interface provides only the information associated with the selected tab.

iOS 7: Yes. The accordion interface provides only the information associated with the selected accordion.

Overall, are user interactions kept as simple as possible?

IE 8: Yes. Normal tab state, roll-over state, on-click state.

iOS 7: Yes. Accordion opened or closed on-click and triangle changes direction as appropriate.

Does the component use plain language?

Tab text should follow a writing style, with labels that are concise and descriptive.

3 completed evaluations! yay team!

whoops I take it back, @ivan4 only put up the template?

@ivan4 I think there was an error when you submitted your evaluation as there's only the template and no evaluation in your submission. Can you resubmit please.

I will review. The review was started but never completed.

UPDATE: Now finished. See above.

3 completed evaluations!

Awesome, thanks @DesignbagGT @JxRath @ivan4

You're welcome.

Colin Eyre Sent from my iPhone

Email: colin@iconology.ie

On 22 Feb 2014, at 12:54 am, Rubina Haddad notifications@github.com wrote:

Awesome, thanks @DesignbagGT @JxRath @ivan4

— Reply to this email directly or view it on GitHub.

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?

Yes.

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?

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?

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?

No.

In widescreen format when a user clicks the tab that tab header gets a blue focus box. As a result the tab no longer looks like a tab. Only when the user clicks somewhere else is the blue box removed.

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

In the narrow screen format the tabs do not look like tabs at all so users will be confused moving back and forth between the two formats.

The tabs in the narrow screen format appears to show twisties at the left of the tab however The twisties do not behave like twisties, however, because they cause other tabs to close. I suspect some users will be surprised by this behavior.

D. Apply standards and ensure consistency

1. Have industry formatting standards been used consistently throughout?

Horizontal tabs, when they are used, usually do not look like these.

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

No. The elements are entirely different in the narrow format versus the wide format.

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?

No. See elsewhere in this document.

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?

Yes.

b. Are the interactions intuitive?

I find the twisty behavior in the narrow screen format to be non-intuitive.

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?

Yes

BUGS

In the narrow screen format, all the information in the page footer is lost.

Summary: Tabbed Interface

Device	OS	Browsers
Laptop (24 inch Monitor)	Windows 8.1	FF 27.0.1
Nexus 7	Android 4.3	Chrome 33.0.1750.136
Apple MacBook Ai	OS 10.9	Firefox 26.0
		Safari 7.0 (9537.71)
		Chrome 30.0.1599.101
Apple iPod Touch	iOS 6.1.5
Desktop PC 1440x900	Windows 7 Enterprise	Firefox v26.0
		IE v8.0.6
Apple iPad 3rd gen 2048x1536	iOS7.0.4	Safari
iPad rMini 2048x1536	iOS7.0.4	Safari
Apple iPhone5 1136x640	iOS7.0.4	Safari
HP Desktop, Dell widescreen monitor (1920x1080)	IE Windows 8.0.7601.17514
Apple iPhone 4	latest iOS 7

Note

The UI has been substantially updated between the initial reviews by jxRath and Ivan4 using IE and FF rendering an unknown number of their comments out of date. It is unclear what issues are fixed and what new ones introduced. This summary covers the last two reviews only.

Bugs

The footer disappears when the window is narrow.

Opportunities for improvement

At least one reviewer was concerned that the horizontal tabs would not be readily understood to be tabs, for the following reasons

they don’t have a “tab” that projects away from the rest of the frame
They show their status by a “twisty”, rather than by a color change
Not everyone understands twisties

Consider using the Open and Closed tab coloring, perhaps along these lines…

wet-boew / wet-boew-styleguide