Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

I have not been able to find guidelines (let alone user studies backing up the guidelines) specifying best practice for this aspect of tab behavior: when (if ever) should the selected (active) tab be made selectable?

I have long assumed that only the inactive tabs should be selectable. Recently however I came across a UI in which the only way to get back to the tab's initial state is to click the active tab again. (There is navigation within the tab.)

Poking around I've found several places where active tabs are selectable. One is Google. There it seems to be equivalent to a page refresh. If you are in Google Maps, for example, selecting Maps from the row of tabs at the top returns the page to the default state, looking down on your location from satellite distance. Here in UX.stackexchange, if Questions is the active tab it is still selectable. Selecting it refreshes the page. This is perhaps useful if you are on p.5 of Questions and want to get back to p.1. There are several other ways users can do the same thing however (refresh page in the browser, select 1 in the pagination widget.)

The guidelines I've explored never mention the issue. The assumption seems to be that there is only one page per tab and thus no need for the active tab to be "live."

If I were to write a guideline myself I'd say: there is nothing wrong with making an active tab selectable, but that should not be the only way to return to the tab's default state. Most sets of tabs do not behave this way, so many if not most users will not think to select the active tab.

Thoughts? Pointers?

share|improve this question
5  
The biggest problem with these interactions is the lack of discoverability. The items look as though they're already active, and because they're often bolded and highlighted, many common hover states on the web don't work. I can't see anything wrong with hitting a selected navigation category to reach its root but I wouldn't use it alone. –  Jimmy Breck-McKye Oct 12 '12 at 0:18
    
To complete Jimmy comment, I find the way ux.stackexchange doing it kind of clever. The active tab is not highlighted, it's shaded so the user doesn't have really the sensation of the tab being selected. –  Xavier Portebois Oct 12 '12 at 7:11
    
Until the comments above, it never occurred to me that "Questions" was clickable. It's grey. That means not clickable to me. –  Bill Oct 24 '12 at 20:01
add comment

2 Answers

It shouldn't ever be required that you click on an active tab to "go back" or navigate in any meaningful way. As Jimmy Breck-McKye points out, it's simply not discoverable. Even if you properly apply "clickable" affordance cues like a hover state, there's often not much reason to even think you could do this.

The most logical place for this practice is the Web and similar data-driven applications that have a notion of "refreshing" the page. This very site does that; if you're on the Questions page and you click the Questions "tab", it just refreshes the page. Since you're still in the same place, just updated, there's little chance for confusion, and it's a logical action.

Allowing navigation this way is trickier. iOS does this with the tab bar. It shouldn't be the only way to get "back" to the initial state, but clicking the Active tab and "resetting" the view can be useful in cases where there's deep navigation within a tab.

So in general it can be a useful interaction but it should never be a required interaction. If necessary, there should be other ways to refresh the view or navigate back to the top of that tab. At best clicking the active tab is one of those shortcuts you can never really depend on unless you've already used it in a particular context.

share|improve this answer
add comment

I think what you are encountering is a commonplace artifact of either incomplete UI specs or "lazy" development. I don't mean either of these negatively but that is the best description of the process that produces this kind of pseudofeature.

Imagine this narrative:

Designer Sid offers a tabbed layout as a solution to an admin form. He designates the style and interaction for the tabs. He describes the active state and the content to be shown or hidden based on the selection.

He discusses the layout with engineering and they decide an AJAX call will load the markup in the content area.

Jessie the developer follows these instructions. She applies the active class to the tab and loads the content with a call each time.

Since no one spec'd it either way, engineering decisions were made with efficiently in mind, QA doesn't see a problem since nothing breaks... Viola, Your interactive active tab is born.

Postscript... there happens to be unintended usefulness to it; it resets the form. People who discover it find it useful and the team leaves it be without further ado.

In my experience scenarios like this often play out in software development. Consequently curious and observant designers such as yourself come across these features and consider on what basis the decision was made. And the the funny thing is, there wasn't a decision at all.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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