Javascript Menus: The Good, The Bad & The Superfluous

October 8th, 2007 Posted by Don Albrecht

Menu widgets: Every toolkit’s got one or more and they sure are easy to use & impressive so the temptation is there to just slap them everywhere. After all, you’re already pushing the toolkit to the client anyway, why not make the most of it.

Before you do, tho I encourage you to consider the following & ask yourself if the javascript solution is really appropriate.

The Good: Reasons to use Javascript Menus

Event Handling.

The biggest reason to use a frameworks menu system is event handling, plain and simple. If you have built an ajax ap that utilizes centralized event brokering. A dynamic menu is all but a necessity for maintainable code & consistent user experience. That said, if the menu doesn’t need to be integrated with the scripts on the page (e.g. A site wide navbar), a dynamic menu is likely superfluous.

Branding.

Lets face it, those slick menus with animated effects are damn sexy. Used effectively, they can really help you capture an audience & encourage a greater depth of exploration by visitors in even the simplest of brochureware sites. Even better, since the menus can be built from <li> elements they provide excellent accessibility.

The Bad: Reasons to Avoid Javascript Menus

Reduced Accessibility

JAWS especially doesn’t deal well with DOM elements created on the client side. While there are many improvements in accessibility that can come from javascript frameworks (improved tab order, shortcut keys, etc). Those all require an investment in time and energy at setup. These allowances, however, do not fully address the issue of users on reduced capability devices or reliably interface with legacy accessibility tools.

Rendering Overhead

Any dynamically generated menu will add to the initial rendering time of the page. While this may not be an issue on a modern machine running the latest release of an A level browser. Performance hits can be quite dramatic on a machine loaded down with spyware, vintage hardware or other sub-optimal deployment environments.

Visual Noise.

This goes without saying, KISS is one of the primary rules of interface design. A big fancy menu will likely call attention to itself at the expense of other content. After all, what’s going to bring more value to the site and project a slick menu, or quality, fast loading content.

Page Complexity

KISS applies to markup too. It’s a simple fact that the more complex the code, the more opportunities for bugs to slow down the development process. More significantly, the more complex the code, the longer it takes to grok it again when it comes time to make revisions.

I realize that many of these widgets require little or no markup, so the complexity issue can be a mute point in terms of markup. The big risk is of course that the code you use will be deprecated or outright removed from the next release of the framework.

The Superfluous:

This article was inspired by a recent discussion with a fellow developer. He spent 2 days struggling to integrate a pretty slick fish eye menu into the navbar of a website. While the comp’s of the bar looked great & everything was functioning well. The finished site seemed to lack something. It turns out that so many concessions had been made in the design to accommodate the menu’s space & bandwidth requirements. That the entire rest of the project was lackluster for better or worse. Don’t let this happen to you.

Remember, menu’s are not the value added prospect of any site. They are there to make it easy for our users to find the content & navigate.