Who framed the web: Frames and usability

Back in the nineties, using frames to split a browser window into several independent parts was very popular. Much due to the increased awareness of usability and accessibility over the last few years, frames usage is not quite as widespread as it used to be. However, frames can still be found on many sites, especially those that haven’t had a major overhaul in a while.

If you spend most of your online time reading blogs, you hardly ever come across any sites that use frames. That’s good, considering that blogs are typically very rich on information. I don’t miss frames at all, and it’s been years since I last used frames myself, but recently I asked myself what the problems with frames are, and if there are occasions where the pros of frames outweigh the cons.

The problems with frames

The drawbacks are obvious to some, while others think frames have some things going for them. The problems I see with frames are mostly related to usability and accessibility. You may have heard of the problems before, but let me reiterate:

Iframes

What about iframes (inline frames) then? Well, usability-wise they really aren’t all that different from normal frames. They suffer from most of the problems mentioned for normal frames. Iframes are probably slightly less complex to maintain than normal frames since they don’t need special frameset files.

There are also reports of potential accessibility problems with iframes, where under some circumstances an iframe grabs focus when its content has finished loading. This can be very confusing for someone using a screen reader, and can cause unexpected results when printing. I haven’t seen this occur in my (limited) testing, but it’s something to keep an eye on.

CSS based frame imitations

CSS can be used to imitate the look of frames. This will avoid most of the problems with real frames. However, it can also cause usability problems that are different from those caused by frames.

One CSS technique used for this displays a header and a footer in fixed positions, letting the whole browser window scroll when necessary. The main content area will then slide behind the header and footer. I’m not aware of this technique causing any serious problems.

However, when an inline frame is imitated by using the CSS declaration overflow: auto, printing the full contents of the “frame” becomes impossible in the browsers I have tested—only the visible part is printed. This can be circumvented by providing a print style sheet, but it’s something that you should be aware of.

Another problem with the overflow: auto technique is that in many browsers, scroll-wheel mice cannot be used to scroll the contents of a “CSS frame”. While this is not a huge problem for most, and probably something that should be fixed by browser vendors (Apple and the Mozilla Foundation come to mind), it is very annoying.

Frame imitations cause fewer problems than real frames, but you should be aware that there are issues. Those issues can be avoided by providing alternative style sheets, both for viewing and printing.

Frames and frame imitations aren’t always bad

You can probably tell by now that I am no fan of frames, iframes, or frame imitations. They do have their uses though. Frames can be useful for intranets as well as for applications like web based e-mail and content management systems, where most of the problems noted here are of little or no concern. On a public website, however, they cause too many problems and should be avoided.

Visual arguments for using frames

But if frames are so bad, why do they even exist? Well, because they were invented back in the nineties, when every new browser feature had to be used just because it was possible. The question should probably be “Why does anyone use frames on public, information based websites?”.

In my experience, most of the web professionals that like to use frames are more visual design oriented than structure oriented. I don’t know if that assumption is true, or if it’s just coincidence. What I do know is that I’ve had plenty of clashes over frames with visually oriented designers wanting to confine a site’s content to a tiny scrollable area. Their reason for wanting to do this is usually a desire to keep the site’s navigation and/or “branding” always visible. Usability, accessibility, and search engine visibility are not on their radar.

I don’t mean that as a knock against all visual designers—I’m just bringing it up as an example of the attitude I’ve run into over and over, especially when working with designers coming from a print background.

Conclusions

To me there is no doubt that frames should be avoided for public websites. They just cause too many problems. For web based applications and intranets however, many of the problems mentioned are of less concern, so there are cases where frames can be useful. Think carefully before using frames though—ask yourself whether you really need them or if there is a better solution available.

As for CSS based frame imitations, my feeling is that those techniques can be useful, but should be used with care. Be aware of the printing problems they can cause, and don’t squeeze your content into a tiny, scrollable area just because you can. Remember that for most sites, people don’t visit just to admire the pretty design—they come looking for content.

Posted on November 18, 2004 in Usability, Search Engine Optimisation, Accessibility