WHY FRAMES ARE NOT A GOOD DESIGN (MOST OF THE TIME)

1.  Fundamental Problems with Frames
2. Implementation Problems with Frames
3.  Users with Frames-Challenged Browsers
4.  Print Problems
5.  Authoring Problems
6.  Search Problems
7.  User Preferences
8.  When It's OK to Use Frames
9.  Toward a Richer Node Model
10.Style Sheets vs. Frames as Web Extensions

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

With respect to the use of frames by highly skilled Web designers, 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 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.

Style Sheets vs. Frames as Web Extensions

In considering how to extend the Web with new technologies, it is instructive to compare Cascading Style Sheets (CSS) with frames. CSS is an elegantly designed extension.

CSS is backward compatible to the extent that viewing a style-enhanced site with an older browser causes no problems at all. Of course, the user doesn't see the stylistic enhancements made possible by CSS (e.g., multiple fonts and indented margins), but the text of the page will be readable and will be presented in a reasonable default style (of course, the extent to which you deem the default presentation reasonable depends on your assessment of the quality of typography in mainstream browsers: admittedly rather poor). In contrast, a page designed with frames is useless for a user with an old browser.

CSS is orthogonal to other features in Web browsing. When multiple style sheets become supported in future releases of the mainstream browsers, users might want to learn the command to switch between styles, but they won't have to. Even if users do learn this new command, it will not interfere with or change their understanding of earlier commands and operations. In contrast, frames destroy bookmarks, change the meaning of established commands like "print" and "view source", and in general make a mess of the user's prior understanding of the Web.

CSS builds on the philosophy of the Web: cross-platform design and simple-to-understand codes that are precisely documented in public specifications. CSS alleviates a widely felt weakness of prior Web technology: authors used to have too little control over the presentation of their content and had to stoop to unseemly hacks and improper HTML to get the effects they needed. Frames admittedly address the often-requested desire to keep a part of the page from scrolling, though this one useful effect of frames could have been achieved much simpler with the <BANNER> tag that was proposed in drafts of HTML 3.0. Most of the features offered by frames are of relatively little utility compared with the effects offered by tables and style sheets.