On Suckerfishes and User Experience

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?