Thursday, 10 September 2009

Disadvantages of using frames

I often encounter developers who think it is a good idea to use frames or iFrames to implement web applications. The most often used argument is that with frames you don't have to update the entire window page. This blog post is an attempt to set the record straight and show why it is not a good idea to use frames unless you have to because of legacy reasons etc.

Benefits of using frames
  • Navigation can be fixed and always visible without scrolling.
  • Logo always visible which can be used to strengthen branding.
  • Less payload with page requests as only sections of the windows is refreshed.
  • You are able to put anything in the frames making the application seem more integrated or as one without having to open new windows or send the user to new sites.
  • If you mess up the markup of your page it might not destroy the entire layout of the site.
Most of the above can be solved without frames using different techniques although some of them would require more advanced technologies such as Ajax or DHTML.

Drawbacks of using frames
  • Facilitating search engines is more difficult and the indexing results by search engines are likely to be less good.
  • Linking to your site might gets tricky. If you are using frames you might need to set up some javascripts to recreate the frame structure.
  • The end user can not use the browser bookmarking or favourite functionality as normal.
  • Many people do not know how to copy the actual page address of a page within a frame setup. The end user can not copy the address of the current page from the browser URL address field since it probably just displays the root page url.
  • If you do not have full control over who creates pages for your frames you can not be sure that branding and style guidelines are followed.
  • Normal navigation for end users with back and forward buttons does not work as expected. (The browser address field is not updated)
  • Hyperlinks on the page inside the frames might intentionally or unintentionally open other external content in your frames, degrading user experience and branding.
  • Printing the pages gets more difficult.
  • Printed pages might loose it's contextual setup such as the breadcrumb trail and it will be difficult for the user to get an overview and find out where the page was printed from.
  • Frames might not be supported very well by many types of mobile or other type of compact clients.
  • The use of frames increase the chance of multiple and horizontal scrollbars when users do not maximize the browser window or when she has low screen resolution.
  • Frames are less usable for handicap users (see WAI/WCAG).
  • Page rendering is slower since firing up frames and doing multiple page requests usually takes more time.
  • The page rendering might seem unnatural as things are not rendered in a linear fashion.
  • You need to make sure hyperlinks all point to the correct sub frames which require additional testing.
  • Frames impose restrictions on the graphical design and layout.
  • The refresh-button seldom functions as expected.
  • You can get into copyright problems or confusion about the origin of content when intentionally or unitentionally presenting external content.
  • Many web application frameworks or content publishing systems are not designed for frames and can thus be an obstacle.
  • Presenting footer information gets more difficult to present in a consistent matter when using frames (not iFrames).
  • The user might experience the site as less trustworthy as the current page URL seems to be cloaked.
  • Use of frames is out of date and the site can be perceived as not being modern.
  • The use of frames requires more http requests which, to some degree, outweigh the benefits of less byte size payload.
  • The end user does not get a clear and consistent confirmation on when a new page is loaded.
  • Frames mess up the page metaphor and will make the site more confusing for novice end users.
  • If your frames are using session state you might encounter timeout or login forms in the wrong frames which cause a lot of confusion.
  • As a developer you might experience problems when the front end code base gets large and cross frames code and other javascripts start to make site browsing seem slow or awkward.
  • When using frames it is harder to debug front end issues.

Conclusion
Avoid frames whenever you can. If used, you should definetly know what you're doing and frames should only be used for application type of sites that do not need the typical document/page metaphor.