Several parts of our existing business application use a tab control to logically separate groups of data. In other applications I often see the expander control also used for this purpose. Does anyone know of any usability guidelines that provide guidance on when to use the tab control versus the expander control?
If it matters I'm primary referring to WPF & Silverlight design principles. Thanks!
If I were trying to figure this out my first thought would be to try whipping up two quick-and-dirty prototypes, one using each method to do the same job, and then grab a few innocent bystanders and ask them to try both prototypes, set them some simple tasks and see which one lets them accomplish them most easily and intuitively. It's not exactly running it through the usability lab, but if you can find a few people at more or less the level of your end users ( rather than other people on your team, for example ) you'll get a fairly clear picture of what will suit them best in an easy and inexpensive way.
If there turned out to be no difference I'd go for whichever is easiest to implement...
Expanders are a relatively new control which we haven’t figured out quite how to use, so I don’t think there are many documented guidelines right now. They have the potential to be substantially more flexible and useful than tabs.
Tabs use a page or sheet metaphor that restricts them to show content that is at the same conceptual level. They’re pretty much limited to showing attributes of the same business object (with groups of attributes on different sheets), or various objects all related to the same super-ordinate object (different objects/classes on each sheet). Doing otherwise “breaks” the tab metaphor.
Expanders, on the other hand, can be used in wider circumstances:
Expanders are excellent for representing hierarchically related content, where a “lower” expander provide more details on what’s selected in an “upper” expander (i.e., master-detail relations). Indeed having multiple expanders extending down and to the right in your window implies going deeper into the information hierarchy, although with the right visual design, I see no reason why you can’t have two adjacent expanders represent content at the same conceptual level, like a tab.
An expander can be used to provide progressive disclosure, keeping rarely used or dangerous controls or content out of view to reduce clutter and the chance of accidental activation. Tabs imply all content is equally important.
Two expanders may be used to provide different perspectives or views of the same content, such as one expander showing the data in tabular format and another showing it graphically. Because each tab sheet metaphorically represents a different physical place, it would be confusing to show the same content on different “sheets” of the same “notebook”.
You can have an expander contain the parameters for determining the output content of the page or another expander (e.g., for advanced search), allowing the user to close the parameter expander to see more of the output. Doing this in tabs breaks the tab metaphor because it means a “sheet” of a “notebook” is determining the content of another “sheet.”
Expanders provide the user more flexibility to 1. Shrink multiple expanders to maximize the real estate dedicated to other content, 2. Expand multiple expanders to compare content or work on them together. Tabs always show exactly one sheet of content.
Each expander can be sized by default to use only the real estate it needs to use, allowing the users to make the most of their window or screen sizes. Tabs are always as large as the largest tab sheet, which can waste space when the users are using a sheet with little content on it.
The primary disadvantages of expanders are:
It takes two clicks to swap one group of content with another, while tabs only take one. This makes tabs better for quickly scanning and editing though the content across selected groups while avoiding real estate control issues. For expanders, I recommend you provide a control or shortcut (e.g., ctrl-clicking the arrow button) that closes all expanders at the same conceptual level as the one being opened in order to provide the same functionality as tabs, but that is something that will only be helpful to trained users.
They destabilize the content, moving groups of content around as expanders are opened and closed. With tabs, the content inside and outside the tab remains in the same virtual location, making it easier to find.
They don’t have a standardized graphic design, making them harder to figure out and use for new users. A strong visual design with clearly indicated controls and boundaries helps, but, nonetheless, tabs are both more familiar and more standardized, and use a metaphor that’s relatively easy for novices to grasp.
Given their flexibility and limitations, I generally see expanders as useful for major divisions of content in the window, where the user can use them like panes in Windows Explorer of MS Outlook to set up their workspace in a window to best suit their tasks, not unlike arranging windows on a desktop. This also minimizes the instability they cause (most controls remain in the same relative position with their neighbors). Use tabs for smaller blocks of content which you expect users to breeze through selectively. If users need to skim through all content, don’t use either. Put it all in a single big scrollable page.
Like nesting tabs, nesting expanders one within the other looks confusing and should be avoided. However, you can nest tabs in an expander (or vice versa) as long as you use strong visual design to make their relation clear to the user. Combining tabs within expanders is an excellent way to put a whole lot of controls in a single window to minimizes navigation effort and maximize scanability.
Because expanders are relatively new, I recommend you follow these guidelines to help users up the learning curve:
Make sure the expander title indicates its content, especially when it’s close. At the very least it should name the content, but you may also want to dynamically include qualifiers that summarize the content or its state (e.g., completed or not, number of characters or records inside, sums or averages of quantities inside)
If your expanders are scrollable, and generally they should be, the outer window should not be scrollable in order to avoid nested scrollbars, which are confusing and difficult to use. Resizing the window should resize the expanders within, adding and removing (or enabling and disabling) scrollbars when necessary.
The expanders themselves should be resizable by drag and drop, like panes are, to allow the user to size the pane as necessary for the task.
To be honest, I don’t know how much of all that is possible with the platform you’re using.