home ....interface design .... web development .... movie reviews .... travel .... about peterme
web development
  Web Dev thoughts  
  July 9, 1999: Webpardy! Web99 SF.

January 25, 1999:
Welcome to 'My' Parlor

October 13, 1998:
Webpardy! Web98 East

June 27, 1998:
This Is Webpardy!

May 24, 1998:
Frames: Information vs. Application

My work with DHTML
  Archive Piece  
  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).

Search Engines
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
If you have a navigation bar in a frame, it's a pain to present user feedback. You either have to a) use JavaScript 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 navigation bar will not reflect that, unless you have JavaScript on each page to ensure that the bar is appropriate.

Speaking of JavaScript
I've never developed a site in frames where at some point I didn't want more than one frame to update based on user interaction. So, if you're going to do a robust frames-based design, make sure you're well-versed in JavaScript. Yes, frame updating is a relatively simple piece of JavaScript code, but things will get complicated because you 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.