||May 24, 1998
Frames: Information Vs. Application
(The following was originally written for A
List Apart, a moderated mailing list about Web design.)
peterme's Rule Of Thumb for Frame Design:
If you're creating an information-centered Web site frames are a bad idea. If you're developing a Web application,
frames are a good idea.
If, as is the case with much of the web, people come to your site to read a series of pages in order to get information,
you should avoid frames. Why?
You can't bookmark pages within a frameset. Browsers only bookmark the initial frameset, so if you dig deep within
a site's frameset, find a nifty bit of information, and bookmark it, well, you're really just bookmarking the page
that declared that frameset. (Note: The 4.0 browsers have added the ability to bookmark a particular frame in a
set, but when you revisit the page, it will be removed from its frame context.) This problem also extends to sharing
URLs (emailing URLs is a huge factor in the word-of-mouth spreading of Web sites).
It used to be that search engines had trouble picking up pages within framesets. I don't know if that's still true,
but I do know that search engines still point only at single URLs. If your content lives within a frameset, and
a search engine takes someone to a particular piece of content, the user will not be given the frameset context
(usually containing the navigation and site branding), and so will often land on a page and have no idea where
he is nor how to get around.
Here is some good info on Search
Engines and Frames.
Feedback in navigation
to swap out graphics or b) load a version of the bar with the appropriate section selected. Also, if you allow
people to traverse using links in the content, and those links take them from one site section to another, your
I've never developed a site in frames where at some point I didn't want more than one frame to update based on
will want frames to update conditionally.
Going From Deep Within One Frameset To Another
This is always my biggest frames-based bugaboo. The sites I've worked on often have complex hierarchical structures.
Being the Web, you want to be able to take people from deep within one part of the hierarchy to deep within another
part of the hierarchy. However, because framesets are essentially hard-coded, you can't use a simple link, or the
user will just be taken to the initial frameset (see 'Bookmarking' above). The way around this is to have the frame
dynamically generated. The safest way to dynamically generate frames is using a .CGI that writes out the frameset
based on variables passed to it. An example of this is Maxi, though I now see they're using the .CGI far less than they used to.
Are you developing heavily interactive Web sites, where the point isn't to get users to read something, but to
perform tasks, to interact with the site? Then perhaps you should consider frames. Most of the problems listed
above go away.
Since Web applications are heavily server-side, you have total control over the appearance of the frames. Bookmarking
isn't a problem, because you're not serving up specific chunks of content, you're providing a way for users to
complete a task (or series of tasks). Without frames, your interface elements are likely to scroll away, much to
the chagrin of your users; with frames, your interface can stay put. By staying put, your interface also provides
cognitive context and keeps the user grounded in your experience. Examples of great frames-based application interfaces
can be found at Netgrocer and Kvetch. The immediate feedback, the persistent interface elements, the overall feeling of utility
provide a highly functional user experience that would be nearly impossible without frames.