Aren't frames bad?
Many complaints about frames do not apply to INTRAnets today.
Last modified: 10/3/98
Many commentators advise against the use of frames, so why are we recommending them in certain situations? Here is a list of some of the issues, and why they may not apply in the cases we recommend.

For links to some of the writings available on the web about frames, see:
"What others say about frames".

Frames used to be a new feature in browsers so were not available to many readers; that has changed
Old browsers are not the problem today that they were when many of the commentaries were written. Also, in the corporate world, you can be more sure of more recent browsers, and can even legislate it within a group.

Many of the commentaries were written just after Netscape 2.0 was released. At that time, very few people had frame-capable browsers. Jakob Nielsen found 13% did not in November of 1996. Today, almost all readers of Intranet material have access to frame-capable browsers (Netscape 2.0 and later, Internet Explorer 3.0 and later, and others). Looking at a variety of INTERnet statistics (not INTRAnet ones, which should be even more skewed to the newer browsers) there seems to be no more than a few percent of distinct "hosts" (i.e., PC's reading with a browser) using non-frame-capable browsers. On this site, and others run by Trellix for business users, only around 1% of the visitors have the older browsers (probably less than the number who are colorblind or run into network problems reading the site). The trend to frame-capable browsers is continuing.

Frames were poorly implemented in some early browsers
The "Back" button was not well integrated into Netscape 2.0. When you followed links within framed pages and then pressed the Back button, Netscape 2.0 would return you to the URL displayed before you went to the original framed page (even if you had clicked on many links since then) and not just back up the content of the one frame whose content changed with the last click. To move back within a frame you had to use the right-mouse button to display a context menu and choose "Back in frame". This is not the case anymore. The 3.0 and later browsers move back one "link click" at a time when you press the Back button.

There were other problems with frame attributes, such as not being able to hide the borders in the first Netscape 2.0 implementation, that have been fixed. As time goes on, more and more of these problems are being addressed successfully in the browsers.

Frames require more hits on the server
This is less of a problem on an Intranet. As Jakob Nielsen says in his Alertbox column for September 15, 1997, "The Difference Between Intranet and Internet Design":

Intranets often run between a hundred and a thousand times faster than most Internet users' Web access which is stuck at low-band or mid-band, so it is feasible to use rich graphics and even multimedia and other advanced content on intranet pages. Also, it is sometimes possible to control what computers and software versions are supported on an intranet, meaning that designs need to be less cross-platform compatible (again allowing for more advanced page content).

Frames can defeat bookmarking
Frames are often used to provide site-wide navigation where there is only one frameset for entire sections of a site. This means that you can't bookmark individual pages. This is not the type of use of frames we are talking about here. This site, and pages like this one, are more of what we are recommending. We do not generally recommend site-wide frames that inhibit bookmarking. (Technically, the key is using the TARGET="_top" attribute within anchor link tags, and separate framesets for each main text page. For example: <a href="info.htm" target="_top">More info</a>. This says to change the frameset when linking, so the same frames with the same text do not hang around after following the link. See "How frames work" for a detailed tutorial on frames.)

Many creators of sites that use frames do not understand the difference between the different types of link targets, and don't use "_top" when they should. Readers encountering those sites then assume that all uses of frames work that way. They do not.

Ashworth and Hamilton, in one of the writings cited in the "What others say about frames" page here, even claim that the use of frames to make all bookmarks go to the home page of an Intranet site can actually be a benefit! They maintain:

Given that corporate intranet sites are highly dynamic in both content and organization, specific page-level URLs are likely to change. Thus, bookmarks of specific page-level URLs would break. In addition, users who enter the site at a specific page that is not the home page are likely to miss the "what's new" alert. Because a web site may well be the only source of much important information, users may fail to notice content changes.

If you follow the guidelines here, and use a separate frameset for each page, bookmarking will still work. There are authoring tools that make this easy, and it can also be done with server-side coding.

Frames don't print
Early browsers could only print the contents of one frame at a time, not the combination you see on the screen. Newer browsers are starting to print frames in a readable way. Some authoring products (like Trellix 2.0) can print correctly. Also, the documents we are talking about here are for where screen reading is the main or only output. A companion, linear printable document may also be created (to be described in a Technique at some point).

Ashworth and Hamilton like the fact that printing just the frame without the navigation makes a cleaner, more appropriate printout, since navigation links have little meaning on paper. (Products like Trellix 2.0, though, can make the navigation links more useful by indicating with footnotes which page they refer to in a multi-page printout.)

Some people claim frames blow up browsers
There are complaints on some of the "I hate frames" pages about frames blowing up browsers frequently. We have not been able to pinpoint exactly what is the problem here, since frames seem to work fine with correct content. It is true, though, and was mentioned in the quotation on the "What others say about frames" page, that erroneous Java and Javascript code could be the real problem, and leading-edge Java and Javascript is often used for advertisements and "cool" navigation bars shown in frames. Therefore, it is the fact that people trying leading edge techniques also use frames that is the problem, not frames themselves. In any event, this should not be a problem on an Intranet where good tools are used to create the content and there is some quality control.

Search engines have problems with frames
In the Internet, search engines often come up with references to pages inside of frames, rather than the frameset itself. For full-text search, this can be a problem. For searches where the title has enough information, this is less of a problem. By putting appropriate "meta-tag" information in the frameset pages, or in the "NOFRAMES" part, this problem can be minimized.

In an Intranet environment, where you have control over the search engine, special coding can also be used to make the appropriate URL (the one referencing the frameset file) show up for searches.

Frames take up too much screen space
Part of the reason frames take up extra space that would not be used by similar, table-based designs is that scrollbars appear. Many early framed pages were designed by webmasters who had 1280x1024 pixel screens, yet were viewed by readers on machines with 640x480 pixels. This often resulted in many frames with scrollbars. In general, we do not recommend creating pages with frames that have more than one frame with scrollbars when viewed on normal size screens.

Many uses of frames in commercial web sites include areas to hold non-scrolling advertising. Readers, understandably, often resent devoting screen space to ads. This should be less of a problem on an Intranet internal to a company, where ads are unusual (for now?).

The space problem should also diminish as average screen size increases, especially in the office. In the Internet world of the home, many computers are older, 640x480 pixel screens. In the office, as new machines are being deployed, 800x600 and larger are becoming the norm. Even laptops are rarely less than 800x600 anymore (Spring 1998). Business users in software development and graphic arts have already found that most programs require 1024x768 or larger screens.

Some says that frames are un-natural in a browser
Frames have been a part of browsers from the first, even if only for their own use. For example, a browser itself uses some "frames" at the top of the screen to hold its title bar, menu, navigation and control buttons, and URL-entry field, with the "content" scrolling below, and a status line below that. The scrollbars themselves are "frames". Good application design mixes scrolling and non-scrolling.


Need to weigh benefits against problems
In some cases, the problems with frames outweigh the benefits. For example, a page that is frequently printed by unknown individuals on the Internet may be inappropriate for frames in the Spring of 1998 when most browsers (other than Microsoft Internet Explorer 4.0, which is used by much less than half the market) cannot print the frames on one page.

In other cases, the navigational benefits of frames, and other uses, could make them the best option. For example, an internal Intranet site in a company where certain pricing or other sales-support material is always read on-screen, and where speed of access to infrequently used information is important, frames may make navigation more efficient. Another example where frames are good would be a framed "tour" of competitors' web sites, with comments.

The experience with frames on this web site has been favorable
Note: This web site underwent a redesign in early October 1998. The comments relate to the older design. The old design was saved in www.gooddocuments.com/olddesign/homepage/hompage.htm.

Most of the comments we've received about the use of frames on this web site, Good Documents, relate to particulars of what is in the sidebar frames (mostly wanting more there, such as mail-to links or other navigation). A few comments disliked the old design of the pages that use a rightside frame, such as used to be on the Techniques homepage, a design decision about the "look" that would have had the same problems if implemented with tables. The biggest problem was the "tour of a tour" page in the sample about this site, a highly unusual, pathological example, especially on smaller screens.

Few of the complaints have been about the use of frames in general. There were positive comments about the site, like "It is well-designed, and that's coming from a guy who generally doesn't like frames." Maybe the lack of comments is because good use of frames is not noticed, only bad use, just like use of fonts and most other aspects of design.

Usability testing showed that navigation techniques made possible by frames worked.

This site is bookmarkable and tries to follow our advice (even though it was mainly created before this section was written and doesn't always succeed in being a good example of our advice).