web design - frames

4 May 2004 - 3:14pm
10 years ago
1 reply
563 reads
Susan Farrell
2004

These are handy uses I had not considered, Craig. Thanks for those tips. It's important to be careful what you pass in HTML code, when money is involved though. I read last year or so in 2600, that a shopping cart that did something similar was getting hacked all the time by people who simply saved the page, changed the product price to what they wanted, and then completed the transaction.

I HATE frames, but there is one case in which they seem to be the lesser evil for design, IMO:

3. When you have many scrolling columns of things on the page and you need to make the column headings visible all the time. Sometimes you have to put the whole table or whatever on one page for some reason, and the trick of repeating the headings in a frame by themselves is very handy.

I've seen this done for persistent navigation on really long pages as well, and it works very nicely at the bottom of the window in a horizontal strip if handled correctly. On a non-application page, it is bad practice to make the fixed frame the one that owns the bookmarkable URL. Also, many database-driven catalog sites have the same page title for every page ( "catalog item" is all too common) which also defeats the purpose of bookmarking or using history lists. So pages need both unique main URLs and unique title tags.

Preventing deep linking on a public informational website (or an e-commerce site's product page) is a silly and annoying practice that I hope is fading into obscurity. I never link to sites or email references to sites if I have to give driving directions to the resource in question. (Instead, I use Icab http://www.icab.de/ to pop the frame into a new window, and link to that URL.) Unfortunately most people who make framed websites don't include at least rudimentary navigation links in content frames so that people who visit a deframed page can get to the home page from there. Sometimes you can't even tell which website owns a content frame once it's isolated from the frameset.

Susan Farrell
farrell at nngroup.com

At 12:22 PM -0700 5/4/04, Craig Oshima wrote:
>
>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.), then this is a
>better way to
>
>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.
>

Comments

4 May 2004 - 4:41pm
Craig Oshima
2004

Hey Susan, how are ya?

> It's important to be careful what you pass in HTML code,
> when money is involved though. I read last year or so in
> 2600, that a shopping cart that

Yes, this is a good point. Security is one good reason why it's better
to keep data on the server side as much as possible. But this leads us
off topic, so I'll leave it at that.

> 3. When you have many scrolling columns of things on the
> page and you need to make the column headings visible all
> the time. Sometimes you have to put

I think Dave Heller's suggestion of using a <div> with the overflow CSS
property would work for this as well. The only reason to opt for frames
instead of the <div> is if you need to support older browsers (including
NN4, which sadly hasn't quite vanished from the radar) that don't
support CSS.

Also, if your list is REALLY long, using an <iframe> for the list would
allow you to display the containing page, while asynchronously loading
the list in the frame. I considered something like this in one
application where an admin is applying an update to the server...this
process could take several minutes, and we display feedback to the admin
via a bullet list that's generated as various steps are completed.
Unfortunately, you don't see the page footer until the entire process is
complete, so the page looks funny. An <iframe> would have solved this
problem, but in the end we decided we could live with it. (Yay, frames
avoided once again!)

That's obviously another esoteric situation...You don't normally want to
drag your server response out like that!

--
Craig Oshima
coshima at acm.org

Syndicate content Get the feed