What is the best way to indicate that it's possible to open and close an element accordion-style?
Arrow pointing left/arrow pointing down
Arrow pointing down/arrow pointing up
Plus sign/minus sign
… or something else?
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It only takes a minute to sign up.
Sign up to join this communityI'd say the convention is for the arrow to point right when collapsed and down when expanded.
See this example, were the third one is opened:
I’m not sure there’s a definitive answer yet. Here’s how I see the options.
Arrow Conventions
Trees have used right-pointing arrows for closed and down-pointing arrows for opened, which, as FreshCode mentions in his answer, has been generalized to expanders. It’s a reasonably well established convention, going back to Vista for Windows and the mid-1990s for Mac (where they were known as “little arrows”).
I’ve been concerned that it could cause confusion. In other uses of arrows like cascade menus, split menus, menu buttons, and dropdown lists, the arrow suggests only a temporary display of some options, not the fixed opening of an entire pane that must be explicitly closed. Also in these other uses of arrows the direction of the arrow is inevitably indicates the motion the user gets on activation. In contrast, in trees or expanders the right-pointing arrows causes a downward motion and the down-pointing arrow causes an upward motion. I haven’t witnessed this being a problem (e.g., users thinking the downward arrow means “expand even more”), but I haven’t witnessed a whole lot of expander use.
Window Control Conventions
Perhaps it would be better to use a downward arrow to mean closed so at least the arrow’s direction is consistent with the motion it creates and with its use in other controls. An opened expander would have a “close” X icon, leveraging its use for windows. However, perhaps users might think the “X” means Delete as in “clear all that input I just put in the expander,” and so users fear ever closing an expander.
Maybe a more apt way to use window controls is to use the minimize and maximize icons for opened and closed expanders respectively. However any use of window control conventions is probably most effective if the controls are on the right, like they are for Windows. This may induce extra mouse slewing since input controls tend to be justified left. Also, I’d be worried about users confusing expander controls with window controls when the expander is scrolled to the top of the window.
Other Tree Conventions
Using "+" to mean closed and "–" to mean open is an alternative seen in pre-Vista tree controls that avoids the arrow directionality contradiction. It seems to work okay, but, like most of the options I covered so far, I’ve always wondered if some users are confused about whether the symbols is supposed to represent the action the user gets on activation or the current state of the expander (they assume "–" means the expander is closed –or at least not fully opened).
Another one worth considering is the “taps” icons used by Java Swing.
For some reason, I feel like they less ambiguously handle the action/state problem.
Toggling Button
The usual way I recommend dealing with the action/state problem is use toggling buttons as I described in answering Should an icon show current state or next state? In this application it means you use the same icon that means “open this” (I think the plus sign is least ambiguous) for both closed and opened expanders, but the button for the icon has a raised appearance for closed expanders and a depressed appearance for opened expanders.
Did I Mention No Definitive Answer?
With so many issues, I don’t think we really know which one is best without some user testing. It’s entirely possible it doesn’t make all that much difference. If you end up testing, please post your results back here.
Lance Gutin at Vidget did some user research on this. My only take-away from it is that it is a bad idea to use no icon, and putting the icon on the right increases task time. I think the problem is that this is a problem that has no good solutions.
Analyzing the results, the most convincing data involved icon location. Presented with an icon to the right of the menu item, many participants preferred to click the icon rather than the text label (figure 2). In addition, in every case, designs with icons to the right resulted in slower task times (figure 3).
What I most commonly see is a down arrow or no arrow. (Glamour is an exception with a right arrow, but I must admit I expected it to navigate to a separate page of comments and not operate as an accordion.)
Facebook
NYTimes
Washington Post
Glamour
Stackexchange
I am quite into using arrows when exploring a tree/file structure. But I feel the contents of an accordion is much like a dialogue, specifically I am not expecting a tree.
Accordions to me have their expand/collapse switches on the right (which is where I think you are placing your left/down symbol) and trees have theirs on the left. They use +/- or arrow symbols respectively.
I am thinking a folder pane vs a feature panel, like windows explorer vs visual studio.
But in answer to your question, if I were to use arrows in an accordion, Up would not communicate closed it would communicate broken. IMHO.
In my opinion the windows tree pattern (left/down) makes no sense, but it seems a lot of users learned to use it.
(down/up) Makes more sense to me, but I guess I am not your user.
(plus/minus) Is less confusing as Michael Zuschlag mentioned
Perhaps do A/B testing?