I’ve had my head buried in markup, style, script, and PHP for going on three months straight and aside from the code fever I’ve come down with, my anxiety about not opening Fireworks once in that time has been wearing on me. So much so that I’ve been re-evaluating various aspects of Web design that have become accepted practice or have been consistently implemented for such a long time we hardly think about them anymore.
I like to step back and examine things from the ground up from time to time, on every level of Web design, right down to the single line styles I write. I prefer to keep my mind sharp, and feel that there’s no better way than to consistently question the methods I’ve become comfortable with. The Web moves at a mile a minute, and sticking with something because you’re comfortable with it will more than likely leave you in the dust quite promptly.
That said, I’ve been thinking a lot about Suckerfish Dropdowns lately.
The root of Suckerfish Dropdowns
I wasn’t even front ending a site when I started thinking about Suckerfish Dropdowns, but once I started I couldn’t stop. Where the heck did they come from? Suckerfish Dropdowns themselves are basically a proper implementation of something rooted back in the days of DHTML dropdown menus. DHTML dropdown menus more than likely came from a ‘this is pretty neat, and it moves!’ epiphany, and that’s where I started to be puzzled.
I’m not really much a fan of inventing completely new interactions on the Web. The Web is still a very scary place to lots of people and I feel it’s our duty to tackle that directly. Surprising someone new to the web with a completely unconventional method of interaction isn’t going to help anybody.
I tried to find another area of computer interaction, aside from the Web, where something resembling Suckerfish Dropdowns appeared; I couldn’t find one. Every other menu system we work with requires a click from our mouse.
That started to make more sense to me. If I were moving around in various applications throughout the day, and simply moving my mouse pointer from one area to the next resulted in a number of Suckerfish Dropdowns activating momentarily only to retreat back to an original position would drive me crazy. I then became annoyed with Suckerfish Dropdowns on the Web.
At the same time, however, I can see why they exist: Suckerfish Dropdowns help organize an entire site in a neat little package, waiting for some interaction. We can’tshouldn’t require a click action because that’s JavaScript dependent and we’d get in big trouble if we were to do that. So where do we go from here?
What’s the alternative?
Perhaps we’re not thinking through our navigation systems thoroughly enough. Maybe we’re just defaulting to Suckerfish Dropdowns because they’ve been put in place so consistently they are a founding interaction on the Web, regardless of their absence elsewhere.
Is bombarding a user with every option under the sun really the best solution? Would we be better off simply going with high (single) level navigation systems and better structuring our secondary navigation elements? Or is it at that point we’re instilling a sense of ‘venturing to the unknown’ for our user? Perhaps we need to develop better copy for the top level navigation in that case?
I have a lot of questions on this and before I delve into it further and drive myself nuts, I’d really like to hear some feedback as to whether anyone even sees this interaction pattern as a detriment for user experience. Thoughts?
Comments
Interesting questions. Simpler interfaces with less options (and opportunities to screw up) can do a good job to stressing what’s most important. But on the flip side of that coin, it could frustrate power users and return visitors who know where they want to go and have to click more than one or twice to get there. Hence drop downs might benefit.
To your point, I think it all starts with copy and labeling things clearly. I’m interested to see how this conversation develops, too!
What about creating a standard Suckerfish dropdown, then using JS to switch the behavior from “dropdown on hover” to “dropdown on click.” That would keep things accessible to those with JS turned off, but use your preferred style of interaction everywhere else. Thoughts?
The jQuery Hover Intent plugin goes a long way in making drop-downs (or anything that you need to hover over) more usable. At its core it says “if a user hovers over this area for slightly longer than normally passing over it, then perform this action”, like expanding a drop-down menu. If sites were to implement it more often, I would be less concerned about usability. But as it is, I generally hate drop-downs too. In fact just yesterday I was on a site where I mis-clicked onto a drop-down menu item TWICE when trying to reach a regular content link.
http://cherne.net/brian/resources/jquery.hoverIntent.html
Just wanted to add some clarification to your introduction, about what Suckerfish Dropdowns are – Suckerfish is to the Dropdown Menu what Google is to the Search Engine. It happens to be the most widely used implementation of dropdown behaviour created entirely through CSS*, as opposed to using javascript (*with a little JS thrown in to get the :hover pseudo class working in Internet Explorer). There is now a Sons of Suckerfish release which is more accessible, light weight and can have multiple levels. There is even a Jquery spin-off implementation named Superfish!.
What you are really questioning here is the use of the Dropdown menu (no matter how it is implemented) which I agree is a UX convention which should be considered carefully. I don’t think that “bombarding a user with every option under the sun [is] really the best solution”, but I don’t agree that the use of a dropdown menu necessarily means you are including every possible option.
The dropdown menu is a behaviour that users have come to expect, but if they are to be able to rely on it being useful, then the options should be carefully chosen during the Information Architecture process as informed by your Content Strategy. It should not be a dumping ground for every single internal link on the website. It should not necessarily be a sitemap.
very interesting. nice read.
i hear you about how it should work on click. however i do think that a click should “take” you somewhere….that said, ajax certainly has changed that.
i do agree that overloading the user is a piss poor solution, however the more visible the navigation the more usable it should be.
i do agree with better copy for top level navigation, most are standard stock and not relevant and/or finite enough on most sites.
interesting nonetheless. looking forward to hearing the outcome.
Yes, exactly, Ted! You’ve hit the nail on the head when comparing power/return visitors and first time visitors. That’s precisely what lead me to think that we can think a bit more about this issue. Thanks for chiming in!
That’s definitely an applicable solution, Joshua, although much of the inspiration behind writing this piece was the interaction itself; does it make sense on the Web or can we do better? What do you think?
I love jQuery Hover Intent! Such a great plugin, but I’d almost like to focus on the root of the interaction itself, specifically comparing to our desktop applications which have an only-click response. I’ve mis-handled Suckerfish Dropdowns more times than I can remember, I think we can probably do a bit better, what do you think?
Thanks so much for clarifying, Emily! I contemplated giving a bit of a history lesson in the article itself and I’m really happy you took the time to do so! You’re totally right when pointing out that just because you’re using a series of Suckerfish Dropdowns you’re overloading a visitor with options. That navigation system could very well have been planned out to the finest detail, so it wasn’t fair to assume everything under the sun was put on display. Users have definitely come to expect dropdowns, and the times where a user is taken aback by their presence are few and fare between. Do you think, though, that it’s an effective way to display a navigation at the lowest level? Thanks so much for your valuable feedback, I can’t wait to see the conversation continue!
Very interesting point about the inherent functionality of clicking and the want to ‘go’ somewhere. That consideration doesn’t pop into our heads when we’re working with desktop apps because, well, it’s not a Web page. That again swings me back to questioning whether Suckerfish Dropdowns are a truly effective method of navigation at their root.
While it’s true that application menus require a click to open, the top-level items (File, Edit, Help, etc.) are simply organizational labels and don’t represent a specific action. In contrast, most dropdown menus have top-level items that represent a specific page in the hierarchy.
This may be unnecessary at times. I’ve seen many examples of “Welcome to the About section” copy that probably could have been omitted. On the other hand, sometimes you do need a page to help orient the user.
In those cases where the top-level items represent an action/document, there needs to be at least two ways of interacting. A way to open the menu, and a way to initiate the action/open the document. Making a click open the menu in this case seems very likely to confuse users.
Another option to consider would be a variant of the “mega dropdown.” In this case the top-level items would be organizational, not representing a specific page. On click, it could reveal a menu with a bit of copy to orient the user, and then present the various options.
Here are some examples of the sort of thing I’m thinking of:
http://37signals.com/svn/posts/1647-mega-drop-down-navigation-at-basecamp-and-rails-guides-site
http://www.useit.com/alertbox/mega-dropdown-menus.html
Though Nielsen talks about the menus being hover-driven, you would probably get all the benefits with less confusion using a click-driven style. (Except for users with JS disabled.)
The first time I ever encountered something resembling Suckerfish Dropdowns was within the Microsoft Encarta encyclopedia program. This was way back when, something like Encarta ’96 or something like that. It contained the typical application menu (File, Edit, Help, etc.), but instead of clicking on them all you had to do was hover over them and the menu slid into view (complete with “whoosh” sound). I was in junior high at the time and thought it was the coolest thing ever.
Yeah, we probably can do better. Have any ideas? =) I don’t! lol I think drop-down menus are fine if used right. I don’t think you need to click on them to open them, because the top-level item is usually a link (usually), and you wouldn’t want to have people miss out on clicking a link if they think it is one. Sure, Windows and Mac menus open on click, but this is the web, and I think it’s OK that it’s a little different. People try to make the web equal to print, or equal to desktop software, but it’s not, and that’s not the right attitude to take when designing for the web I don’t think.
Great insight as always. I couldn’t agree more. I am a strong believer in striving for better content/copy to clarify functionality. Most sites on the web do not need drop down menus.. however, most of us will be hard-pressed to explain that to the client 🙂
Firstly, This is one of the most polite, well-informed, and well-considered crop of blog comments I’ve seen in a while. Well done.
Secondly, I think that this is an important discussion, particularly as human interaction methods get a good shake-up. I think that it could be broadened, in fact, to consider how we think about web navigation – should it follow conventions from other areas (i.e. desktop), or innovate unique solutions. Are web innovations reverse-transferrable to the desktop environment? What do users really expect. I was wild about drop-downs, until I saw people who weren’t web-savvy interacting with them. I still really like them, but I realised they weren’t as intuitive as I thought (surprise!), and that they do require a lot of careful thought and planning. That does often mean paring back the amount of items.
Regarding clicking – there are often times where one top-level item has no children, amongst others which do. Thus if a user clicks one top-level item to gain the drop-down, and then decides the option they are after may be in the category that (unbeknownst to them) has no children, their next click will take them to another page.
I personally like nav that is consistent on every page – so that the user comes to know it. That said, I have had great experiences with nav that is contextual.
As I’ve written this, I keep wanting to say something that contradicts something else I’ve said. I think the key is that whatever you do, it must be carefully planned. It isn’t clicking or not, dropdowns or not dropdowns, consistent or contextual nav options, it’s that whatever you choose changes the rules, and if you plan carefully so that your site is internally consistent, loads of different approaches can be totally successful. Hence the wonderful diversity of the web.
Whoa, that was a big post.
Dropdowns are just straight bad UI in my opinion. They confuse users and, to your point Jonathan, most users can’t handle all of the options. Think of it like the grocery store: do you really want 200 toothpaste options? Why would you want that on a website? Having secondary navigation on a downstream page makes better sense to me.
You may want to check out a book called ‘The Paradox of Choice’ by Barry Schwartz – he outlines why you want to reduce options to your audience. The human mind can’t handle more than like 4-5 choices without it starting to overwhelm most people.