Best Practice for Tab Placement on Widget?

Question

For the past week I have been working on restyling tabs on a widget. Some problems I have encountered during the restyle is our 960 grid system which with a side navigation included allows me a space of 12 cols to work with.

While researching, top tab placement seemed to be a common pattern used. However if more tabs are added to max out the first row a second row is created which isn't very eye-catching.

Side tab placement would allow the widget to display tabs in a single row going downwards. However less content doesn't look good in a large container.

What is the best practice for tab placement on a widget? Which would provide for a better user experience?

Answer 1

Use a drop-down menu for excessive tabs.

Answer 2

There was an earlier question about whether it's ever okay to have multiple rows of tabs. The general consensus was that it breaks the tab metaphor and gets confusing.

Accepting that multi-row tabs won't work, you have a couple of options:

1. Use the side tabs.

2. Use tabs across the top when there are only a few of them, but if there are more tabs than fit across the top, either:

   • a. add additional tabs down the side.
   • b. move all tabs to the side.

I don't like option 2b because it means moving the navigation, which could be confusing to the user, interfering with the Gestalt principle of consistency. Option 2a might work depending on your layout and on how rare it is to have more tabs than fit across the top. I think it's probably just best always to put the tabs on the side. Never mind that it will look a bit odd when there are only a few tabs; don't compromise usability for aesthetics.

Answer 3

Through research regarding tabs, top placement is best as a top tab can appear as a header to the associated content below.

It's also a good rule of thumb to constrain a tab count (usually 5 - 7) that adds a bit of control to user content. If tabs exceed the 5 - 7 limit content editors will continue to create new tabs which can overflow and create clutter. Even adding a more tab could create more user confusion as it can display even more information that creates more clutter.

Users like simplicity and being able to find information quickly!

Answer 4

It seems like there is a better way to deal with excessive tabs on the first option:

1. Firefox-style horizontal scrolling for additional tabs.

2. Windows Classic-style tabs, which match the width on top and bottom. (I'm not a fan of this).

3. Dropdown menu per Andy's answer.

Answer 5

Google Chrome for iPad has an innovative way of dealing with "too many" tabs that's works well but is not for every application. Beyond a comfortable number of tabs, which seems to be 4 on an iPad in portrait orientation, new tabs stack up on top of old tabs. They are fanned in such a way that they're all visible (the text on the tab isn't always visible but the edge is visible). Taking advantage of the touch UI, you can touch a behind tab to bring it to top, and actually slide them around with your finger.

Hard to describe, it's best to try it yourself to understand it. And not easy to implement. Like I said, not for all applications, but a very good solution for touch UIs and small screens.

Answer 6

I'm not sure what kind of real estate you have to work with, but I am a big fan of the menu system that Mashable recently implemented. They use both the a horizontal and vertical running menu, which might be useful if you can break up your content by some form of a category.

Maybe something less space heavy like what tabbed browsing does when you have large number of pinned tabs and unpinned tabs open. If the menu can be sorted into primary (pinned) and secondary (unpinned) tabs. The secondary tabs can then collapse and users can scroll through or expand these collapsed tabs.

You may want to consider your content when deciding how to display a menu with a significant number of options. For me, navigation is what keeps me coming back - how easily I can navigate your site/application successfully.

Things I try to consider when developing navigation: - How technology/software experienced are my users? - What menu options will users need most frequently? - How easily can my users get lost? - Can menu options be combined to make the navigation less cumbersome?