As I said I don't want to start a frames debate. Suffice it to say, the
problems you bring up are valid concerns, but aren't always an issue.
Bookmarking the frameset in my case is exactly what I want as it will
redisplay the page in its initial state. There is no need (trust me) for
anyone to want to bookmark an interim frame like one might have in a menuing
situation.
Web design is always a matter of weighing trade offs, like anything else.
Knowing your audience (or knowing you don't know your audience) is
important. Sometimes you have to decide if how the page works (and why that
is important), is more important than who will be affected by it. Providing
alternatives is appropriate as well if necessary.
We can discuss this further offline if you must.
Dan
> ----------
> From: Rod McChesney[SMTP:[EMAIL PROTECTED]]
> Reply To: Rod McChesney
> Sent: Friday, March 05, 1999 2:17 PM
> To: [EMAIL PROTECTED]
> Subject: Re: My view on JSP
>
> The problem is that bookmarking a framed page typically bookmarks the
> frameset oage itself, which means that if the real content is in a
> middle frame, the visible content is not actually getting bookmarked.
> This is very frustrating when you click on the bookmark and get back
> the home page instead of the page you intended to save.
>
> > No one would want to bookmark an individual frame.
>
> Maybe not, but they want to bookmark the page they see in front of them,
> and the default behavior of frames prevents that.
>
> As for back and forward, their behavior depends on which frame has
> focus. So if a middle frame has focus and users click Back, it
> is not the same as if the top or bottom frame has the focus and they
> click Back. This can also be very confusing.
>
> There are sites designed to work with this behavior --
> http://www.zhongwen.com is a great example of a heavily frame-based
> site that works very well indeed. But for adding standard navigation
> controls at the top or bottom of the page frames are not so good.
>
> I'm a little surprised you haven't run into these issues...they are the
> reason most of the heavily used portal-type sites moved away from
> frames, as I understand it. See http://www.useit.com/alertbox/9612.html
> for some other points; the article dates to 1996 but I don't believe
> newer browsers have fixed these problems.
>
> Rod McChesney
>
>
> Kirkdorffer, Daniel wrote:
> >
> > Bookmarking isn't an issue as no part of the page has meaning without
> the
> > rest of the page. No one would want to bookmark an individual frame.
> Like
> > anything else the back and forward buttons can be used, but nothing
> dramatic
> > will happen if they are.
> >
> > Dan
> >
> > > ----------
> > > From: Rod McChesney[SMTP:[EMAIL PROTECTED]]
> > > Sent: Friday, March 05, 1999 1:34 PM
> > > To: Kirkdorffer, Daniel
> > > Cc: [EMAIL PROTECTED]
> > > Subject: Re: My view on JSP
> > >
> > > > This improves the interface in a manner that is
> > > > transparent to the user,
> > >
> > > Except for bookmarking and the behavior of the Back and Forward
> > > buttons, that is...have you found some way around those issues?
> > >
> > > Rod McChesney, Korobra Corporation
> > >
> > >
> > > Kirkdorffer, Daniel wrote:
> > > >
> > > > Not wanting to start a frames debate, I should point out, like many
> > > things,
> > > > it all depends on how they are used. I often use frames to create
> > > "static"
> > > > header or footer sections for a page that sandwich scrollable data
> > > display
> > > > areas. For example, the footer may contain the action buttons (who
> > > wants to
> > > > have to scroll to the bottom of a page to access these all the
> time?).
> > > For
> > > > example I'm developing a form that is actually comprised of 6
> horizontal
> > > > zones, each a frame. This improves the interface in a manner that
> is
> > > > transparent to the user, and allows for me to change the content of
> each
> > > > frame without having to change the whole page, which would be a much
> > > more
> > > > complex and less elegant approach.
> > > >
> > > > Dan
> > > >
> > > > > ----------
> > > > > From: Craig R. McClanahan[SMTP:[EMAIL PROTECTED]]
> > > > > Reply To: Craig McClanahan
> > > > > Sent: Friday, March 05, 1999 9:31 AM
> > > > > To: [EMAIL PROTECTED]
> > > > > Subject: Re: My view on JSP
> > > > >
> > > > > "Kirkdorffer, Daniel" wrote:
> > > > >
> > > > > > [snip]
> > > > > > 2) Craig's example below begs for a feature that is lacking
> right
> > > now:
> > > > > the
> > > > > > ability to "re-target" a page. Craig talks about the common
> need to
> > > > > > conditionally display a page. Well I develop pages that use
> frames,
> > > and
> > > > > > often find that the target of my next page might need adjusting
> > > > > depending on
> > > > > > what happens server side. However a page's target is determined
> at
> > > the
> > > > > time
> > > > > > a server side call is made, and cannot be adjusted after the
> fact.
> > > I've
> > > > > > sent SUN a request for the ability to change target at redirect
> or
> > > > > callpage
> > > > > > time. I certainly hope it makes it into JSP 1.0. That's
> assuming
> > > it
> > > > > can
> > > > > > even be done.
> > > > >
> > > > > I think your last sentence above is the key ... frames and targets
> are
> > > a
> > > > > purely
> > > > > *client* side phenomenon. There is nothing in an HTTP request
> that
> > > > > indicates
> > > > > what the requestor is going to do with the data, and there's
> nothing
> > > the
> > > > > server
> > > > > can do to "direct" the response to a particular frame.
> > > > >
> > > > > So, before it becomes possible to accomplish your goal (determine
> the
> > > > > target at
> > > > > the server side), some modifications to the HTTP protocol itself
> would
> > > be
> > > > > required. As many designers who have used frames can attest, this
> > > issue
> > > > > affects static HTML pages just as much as it does dynamic ones.
> It is
> > > > > also one
> > > > > of the reasons I have tended to stay away from frames in my own
> apps.
> > > > >
> > > > > >
> > > > > > Dan
> > > > > >
> > > > >
> > > > > Craig McClanahan
> > > > >
> > > > >
> > >
> ==========================================================================
> > > > > =
> > > > > To unsubscribe, send email to [EMAIL PROTECTED] and include in
> the
> > > > > body
> > > > > of the message "signoff JSP-INTEREST". For general help, send
> email
> > > to
> > > > > [EMAIL PROTECTED] and include in the body of the message
> "help".
> > > > >
> > > >
> > > >
> > >
> ==========================================================================
> > > =
> > > > To unsubscribe, send email to [EMAIL PROTECTED] and include in
> the
> > > body
> > > > of the message "signoff JSP-INTEREST". For general help, send email
> to
> > > > [EMAIL PROTECTED] and include in the body of the message "help".
> > >
>
> ==========================================================================
> =
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> body
> of the message "signoff JSP-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
>
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JSP-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
