Jakob Nielsen's Alertbox for December 1996:

Why Frames Suck (Most of the Time)

Judging from the email I receive, the most controversial statement I have made in my Alertbox columns so far was to make "the use of frames" one of the mistakes in my list of top ten mistakes in Web design.

For new or inexperienced Web designers, I stand by my original recommendation. Frames: Just Say No.

With respect to the use of frames by highly skilled Web designers, I have changed my opinion somewhat: people who really know what they are doing can sometimes use frames to good effect, though even experienced designers are advised to use frames as sparingly as possible.

Fundamental Problems with Frames

Part of the genius of Tim Berners-Lee's original design of the Web was a total unification of several concepts in a single idea, the page:

the user's view of the information on the screen
the unit of navigation (what you get when you click a link or activate a navigation action like a bookmark)
a textual address used to retrieve information over the net (the URL)
the storage of the information on the server and the author's editing unit (except if using embedded objects like image files which do require the author to manage multiple files for a page)

The fundamental design of the Web is based on having the page as the atomic unit of information, and the notion of the page permeates all aspects of the Web. The simplicity of the original Web contributed to its ease of use and its rapid uptake.

Frames break the unified model of the Web and introduce a new way of looking at data that has not been well integrated into the other aspects of the Web. With frames, the user's view of information on the screen is now determined by a sequence of navigation actions rather than a single navigation action.

Navigation does not work with frames since the unit of navigation is different from the unit of view. If users create a bookmark in their browser they may not get the same view back when they follow the bookmark at a later date since the bookmark doesn't include a representation of the state of the frames on the page.

Even worse, URLs stop working: the addressing information shown at the top of the browser no longer constitutes a complete specification of the information shown in the window. If an author copies the URL in order to include it as a hypertext anchor in one of his or her own pages then that anchor will not lead readers to the desired view but to the initial state of the frameset. Similarly, if a user decides to send an email message to a friend with the recommendation to check out a page, then copying the URL from the browser will not work if frames are used since the URL points to the frameset and not to the current view (with the information of interest to the friend). Given that social filtering is one of the most powerful mechanisms for information discovery on the Internet, it is an utter disaster to disable the URL as an addressing mechanism.

Implementation Problems with Frames

In addition to the fundamental problems discussed above, there are several minor problems with the current implementation of frames. These problems will go away over the next few years, but for designs done in 1997 (and maybe even 1998) they will remain a reason to minimize use of frames.

Users with Frames-Challenged Browsers

The November 1996 browser statistics from Interse show the following distribution of browser usage:

Netscape 2: 13% of users
Netscape 3: 47% of users
Internet Explorer 3: 28% of users
Other browsers or earlier versions: 13% of users

Percentages sum to 101% due to rounding. Thus, 13% of users would not even be able to see a site with frames. Sure, it is possible in principle to use the <NOFRAMES> feature to serve alternate content to these users, but most designers don't bother designing two versions of their pages and reserve <NOFRAMES> for a "helpful" link to the download site for a frames-supporting browser version.

13% of users are still using Netscape 2 which had one of the worst usability problems to be seen on the Web so far: the BACK button in the browser simply didn't work with framed sites. The BACK feature is an absolutely essential safety net that gives users the confidence to navigate freely in the knowledge that they can always get back to firm ground. We have known from some of the earliest studies of user navigation behavior that BACK is the second-most used navigation feature in Web browsers (after the simple "click on a link to follow it" action). Thus, breaking the BACK button is no less than a usability catastrophe.

Combining these two statistics leads to the conclusion that more than a quarter of the users either can't see frames at all or can only do so while suffering severe usability problems. Even though many of these users will upgrade over the next year, there will probably still be about 10% left by the end of 1997. Remember that many people don't view Web browsing as a central part of their lives and therefore don't invest much effort in keeping up with the changing tools.

Thus, even if frames improve a design, they only do so for three quarters of the users, meaning that the improvement will have to be substantial to be worth the additional effort and the risk of aggravating the frames-poor quarter of the users.

Print Problems

Many browsers cannot print framed pages appropriately. Of course, most browsers don't print anything really well, but at least regular pages normally print in full. With frames, it is common to have the print command result in the printing of a single frame. Printing the full page is difficult with scrolling frames: should only the visible part of the frame be printed or should the content be allowed to expand and take up more room than it does on the screen?

Authoring Problems

The original release of HTML was simple enough that many people learned it without any problems. Frames are another matter, though. Newsgroups like comp.infosystems.www.authoring.html are filled with questions from Web authors who desperately need to know why their frames don't work as intended. Frames are currently so hard to learn that many page authors write buggy code.

Search Problems

Search engines have trouble with frames since they don't know what composites of frames to include as navigation units in their index.

User Preferences

Many websites that offer users a choice between regular and framed versions have found that most users prefer frame-free designs.

When It's OK to Use Frames

The main issue in using frames is to ensure that URLs keep working. To do so, all hypertext links must have a TARGET="_top" attribute in their anchor tag (e.g., <A HREF=foo.html TARGET="_top"> ). Adding the _top makes the browser clear out all the frames and replace the entire window with a new frameset. The destination frameset may well have many frames that are identical to the ones in the departure frameset and will be cached in the browser, but by forcing a complete reload in principle, the browser gets a new URL for the destination. This means that navigation actions (e.g., bookmarking) work again and that the URL is available for other people to link to.

The only exception from the need to use a TARGET="_top" attribute is when frames are used as a shortcut for scrolling within a single page. For example, a very long directory or other alphabetical listing could have a frame on top listing the letters of the alphabet. Clicking one of these letters would cause the listing to scroll within another frame while keeping the user on the same page and thus not destroying navigation.

Frames are also useful for "meta-pages" that comment on other pages. For example, a Web design styleguide may need to mix discussions of design principles with live examples of entire pages that follow (or break) the rules. In these cases, the embedded page should be treated as an embedded image (even though it is implemented as an independent page) and the "main" information that users will want to bookmark should be the content of the commenting frame.

Finally, it seems that the inline frames introduced in HTML 4.0 will be mostly harmless. A frame that is inlined will be subordinate to the main page, and the user can still bookmark the main page and navigate as usual. Since mainstream browsers still do not implement HTML 4.0, we don't know whether inline frames will have their own implementation problems: in particular, it is doubtful whether good ways will be found to print pages that have scrolling inline frames (my current best guess is that it will be best to print the currently visible part of a scrolling inline frame in order to maintain the layout of the main page, but some users may want to have the entire contents printed, so messy option settings may be necessary).

Toward a Richer Node Model

In the long term, we will need a richer model for hypertext nodes on the Web than can be supported by frames. For example, composite nodes, typed nodes, hierarchical nesting of nodes, nodes with different views, and nodes with actions that influence other nodes are all ideas that have been explored in hypertext research. It will be important to retain the positive attributes of the Web as we move toward these richer information structures.

Next month: Trends for the Web in 1997

See Also: List of other Alertbox columns
If you still want to do frames after reading this column, then check Builder.com's or the Web Design Group's frames-building tutorials for advice on how to do it with minimal damage.