Thoughts on Accordion Usability
It’s no big secret that I’m not a particularly big fan of the accordion control. In almost every case I encounter, the use for the accordion is to provide an alternative view to stepping through complex forms. While it can certainly be made to accommodate this use-case, it has to be one of the most abused applications of the container. What’s worse is that I fear we’ll see a lot more of it in the not too distant future.
Let’s take a common complex form that many of us here in the United States are very familiar with as an example - the Internal Revenue Service (IRS) Form 1040. The basic 1040 as pulled from the IRS web site has no fewer than thirteen different sections (nine on the conservative side). Let’s stop and think about this then for a second as it relates to the accordion. What does the accordion look like with thirteen sections in it?
I’ve only had to complete the few sections here to get the point across. The first section fills in nicely. The second section leaves copious amounts of extra space lying around. My favorite however is the fourth section, in which I’ve run out of room and stopped after only nine fields. The actual Form 1040 goes on for another nine fields - the “Tax and Income” section is the longest with 23 fields. The “one size fits all” approach of the accordion creates this white space feast or famine situation.
On the positive side, the accordion does fundamentally provide contextual information to the user. We always know where we are and how much we’ve got left to go. Is that really the best way to display the content? Should we just shove our forms into Flex and everything else will just magically improve? What are some of the alternative displays we might choose for this type of complex form?
When I find myself struggling for how to implement something in Flex, I ask myself “How is it accomplished in the day-to-day applications I encounter on the desktop?” To be fair, this question in its own right is somewhat flawed because what we really want is something rich and engaging. We like to think of this as desktop applications in the context of RIA, but it’s really just falling back on an earlier metaphor. But I digress…
Just how is a complex form displayed in a desktop application? It may seem elusive at first, but we see them every time we install a new application - wizards. The parts that are broken about complex forms on the web aren’t “Next” and “Previous” but rather the waits and refreshes that accompany the approach. With RIA however we can offer instantaneous feedback. Let’s apply the “wizard” metaphor to a complex form, and throw in a splash of Flash for emphasis.
From a usability perspective this is better and worse. While the forms aren’t crowded by the container itself any longer, we’ve lost most of our context. Where are we in the form? A little extra UI chrome can bring this out to the user - something for which we now have space. Perhaps a menu bar (ButtonBar in Flex) across the top of the form? Maybe thumbnails of the various form sections? In fact, you now have enough space to take it forwards to RIA and include context-sensitive video help.
For the record here, I didn’t come up with the blur effect on forms. This is actually how a form in one of our demos is transitioned (thanks to Adobe’s Experience Design team). The effect has been very popular in customer demonstrations, and I’ve had many people ask me how it is accomplished. I’ve even had one colleague suggest that I build a framework for the behavior. Suffice to say it isn’t that complex, and I’ve attached the source (video files) if you’d like to see for yourself.
I didn’t come up with the page thumbnails either - you can see that in Adobe Acrobat Reader. Once again I go to the desktop for inspiration. What I did come up with however is a way to generate the thumbnails at runtime based on the forms. What? Yup, whenever navigation occurs from one form to another, the thumbnail gets updated dynamically at runtime. Credit here goes to the bitmap features in the Flash Player. The source (video files) for that is also included in the example.
February 19th, 2007 at 9:51 am
Hi Kevin
I totally agree with you… Accordians are ok for left-hand side navigation areas of big applications, were you have 3 or 4 sections … but other than that I can’t think of any other practical use … I almost always use wizards for form navigations … and I think that having some sort of indicator for context is a great idea … I’ll have them in all wizards that i build from now on.
Thanks for the tip.
Mrinal
February 19th, 2007 at 4:07 pm
Hi Kevin,
The problem, as you stated, with the 1040 form placed inside an accordion is the amount of real estate the chrome takes up. An alternative approach, if you have some horizontal real estate to spare, is to place the navigation on the left side as a set of links in a vertical list. The user works their way from top to bottom. This is similar to your last example, switching the thumbnails for text links and ditching the menubar. Theirs not much pizzaz in this solution, but it works.
Another note about the accordion; I’ve seen users bypass accordions sections because they didn’t notice the inactive sections plopped way at the bottom of the screen. Users tend to keep their eyes above the middle of the screen unless something leads them downwards.
February 26th, 2007 at 2:21 am
Hi
this is a great article and i completely agree with you, but i’m thinking on doing another kind of navigation, a windows control panel like, i mean i want to put several icons on one panel and as the user clicks on one icon it passes to another level or to the form they want.
I haven’t seen this kind of navigation made in flex yet and i’d like some ideas on how to do this if you can spare some time thinking about it i’d appreciate.
July 24th, 2007 at 4:20 pm
I agree that a lot of developers have a tendency to abuse the accordion component as it is a really easy way to cram a bunch of fields into a small area. I think that an accordion relates to checkboxes in the way that both accordions and checkboxes are useful in small quantities. It would be crazy to use 50 checkboxes when you could use a multi selection list instead. Same thing goes for accordions, if you use it properly it can be very efficient.
August 27th, 2007 at 2:51 pm
very nice article… sorry to digress.. i love the transition effect on that last application.. i was wondering if i could get any tips on how to do somethin like that… thanks
August 27th, 2007 at 2:55 pm
kevin, very informative article.. sorry to digress, i love the transition effect on that last appliation.. i was wondering if i could get any tips (or code) on how to do something like that.. thanks
August 28th, 2007 at 11:07 am
Sho,
A link to the source code is included in the post. At a high level, each screen is placed side by side in an HBox, and then clipped by being placed inside a Canvas without scroll bars turned on. The movement is accomplished using the Move effect, with a BlurFilter being added just before the move, and removed just after the move. The filter has a high value for the horizontal blur, and a small value for the vertical blur, which gives the overall effect of movement.
Hope this helps,
Kevin
August 29th, 2007 at 9:18 am
thanks a lot… very helpful… i didnt see any contact email on ur website for futher correspondence
August 30th, 2007 at 7:07 am
I agree with you about the chance to misuse. But I found the pattern very usable in certain situation where the alternatives require you to scroll through the web page vertically.
For example, I find the use of this pattern in Google Reader has improved my reading experience. Now I just glance at the blog titles and decide which ones to explore.
January 31st, 2008 at 8:36 pm
Accordions are very useful to simplify long forms. I think of them as collapsed sections of a written document with the folds representing the familiar model of a vertical outline. Users recognize them. Most of the issues can be managed with features like “show all” or mouseover effects to indicate the hidden content. My concern with your proposed alternative is that you have implied a linear left-to-right workflow. I dont’ think users respond to tabs that way. Also, you provide no way to show everything at once. If it were a multi-part form, how would you avoid hiding data entry errors unless there was a separate save for each tab?
April 23rd, 2008 at 9:00 am
Hi,
Nice example ! Thanks a lot for sharing it.
I used this wizard example to build an application.
It’s working very well but I am blocked…
With the Accordion, I can use the IndexChangedEvent when the selected element changes. But, how to use such event when the user switch form pages in the Wizard ?
I hope you understood my question… My English is not so good.
Thanks a lot !
April 29th, 2009 at 5:11 pm
A 13-step form in an accordion vs. a different 5-step form in tabs.
Hmmm. I would lean toward a 5 step form.
Naturally.
I might lean away from a form divided into 13 tabs with long names though.