My Opinion of HTML Magic Acts

Authored September 2001

With the advent of dynamic pages (both client- and server-side) we now have the ability to modify the display in ways that the authors of the HTML 2.0 specification only imagined. As web content authors we can bestow the ability to add and remove features, content, or controls at the whim of our readers. While this type of processing, as a class, has definite benefits it is overly (and often wrongly) used.

One of the most common examples of this type of functionality is the expanding/contracting menu. I use one here (to left in case you missed it). This menu is dynamic: when you select a menu header the items it contains are displayed. Choose another header and its items are displayed while the previous ones are removed. The idea here is simple: display only what is requested.

(Even this simple case is suspect however. A compelling argument can easily be made that such "peekaboo" menus hide choices from the user forcing them to dig for what they want. Wouldn't it be easier, after all, if your visitor could see all your options at a glance? In this case a counter argument is also compelling: by showing all the options you risk "option overload". For largish menus there's also a chance that people may not be able to see all of your top-level headers at once due to monitor/resolution differences.)

Another example would be any of the many styles of contextual help. Mouse over or click a glossary term and the definition might appear as a tooltip or a pop-up window. Click on the help icon near a form field and an explanation of the field might insert itself within the page using Dynamic HTML. A FAQ page might present only questions until one is chosen then refresh itself with the answer inline.

The ability to create these kinds of dynamic, choice driven displays have dramatically increased what it possible within a Web browser. With them we can create contextually appropriate systems and content.

When Tools Become Toys

It's tradition that any new feature given to web authors is immediately overused to the point of nausea. Although not a "feature" per se this is no different. Amateurs taking advantage of whiz-bang features for the sake of their existence will always be with us. What suprises me is that it's continuously used so badly by those that should know better.

Consider the "Advanced Search Page" at HotBot (pictured). Here we see a lot of form fields (the page continues much further than what is shown in the image) and a lot of blank, green space. There is a graphical link (top center of the page's content area) informing us that we can "click to see explanations of how these options work".

Selecting that link repaints the page with some of the blank, green space now populated with a thin, fixed-width column of instructional help content. This page, with the help content, is about 20% longer than the page without the help content. This additional length is presumably the reason that the help content is not displayed by default. However simply allowing the help content to adapt to the browser width would eliminate the extra length in the vast majority of cases.

The help content is not complex and often states the obvious. For example, the "Language" field presents a drop-down down list box allowing the user the select from one of several languages. The help content displayed for this field is "Limit results to a specific language." Although in my opinion this isn't particularly helpful it may, indeed, help some novice users of the system.

In this case several things should be clear:

• The help content, when displayed, is not so large as to hinder the usability of the page. In fact if better designed it would not affect page length at all or, at worst, minimally.
• The help content, as authored, is most applicable to new users unfamiliar with the system.
• Although the help content isn't particularly helpful to advanced users it doesn't inhibit their use of the system when displayed.

Usability is best served by persistently displaying the help content. Utility would also be served by a static version as those users needing the help content would not have to perform a separate, and distracting, action to obtain it. Development of the toggling solution is also more involved than the more effective static solution. In short there is absolutely no good usability or practical reason to allow this this help content to be toggled.

Another Example

An even simpler example can be seen on the Microsoft home page. On this page their are two sidebar areas: "Today's News" and "New Downloads". The side bars change appearence when moused over and when the header is clicked the side bar content is removed from the page. Clicking the header again restores the content to its default state. (Well, at least it does in Internet Explorer.)

Default State	Mouse over State	Toggled State

I encourage you to go to the page and experience the effect that this functionality has on the usability of the page. It should be painfully obvious that this capability adds no value. None at all. That being said it doesn't actually hurt the experience either. At best it can be considered an example of what's possible. At worst it's a waste of download capacity. As it stands I would classify the feature as simply useless, but harmless.

Conclusion

It will be a recurring theme in these columns, but it bears (nearly constant) repetition: increased capability requires increased responsibility. Any feature that allows you to modify the user experience should be examined from the point of view of the user. Does it help or does it hinder (remembering that even if usability doesn't suffer on the surface more code means a longer download time and a less responsive application)? Even if it does improve usability is the improvement enough to warrant the inclusion of new, and possibly confusing feature?

In the vast majority of cases these (and similar) questions, properly considered, will lead you to a common conclusion: simpler is almost always better.