Anyone know of usability studies that indicate how to deal with a design that comes your way and has a lot of subtabs? By subtabs I mean tabs within tabs on the same page. So, there might be a row of tabs each of which can reveal another when activated: in all one, two or three sets of embedded, nested tabs....These are not dynamic tabs — as you might see in multitasking designed solutions — but static, fixed tabs.

To me a lot of tabs and subtabs indicates a decomposition of the task flow or object that makes for an unwieldy, unproductive UX, one that can be difficult for users to navigate and recall what does what too....

The question is:

  • Is there any optimal number of subtabs within a main tab arrangement? Maybe one level? (I've seen four. Even for very advanced users and complex tasks I think that's a lot.)
  • Are there any alternatives to tabs within tabs within tabs too? (Assume this is a web-based consumer application.)

I don't think an optimal number exists as each application is different, see this link short term memory and web usability.

4 levels of sub tabs (!) probably means that the Information Architect, if any, missed something. Multiple groups of nested tabs tells me that the application is overly descriptive instead of having been thought for what users are trying to accomplish.

A basic example would be to replace a set of tabs by a drop down menu. There are many examples of online applications with complex navigation structure using mega menus, lists, tabs, etc. Take a look at amazon.com, www.zappos.com...

| improve this answer | |

Whether or not you need to decompose the task into so many levels depends on the task complexity or amount of content. There's also the classic depth-breadth tradeoff. In general with web apps, where you have large windows and slow page loads, you're better off with a few complex pages in a simple hierarchy than a lot of simple pages in a complex hierarchy. However, it's possible you have a very complex task that requires with lots of complex pages, so maybe you must have many levels.

But that is not especially related to the type of control used to access those levels (e.g., tabs). I'll assume you've optimized the AI hierarchy, so it's a question of whether you want to use tabs to access it or not.

Guidelines Say One Level

Just to be clear, by “number of tabs,” you mean number of levels of nested tab controls, not number of tab panels per level. The Windows 7 UX Guidelines give a specific and unambiguous answer: 1.

Don’t nest tabs or combine horizontal tabs with vertical tabs. Instead, reduce the number of tabs, use only vertical tabs, or use another control such as a drop-down list (p182).

I believe the main concern is the users can get lost in the hierarchy with nested tabs. All tabs look alike so it’s easy for users to confused the level they’re on and the level of the tab they're clicking. Plus a tab within a tab is a weird metaphor.

Not So Sure it Applies to Web Apps

As a general rule, what applies to desktop apps applies to web apps. Desktop apps have been around longer so they have had more time to figure what works, presumably through their own usability testing, although I'm not aware of anything published on this particular issue.

In this case, I’m not so sure this no-nesting guideline applies. With a web app, you have greater latitude in the visual design, so it seems it would be possible to clearly divide and distinguish the tab sets from each other and make it visually clear what tab set is within what tab set. Kingsburg (2004) shows how you should combine sidebar and top menus, for example. Tabs are just menus with a metaphorical kicker, so the results should be applicable to tabs too.

Do you buy that? I’m not sure I do. When you have reason to believe an established guideline doesn’t apply, don’t just disregard the guideline. Test your alternative it in a usability test and see if it creates the problems the guideline was trying to avoid.

Alternatives to Tabs

As I said, tabs are a type of menu, so the alternatives are other kinds of menus. Which is best is a matter of trading off clutter per page with mechanical access (number clicks and scrolls) to the pages, which in turn depends on which pages users tend to access in what sequence and how often.

  • You can have a static hierarchical sidebar menu, showing options indented within options, explicitly showing the AI hierarchy. This can provide one-click access from any page to any page, but can mean scrolling if the menu is tall, and can take a lot of space that otherwise would be for the actual content.

  • You can use a tree control for the menu, basically a hierarchical sidebar menu where the users can open and close various levels to show the options they are using. Now the menu takes less space and less scrolling, but more clicking. It’s good if users get to given level then move among the options at that level. This has about the same clutter-mechanics tradeoff as nested tabs, so it may be your primary alternative.

  • You can have pulldown/dropdown and cascade menus, basically a tree that “closes up” automatically. Now you’ve minimized space used by the menu, but to go to another page, the user has to start over from the top –lots of clicking. It’s best when the users tend to go down to one page and stay there for the rest of the session.

  • You can have home page that’s nothing but a static hierarchical menu (if it won’t reasonably fit in a sidebar). Each page of content has only a home link. Advantage: no menu taking up content space, and only two clicks to any page. Disadvantage: two clicks to every page.

And, of course you can have combinations of the above. For example a, you can have a two-level pulldown that can bring the user to a page with a multi-level tree to access a page which has a single-level tab on it. While you're at it, throw in a bank of expanders. Or, if you find yourself doing that, maybe you need to reconsider the complexity of your app.

| improve this answer | |
  • I would second the MS approach, If you need to nest your tabs there is likely something else wrong. A Treelist would have essentially the same effect but be more approachable. – Austin French May 20 '13 at 14:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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