12

I've seen many design patterns that help solve different content presentation issues by leveraging "tabs".

Assuming I do want to display grouped content on a page (complex content or simple) and support multi-device experience.

Assuming I have "N" number of such groups.

Let's also assume, the amount of groups can not be drastically reduced by doing IA revamp

  1. What are the pros and cons around the patterns I've listed below?
  2. Are there any other design patterns that could offer better UX compared to what I listed below?

Tabs

I have my own opinion and a list of pros and cons for each, however I wanted to ask here to broaden my knowledge.

Improve this question
2
  • Do you rather have Module Tabs or Navigation Tabs?
    – Crissov
    Nov 17, 2015 at 8:17
  • The use case I am working with uses Module Tabs design pattern. Great links by the way!
    – Igorek
    Nov 17, 2015 at 14:43

5 Answers 5

Reset to default
5

Nice question - I am looking for other answers than mine as well!

@ Version 1:

Android introduced this as a more "standard" element for mobile apps (swiping screens that mimic "tabs"), when iOS still went for the segmented control as the only opportunity to go for tab-like structures. So Android wanted to have more complex architecture, while accepting complexity in usability.

Pro: Learned behavior on the most used mobile OS; Is able to contain very complex structures; Mobile friendly.

Con: For desktop, this is very uncommon behavior (scrolling right-left is harder than up-down); users can not see what is at the end of the tab list; probably not intuitive at all

@ Version 2:

I honestly never used this one. On first sight,

Pro: Visibility of most likely all the options possible (if we are talking about N tabs, this might not be the case)

Con: Position of tab content hardly predictable; Connection of tab to content hard, as soon as we have 2 rows of tabs; possibility of losing overview on responsive sight - can a user grasp all information if the boxes are not of the same width?; possibly inifitely complex

@ Version 3:

Pro: easily readable For european readers; Can be attached to a horizontal top nav; good for desktop usage (e.g. with mega menus that expand from top nav); Possible nice control with mouse wheel

Con: Hardly usable for phones (blocks too much horizontal space, is potentially getting infinitely long); Not all options are visible on first sight; Acroll all devices, vertical space is more limited than horizontal space, so possibly the amount of items visible is lower than horizontally ordered

@ Version 4:

Pro: Smallest space usage;

Con: Cannot contain content as tabs can(if we are not using another box to push the content to); The longer the list the worse the mobile usage;

So if I could, I would use horizontal tabs (again: Depending on context), since the vertical limit is smaller and it is learned Android behavior. If I co not have control over the amount of tab items, I would reconsider using tabs at all, since the flaw of "not having an overview" over all tabs destroys the tab's purpose (which I think is the major flaw of the Android approach).

Improve this answer
5
  • Thank you Jan, good write up. Are there alternative design patters one should also consider?
    – Igorek
    Nov 6, 2015 at 13:06
  • I think the trickiest part here is not only the arrangement of tabs, but rather "how to deal with possible infinite amount of options". At some point I would rather offer an ordering and/or sorting mechanism (like on mobile address books) or give the possibility to select "favorite" items that then appear in front or a certain order. Frankly, I do not think that, considering an infinite amount of items, tabs are the right choice - I'd rather go for sorted lists with additional content boxes.
    – Jan
    Nov 6, 2015 at 13:12
  • Version 1: "For desktop, this is very uncommon behavior" - well, it's the default on desktop for any tabbed MDI, hence it strongly depends on the target audience.
    – O. R. Mapper
    Nov 6, 2015 at 15:21
  • Sure. Context always matters. But still, I'd take the cheeky proposition, that more than 90% of horizontal tab navigation constructs which are not Android apps rather collapse content or leave it out, instead of scrolling infinitely to the right. If we just take a look at the top 5 to 10 responsive frameworks, at big players in e-commerce with tons of categories and so on and so on. They rather escape to the vertical way than going horizontally. So yes, admin interfaces and things you pointed out work like this, but the majority does not. Keyword "user expectations".
    – Jan
    Nov 6, 2015 at 15:30
  • @Jan: Indeed, context might matter more than one thinks - I was rather thinking about common UI toolkits for desktop applications, and if memory serves, tab controls from ancient toolkits such as the Delphi VCL, and more recent ones such as .NET Windows Forms and WPF all support versions 1 and 2 (and usually nothing else). And most of those appeared before tabbed MDI interfaces became somewhat more widespread, with browsers such as Firefox adopting Version 1, as well.
    – O. R. Mapper
    Nov 20, 2015 at 15:20
3

Option 1

Pros:

  • A scrolling nav menu not hidden behind a menu click is visible
  • Content is discoverable
  • works well with mobile

Cons:

  • Anything more than a couple of items in is not immediately obvious
  • Is an unfamiliar pattern for many desktop users, although this is highly dependent on your user demographics.

I would use this when you are displaying on a widescreen or larger screen device (i.e. desktop), or you know that N is small enough that there will not be too many tabs to comfortably display in a single row. Alternatively, the screen is narrow enough that you know that you will definitely have partial tabs visible to indicate that the user can scroll.

Option 2

This concept is not too dissimilar from the sitemap footers that many websites use, or the fat menus pattern, except brought to the fore all the time.

Pros

  • Everything is highly visible; no options are hidden

Cons

  • This is going to be a nightmare for mobile users
  • This can easily take a lot of screen real estate
  • The larger "N" is, the harder it will be to make anything findable

I would only use this where the expectation is a desktop, mouse driven device.

Option 3

Pros

  • Users are generally used to how this operates; make a selection on the left, and what is shown on the right changes to reflect that selection. Most basic computer users are used to that behaviour from other applications
  • "N" becomes infinitely scalable
  • The 2-panel design can relatively easily adapt to a small screen format by allowing the user to view either the list on it's own after selecting a menu, and then displaying the content on it's own. (AKA a one window drilldown)
  • The cognitive load on the user is reduced during navigation, as they can see where they are/where they are sending themselves without requiring the screen to move navigation landmarks

Cons

  • Not everything is visible
  • It takes a lot of space, and will need a backup design for smaller screens using a different interaction pattern

I would default to this unless there is a compelling case for a different design in this scenario. It allows for lots of options. The affordance of a vertical scrollbar to show more options off screen is easily recognised (and more expected than a horizontal scroll bar) and it is already familiar to most windows, mac, and linux users. I would reconsider using this for a mobile view, and provide a one window drilldown option as part of your responsive design.

Option 4

Pros

  • Given the use cases I imagine the other design options are catering for, I can't really think of a very compelling reason to have your navigation this way, because I don't really see any pros to having this as your navigation method.

Cons

  • Not very mobile friendly
  • TBH, not particularly usable on a desktop either (for navigation)
  • Everything is hidden, and you have to open the dropdown to see any of the options.
  • The user has no real context for where they are in relation to anything else.

I wouldn't use this for navigation.

Improve this answer
2
  • When would you use one or the other option and why?
    – Igorek
    Nov 17, 2015 at 17:20
  • Have edited to include a when and why.
    – Nathanael
    Nov 20, 2015 at 15:04
2

I am only starting with ux, but i will try to do my best to answer the question appropriately.

1. Pros and Cons:

a) "Browser Tabs"

Pros:

  • A lot like the usability in browsers and may even relate to the swap mechanic if a touch screen is supported.
  • It's a pattern that is very common in everyday activities in both desktop and mobile.
  • May easily support a "sub-menu" navigation if needed.

Cons:

  • All options may not be on screen, what may confuse a not so knowledgeable user.
  • Accessibility guidelines: Usability! the user with a screen header may not see the listed links by using the Tab key or his 'show all links' shortcut.(May be improved if it's scrollable by default instead of by click.)
  • May get a little strange if for some reason two "tab layers" must be used in any page.
  • If the text of one tab is too large it may break the pattern.

b) "Old Amazon"

Pros:

  • A lot like the usability in browsers and may even relate to the swap mechanic if a touch screen is supported.
  • It's a pattern that is very common in everyday activities in both desktop and mobile.
  • All options will be on screen, making user decision easier.
  • Accessibility guidelines: Usability! the user with a screen header will see the listed links by using the Tab key or his 'show all links' shortcut.
  • May work well if 'N' doesn't grow too much.

Cons:

  • May get very strange if for some reason two "tab layers" must be used in any page.
  • If the text of one tab is too large it may break the pattern.
  • The tabs as 'N' grows will get out of control if a designer isn't set to reorder them or even redesign them. (An exagerated image of what amazon might look today if they didn't give up on tabs, courtesy of dack.com http://www.dack.com/web/amazon.html)
  • User may be confused or even with fear of choosing by too many information(options).
  • If too many options are displayed may make content in mobile (or even in desktop) too much after the fold.

Obs: It's the same pattern Amazon used many years ago (around 2000).

c) Vertical Nav

Pros:

  • A lot like the usability in apps when a side menu is opened.
  • It's closely related to a pattern that is very common in everyday activities in mobile.
  • May easily support a "sub-menu" navigation if needed.
  • May be used as a sub-menu of a horizontal navigation.
  • May use collapsables/accordions if the tabs may be grouped.

Cons:

  • All options may not be on screen, what may confuse a not so knowledgeable user.
  • Accessibility guidelines: Usability! the user with a screen header may not see the listed links by using the Tab key or his 'show all links' shortcut. (May be improved if it's scrollable by default instead of by click.)
  • May get very strange if for some reason two "tab layers" must be used in any page.
  • If the text of one tab is too large it may break the pattern.
  • It will need two implementations one for mobile (as a open on demand side menu) and desktop (as a permanent side menu).

d) Select

Pros:

Cons:

  • All options may not be on screen, what may confuse a not so knowledgeable user.
  • Usability! the users may have to look at the entire list to find what they're looking for.
  • If the autocomplete approach is used it may take a long time to elaborate in all the alternative ways an user may try to access a given content.

2. Other solutions

I told you about the autocomplete approach and the search approach may be used too. I don't know any others that may fit even close to the tabs patter.

Verdict: I would choose the a solution if given a limited number of items of a regular size, a maximum of 12. If more items i would use the vertical solution with the caveat of making it hide and appear om mobile.

Exception: If i know my users are knowledgeable of what they're trying to access most of the time (like university departments or countries) i would use the select or the autocomplete approach.

Improve this answer
4
  • Can you elaborate on "... If more items i would use the vertical solution with the caveat of making it hide and appear on mobile"?
    – Igorek
    Nov 17, 2015 at 17:28
  • I assume that if the user wants to "change tabs" the flow is interrupted. If it's so you can use a toggle/sliding side menu that appear when i click on "tab list" button or you can use a full screen vertical list with scroll to appear overlaying the page. There is an option to instead of using a vertical list use a tiling system, but this is harder and some conditions would need to be met. Slidebars are an example of a sliding menu: plugins.adchsm.me/slidebars
    – Gabriel Fonseca
    Nov 17, 2015 at 21:25
  • I see, I was actually trying to stay away form an off canvas menu example you provided because we are using it for the primary navigation and the "tabs" component is being placed in the content area of the website in addition to the off canvas menu, which makes the selection of a design pattern more complex. Let me know if that helps
    – Igorek
    Nov 17, 2015 at 21:32
  • Humm... I can't think in a good way to make it better and unless phones aren't in your range of devices i would stay away from the first solution. So I would use something akin to a "modal menu" then. Some examples: enableds.com/itemscc/?theme=below demos.jquerymobile.com/1.3.0-rc.1/docs/demos/widgets/popup
    – Gabriel Fonseca
    Nov 17, 2015 at 22:46
2
+50

Other answers covered pretty much all pros and cons I could think of, so I’ll only be answering part 2 of the question – alternatives.

Generally, avoid having more than seven entries in any group and otherwise consider adding another hierarchy level. Strive for a design that is optimal around five items, but works well enough up to an exceptional dozen and doesn’t fail completely with more.

Media Queries (on the Web) and similar platform-dependent technologies allow to target layouts on devices with different user I/O capabilities, which feel native and still look familiar although not exactly the same.

For mobiles with touchscreens, use a variant of option 1 (tabs on top, horizontal scrolling): The title of the current tab is visible and takes up most of the space, next to it are the adjacent titles, but truncated (maybe to an icon) or blurred or both with overlaying chevron arrows. Swiping works as expected and a long press on the title reveals an overlayed scrollable dropdown-like vertical selection with all tab titles.

For desktops with a pointing device (usually a mouse), use a variant of option 3 (tabs on side, vertical scrolling): All the most relevant tab labels (e.g. next/previous, previously viewed, search results, …), but at least the active one, are shown, all others are compressed vertically up to mere horizontal lines – only when hovering with the cursor do they get zoomed in to be readable and provide sufficient click target. (Vertical scrolling also works.) You may consider something like Tab Exposé depending on the content and platform.

Improve this answer
1

Option 1

This one was proposed as a pattern for desktop only. I agree with Jan that it is a more known pattern for mobile experience and it is NOT a well known or understood pattern for larger screens. Option 1 does support different languages and "N" number of tabs

Option 2

Is outdated and there are better options available

Option 3

This is another favorable option, specifically for larger screen experience, however it does not work well for smaller screen experience.

Option 4

Is mostly optimized for mobile, however it optimized for a smaller number of "N" tabs

Summary

It seems the common approach is to use not just one example I brought up but a combination. Option 1 seems to be most favorable for mobile experiences and Option 3 is most favorable for desktop. A proposed solution would be to offer a responsive approach which uses Option 1 for mobile and Option 2 for desktop.

Alternative

Depending on the content that goes into each tab area, you could potentially use a different pattern (a carousel). This pattern works well on both mobile and desktop and it also exposes content to the user. This may be beneficial if it helps the user to see content side by side instead of taping between tabs.

Carousel

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.