why frames are bad

4 May 2004 - 1:53pm
10 years ago
3 replies
393 reads
Jim Hoekema
2004

I guess I'm feeling perverse today, but those poor downtrodden frames need a
defender! David said:

The reasons that frames don't work:

1. harder on searchengines
2. bookmarking becomes difficult
3. calculating frame sizes isn't x-browser equal
4. frames the way implemented in the HTML does not map to user expectations
in terms of scrollbar layout and what not

Strictly speaking, items 1 and 2 don't work well in most web STRATEGIES, but
this does not mean that web pages with frames don't display their content
just fine. If you don't care about search engines or bookmarking every page,
these factors don't matter.

Item 3 - can you quantify this? What percentage error is the most extreme
case? I suspect it's well within the range of unpredictable elements we are
used to accepting in web design, such as the variability of users screen
resolutions, platforms, color space, text size settings, default fonts, etc.

Item 4 - Well, you got me there... it's the "what not" that'll get you every
time! Though you could argue that frames don't map to user expectation
because nobody uses frames... kind of a circular argument.

Perversely yours,
Jim Hoekema
www.hoekema.com

Comments

4 May 2004 - 2:07pm
Dave Collins
2004

The reasons that frames don't work:

1. harder on searchengines
2. bookmarking becomes difficult
3. calculating frame sizes isn't x-browser equal
4. frames the way implemented in the HTML does not map to user
expectations
in terms of scrollbar layout and what not

>Strictly speaking, items 1 and 2 don't work well in most web
STRATEGIES, but
this does not mean that web pages with frames don't display their
content
just fine. If you don't care about search engines or bookmarking every
page,
these factors don't matter.

Yes. That's what I'm after. Users (including robots) can't use the site
easily. Why would anyone build a site (to support a money-making
organization) that didn't care about search engines or bookmarking?

>Item 3 - can you quantify this? What percentage error is the most
extreme
case? I suspect it's well within the range of unpredictable elements we
are
used to accepting in web design, such as the variability of users screen
resolutions, platforms, color space, text size settings, default fonts,
etc.

A 1 pixel discrepancy is enough disqualify - and thus significantly
restrict the pool of - designs.

>Item 4 - Well, you got me there... it's the "what not" that'll get you
every
time! Though you could argue that frames don't map to user expectation
because nobody uses frames... kind of a circular argument.

It would be an utterly senseless argument. Tantamount to "Let's add more
widgets! That'll force the user to learn them, so we can claim that
eventually we'll have technically-savvy users!"

Perversely yours,
Jim Hoekema
www.hoekema.com

_______________________________________________
Interaction Design Discussion List
discuss at interactiondesigners.com
--
to change your options (unsubscribe or set digest):
http://discuss.interactiondesigners.com
--
Questions: lists at interactiondesigners.com
--
Announcement Online List (discussion list members get announcements
already)
http://interactiondesigners.com/announceList/
--
http://interactiondesigners.com/

4 May 2004 - 2:13pm
Todd Warfel
2003

On May 4, 2004, at 2:53 PM, Jim Hoekema wrote:

> [Dave Heller...]
> 1. harder on searchengines
> 2. bookmarking becomes difficult
> 3. calculating frame sizes isn't x-browser equal
> 4. frames the way implemented in the HTML does not map to user
> expectations
> in terms of scrollbar layout and what not
> [...]

> Strictly speaking, items 1 and 2 don't work well in most web
> STRATEGIES, but
> this does not mean that web pages with frames don't display their
> content
> just fine. If you don't care about search engines or bookmarking every
> page,
> these factors don't matter.

I've yet to have a commercial client who didn't care about search
engine placement. However, if you're referring to Web-based application
types, then I'd agree; search engines aren't much of a factor.

On the bookmarking issue, it's hard to tell when a user will/won't
bookmark a page. And unfortunately, bookmarking and frames don't map to
users' expectations. Most users don't understand that each frame is a
page and that when you bookmark, your browser is bookmarking the last
frame you interacted with/clicked in. And this becomes confusing -
consistently.

> Item 4 - Well, you got me there... it's the "what not" that'll get you
> every
> time! Though you could argue that frames don't map to user expectation
> because nobody uses frames... kind of a circular argument.

In our experience, it's less about "nobody uses frames" and more about
users don't understand the frames concept fully, or even close to
fully. I'd have to say over the past 10 years, we've seen countless
participants in usability testing become confused by frames, especially
when there are three or more (e.g. Web-based applications, iTV).

A great deal of the confusion comes into play when they try and
bookmark, print, or use the browser's back button. Since frames
dictates that each of these actions is applied to the last frame you
clicked in, that's the piece that becomes confusing - participants
typically are expecting a different action (e.g. back should return me
to the last page of content, when in fact it refreshes the navigation).

You can get away with frames for applications; however, their are
typically better alternatives to accomplishing the same goal:
- server side includes
- divs in XHTML
- flash components (yes, I said Flash components - wonderful when
executed correctly)

Cheers!

Todd R. Warfel
User Experience Architect
MessageFirst | making products easier to use
--------------------------------------
Contact Info
voice: (607) 339-9640
email: twarfel at messagefirst.com
web: www.messagefirst.com
aim: twarfel at mac.com
--------------------------------------
In theory, theory and practice are the same.
In practice, they are not.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 3081 bytes
Desc: not available
Url : http://listserver.dreamhost.com/pipermail/discuss-interactiondesigners.com/attachments/20040504/8108f20e/attachment.bin

4 May 2004 - 2:32pm
Craig Oshima
2004

> Frames, are not usable b/c they are a poor hack into the HTML spec.

I agree with everything you level against frames; I don't care for them
either. However, you go on to ask:

> The reason to use frames? hmmm? Can't think of any.

There are two reasons I can think of that warrant consideration *in
certain circumstances*. Both are more applicable to web applications,
rather than the typical web page. Notably, they're also raised for
practical implementation reasons rather than design reasons:

1. You need to keep substantial or complex data persistent across
multiple pages. You could embed this data in the URL (ugly) or store it
in a cookie (not guaranteed to be enabled), but a hidden frame is
another option. It has more flexibility, fewer limitations, and avoids
having to pass the data back and forth repeatedly across the wire. If
you have server-side functionality (ASP, PHP, JSP, etc.) however, there
are probably better ways to deal with this problem.

2. You need to communicate back to the server, but for whatever reason,
you don't want to reload the entire page. Amazon did this some time
back with their "Earn a nickel" thing where you answered questions about
their site and get nickels that get applied as discounts to your
purchases. By using a hidden frame, you can submit form posts (and
examine the response) without having the whole page reload, and that can
be useful. I've never done it myself, but there've been times I
considered it.

--
Craig Oshima
coshima at acm.org

Syndicate content Get the feed