Who framed the website?
I realised that designers love frames. They use it everywere. In hotsites, e-commerce, portfolios or annual reports websites. My guess is that they love the idea of a design fitting in that narrow square space, just like they get in their print jobs.
But they have to let go. Think big. Go vertical. Discover the page there is below the fold.
And, as a rule of thumb, avoid frames.
Here’s my own list of reasons:
- Low performance on search engines
- Browser and Accessibility Problems
- Copyright issues
- Wrong Bookmarking
- Complex navigation
- Poor hyperlinking
- Page reloading issues
- Printing problems
- Screen sizes
– Low performance on search engines. Frames usually don’t provide relevant metatags or establish meaning or relation between different framesets. This is a serious problem since users might never find your site, as long it can’t be indexed by search engines.
– Browser and Accessibility Problems. Several browsers don’t support frames (mobile browsers, screen readers), forcing extra effort to program a no-frames version.
– Copyright issues. Loading a third-party page in a frameset will probably confuse users as if it was our own content, leading to some legal issues and even some security holes in old browsers may occur.
– Wrong Bookmarking. Most of the times, when a user bookmarks a page with framesets, it actually retrieves the parent adress, and not the contextual adress, leaving the user with no idea what was the real page visited. When bookmarking frames, most often we get only a link to a navigation with no relevant content. The bookmark adress no longer represents the information and state of the page when we saved it.
– Complex navigation. Users cannot provide to others a meaningful and simple URL, but instead have to give complex directions on how to get to a particular content within the site map. Users might also be trapped within a frameset when following an external link.
– Poor hyperlinking. If other websites try to link to our pages, they will probably get only the homepage, and not the individual content relevant to them. First, it decreases the page ranking in search engines, but most important, it affects the very own nature of the web, which is in the words of one of his founders, Tim Berners-Lee, a “semantic web”, with the page as an “atomic unit of information“.
– Page reloading issues. When reloading a frameset, if some care hasn’t been put into scripting, the page will reload the parent page, and will lose focus of the previous page.
– Printing problems. Although some modern browsers have already adressed this issue, the printing of framesets is quite complicated to novices, that usually get printed only the current focused frameset, with a lazy print of the navigation bar when what you really wanted was the main body with text.
– Screen sizes. If the screen resolution is low, users might find themselves forced to scroll both horizontal and verticaly as a result of the imposed framed interface.
If that isn’t enough, please try to explain to me why you must use them. But not again the old mantra, “because it looks good”. Forget it. The HTML page is functional, and serves his purpose as a unit, so you don’t need to put it behind those stinkin frames.
Design for the web and not for print, please.
The users and web developers of the world.
P.S.: You achieve the same scrolling result of a frame using the CSS property
position:fixed, keeping the page as a unit and thus avoiding frames. But, as usual, it doesn’t work in IE.