I'm beginning a project with a client who kinda expects that "good
sites" use frames and need material that either supports of rejects
this expectation.
So:
Are users still resistant to framed sites and chosing the non-framed
version when availble?
tia
--steve...
Good sites have pages that load all the material necessary for
the user to decide which button to push in under ten seconds on
a moderate-speed modem under heavily loaded conditions.
In other words, the visual clutter, if you have to have it,
must load LAST. That's hard to do with frames.
John Nagle
>As of six months ago the conventional wisdom was that given a choice,
>most users preferred non-framed site versions. I know I did. And
>there's still plenty about frames I don't like (not knowing title and
>url of active file chief among 'em) but now that current browser
>versions are far more graceful than in the past I find myself
>preferring them instead of avoiding them.
>I'm beginning a project with a client who kinda expects that "good
>sites" use frames and need material that either supports of rejects
>this expectation.
>So:
>Are users still resistant to framed sites and chosing the non-framed
>version when availble?
>tia
>--steve...
I certainly avoid frames whenever there's an option. My main
objection, though, is to sites that load an external URL into one of
the frames. The difficulty is that the document (in my experience,
anyway) never fits into the frame, so you have to use horizontal
scroll bars to view the whole thing.
There are a few sites I've hit where frames are used for internal
navigation, which can work. The Iconolog site is one that comes to
mind.
But using frames for the sake of using frames because it's considered
"cool" or "in" or something is a mistake, IMHO.
--
Ralph Hickok
Author "The Pro Football Fan's Companion"
Macmillan, 1995 (Paper--Green & Gold Cover)
Hickok's Sports History: http://www.ultranet.com/~rhickok/
St...@JustSteve.com (Stephen Hueners) wrote:
>Are users still resistant to framed sites and chosing the non-framed
>version when availble?
s/version/"competitor's site"/
--
int m,u,e=0;float l,_,I;main(){for(;1840-e;putchar((++e>912&&941>
e?60-m:u)["\n)ed.fsg@eum(rezneuM drahnreB"]))for(u=_=l=0;79-(m=e%
80)&&I*l+_*_<6&&20-++u;_=2*l*_+e/80*.09-1,l=I)I=l*l-_*_-2+m/27.;}
On Tue, 2 Sep 1997, Stephen Hueners wrote:
> As of six months ago the conventional wisdom was that given a choice,
> most users preferred non-framed site versions. I know I did.
If you decide to use frames, it would be an exceedingly hostile move not
to provide a competent alternative. One that could have significant
consequences, indeed. (I'm not talking about possible legal
requirements for disabled access, though they might be an issue too, but
about accessibility of your site to indexing robots).
> I'm beginning a project with a client who kinda expects that "good
> sites" use frames and need material that either supports of rejects
> this expectation.
Your choices are either to put in the necessary extra work, or to
be extremely hostile to those who cannot or do not wish to use frames.
If you decide not to use frames, then you don't have that problem.
> Are users still resistant to framed sites and chosing the non-framed
> version when availble?
I make no secret of the fact that as a reader I don't like them, and I
know that my colleagues generally hate using them too. So consider me
prejudiced if you like. But even if I loved them, I'd have to recognize
that there are client agents that cannot use them anyway, so I'd still
have to put in that extra work. I don't see how a speaking machine can
ever be expected to do useful things with a framed site. They might be
able to navigate the individual frames one at a time, as Lynx does
already, but then you have all the disadvantages of a [sub]page that is
lacking the usual navigational conveniences, title indications etc.
because you put those in different frames of your set.
Have browsers advanced to the point that they have solved all of the
inconveniences of the frames design? I say not - they have solved some
of the faults of the initial implementations, but the inherent problems
are still there, such as the inability to bookmark, the inability to
print a complete document, the fact that framesets tend to sprout scroll
bars in the strangest places - or even make information completely
inaccessible - if the window size differs too much from what the author
expected. And so forth.
Do you welcome the indexing robot with "download a proper browser now,
loser"?
>I certainly avoid frames whenever there's an option. My main
>objection, though, is to sites that load an external URL into one of
>the frames. The difficulty is that the document (in my experience,
>anyway) never fits into the frame, so you have to use horizontal
>scroll bars to view the whole thing.
I actually don't mind frames if they are used correctly. In my mind,
correct frames means "for navigation". Frames for navigation are also only
really needed for large sites, say something like CNet or Microsoft's site,
even though you don't see them using it. Frame issues like no URL or title
are minor annoyances for me, but the following situations really make me
reach for that "Open in New Window" link:
#1. When I have to scroll horizontally.
#2. When an external page is loaded into the frame (site designers - page
killer scripts are very simple!).
#3. When I have to scroll to see stuff on the "nav bar" or less prominant
bar.
#4. When frames are used only for advertisements, even though I can see the
logic behind it.
I would like to see something replace frames as a form of navigation. Once
DHTML browsers become more available perhaps we will see some more DHTML
solutions. One that I would like to implement would be a "pull tab" thing
that is small and stays on the side of the viewers screen. When clicked,
the navigation panel would scroll out from the side, waiting for a click.
If the user clicked a link, or clicked somewhere else, it would go away.
Right now my biggest hindrance to implementing the above is how to get the
little "pull tab" to stay "locked" to the window and not scroll with the
document...
Wow, that turned into a rant, didn't it?
-----
Evan Jones jon...@cadvision.com
The Future of Gaming: http://www.geocites.com/TimesSquare/4941/
YES!
--
dmo...@efn.org _/_/_/_/_/ David W. Morgan \_\_\_\_\_ Honolulu Hawaii
http://www.efn.org/~dmorgan/congress.html - Congressional E-Mail Addresses
http://www.efn.org/~dmorgan/worst.html ------- Worst Web Pages of Congress
http://www.efn.org/~dmorgan/access.html - Free Internet access from Hawaii
>Are users still resistant to framed sites and chosing the non-framed
>version when availble?
I believe you're asking the wrong question. Don't you mean to ask
"Should I fight my client's wishes and do what I want or should I do
what I'm being paid to do and do it the best way possible?"
Jeff
That's not an exclusive OR. You're being paid, one assumes, to help
the client produce a successful site. If that includes telling the
client that frames are inappropriate for the site, then the client is
getting her money's worth. Otherwise, if the client later finds out
that many people despise frames, she may wonder why the expert she
hired did not warn her.
Liam Quinn
=============== http://www.htmlhelp.com/%7Eliam/ ===============
Web Design Group Enhanced Designs, Web Site Development
http://www.htmlhelp.com/ http://enhanced-designs.com/
On Tue, 02 Sep 1997 23:19:42 GMT, jon...@cadvision.com (Evan Jones)
wrote:
>I would like to see something replace frames as a form of navigation. Once
>DHTML browsers become more available perhaps we will see some more DHTML
>solutions. One that I would like to implement would be a "pull tab" thing
>that is small and stays on the side of the viewers screen. When clicked,
>the navigation panel would scroll out from the side, waiting for a click.
>If the user clicked a link, or clicked somewhere else, it would go away.
This can be done today using HTML 2.0's LINK element, e.g.,
<LINK REL=Index HREF="navigation_links.html">
I think that what you describe above is a perfectly good, and even
creative, method of presenting LINKs to the user. It's too bad that
browser vendors don't have this much thought capability.
>Right now my biggest hindrance to implementing the above is how to get the
>little "pull tab" to stay "locked" to the window and not scroll with the
>document...
I'd rather let the browser handle presentation details like this. I
think that MSIE 4.0b2's Favorites and History panes are an excellent
model for a possible browser implementation of HTML 2.0's LINK
element.
> As of six months ago the conventional wisdom was that given a choice,
> most users preferred non-framed site versions. I know I did. And
> there's still plenty about frames I don't like (not knowing title and
> url of active file chief among 'em) but now that current browser
> versions are far more graceful than in the past I find myself
> preferring them instead of avoiding them.
>
> I'm beginning a project with a client who kinda expects that "good
> sites" use frames and need material that either supports of rejects
> this expectation.
>
> So:
>
> Are users still resistant to framed sites and chosing the non-framed
> version when availble?
>
> tia
> --steve...
Steve:
Tell your client that search engines may not be able to find any pages
in his site other than the home page. This is because when you navigate
within a framed site, your URL remains the same. This should be
sufficient!
J.
Jill Cozzi:
> Tell your client that search engines may not be able to find any pages
> in his site other than the home page. This is because when you navigate
> within a framed site, your URL remains the same. This should be
> sufficient!
I might add a few things ;
- A lot of browsers crash on machines with little memory.
- Bookmarks cause confusion. (Which page did I REALLY bookmark?)
- Waste of computer resources.
- Unless they are used in a very good design, it is very confusing for
people to understand navigation.
I can of course think of more, but these are the big ones that really
irretates me.
Kind regards,
Alexander
--
______________________________________________________
Life is not a mystery to solve, but a puzzle to play
______________________________________________________
Alexander Johannesen, Oslo, Norway
http://home.powertech.no/alexjo/
In article <5uhsha$s5f$1...@decius.ultra.net>, rhi...@ma.ultranet.com writes:
|> St...@JustSteve.com (Stephen Hueners) wrote:
|>
|> >As of six months ago the conventional wisdom was that given a choice,
|> >most users preferred non-framed site versions. I know I did. And
|> >there's still plenty about frames I don't like (not knowing title and
|> >url of active file chief among 'em) but now that current browser
|> >versions are far more graceful than in the past I find myself
|> >preferring them instead of avoiding them.
|>
|> >I'm beginning a project with a client who kinda expects that "good
|> >sites" use frames and need material that either supports of rejects
|> >this expectation.
|>
|> >So:
|>
|> >Are users still resistant to framed sites and chosing the non-framed
|> >version when availble?
|>
|> >tia
|> >--steve...
|>
|> I certainly avoid frames whenever there's an option. My main
|> objection, though, is to sites that load an external URL into one of
|> the frames. The difficulty is that the document (in my experience,
|> anyway) never fits into the frame, so you have to use horizontal
|> scroll bars to view the whole thing.
|>
|> There are a few sites I've hit where frames are used for internal
|> navigation, which can work. The Iconolog site is one that comes to
|> mind.
|>
|> But using frames for the sake of using frames because it's considered
|> "cool" or "in" or something is a mistake, IMHO.
Some objections I haven't seen yet....
1. It's difficult or impossible to bookmark a page that's inside a
frame. "Difficult" but doable applies only to those that will let you
take a page that's already in a frame and open it in a new window. Without
that, no bookmarks.
2. Suppose you use frames for navigation. And suppose someone finds
a link (from another site or through a search engine) that takes them
into an internal page in your site. All of a sudden, there they are,
visiting your site, without your navigation frames! Now just how are
they going to find their way around?????
3. Frames are brutally difficult to size correctly, given that margins
aren't going to be constant, type size can't be controlled, etc. I've
seen lovely *non-sizeable* and *non-scrollable* frames that had text or
icons falling off into the bit bucket. Bad designer!!! No cookie!!!
But the alternatives aren't any better, because you can't predict whether
a scroll bar will be present or not and therefore can't allow for it
in even *trying* to get things to fit.
4. When the reader finally does get to the content, the frames are a
waste of valuable screen space. There's no way to make them go away
"temporarily."
AFAIC, frames are broken-as-designed. It's impossible to be sure that
you have compensated for all their faults.
And yes, you are responsible for pointing these things out to your
client.
--
Diane Wilson | Information consumes attention; a
anon-...@anon.twwells.com | wealth of information creates a
http://www.lava.net/~dewilson/ | poverty of attention.
http://www.acm.org/chapters/trichi/ | --Herb Simon
St...@JustSteve.com (Stephen Hueners) writes:
>As of six months ago the conventional wisdom was that given a choice,
>most users preferred non-framed site versions. I know I did. And
>there's still plenty about frames I don't like (not knowing title and
>url of active file chief among 'em) but now that current browser
>versions are far more graceful than in the past I find myself
>preferring them instead of avoiding them.
>I'm beginning a project with a client who kinda expects that "good
>sites" use frames and need material that either supports of rejects
>this expectation.
>So:
>Are users still resistant to framed sites and chosing the non-framed
>version when availble?
>tia
>--steve...
--
---***---
"If you want a picture of the Future,
imagine a boot stamping on a human face - forever."
1984- George Orwell
That's not quite correct. The search engines *will* be able to find his
sub-pages, but when a user follows the search engine's link and loads the
sub-page, that's *all* he'll get, because there's nothing on sub-pages
that can tell the browser that they belong to a frameset.
Let's take a hypothetical catalog site, where one frame contains the
company name and logo, another contains the index, and the third contains
variable content such as product description pages, price lists and
ordering information. If the user uses a search engine to get to one of
the product description pages, he may very well find a page that
describes exactly the product he's looking for but doesn't say who makes
it or how to order it. The only real way around this is to put redundant
information on each of the sub-pages so that they can stand alone, but
this will look silly and confusing to users who do come in through your
main frameset.
It is interesting to note that Netscape was informed of this and other
problems as soon as they publicly proposed their frames model, but they
went ahead and released it as is. As a result, frames aren't usable for
anything other than creating a flashy appearance for a site's opening
page; they're not useful for organizing sites that need to present a
combination of fixed (such as an index) and variable (such as individual
product sheets) content simultaneously. They're great for prototyping
flashy pages to impress the boss, but lousy at making sites easy for
customers to use. Sigh.
>>I would like to see something replace frames as a form of navigation. Once
>>DHTML browsers become more available perhaps we will see some more DHTML
>>solutions. One that I would like to implement would be a "pull tab" thing
>>that is small and stays on the side of the viewers screen. When clicked,
>>the navigation panel would scroll out from the side, waiting for a click.
>>If the user clicked a link, or clicked somewhere else, it would go away.
>
>This can be done today using HTML 2.0's LINK element, e.g.,
>
><LINK REL=Index HREF="navigation_links.html">
Yes, but which browsers actually support the LINK tag for anything other
than CSS?
If both the big browsers havn't supported it since their last version, you
still need to do some backwards compatability hacks, or else your web page
become one of many that some people won't see properly. Damn technology.
>I think that what you describe above is a perfectly good, and even
>creative, method of presenting LINKs to the user. It's too bad that
>browser vendors don't have this much thought capability.
I think it is really too bad that the browser vendors don't listen to the
web designers.
>>Right now my biggest hindrance to implementing the above is how to get the
>>little "pull tab" to stay "locked" to the window and not scroll with the
>>document...
>
>I'd rather let the browser handle presentation details like this. I
>think that MSIE 4.0b2's Favorites and History panes are an excellent
>model for a possible browser implementation of HTML 2.0's LINK
>element.
I don't know about that. I prefer to let ME handle presentation details. I
like to know that someone who is looking at my site will see exactly what I
want them to see. I don't see many designers not filling in the <BODY TEXT>
tags if they want black text, even though browsers TEND to default to black
text. Why not? Because most designers want everyone to have the same
experience.
If browsers provided an easy to implement option, and I can't figure out
how to do something similar myself then I would use it, but if I can do
something similar myself, I usually will.
To me, cross-browser, cross-platform, backwards compatability is VERY
important.
On Wed, 03 Sep 1997 20:29:30 GMT, jon...@cadvision.com (Evan Jones)
wrote:
: On Wed, 03 Sep 1997 04:40:40 GMT, li...@htmlhelp.com (Liam Quinn) wrote:
: >I'd rather let the browser handle presentation details like this. I
: >think that MSIE 4.0b2's Favorites and History panes are an excellent
: >model for a possible browser implementation of HTML 2.0's LINK
: >element.
:
: I don't know about that. I prefer to let ME handle presentation details. I
: like to know that someone who is looking at my site will see exactly what I
: want them to see. I don't see many designers not filling in the <BODY TEXT>
: tags if they want black text, even though browsers TEND to default to black
: text. Why not? Because most designers want everyone to have the same
: experience.
And how do blind users experience black text?
---
Richard Noteboom
Ric...@noteboom.demon.nl
http://www.noteboom.demon.nl/
"Tolkein Lives!"
>Jill Cozzi (jco...@sbsusa.com) wrote:
>: Tell your client that search engines may not be able to find any pages
>: in his site other than the home page. This is because when you navigate
>: within a framed site, your URL remains the same. This should be
>: sufficient!
>That's not quite correct. The search engines *will* be able to find his
>sub-pages, but when a user follows the search engine's link and loads the
>sub-page, that's *all* he'll get, because there's nothing on sub-pages
>that can tell the browser that they belong to a frameset.
Some search engines, notably Excite, specifically warn that they do
not index framed sites, and they recommend having a no-frames
alternative in order to get indexed.
<rest of post snipped>
>On Tue, 02 Sep 1997 20:39:01 GMT, rhi...@ma.ultranet.com wrote:
>
>>I certainly avoid frames whenever there's an option....
>
>I actually don't mind frames if they are used correctly.
>cut
>... One that I would like to implement would be a "pull tab" thing
>that is small and stays on the side of the viewers screen. When clicked,
>the navigation panel would scroll out from the side, waiting for a click.
>If the user clicked a link, or clicked somewhere else, it would go away.
There is a $20 java app called Menu-Let by www.q-d.com I am going to
use it in my schools webpage, with many students and teachers and 4
school braches, it might make navigating easier.
It doesn't go away, it will be in a botton frame. The good thing about
it is the links that fold out have messages that are show up in the
status bar. The menu is in English and the status bar info is in
Japanese. Great bylingual tool, if users have a Japanese configured
browser.
I will post the URL when I finish doing the webpage in a week.
Alan in Kyobashi, Osaka
Kansai Time Out
www.kto.co.jp/computers/97_Local_Ta.html
free e-mail/copy webpages/english radio
Stephen Hueners wrote in article
<340c1523...@news.wi.centuryinter.net>...
>I'm beginning a project with a client who kinda expects that "good
>sites" use frames and need material that either supports of rejects
>this expectation.
>Are users still resistant to framed sites and chosing the non-framed
>version when availble?
It's really not so much a question of the "acceptability" of frames as it is
of the "necessity" of frames. Before you start framing, why are you doing
it? Do you have complex information that needs to be cross-referenced, or
drilled into visually? Do you have a unique on-screen effect that can be
accomplished mechanically only by using frames? Both are valid purposes
(the former, arguably, more valid than the latter.)
If, however, your intent is only to provide a consistent means of
navigation, you'd likely be best served not by frames, but by anchoring your
site with fundamental design principles; ordered information, predictable
menus and links, and feedback that lets your audience know where they are in
the site.
Best,
Doug Cadmus
NeuroMedia, Ltd.
http://www.neuromedia.com
In <5ukul6$dun$1...@samba.rahul.net>,
c.c....@43.usenet.us.com (Rahul Dhesi) writes:
| In theory it's possible to create a frames-based site that works better
| than without frames. I haven't seen anybody do it yet.
Perhaps the "theory" hinges on a broken definition of "works better".
Nevertheless, I'd like to see the theory spelt out. One possible
approach would be a requirements-based analysis: i.e. the set of
requirements that Netscape's FRAME "functionality" can be (1) asserted
to address, and (2) shown optimal with respect to alternatives.
It may help to read the thread "Generalizing banners" from the HTML-WG
mailing list archives at <URL:http://www.acl.lanl.gov/HTML_WG/> before
attempting a theoretical justification. (See the index for 3Q95.)
:ar
In <340ED20E...@net-web.com>,
"William H. Sansbury" <webd...@net-web.com> writes:
| Another consideration is that, if the navigational elements of the site
| are cumbersome (ie. java animated buttons or other bells & whistles that
| take time to download), then placing the site in frames only demands the
| download of the navigational elements once, improving overall
| performance of large sites.
Why did the "navigational elements" have to be cumbersome in the first
place? Some Designer D00d flexing his programming muscles?
>In article <5uhsha$s5f$1...@decius.ultra.net>, rhi...@ma.ultranet.com writes:
>|> St...@JustSteve.com (Stephen Hueners) wrote:
>|>
>|> >As of six months ago the conventional wisdom was that given a choice,
>|> >most users preferred non-framed site versions. I know I did. And
>|> >there's still plenty about frames I don't like (not knowing title and
>|> >url of active file chief among 'em) but now that current browser
>|> >versions are far more graceful than in the past I find myself
>|> >preferring them instead of avoiding them.
>|>
>|> >I'm beginning a project with a client who kinda expects that "good
>|> >sites" use frames and need material that either supports of rejects
>|> >this expectation.
>|>
>|> >So:
>|>
>|> >Are users still resistant to framed sites and chosing the non-framed
>|> >version when availble?
>|>
>|> >tia
>|> >--steve...
>|>
>|> I certainly avoid frames whenever there's an option. My main
>|> objection, though, is to sites that load an external URL into one of
>|> the frames. The difficulty is that the document (in my experience,
>|> anyway) never fits into the frame, so you have to use horizontal
>|> scroll bars to view the whole thing.
>|>
>|> There are a few sites I've hit where frames are used for internal
>|> navigation, which can work. The Iconolog site is one that comes to
>|> mind.
>|>
>|> But using frames for the sake of using frames because it's considered
>|> "cool" or "in" or something is a mistake, IMHO.
>Some objections I haven't seen yet....
>1. It's difficult or impossible to bookmark a page that's inside a
>frame. "Difficult" but doable applies only to those that will let you
>take a page that's already in a frame and open it in a new window. Without
>that, no bookmarks.
>2. Suppose you use frames for navigation. And suppose someone finds
>a link (from another site or through a search engine) that takes them
>into an internal page in your site. All of a sudden, there they are,
>visiting your site, without your navigation frames! Now just how are
>they going to find their way around?????
A link, button, icon, that says: Frames On! As you suggest though,
the site should be navagational from any page.
>3. Frames are brutally difficult to size correctly, given that margins
>aren't going to be constant, type size can't be controlled, etc. I've
>seen lovely *non-sizeable* and *non-scrollable* frames that had text or
>icons falling off into the bit bucket. Bad designer!!! No cookie!!!
>But the alternatives aren't any better, because you can't predict whether
>a scroll bar will be present or not and therefore can't allow for it
>in even *trying* to get things to fit.
>4. When the reader finally does get to the content, the frames are a
>waste of valuable screen space. There's no way to make them go away
>"temporarily."
Frames are movable in browsers that support this feature.
>AFAIC, frames are broken-as-designed. It's impossible to be sure that
>you have compensated for all their faults.
>And yes, you are responsible for pointing these things out to your
>client.
Some search engines will also not properly index your site, using frames.
>--
>Diane Wilson | Information consumes attention; a
>anon-...@anon.twwells.com | wealth of information creates a
>http://www.lava.net/~dewilson/ | poverty of attention.
>http://www.acm.org/chapters/trichi/ | --Herb Simon
As frames can aid navagation and appearence, it is still important
to include support for browsers incapable of displaying frames.
I suggest a non framed page for your opener. All your Meta info
can be in this page. This will smooth submission to some search engines.
Also give your viewer a choice on this page if they would like the framed version .
P.S.
And don't visit my page. I didn't say I practice what I preach. :-)
=============================================
Dog Byte Classifieds
mac...@cwave.com
http://www.wipd.com/~dogbyte/
=============================================
: Whether the site is more attractive to users outside the demo context is
: rather irrelevant; they don't sign the designer's check... In effect the
: culprits are not designers (unless they are in good faith of course),
: but their infantile bosses/clients that set the reward in a certain way.
The companies that are currently falling for "demo" sites are soon to be
the companies that conclude that the WWW was just another overhyped
Generation X fad like grunge fashion. How their managers will resolve the
cognitive dissonance created by observing that there are other companies
that *do* seem to be using the Web successfully is a good question, though
I suspect that most of them will do so the same way GM's managers resolved
the cognitive dissonance between their own beliefs that American drivers
didn't like small cars and the observable fact that American drivers were
buying small cars, just not from GM.
: Fortunately a minority of designers do try harder and target the
: audience, not just the boss/client, for a site. But it is pretty hard
: going...
Sooner or later there's going to be a shakeout; the "demo" designers are
prospering only because the market is new enough that players can make
lots of money doing business for new clients rather than doing repeat
business for previous clients (which is only going to come when the
previous work actually generates business for the client by reaching the
client's customers). The designers who did target the audience will be
way ahead at that point, as their clients will be coming back to them and
repeat business with existing clients is almost always more profitable
than business with new clients (less overhead in drumming it up).
In <yf3zpps...@sabi.demon.co.uk>,
pier...@sabi.demon.co.uk (Piercarlo Grandi) writes:
| Whether the site is more attractive to users outside the demo context is
| rather irrelevant; they don't sign the designer's check... In effect the
| culprits are not designers (unless they are in good faith of course),
| but their infantile bosses/clients that set the reward in a certain way.
Not necessarily. Catering to stupidity is still a matter of choice,
even when the ultimate motivating factor is fear (of losing the
"reward" altogether.) The erstwhile designers, who claim that they are
basically "forced" to "give clients what they want", are actually
glossing over the fact that professional conduct is a matter of giving
customers what they *need*.
However, engaging the customer in a constructive dialog to elucidate
real needs and requirements would require *professional* preparation,
which starts with a thorough understanding of the technology. The fear
of revealing incompetence can be a motivating factor too; at any rate,
inadequate grounding will inhibit honest appraisal of alternatives,
and the customer need be no wiser if he weren't drawn into a dialog at
all...
| Fortunately a minority of designers do try harder and target the
| audience, not just the boss/client, for a site. But it is pretty hard
| going...
For all the anecdotal evidence of losing business to less scrupulous
competitors, I can't sympathize with those who are essentially arguing
that they can't afford to be honest. Most of the time, this is just
special pleading to hide the fact that they don't know enough about
this line of work to have the courage of their convictions, and so
they dare not even try to appeal to the client's *intelligence*. As
for the few who do, they're usually too good to lack for work. IMHO,
of course: I'll omit anecdotal evidence.
:ar
>Are users still resistant to framed sites and chosing the non-framed
>version when availble?
Not everyone even has the option to choose (or perhaps
they chose a browser which doesn't do frames). At the
sites I've measured (with the usual unknown errors in the
log files), the ratio of such users has remained steady
at about 10% for close to a year now.
--
Urban Fredriksson gri...@kuai.se If you lie to the web browser,
http://www.alfaskop.net/%7Egriffon/web/ it will get its revenge.
See URL for: Writing stylesheets, setting up your browser.
>>>> On Fri, 05 Sep 1997 03:20:30 GMT, ar...@nmds.com (Arjun Ray) said:
>aray> [ ... ] The erstwhile designers, who claim that they are basically
>aray> "forced" to "give clients what they want", are actually glossing
>aray> over the fact that professional conduct is a matter of giving
>aray> customers what they *need*.
Some one told me years ago - "Selling (Marketing) is
allowing the customer to have *your* way". The 'true'
professional will make every effort (based on his/her
knowledge) to convince the customer to do things the 'right'
way. But in the end the customer is _always_ the boos and
the Site is _his/hers_. A 'pro' will do the Site to the
customers satisfaction, while following his/her own "code".
If this becomes a dilemma the "pro" can not live with - then
he/she can refuse the project, having a good feeling and
empty pockets. More of a personal choice than a professional
one (as long as there is no moral or legal issues).
>aray> However, engaging the customer in a constructive dialog to
>aray> elucidate real needs and requirements would require *professional*
>aray> preparation, which starts with a thorough understanding of the
>aray> technology. [ ... ]
Of course you *try* to educate the client, but in
the end it is still his/her decision.
>aray> For all the anecdotal evidence of losing business to less
>aray> scrupulous competitors, I can't sympathize with those who are
>aray> essentially arguing that they can't afford to be honest. Most of
>aray> the time, this is just special pleading to hide the fact that they
>aray> don't know enough about this line of work to have the courage of
>aray> their convictions, and so they dare not even try to appeal to the
>aray> client's *intelligence*.
Affording to be honest is the not same as doing what
someone has hired you to do. Which is IMHO create *his/her*
Site, using *his/her* parameters, conditions, and judgement.
>aray> As for the few who do, they're usually too good to lack for work.
Your assertion that being honest (by _your_
standards) equates to financial success opposes your
frequent degrading of Bill Gates :-)
Sometimes I wonder. Check out "www.softimage.com". Try it with
JavaScript, Java, and cookies disabled.
John Nagle
> Stephen Hueners <St...@JustSteve.com> wrote:
> >I'm beginning a project with a client who kinda expects that "good
> >sites" use frames and need material that either supports of rejects
> >this expectation.
>
> I think folks are starting to use frames sensibly at last.
Are they _possible_ to use sensibly? In some specialised
cases, yes, but their drawbacks are simply too big.
> >Are users still resistant to framed sites and chosing the non-framed
> >version when availble?
>
> Not all browsers support frames. And some that do (like lynx) make it
> painful (frames on 80x25 text aint so cool). Its not that hard to put
^^^^^
80x40 please. I could run Lynx in a 160x80 window if I
wanted... :-)
And have you seen how Lynx handles frames? Hint: it's not by
dividing its window into smaller parts.
> alt tags in your images and non framed versions. A lot of framesets can
> be translated into tables and all you lose is some of the neater scrolling
Well, while handling the ALT text is rather easy (you do it
once and forget about it) having parallell framed and
non-framed structures means a lot more work in simple
maintenance. This of course unless you generate the HTML
code in the pages, which leaves the realm of simple HTML
coding for text-processing programming.
--
Karl-Johan Norén (Noren with acute e) -- k-j-...@dsv.su.se
http://www.dsv.su.se/~k-j-nore/
- To believe people are as stupid as one believes is
stupider than one can believe
>
>For all the anecdotal evidence of losing business to less scrupulous
>competitors, I can't sympathize with those who are essentially arguing
>that they can't afford to be honest. Most of the time, this is just
>special pleading to hide the fact that they don't know enough about
>this line of work to have the courage of their convictions, and so
>they dare not even try to appeal to the client's *intelligence*. As
>for the few who do, they're usually too good to lack for work. IMHO,
>of course: I'll omit anecdotal evidence.
>
>:ar
I'm really convinced by this and your past arguments, but it's so hard to learn
proper HTML authoring with all the "kewl" sites cluttering up the internet.
Could you please post the addresses of a few commercial sites you have designed
so that I may learn from your example? TIA.
In <vwj90xc...@osfb.aber.ac.uk>,
p...@aber.ac.uk (Piercarlo Grandi) writes:
| >>> On Fri, 05 Sep 1997 03:20:30 GMT, ar...@nmds.com (Arjun Ray) said:
|
| [ ... on designers using frames to impress bosses/clients, and damn the
| users :-) ... ]
|
| aray> [ ... ] The erstwhile designers, who claim that they are basically
| aray> "forced" to "give clients what they want", are actually glossing
| aray> over the fact that professional conduct is a matter of giving
| aray> customers what they *need*.
|
| Uhm, as to this I must strongly disagree, as expressed;
Diane Wilson, writing about "solutions as requirements", and Eric
Bohlman, writing about "premature closure", have probably expressed
the essential distinction better than I have.
| it is both patronizing and dangerous.
I was not advocating that professionals should disregard a client's
expressed wants. The point is that the client should *understand* what
he has asked for. Even that is a matter of context: if a client says
"I want animated gifs", the expressed want is a perfectly lucid
request when the professional is a technician/artist, but a sign of
besotted confusion when the professional is a designer/consultant.
| I would rather say that a professional should provide a customer first
| with advice
I disagree. If advice is involved (i.e. a consultative relationship),
it should be preceded by education: the client should be in a position
to understand the advice on the basis of more than mere common sense,
which more often than not *in the cases considered here* rates to be a
mishmash of myth, superstition and "peer pressure".
| It would be a rather nasty world one in which professionals were to
| refuse service merely because they think the customer is making the
| wrong (as opposed to unethical/illegal) choice (or because of any other
| arbitrary reason -- imagine being refused dental treatment because ``a
| bit of pain is good for you''). Not as frightening as one in which
| professional did what they thought the customer needed, though.
We *are* talking about a context where a client quite often is not
only ignorant (which in itself need not be a fault) but also primed
with bogus notions (indeed, dangerously so.) I had hoped not to have
to repeat this in every sentence, but omitting the qualification
appears to have been a mistake. Sorry.
The issue is not one of refusing service on the basis of an opinion.
Nor is it one of rendering service according to a unilateral opinion
(both mischaracterisations which you've eagerly siezed upon.) The
issue is whether the client has *understood* the reasons for the
opinion.
(Aside: Your dentist analogy is flawed in mislocating the context of
the service to be rendered; if you want a better but still incomplete
medical analogy, try the case of a vet treating a client's pet. I'll
also remark that while the construction industry is a much better
source of analogies, people discussing these issues tend to take their
analogies from medicine. I wonder why.)
| aray> However, engaging the customer in a constructive dialog to
| aray> elucidate real needs and requirements would require *professional*
| aray> preparation, which starts with a thorough understanding of the
| aray> technology. [ ... ]
|
| Ah, but what if the customer rejects the advice, and thinks s/he knows
| better? Perhaps s/he _does_ know better. Hir money, hir chances.
I'm talking about education. You're talking about advice. Wrangling
with the customer about animated gifs or frames achieves nothing:
agreeing with the client on the goals and a plan to achieve them is
what this is all about. I'll quote Diane Wilson at some length here:
> In commercial software development, I've worked a *lot* with product
> requirements. It is pretty common for clients and customers to state
> requirements in terms of solutions. "I want graphics, Java, and VRML"
> is a solution. To what? If you don't know the problem you're solving,
> you aren't likely to solve the problem.
>
> When faced with solutions-as-requirements, the only way to get to the
> real problem is to start asking questions. What do you want to accomplish
> on the web? Who do you want to look at this? What do you want them to
> do with what they see? Only after you've got answers to these who, what,
> and why questions can you even see the problem, and it's only after
> understanding the problem and considering solutions that will *solve*
> that problem, that you start reaching for technology. It's also a
> *very* good idea not to start implementing that technology until you've
> walked through that proposed solution with the people who will use it:
> not the client, but the client's customers.
This is why a requirements analysis is so important. But I get the
feeling that you've set out to misunderstand everything I've said.
| aray> For all the anecdotal evidence of losing business to less
| aray> scrupulous competitors, I can't sympathize with those who are
| aray> essentially arguing that they can't afford to be honest. Most of
| aray> the time, this is just special pleading to hide the fact that they
| aray> don't know enough about this line of work to have the courage of
| aray> their convictions, and so they dare not even try to appeal to the
| aray> client's *intelligence*.
|
| Again, this sounds patronizing to me: the assumption here is that the
| customer disagrees because s/he is stupid/...;
My English must be failing me. (Either that, or you're scraping for
things to argue about.) The assumption is that a client *will*
understand unless he's incorrigibly stupid. The problem isn't the
client, but the soi-disant expert who *doesn't* know enough to make a
case convincing or no, and thus in general doesn't even try.
If I'm condescending, it's to the wannabes.
| aray> As for the few who do, they're usually too good to lack for work.
|
| The idea that competence results in commercial success is so unrealistic
| that one cannot agree with this phrase, Oh please.
Is that what I was saying? It seems my command of English isn't good
enough to convey my thoughts. So, pardon me, I'll stop here.
:ar
In <341000ac...@news.infi.net>,
G...@Old-Hippy.com (Gil Harvey) writes:
| >>>> On Fri, 05 Sep 1997 03:20:30 GMT, ar...@nmds.com (Arjun Ray) said:
| >aray> However, engaging the customer in a constructive dialog to
| >aray> elucidate real needs and requirements would require *professional*
| >aray> preparation, which starts with a thorough understanding of the
| >aray> technology. [ ... ]
|
| Of course you *try* to educate the client, but in
| the end it is still his/her decision.
Yes. However, most of the "professionals" in the business we're
talking about don't knwo enough themselves to educate anyone else.
Which is to say, most clients end up making decisions in no better
informed state than before.
(I'm aware that there is an army of wannabes who would like nothing
better than to be accepted as professionals, and to that end will make
the most of simply *claiming* that they "*try*" to educate the client.
Sorry, that won't wash. It's still a cottage industry of wannabes.)
| >aray> For all the anecdotal evidence of losing business to less
| >aray> scrupulous competitors, I can't sympathize with those who are
| >aray> essentially arguing that they can't afford to be honest. Most of
| >aray> the time, this is just special pleading to hide the fact that they
| >aray> don't know enough about this line of work to have the courage of
| >aray> their convictions, and so they dare not even try to appeal to the
| >aray> client's *intelligence*.
|
| Affording to be honest is the not same as doing what
| someone has hired you to do. Which is IMHO create *his/her*
| Site, using *his/her* parameters, conditions, and judgement.
Then you're a technician, working to specs prepared by someone else.
All the relevant *decisions* have already been made. No one asked for
your opinion, so your honesty isn't at issue. It's when *your* expert
judgement is what the client is buying that saying "yes, yes, yes" can
be dubious.
| >aray> As for the few who do, they're usually too good to lack for work.
|
| Your assertion that being honest (by _your_
| standards) equates to financial success opposes your
| frequent degrading of Bill Gates :-)
I was talking about the few who, *because* they know their stuff, do
dare to appeal to their client's intelligence.
My assertion is that the many, the vast majority, *don't*. They don't
know their stuff, and they don't address the client's requirements
(because at root, they *can't*.) I can see why you would want to
suppress that by misunderstanding what I said.
:ar
Your opinion, I do not dispute it, but also do not
accept it just because you say it.
>(I'm aware that there is an army of wannabes who would like nothing
>better than to be accepted as professionals, and to that end will make
>the most of simply *claiming* that they "*try*" to educate the client.
>Sorry, that won't wash. It's still a cottage industry of wannabes.)
I agree.... doesn't that shock the whole NG :-)
>Then you're a technician, working to specs prepared by someone else.
>All the relevant *decisions* have already been made. No one asked for
>your opinion, so your honesty isn't at issue. It's when *your* expert
>judgement is what the client is buying that saying "yes, yes, yes" can
>be dubious.
BS.... I'm talking about when (not a hypothetical
scenario) the client and I have been discussing this for
over a month. I have pointed out - say 10 'faults' with his
ideas for the site. He has acquiesed on 8, the last 2 he
will not budge on (after a month of pointing out the whys &
the possible results). NOW, what has this to do with
"courage"??
>| Your assertion that being honest (by _your_
>| standards) equates to financial success opposes your
>| frequent degrading of Bill Gates :-)
>My assertion is that the many, the vast majority, *don't*. They don't
>know their stuff, and they don't address the client's requirements
>(because at root, they *can't*.) I can see why you would want to
>suppress that by misunderstanding what I said.
I didn't "misunderstand" anything - _you_ drew the
analogy that knowledge = success. I just pointed out that
the richest man in the world _SUCCESS_ was someone you have
repeatedly downgraded. I can understand why you are trying
to confuse that! BTW, I agree with your "vast majority".
I think the "Web Designer" profession as a whole is
a lot like a classic bell curve, with those that know how to
write Sites _and_ know how to market at one end, and those
that know _all_ there is to know about HTML & _nothing_
about marketing at the other. That leaves a huge majority
somewhere in the "bubble".
In <34108b87...@news.sprynet.com>, nospam....@sprynet.com
(M. Locsin) writes:
| I'm really convinced by this and your past arguments,
Whoa. Please think again. Or, at least, be prepared to think again.
| but it's so hard to learn proper HTML authoring with all the "kewl"
| sites cluttering up the internet.
This makes me wonder what I seem to have convinced you about.
The only relevant meaning of "proper" is syntactic correctness. But
that's a more or less technical skill, and the only real problem in
that context is the general lack of editing tools automating this
aspect of document preparation. There is of course the wider issue of
understanding the HTML *document type*, both its strengths and its
limitations, but the learning process has to do with what you think
HTML -- actually, SGML -- will do for you.
| Could you please post the addresses of a few commercial sites you
| have designed so that I may learn from your example? TIA.
Now I'm really wondering... If you really want to know, my job usually
involves taking up the role of "site-killer": how to save companies
from their web sites:-) Why? Because when it comes to information
management, HTML is one piece of a whole shaping up to be far short of
a viable solution. By the time a company puts up whatever their
marketing division has been stampeded into thinking is "kewl", I
consider my mission accomplished if I've enabled the infotech guys in
the back office to assure management that the enterprise data store
would be minimally damaged were the website to be abandoned.
Stay tuned. In about two months I may have three such surface
disasters to show you.
:ar
>>#2. When an external page is loaded into the frame (site designers - page
>>killer scripts are very simple!).
>
>Forgive me, if I undestood your comment wrong (the concept of page killer
>script is not quite clear)
Sorry, I was thinking something else while typing that. I meant a FRAME
killer script. And no, you don't include it at the top of every page, just
your main one, since that is where most of your users will be entering.
>I'd rather have the author of the "let's frame everyone else" have
>a clue.
Well yes, but on the Internet, that is not bound to happen. Perhaps
Microsoft or Netscape should do something about the problem?
>One of the most boneheaded things I've ever seen done with
>frames is to have a client-pull advertisement banner with a very
>fast refresh rate. Can you say back-button hell?
Well, I understand the theory - get lots of banner hits, but it is VERY
annoying. They should just do it with JavaScript and avoid the back button
problem. Or better yet - not do it at all.
-----
Evan Jones jon...@cadvision.com
The Future of Gaming: http://www.geocities.com/TimesSquare/4941/
In <3410c53d...@news.infi.net>,
G...@Old-Hippy.com (Gil Harvey) writes:
| >Then you're a technician, working to specs prepared by someone else.
| >All the relevant *decisions* have already been made. No one asked for
| >your opinion, so your honesty isn't at issue. It's when *your* expert
| >judgement is what the client is buying that saying "yes, yes, yes" can
| >be dubious.
|
| BS.... I'm talking about when (not a hypothetical
| scenario) the client and I have been discussing this for
| over a month. I have pointed out - say 10 'faults' with his
| ideas for the site. He has acquiesed on 8, the last 2 he
| will not budge on (after a month of pointing out the whys &
| the possible results). NOW, what has this to do with
| "courage"??
The phrase was "courage of one's convictions". I'm not going to dwell
too much on this misreading of what I wrote (and besides, I've already
admitted my poor English, so the fault could have been mine.) I'll
just refer you to the excerpt from one of Diane Wilson's posts about
the importance of requirements analysis. That's the consultant's job:
to analyse and explain the alternatives. The end result should be a
functional spec, and if you're really good, a technical spec. The rest
is implementation. "Discussing with clients", in my experience, is
usually a divagatory waste of time. Put it down on paper and focus the
issues, that's my advice.
| >| Your assertion that being honest (by _your_
| >| standards) equates to financial success opposes your
| >| frequent degrading of Bill Gates :-)
|
| >My assertion is that the many, the vast majority, *don't*. They don't
| >know their stuff, and they don't address the client's requirements
| >(because at root, they *can't*.) I can see why you would want to
| >suppress that by misunderstanding what I said.
|
| I didn't "misunderstand" anything - _you_ drew the
| analogy that knowledge = success.
I did no such thing. If you'll go back to the line you quoted in your
misunderstanding, you'll find that it began "As for the few who do".
It did not begin "As for the few who are" -- which is how you seem to
think it began. Then read the preceding sentences to figure out which
few I was talking about.
:ar
OK, I'll accept that your wording may have led me to
'misread' what you actually meant. I have no problem with
consultant's job (it could be argued that a "designer" is
not a consultant, but we'll leave that for another thread),
but none of that changes the fact - the person paying the
consultant still makes the decision. "If" the consultant has
done his/her job, the decision _should_ be a sound one,
_but_ it is still the "owner/boss" making it. And if he/she
decides to ignore a portion of the consultants advice the
"consultant" can either go along or quit. Simple huh?
>I did no such thing. If you'll go back to the line you quoted in your
>misunderstanding, you'll find that it began "As for the few who do".
>It did not begin "As for the few who are" -- which is how you seem to
>think it began. Then read the preceding sentences to figure out which
>few I was talking about.
No since in pursueing this, We both know what you
were saying....
> >I'm beginning a project with a client who kinda expects that "good
> >sites" use frames and need material that either supports of rejects
> >this expectation.
> >Are users still resistant to framed sites and chosing the non-framed
> >version when availble?
> I believe you're asking the wrong question. Don't you mean to ask
> "Should I fight my client's wishes and do what I want or should I do
> what I'm being paid to do and do it the best way possible?"
You've omitted a serious alternative, here: Attempting to educate the client.
If you know what you're doing, know what the client is attempting to achieve,
(often not as simple as one might expect -- frequently, clients have only a
vague idea themselves) and you know that what he _thinks_ he needs in order to
achieve it will actually be detrimental, then present him with your case as
honestly, clearly and patiently as you can, and whenever possible provide him
with a demonstration. It works for me. I have never lost a client by
pointing out that there's a better way to achieve what he's after than the one
he had in mind.
-={lsg}=-
[Posted & E-mailed]
>
> In <yf3zpps...@sabi.demon.co.uk>,
> pier...@sabi.demon.co.uk (Piercarlo Grandi) writes:
>
> | Whether the site is more attractive to users outside the demo context is
> | rather irrelevant; they don't sign the designer's check... In effect the
> | culprits are not designers (unless they are in good faith of course),
> | but their infantile bosses/clients that set the reward in a certain way.
>
> Not necessarily. Catering to stupidity is still a matter of choice,
> even when the ultimate motivating factor is fear (of losing the
> "reward" altogether.) The erstwhile designers, who claim that they are
> basically "forced" to "give clients what they want", are actually
> glossing over the fact that professional conduct is a matter of giving
> customers what they *need*.
>
> However, engaging the customer in a constructive dialog to elucidate
> real needs and requirements would require *professional* preparation,
> which starts with a thorough understanding of the technology. The fear
> of revealing incompetence can be a motivating factor too; at any rate,
> inadequate grounding will inhibit honest appraisal of alternatives,
> and the customer need be no wiser if he weren't drawn into a dialog at
> all...
>
> | Fortunately a minority of designers do try harder and target the
> | audience, not just the boss/client, for a site. But it is pretty hard
> | going...
>
> For all the anecdotal evidence of losing business to less scrupulous
> competitors, I can't sympathize with those who are essentially arguing
> that they can't afford to be honest. Most of the time, this is just
> special pleading to hide the fact that they don't know enough about
> this line of work to have the courage of their convictions, and so
> they dare not even try to appeal to the client's *intelligence*. As
> for the few who do, they're usually too good to lack for work. IMHO,
> of course: I'll omit anecdotal evidence.
>
> :ar
Well said and worth repeating. Thanks, aj.
-={lsg}=-
Signed:
Brad Pilcher
Webmaster - Online Norcross
http://www.mindspring.com/~norcross/
"Nick Harrison" <nhar...@hotmail.com> wrote:
>The frames issue has now been floating around for some time...
>(BTW - Good thread) :-)
>At present, there is a great divide between classical design and web page
>design. The design criteria has changed and therefore must be apt for the
>web.
>Some classic design theory cannot be applied to the web, just as some web
>design cannot be applied to paper based design.
>Frames is a trickyone - I have always remembered a saying - "don't use
>frames for frames' sake" - This is a good rule.
>If frames are used, and your audience (ie/-target users) is varied, you
>will have to make sure that everyone can see what you are doing. Use
>the<noframes> tag I cry..
>I have recently been involved in a project where one of our clients wanted
>an intranet with an Oracle backend surving over 4,000,000 records. They
>spent a fortune on research and decided on using ONE browser company wide.
>- NETSCAPE 4.0.
>The data on these pages was of a financial stock nature and various types
>of LIVE data had to be viewed at one time. We decided to use frames. The
>reason being?
>they wanted multiple windows viewable, different feeds, graphs and
>comparison charts which could be placed next to each other.
>In essence they wanted to be able to fit lots of stuff into a small space
>without changing pages or having separate sections of the site.
>An efficient way of doing this was..Yes you guessed it....FRAMES.
>It is really dependent on what the pages contain. The above example was a
>good use. Regular 'brochureware' or simple pages don't justify frames - to
>start with, it puts more of a load on the server (all be it small)
>'Think before you frame'
>Rgds
>Nick.
>Piercarlo Grandi <pier...@sabi.demon.co.uk> wrote in article
><yf3yb5c...@sabi.demon.co.uk>...
>> >>> On 4 Sep 1997 00:16:38 GMT, c.c....@43.usenet.us.com (Rahul Dhesi)
>said:
>>
>> c.c.eiftj> In <340c1523...@news.wi.centuryinter.net>
>St...@JustSteve.com
>> c.c.eiftj> (Stephen Hueners) writes:
>>
>> >> Are users still resistant to framed sites and chosing the non-framed
>> >> version when availble?
>>
>> c.c.eiftj> The problems is not with frames per se but with (a) the
>> c.c.eiftj> indiscriminate and sloppy use of them
>>
>> Well, the problem is indeed with frames as defined by Netscape: one
>> could make an argument that some sort of ``galley'' like presentation
>> device might help, but the particular sort defined by Netscape is very
>> badly designed; a better frame-like facility might have been more
>> defensible.
>>
>> c.c.eiftj> and (b) that frames-based sites usually present something
>> c.c.eiftj> meaningless when viewed with Lynx.
>>
>> Well, I find the way Lynx deal with frames fairly reasonable; better
>> than no frame support at all.
>>
>> c.c.eiftj> I most frames-based sites annoying.
>>
>> Ah for sure.
>>
>> c.c.eiftj> In theory it's possible to create a frames-based site that
>> c.c.eiftj> works better than without frames. I haven't seen anybody do
>> c.c.eiftj> it yet.
>>
>> If there had been a better definition of frames it might have
>> happened...
>>
"causa libertas" - for the sake of freedom
On 3 Sep 1997 09:58:45 GMT, p11...@cc.tut.fi (Tero Paananen) wrote:
>>#2. When an external page is loaded into the frame (site designers - page
>>killer scripts are very simple!).
>
>Forgive me, if I undestood your comment wrong (the concept of page killer
>script is not quite clear)
Sorry, I was thinking something else while typing that. I meant a FRAME
killer script. And no, you don't include it at the top of every page, just
your main one, since that is where most of your users will be entering.
Or so one would hope. But just the other day I submitted a plausible query
to Excite to see if it would turn up one of my sites, and sure enough it did:
just not the main entry point. What inspired their robot to index the German-
language calendar of forthcoming events I will never know. |:?
--
Chris Gray
(^_^)/~~
In article <34108c47....@38.8.213.2>, ar...@nmds.com (Arjun Ray) writes:
|> Diane Wilson, writing about "solutions as requirements", and Eric
|> Bohlman, writing about "premature closure", have probably expressed
|> the essential distinction better than I have.
<snip>
|> I'm talking about education. You're talking about advice. Wrangling
|> with the customer about animated gifs or frames achieves nothing:
|> agreeing with the client on the goals and a plan to achieve them is
|> what this is all about. I'll quote Diane Wilson at some length here:
Wow! Quotes from a seven-month-old post that I'd forgotten about!
Thank you for the compliment, and thank you also for refreshing my
memory on this. I'm writing a design column locally now, and the
post you quoted will do nicely.
But to get down to the serious side of this post, I went looking to
see if I'd ridden this particular horse in anything I've put on the web,
and it looks like I haven't. However, my search did remind me that I
have some articles that are both useful and relevant in this context.
They were written before the web (or at least before my awareness of it),
so they're placed on my site in a "software" section where a lot of web
designers might not look.
If you are interested in issues of understanding requirements and ways
to turn requirements into design, I highly (and immodestly) recommend:
http://www.lava.net/~dewilson/diane/software/cycle.html
http://www.lava.net/~dewilson/diane/software/prototype.html
http://www.lava.net/~dewilson/diane/software/metaphor.html
http://www.lava.net/~dewilson/diane/software/humane.html
s/viewed with Lynx/gathered by search engines/
Lynx is not important (except for testing what search engines might
see), but search engines are important.
--
Hubert Partl pa...@mail.boku.ac.at
ZID BOKU Wien http://www.boku.ac.at/
~~~~~~~an~der~schoenen~blauen~Donau~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Lynx is not important
There's a class of readers who will disagree strongly with that, even if
they are a minority.
(except for testing what search engines might
> see), but search engines are important.
Sure thing.
I used to be against frames (and my site doesn't have them), but I find that a
site which uses frames as an *additional* method of navigation can be quite
attractive. A nice example is <http://www.be.com>. What I absolutely hate is a
site that puts external pages into it's own frameset. And I would prefer to
have the equivalent of the 'back button' on every page - I think that
navigation *within* a framed site is a lot more difficult.
If your client really has that many levels that he needs frames, ok. If you can
design the site to get away without, even better.
Catja
<http://www.aber.ac.uk/~cap96>
I was reasonably certain that eventually someone would provide an
example of Diane Wilson's "solutions-as-requirements" bogosity without
even knowing it. Tada.
In <01bcbd50$e7970a00$8c07...@voyager2.strand.iii.co.uk>, "Nick
Harrison" <nhar...@hotmail.com> writes:
| I have recently been involved in a project where one of our clients wanted
| an intranet with an Oracle backend surving over 4,000,000 records.
Exactly what problem was "an intranet with an Oracle backend" supposed
to solve? In other words, why did the client want an i-w-a-O-b? You've
stated two solutions (intranet, Oracle) without specifying a problem.
| They spent a fortune on research and decided on using ONE browser
| company wide. - NETSCAPE 4.0.
A third solution (specific Web browser), still no problem statement.
Why did they need a browser? What problems were solved by it?
| The data on these pages was of a financial stock nature and various types
| of LIVE data had to be viewed at one time.
LIVE data? To be delivered over HTTP? Who was smoking what to think
this could be a requirement?
| We decided to use frames. The reason being? they wanted multiple windows
| viewable, different feeds, graphs and comparison charts which could be
| placed next to each other.
Slow down, please. The requirement was the simultaneous viewability of
several types of information: graphs, charts, and presumably text
(e.g. headlines, news flashes and the like.) Not just that, but LIVE
data, to use your phrase: which suggests close-to-real-time updates,
as are available from (at least)112Kb serial-line/satellite feeds such
as PCQuote, Knight-Ridder, Comstock, etc. Complete kitchen-sink GUI
interfaces to some of these, with tie-ins to DOT systems for the
really fancy, have been available for years.
Frames in a web browser? Somebody apparently "wanted" a square wheel
reinvented.
| In essence they wanted to be able to fit lots of stuff into a small space
| without changing pages or having separate sections of the site.
Changing *what* pages? What do "separate sections" (whatever that
might mean when URL-space is *flat*) have to do with fitting "lots of
stuff into a small space"?
In fact, none of this makes much sense any more. It began by sounding
vaguely like a close-to-real-time information system for a trader or
market analyst. And then it became something to do with "pages" not
"changing" in a web browser.
| An efficient way of doing this was..Yes you guessed it....FRAMES.
Frames are an efficient way to fit lots of stuff into a small space?
An efficient way to avoid "separate sections"?
| It is really dependent on what the pages contain. The above example
| was a good use.
The above example was if anything incredible. It sounds like some
people spent a lot of money "researching" how to talk themselves into
doing what they had already decided in advance would be "kinda kewl".
Sorry, please try again.
At present, there is a great divide between classical design and web page
design. The design criteria has changed and therefore must be apt for the
web.
Some classic design theory cannot be applied to the web, just as some web
design cannot be applied to paper based design.
Regarding the second sentence: pardon? Regarding the first and third:
to avoid a flamefest, I will refrain from responding until Nick tells us what
he means by "classic design theory".
--
Chris Gray
(^_^)/~~
In article <3415fe7c....@38.8.213.2>, ar...@nmds.com (Arjun Ray) writes:
|>
|> I was reasonably certain that eventually someone would provide an
|> example of Diane Wilson's "solutions-as-requirements" bogosity without
|> even knowing it. Tada.
|>
|> In <01bcbd50$e7970a00$8c07...@voyager2.strand.iii.co.uk>, "Nick
|> Harrison" <nhar...@hotmail.com> writes:
|>
|> | I have recently been involved in a project where one of our clients wanted
|> | an intranet with an Oracle backend surving over 4,000,000 records.
|>
|> Exactly what problem was "an intranet with an Oracle backend" supposed
|> to solve? In other words, why did the client want an i-w-a-O-b? You've
|> stated two solutions (intranet, Oracle) without specifying a problem.
|>
|> | They spent a fortune on research and decided on using ONE browser
|> | company wide. - NETSCAPE 4.0.
|>
|> A third solution (specific Web browser), still no problem statement.
|> Why did they need a browser? What problems were solved by it?
More than that.... WHO will be using this? WHAT will they do with the
information? WHAT are the timeliness requirements: 10 minutes? 24 hours?
Ever hear of task analysis? Ever hear of separating the problem domain
from the solution domain? The problem domain consists of users, data,
tasks, and needs. The problem domain generally does not contain
computers unless you are a network or operating systems engineer.
I can understand that the Oracle data base may already exist, and that
the 4,000,000 records may be current data rather than an estimate of
future usage. But this is still part of the solution domain. It may
well be a constraint on possible solutions. But I don't see the
evidence of any effort to understand the *PROBLEM.* It is not possible
to solve a problem that you don't understand. You may accidentally solve
part of the problem, but that is not a professional approach.
|> | In essence they wanted to be able to fit lots of stuff into a small space
|> | without changing pages or having separate sections of the site.
This is a rather muddled statement.... "Without changing pages."
What does that mean? Are you aware that a frameset consists of
multiple pages? Are there existing pages which "can't be changed?"
If so, why not? This isn't just bellyaching; it's identifying and
understanding constraints.
|> | An efficient way of doing this was..Yes you guessed it....FRAMES.
|>
|> Frames are an efficient way to fit lots of stuff into a small space?
|> An efficient way to avoid "separate sections"?
There is one thing that frames are not, and that is EFFICIENT. They
take more screen real-estate than other solutions. They take more
time to load. These are defects that can NOT be overcome, and any
design that uses frames has to provide something that compensates
for these. What in your design compensates for the shortcomings of
frames?
The first example I've seen of Netscape's layers was pretty frightening
(NS's current home page), but even that looks like a better approach
than frames; it makes better use of space and gives the user some
control over what takes priority on the glass, selecting from information
that is already delivered rather than waiting for more pages.
Frames? Efficient? I don't know whether to laugh or cry. I think today
I need the laugh.
|> | It is really dependent on what the pages contain. The above example
|> | was a good use.
|>
|> The above example was if anything incredible. It sounds like some
|> people spent a lot of money "researching" how to talk themselves into
|> doing what they had already decided in advance would be "kinda kewl".
|>
|> Sorry, please try again.
And again, and again. Iterate, iterate, iterate. On your understanding
of the problem space. On your proposed solutions. On the technical
requirements and limitations. ON THE USABILITY OF YOUR DESIGN, which
needs to be done before you start implementation. Make bloody certain
that the evaluations inherent in an iterative approach include real
users, not just representatives of the client.
If you're not asking hard questions, if you are not critically examining
underlying issues, the prior assumptions, or the suitability of proposed
solutions, then you are not doing your job. Whatever you are doing,
you cannot call it design.
Web design has both technological limitations and opportunities.
The fact that it takes time to download a page, and that that time
increases with page complexity, has design implications. Paper and TV
aren't like that.
John Nagle
In article <01bcbd50$e7970a00$8c07...@voyager2.strand.iii.co.uk>,
"Nick Harrison" <nhar...@hotmail.com> wrote:
> At present, there is a great divide between classical design and web page
> design. The design criteria has changed and therefore must be apt for the
> web.
Well, that's certainly true, although I don't think we mean this in
the same way. Most of the rules for designing on paper don't apply
to WWW design, and due to the platform-independence, you can't even
use GUI design guidelines if they're specifically for, say, Windows
or the Mac.
> I have recently been involved in a project where one of our clients wanted
> an intranet with an Oracle backend surving over 4,000,000 records. They
> spent a fortune on research and decided on using ONE browser company wide.
> - NETSCAPE 4.0.
But what does that browser have to do with the DBMS and the
clients doing the query? Surely there are better ways to handle
such a large system than writing an HTML "front-end"? The limitations
you encounter here are countless, even when you choose one specific
browser and treat that as the only client that can do queries on
the DB.
- --
E-mail: gala...@htmlhelp.com .................... PGP Key: 512/63B0E665
Maintainer of WDG's HTML reference: <http://www.htmlhelp.com/reference/>
-----END PGP SIGNED MESSAGE-----
However, we are looking at cheaper, faster bandwidth in the next few years
with cable modems and the like. Will designers then get sloppy and design
bandwidth-clogging sites? Will the technology they use encourage it (e.g.,
just how much bandwidth does an "average" Dynamic HTML page take anyway?)
An analogy I see is our own cheaper, faster PCs. Fifteen years ago, memory,
hard drives and CPUs were expensive, slow and limited. Programs were
optimised to wring every byte out of a 64k RAM and save space on a 50meg
hard drive.
You don't get the same kind of leanness today with dirt-cheap RAM and hard
drives. You get programs bloated with features and add-ons you'll probably
never use in the first place.
I see the same for the next generation of sites adding kinds of animation
and multimedia because the designers know the end-user's pipe will be able
to handle it.
RRT
--
________________________________________________________________________
rolandthomas at earthlink dot net|http://www.earthlink.net/~rolandthomas
"Will work for food for thought. On second thought, just give me food."
>In article <01bcbd50$e7970a00$8c07...@voyager2.strand.iii.co.uk>
> "Nick Harrison" <nhar...@hotmail.com> writes:
> At present, there is a great divide between classical design and web page
> design. The design criteria has changed and therefore must be apt for the
> web.
> Some classic design theory cannot be applied to the web, just as some web
> design cannot be applied to paper based design.
>Regarding the second sentence: pardon? Regarding the first and third:
>to avoid a flamefest, I will refrain from responding until Nick tells us what
>he means by "classic design theory".
My assumption was, when I first read and when I read it this time
around, that "classic" or "classical" design theory meant standards of
composition that have been applied for centuries, beginning at least
with the Golden Mean.
Of course, assumptions are often wrong. . .
--
Ralph Hickok
Author "The Pro Football Fan's Companion"
Macmillan, 1995 (Paper--Green & Gold Cover)
Hickok's Sports History: http://www.ultranet.com/~rhickok/
>>However, we are looking at cheaper, faster bandwidth in the next few years
>>with cable modems and the like. Will designers then get sloppy and design
>>bandwidth-clogging sites? Will the technology they use encourage it (e.g.,
>>just how much bandwidth does an "average" Dynamic HTML page take anyway?)
>>
No, designers will not get sloppy. As I see it, we have limitations to
data transfer because of the telephone infrastructure which we will have
to live with it for a long, long time. Personally, I'm writing leaner and
meaner HTML--have been for a long time. YMMV
Email: sar...@sirius.com
URLs: an art studio:
http://www.art.net/Studios/Visual/Sarabel/sarabel.html
where to see the whooping crane:
http://www.sirius.com/~sarabel/Vacation.html
an old nursery rhyme:
http://www.sirius.com/~sarabel/gingham.html
> Gotta agree with this guy complete. Is a great thread and good
> discussion. The problem with frames is that Netscape released it as a
> ground breaking new web design system.
They did? I thought it was a competitor-breaking old paradigm,
warmed-over so that they could avoid having to implement the more
perceptive proposals that were already on the table.
> That only went as far as web
> design and not the true practicality of it. That was the problem.
That was anOTHER problem: the design was not only ill-conceived,
in the context of the WWW, but also poorly implemented.
It seems that I agree with you on the principles, I'm just
concerned about how you're addressing the details...
> Problem #2? Simple, people saw frames and said - "Hey, that looks
> pretty neat. I can do some cool stuff with that!" and they proceeded
> to act without thinking.
I haven't seen much evidence of the big-two trying to educate web
authors. Rather, they seem to have said hey, you 1980's DTP fans,
we know you're not ready for reusable content yet, so we're going to
wreck the original intentions for reusable content, and give you
what you wanted, DTP on the WWW. The only problem is, it doesn't
work, and causes all that "download foo browser now" nonsense.
[please, don't hang the entire previous discussion onto the end of
your postings. You're evidently a newcomer to usenet: there are some
splendid new-user FAQs on news.announce.newusers which you owe it to
yourself to read and take on board, unless you enjoy flamefests]
--
"Any sufficiently advanced cluelessness is indistinguishable
from humor" (I'm not sure who said it first, but how true).
| The problem with frames is that Netscape released it as a ground
| breaking new web design system.
The problem with frames is that there were enough people not to know
any better than to simply swallow hoopla and parrot the hype that it
was ground-breaking.
| That only went as far as web design and not the true practicality of
| it. That was the problem. Even when facing obvious implementation
| problems with the original frame design, Netscape went ahead with
| frames as-is and made not major changes.
Um, no. It was not a matter of "implementation problems with the
original design". It was a matter of conceptual incompetence in the
original "design" (if such a word could grace the concoction), and of
studied disregard for both advance warnings and better ideas in the
name of "Not Invented Here" and larger hat sizes.
| In response, W3C is trying to avoid such pitfalls when it closes the
| book on frames.
The W3C is a consortium, in which Netscape is a member. As such, the
W3C is constrained by what its members have (or lack) the wit to come
up with. It's comforting to believe -- as Netscape apologists do --
that no idea is harebrained enough that the W3C can't find a palatable
reworking.
| The basic rule of thumb is this - use frames when you know your users
| can burn the bandwidth and when you know you can implement them in a
| clean and sharp design way that can only be achieved with frames.
Looks like two "rules" here... There's not much to be said for the
first (a platitude on bandwidth), but the second is too comfortably
tautological:
> The basic rule of thumb is: use frames when you know you can implement
> them in a clean and sharp design that can only be achieved with frames.
That's like saying: use trucks when you know you can drive them over
roads that can only be negotiated with trucks. Not much use as a rule
of thumb, sorry.
Analogies aside, this "rule of thumb" begs the question of *what*
"clean and sharp design" can only be achieved by frames. Would you
care to offer some real criteria?
In article <5v7agv$vv$1...@decius.ultra.net> rhi...@ma.ultranet.com writes:
Chris Gray <gr...@se.bel.alcatel.be> wrote:
>In article <01bcbd50$e7970a00$8c07...@voyager2.strand.iii.co.uk>
> "Nick Harrison" <nhar...@hotmail.com> writes:
> At present, there is a great divide between classical design and web page
> design. The design criteria has changed and therefore must be apt for the
> web.
> Some classic design theory cannot be applied to the web, just as some web
> design cannot be applied to paper based design.
>Regarding the second sentence: pardon? Regarding the first and third:
>to avoid a flamefest, I will refrain from responding until Nick tells us what
>he means by "classic design theory".
My assumption was, when I first read and when I read it this time
around, that "classic" or "classical" design theory meant standards of
composition that have been applied for centuries, beginning at least
with the Golden Mean.
Hm, I never even considered that possibility: I was wondering whether he
was talking about design for the printed page, design of useful objects,
or maybe human-computer interface design. And even then I wasn't sure
what he meant by "classical": not in the way that I know what is meant
by "classical control theory", "classical optics", or "classical harmony".
Of course for many definitions Nick's statement will be obviously true:
for example you cannot apply rules of visual composition and proportion
when you don't know the shape of the canvas (or even whether there *is*
one). But I assume that Nick wasn't just trying to set up some imaginary
thesis just to have the satisfaction of disproving it: that would be a
so-called "straw man" argument, and we don't do that around here.
--
Chris Gray
(^_^)/~~
[Posted & E-mailed]
>However, we are looking at cheaper, faster bandwidth in the next few years
>with cable modems and the like.
{sigh} I hate to keep repeating this, but it seems that the message has yet
to get through. This is not the US Web, nor even the North American Web. I
sincerely have my doubts that as several hundred million Chinese get access
to the Web they will have access to "cable modems and the like". And please
recognize that my use of China here is simply by way of example. A good deal
of Eastern Europe will likely find itself in similar circumstances as they
too begin to access the Web in increasing numbers. We are discussing the
WORLD WIDE Web and when projecting what "we are looking at" we need to bear
in mind just who "we" includes -- and to repeat that ain't just Norte
Americanos. This is not to belittle the effect that technological
developments in the US/Canada, Western Europe and Japan, by way of example,
will have on those markets. It is, instead, an attempt to keep the focus on
the fact that the Web is not the North American Web despite the fact that all
too many mistakenly continue to treat it as such. By way of a single
example, I've a client, the Hopi Cultural Center in Northern Arizona, who
constantly gets messages FROM ALL OVER THE WORLD requesting information about
accomodations and events.
>Will designers then get sloppy and design bandwidth-clogging sites?. . .
If they do, they will pay the price.
> I see the same for the next generation of sites adding kinds of animation
> and multimedia because the designers know the end-user's pipe will be
> able to handle it.
Which "end-user" would those be? The ones in Norway? In Taiwan? In Japan?
In China? In Africa? In Mexico or in Central/South America?
-={lsg}=-
RRT> == Roland R Thomas <roland...@earthlink.net>
RRT> However, we are looking at cheaper, faster bandwidth in the next
RRT> few years with cable modems and the like. Will designers then get
RRT> sloppy and design bandwidth-clogging sites?
If they do, they will reap the dubious rewards.
As I posted on June 19th:
================================================================
I will argue that the advent of 56K modems may well cause the images-off
movement to grow, not shrink.
Why? It's simple.
The "last mile" bandwidth is *not* the only thing slowing users down.
Server network congestion, high server loads, backbone and interchange
congestion (seen MAE-East lately?), and the fact that end-to-end *latency*
is more important in some cases than bandwidth (and latency is not falling
the way last-mile bandwidth is growing) can all conspire to make delays
worse--and congestion will *grow* as more people get on line and have
faster connections. (A 28.8 modem won't swamp a T1; 100 "x2" modems will.)
As more people continue get on line (even if the exponential growth slows
down), backbone bandwidth and server capacity are likely to fall behind
the curve, exacerbated by "flash crowd" effects a la Niven for the most
popular pages (tried getting on cnn.com during a major news event?).
Turning off image loading is a very quick way to speed up page loading,
because the additional connections are hurt by end-to-end latency, server
load ("waiting for reply..."), and TCP's slow start algorithms. Making
one connection to pull down 10K of text is much faster than making four
connections, three of which are pulling down 2K each...
================================================================
Note that fourth paragraph; as it turns out, traffic on the Internet has
recently increased markedly due to the death of Princess Diana.
--
Christopher Davis <c...@kei.com> <URL: http://www.kei.com/homepages/ckd/ >
Geographic locations in DNS! <URL: http://www.kei.com/homepages/ckd/dns-loc/ >
Arjun Ray wrote:
> Analogies aside, this "rule of thumb" begs the question of *what*
> "clean and sharp design" can only be achieved by frames. Would you
> care to offer some real criteria?
Sorry to intrude if this is a private flame war, but:
It is a truism of UI design that constantly available navigation
information is a good thing. One way to do this is with a panelled
window, one part with navigation and/or command information, the other
with content. The odds are good that everyone reading this message
on-line seems some kind of window frame with buttons around it.
Frames are a way of doing this, not the only way.
--
Henry Troup h...@nortel.ca Nortel Public Data Networks
int *ceci; // ceci n'est pas une integer
In article <3417F6...@nortel.ca>, Henry Troup <h...@nortel.ca> writes:
|> Arjun Ray wrote:
|>
|> > Analogies aside, this "rule of thumb" begs the question of *what*
|> > "clean and sharp design" can only be achieved by frames. Would you
|> > care to offer some real criteria?
|>
|> Sorry to intrude if this is a private flame war, but:
|>
|> It is a truism of UI design that constantly available navigation
|> information is a good thing. One way to do this is with a panelled
|> window, one part with navigation and/or command information, the other
|> with content. The odds are good that everyone reading this message
|> on-line seems some kind of window frame with buttons around it.
Yup, but the bulk of those window frames were designed to minimize the
screen real estate that those buttons take away from content. That's
very hard to do with frames, especially considering platform variances
and user customization.
|> Frames are a way of doing this, not the only way.
And not very reliable, not very predictable, not very efficient in load
time....
Beware of truisms. Most of them have exceptions.
> It is a truism of UI design that constantly available navigation
> information is a good thing. One way to do this is with a panelled
> window, one part with navigation and/or command information, the other
> with content. The odds are good that everyone reading this message
> on-line seems some kind of window frame with buttons around it.
>
Sorry to intrude, but I'm not seeing a window frame with buttons around
it. I'm reading news through a UNIX shell using emacs. No buttons, no
frame, no mouse, just content.
"Constantly available navigation information" that requires frames is not
"constantly available navigation information."
--
Phil Stripling |Sorry for the inconvenience of the
The Civilized Explorer |munged reply, but you know what.
http://www.cieux.com/~philip/ |you need to remove.
On 11 Sep 1997, Diane Wilson wrote:
> |> Frames are a way of doing this, not the only way.
>
> And not very reliable, not very predictable, not very efficient in load
> time....
>
> Beware of truisms. Most of them have exceptions.
Good point. Now let me tell you a tale. (Btw I _had_ noted the earlier
discussion of a site that provides a proper fallback, and all due
praise for that.)
I asked altavista to search for the phrase "uses frames but".
10,000 matches, and you can guess what they said. This stupid message
is presumably built-in to a certain authoring tool: what took me
aback more, though, was that many of the sites said it twice or even
three times, and had no other message whatever for supporters of HTML
standards. Consider this prize example:
Master Frameset
FRAME: tstar
FRAME: sponsor
FRAME: help
FRAME: marquee
FRAME: main
This web page uses frames, but your browser doesn't support them.
This web page uses frames, but your browser doesn't support them.
This web page uses frames, but your browser doesn't support them.
The indexer doesn't have the slightest clue what this company is called,
(its best guess would have to be Master Frameset, inc.?), nor what it
does nor anything. When I finally reached one of their pages that had
some content, I tried feeding a bit of that content to altavista to find
out whether it had indexed that page. It hadn't.
Our Mission
It is our goal to provide some of the technology necessary to make the
Internet and the World Wide Web truly useful for the general public.
Sorry guys, your mission seems to have got lost in hyperspace. Oddly
enough, you only had two competitors for the title of Master Frameset.
Let's learn from these mistakes, people...
>It is a truism of UI design that constantly available navigation
>information is a good thing. One way to do this is with a panelled
>window, one part with navigation and/or command information, the other
>with content. The odds are good that everyone reading this message
>on-line seems some kind of window frame with buttons around it.
Actually, the odds of that approach zero very closely. I would be willing
to bet money that at least one regular reader of
c.i.w.a.[misc/site-design/html] browses with Lynx or some other
non-window-oriented browser.
(And I'm a Windows 3.1/Netscape 3 user.)
However, I generally agree with the point you were making. :)
--Kai MacTane.
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GO/U d-- s+:- a- C++ UL(+)>+++>$ P+>$ E- J+>+++>$ W++>$ N+ K
w++(--)@ PS+(+++) PE Y+ t(+) 5++ R+ tv-(--) b+++(+) DI++ D+ G
e(++) h r++(+) y++(+++++)(*)
------END GEEK CODE BLOCK------
In article <w3qpvqf...@gilligan.tsoft.net>, Phil Stripling <phi...@what.civex.com> writes:
|>
|> "Constantly available navigation information" that requires frames is not
|> "constantly available navigation information."
I like this. Kind of like "Click here if you are not using a mouse."
> Or the notorious "No keyboard connected. Hit any key to continue". :)
If I recall correctly:
"Keyboard Error: keyboard missing. Press F1 to continue."
>:)
--
"DTD did the job on me, now I am a real sickie. Guess I gotta break the news,
that I got no site to loose. All the geeks are in love with me, I'm a
twenty-something lobotomy... " - with apologies to 'The Ramones'.
In article <w3qpvqf...@gilligan.tsoft.net>, Phil Stripling <phi...@what.civex.com> writes:
|>
|> "Constantly available navigation information" that requires frames is not
|> "constantly available navigation information."
I like this. Kind of like "Click here if you are not using a mouse."
Or the notorious "No keyboard connected. Hit any key to continue". :)
--
Chris Gray
(^_^)/~~
In article <3417F6...@nortel.ca>, Henry Troup <h...@nortel.ca> wrote:
>
>It is a truism of UI design that constantly available navigation
>information is a good thing. One way to do this is with a panelled
>window, one part with navigation and/or command information, the other
>with content. The odds are good that everyone reading this message
>on-line seems some kind of window frame with buttons around it.
>
NOT. I don't see any window frame with buttons around it. All I see is
content.
--
dmo...@efn.org _/_/_/_/_/ David W. Morgan \_\_\_\_\_ Honolulu Hawaii
http://www.efn.org/~dmorgan/congress.html - Congressional E-Mail Addresses
http://www.efn.org/~dmorgan/worst.html ------- Worst Web Pages of Congress
http://www.efn.org/~dmorgan/access.html - Free Internet access from Hawaii
>[...]
> Now style-sheets are becoming much
>more powerful and will continue. This will probably limit the times
>in which frames are really the only good alternative. Personally, I
>think the real wave of the future in design is cascading style-sheets.
Where should I look for info about style-sheets?
And... well, my site is frame - enabled (but there is the no-frame side...).
May someone let me know his comment about I used them?
I'll really appreciate this.
Bye and thanks, Andrea
Andrea Penna - Ferrara-Italy
ape...@estense.global.it
Manuali JS, PGP, HTML, lista web gratuiti, OS/2:
http://www.aspide.it/freeweb/online
Using OS/2 Warp 4.0
: See it at http://www.munisource.org/apef
: I think it is an acceptable, jusifiable use of frames to allow flip-flopping
: between the two versions. (It is unfinished by the way...NOFRAMES problem
: hasn't been tackled)
: Comments?
I don't think it's justifiable. For the majority of users, half of
what's displayed on the screen at any given time is going to be useless.
Most of the users are going to want to read the text in either French
*or* English, not in French *and* English at the same time. This strikes
me as a classic example of a site designed to please the client's
officials rather than the client's constituents. (BTW, why do I have
this hunch that once the decision to use frames was made, a substantial
amount of time was devoted to the issue of which language should be on
the left (or top) and which should be on the right (or bottom)?)
For all practical purposes, you already *do* have parallel sites, since
the frames model requires that the contents of each frame be a separate
HTML document. I don't see what you've gained by making them both
display at the same time. Well, I guess you've gained the ability for
someone to compare the English and French text and make sure that they
say the same thing; somehow, though, I doubt that's the main goal of
people who come to the site.
[I've narrowed followups]
On 14 Sep 1997, Michael Lindsay wrote:
> I had a request from a Canadian govt. agency to design a site in both
> official languages. The information and structure is identical in both
> languages.
> See it at http://www.munisource.org/apef
> I think it is an acceptable, jusifiable use of frames
Why? You've already said that the information is the same. One
presumes that each reader has a preferred language. So for the majority
of readers you're throwing away part of their real-estate in order to
offer links to information in a language that they don't want to read.
For the few who want to test the accuracy of the translation, they need
only open the other language in a separate window, something that
graphical browsers can do easily. Whereas your frames design doesn't
help them, and takes away real estate that they could use for that
second window.
Perhaps if you could describe the kind of reader who you think would
benefit from having both French and English menus on their page at the
same time, we might understand better what it's meant to achieve. Is
this page perhaps supposed to be on permanent view at a public library
or kiosk, for example?
> between the two versions. (It is unfinished by the way...NOFRAMES problem
> hasn't been tackled)
Why not? If you're going to use frames then that's an integral part of
the design. I would have wanted to work out (if I wanted to use frames,
which I don't) how to have the content appear in both contexts, before
starting to actually author anything. Once you've built the documents
for the framed site, you've given yourself extra work if you don't
already have the mechanism for getting that content into the noframes
version. And you're giving yourself (or your customer, what's worse) a
double maintenance job if you don't do that right.
Thanks for the demonstration.
well...I definitely agree with the other comments here.
the client's decision is a bad one. they should not be wasting screen real
estate for any reason.
there is absolutely NO justification for offering English and French side
by side.
i would try hard to explain this to them
good luck
jonathan
In article <5vfhjd$kpl$1...@ragnarok.hfx.hookup.net>, mlin...@auracom.com
(Michael Lindsay) wrote:
> I had a request from a Canadian govt. agency to design a site in both
> official languages. The information and structure is identical in both
> languages. They did NOT want two parallel sites....English this way, French
> thattaway which is mostly the practice in Can. govt. sites. So I decided on a
> framed layout.
>
> See it at http://www.munisource.org/apef
>
> I think it is an acceptable, jusifiable use of frames to allow flip-flopping
> between the two versions. (It is unfinished by the way...NOFRAMES problem
> hasn't been tackled)
> Comments?
--
Jonathan Segal
jse...@panix.com
>Michael Lindsay (mlin...@auracom.com) wrote:
>: I had a request from a Canadian govt. agency to design a site in both
>: official languages. The information and structure is identical in both
>: languages. They did NOT want two parallel sites....English this way, French
>: thattaway which is mostly the practice in Can. govt. sites. So I decided on a
>: framed layout.
>
>: See it at http://www.munisource.org/apef
>
>why do I have
>this hunch that once the decision to use frames was made, a substantial
>amount of time was devoted to the issue of which language should be on
>the left (or top) and which should be on the right (or bottom)?
This kind of decision is, AFAICT, always an issue in a multilingual
site regardless of frames use. Without frames, you still have to
decide whether the home page should be completely bilingual, and if so
which language should be "first" (usually on the left or on top when
rendered visually). I can't see a solution that wouldn't involve one
language being in a position where it could be construed as less
important than another. (Even with ACCEPT_LANGUAGE you would have to
account for browsers that don't send this header, or don't send an
appropriate language. Hopefully in the long-term ACCEPT_LANGUAGE will
be utilized more fully.)
Canadian government sites (e.g., <http://canada.gc.ca/>), like most
information produced by the Canadian government, tend to use English
prior to French (likely because English is more widely used). I can't
help but think that sensitive francophones might feel shafted by
always being "the afterthought" on bilingual pages.
Liam Quinn
=============== http://www.htmlhelp.com/%7Eliam/ ===============
Web Design Group Enhanced Designs, Web Site Development
http://www.htmlhelp.com/ http://enhanced-designs.com/
This one is "better" for the frame-haters. Does it conserve real
eastate? Is the Eng/French flip-flopping easy (Yes, it IS important to
the clients for reasons mentioned before....for the other readers, if
there are any, I doubt it. Mainly it must be "seen" to be available
without too much trouble.)
Again, work in progress. Awaiting the official francais which has to be
sent to the appropriate agency. They don't trust mon francais.
Will the new Scots govt. sites also be bilingual.
You can use mine as templates if you want.
Politics
>
>Perhaps if you could describe the kind of reader who you think would
>benefit from having both French and English menus on their page at the
>same time,
Politicians
>
>Why not? If you're going to use frames then that's an integral part of
>the design. I would have wanted to work out (if I wanted to use frames,
>which I don't) how to have the content appear in both contexts, before
>starting to actually author anything. Once you've built the documents
>for the framed site, you've given yourself extra work
It's OK, I'm an Ulster-Scots presbyterian who sees work as an an entree to
Heaven
>Thanks for the demonstration.
>
You're welcom young man.
Congrats on the Scots referendum....another burden on the tax revnue real
estate?
[Posted and e-mailed]
>OK here's another example tackling the same bilingual proble:
>
>http://www.munisource.org/cmp
>
>This one is "better" for the frame-haters. Does it conserve real
>eastate?
It certainly is better than the frames one, but for real estate
conservation it'd be nice to have a unilingual opening page. Having
two languages when I'd prefer to read one is a distraction. This
problem is addressed in HTTP/1.1 [1] by the ACCEPT_LANGUAGE header.
Using this header, you could give anglophones an English welcome page,
francophones a French welcome page, and allophones (or those whose
browsers don't send ACCEPT_LANGUAGE) the bilingual page that you
currently use. (Each unilingual page should still have a link to the
other language, for those with misconfigured browsers.)
Servers such as Apache make using ACCEPT_LANGUAGE quite simple (see
<http://www.apache.org/docs/content-negotiation.html>).
[1] http://www.w3.org/Protocols/rfc2068/rfc2068
---------------------
| English | cibarA |
| or | ro |
| French | werbeH |
-------------------- ...? <G>
--
Colin Reynolds
> hasn't been tackled)
> Comments?
I think the majority of respondents didn't bother to visit the site to see
what you were actually doing, and instead commented on one person's
interpretation of your words.
The site is an intelligent response to a very sensitive situation.
For the edification of those who do not follow the politics of this polite
little backwater called Canada (the "retarded giant on your doorstep,"
according to National Lampoon), any perception that one is playing
favourite between French and English can cause problems for a government
agency. The equal ease of access to navigational aids in either official
language constitutes a strong statement of the respect which we feel for
what in other countries to the south of us might be considered mostly a
nuisance -- and certainly un-patriotic.
As to the no-frames issue. You might want to consider server-side includes
combined with a scripting capability to generate bilingual documents on the
fly. Email me at webm...@moodindigo.com if you'd like more detail.
--
Dan McGarry
http://www.moodindigo.com/
Dan McGarry wrote:
> I think the majority of respondents didn't bother to visit the site to see
> what you were actually doing, and instead commented on one person's
> interpretation of your words.
The respondents I saw raised the issue that the
presistent side frames take away valuable screen space,
especially on smaller displays. This is a valid
criticism, regardless of political issues.
> The site is an intelligent response to a very sensitive situation...
> The equal ease of access to navigational aids in either official
> language constitutes a strong statement of the respect which we feel for
> what in other countries to the south of us might be considered mostly a
> nuisance -- and certainly un-patriotic.
In my opinion, the author of the site did his task
backwards. He should have created the entire site to
work well without frames, and then considered whether
he still wished to add an optional framed version. One
way to do this would have been to have a totally
bilingual home page, with links in both languages to
the English and French versions of the site. The
author acknowledged that many Candadian sites,
governmental and otherwise, do exactly that, but
protested that he preferred to try out a new way,
which he was offering for comment. I rather resent
the implication that those who took up his offer,
pointing out problems with this approach, did so
out of ignorance of the site itself, or of the
political issues involved.
--
Warren Steel mu...@olemiss.edu
Department of Music University of Mississippi
http://www.mcsr.olemiss.edu/~mudws/
> I think the majority of respondents didn't bother to visit the site
I can't speak for the majority; I noticed that one respondent could
not have actually seen the site...
> The site is an intelligent response to a very sensitive situation.
I didn't agree, and still don't, but when the original poster explained
that it had been designed for political reasons rather than to be useful
to ordinary readers, it all fell into place.
> For the edification of those who do not follow the politics of this polite
> little backwater called Canada (the "retarded giant on your doorstep,"
> according to National Lampoon),
I don't think I need to know anything about USAn perceptions of Canada
to address this particular problem. It's enough to know a little about
Canadian perceptions of Canada. After all, the pages aren't being
designed specifically for USAns, nor indeed for Brits like myself. I
tried to approach the problem with that in mind.
> any perception that one is playing
> favourite between French and English can cause problems for a government
> agency.
There are several solutions that address this issue equally well (or
equally badly) that don't involve frames. Some of them have already
been mentioned in followups. Why not address those, rather than trying
to impugne all the contributors on the basis of one misinterpretation?
> The equal ease of access to navigational aids in either official
> language constitutes a strong statement of the respect
YM "forcing those who want the French page to have their realestate
occupied by the English" (and vice versa). Very respectful.
> which we feel for
> what in other countries to the south of us might be considered mostly a
> nuisance -- and certainly un-patriotic.
We don't all come from that direction. Some of us have even lived in
foreign countries, where they speak foreign languages ;-)
> As to the no-frames issue. You might want to consider server-side includes
I'm glad to be able to agree with you on something. That's perfectly
good advice, at least for a low-traffic site.
In a wider context, one might decide to do a quick study to see if it
wouldn't be worth building static copies of the pages from the original
source materials, to cut down the overhead - there are several products
that can do that. Since the problem of providing framed and non-frame
versions of the same content is essentially the same for all users of
frames, irrespective of the details of the content, it's the kind of
problem field where it would be useful to have a standard software tool
for handling the whole thing. Feed in the content here, get a pair of
linked sites - framed and non-framed, out there. Publish to web, done.
As i said, this seems to me to be a sine qua non that an author needs
before deciding to use frames.
Indeed, some foo-to-HTML packages (for various values of foo) already
provide this kind of option. Not that I'm suggesting you'd want to
author your content in RTF just to be able to use rtftohtml for this
purpose ;-)
> I don't think it's justifiable. For the majority of users, half of
> what's displayed on the screen at any given time is going to be useless.
> Most of the users are going to want to read the text in either French
> *or* English, not in French *and* English at the same time. This strikes
> me as a classic example of a site designed to please the client's
> officials rather than the client's constituents.
There is another very good reason why this is not acceptable. IMNSHO,
all government sites should be accessible to all of her citizens. This
one ain't.
Kathy
--
Kathy E. Gill
http://www.dotparagon.com/aboutgill.html
You must be the change you wish to see in the world. - Ghandi
> It is a truism of UI design that constantly available navigation
> information is a good thing. One way to do this is with a panelled
> window, one part with navigation and/or command information, the other
> with content. The odds are good that everyone reading this message
> on-line seems some kind of window frame with buttons around it.
>
> Frames are a way of doing this, not the only way.
Hmmm ... this is the first I've heard of this principle, and I've done a
lot of HCI reading/research. If this were universal, we'd need to have
the table of contents present on each-and-every double-page spread of a
book or magazine, wouldn't we? And you are also assuming everyone uses a
graphical newsreader -- not necessarily so.
There are many ways to provide navigation context without burdening a
user with frames, which cannot be bookmarked for easy return. This is
really my most maddening frustration (except on really poorly designed
sites).
Kathy
> There are many ways to provide navigation context without burdening a
> user with frames, which cannot be bookmarked for easy return. This is
> really my most maddening frustration (except on really poorly designed
> sites).
>
> Kathy
Of course Netscape could fix this bookmarking bug by showing the URL of
the framed site. Since this bug seems to aggravate so many people,
especially here, I'm surprised that they don't fix it. If any Netscape
programmers are reading this, please give us an explanation of why you
don't fix the bug.
Joseph Zorzin <red...@forestmeister.com> writes:
>
> Of course Netscape could fix this bookmarking bug by showing the URL of
> the framed site.
Not really. You can bookmark the framed page by right-clicking on the
link and choose "Add bookmark". However, that doesn't help much as you
then won't get the surrounding frames.
Frames are broken-as-designed, and there's not much to do about it. If
Netscape et al supported the LINK element things would be easier, but I
wouldn't hold my breath waiting.
> Since this bug seems to aggravate so many people,
> especially here, I'm surprised that they don't fix it.
They've had several more serious bugs unfixed since version 1.x and 2.x,
so I must say I'm not at all surprised.
--Lars M. (anxiously awaiting Opera 3.0)
--
________________________________________________________________________
Lars Marius Garshol
"Make it idiot proof and someone will make a better idiot", Bill Arnett
http://www.ifi.uio.no/~larsga/ http://birk105.studby.uio.no/
>Of course Netscape could fix this bookmarking bug by showing the URL of
>the framed site. Since this bug seems to aggravate so many people,
>especially here, I'm surprised that they don't fix it. If any Netscape
>programmers are reading this, please give us an explanation of why you
>don't fix the bug.
You have to understand the Netscape way of thinking...
If something isn't kewl, it isn't worth spending time on. What could be
more boring than bookmarks, nothing even close to resembling kewl in them.
Furthermore, fixing this feature does not benefit HTML authors in any way.
Netscape is a browser *primarily* directed to the armchair HTML authors
(you know, the ones who stick gazillions of gif animations on their
front page) and not towards end users.
-TPP
--
--
Nanoteknologia: Epämääräinen käsite, joka voi tarkoittaa
kotikielessä mitä tahansa ajattelu- tai muuta prosessia, johon
tiede ei vielä löydä selitystä. - Jussi Luukkonen (To The Point)
Henry Troup <h...@nortel.ca> writes:
> It is a truism of UI design that constantly available navigation
> information is a good thing.
I have to disagree.
A good UI provides you only the information and tools you need in a given
context and hides those features you don't need. Thus, you save screen
estate and can concentrate on the important things (at each time).
Face it: NOBODY will navigate and read the contents at the SAME time.
You do these things one after another. Thus, there is no need to display
content and navigation bars at the same time.
Instead of "navigation frames" I prefer fullsize orientation or index
pages that guide me to the content I'm interested in. These pages can
provide much more information about the content and organzation of a
web site than a small "navigation frame" . Thus, they fasciliate navigation
a lot. When I've found the content I'm looking for, I want to read that
page. The content should occupy the whole browser window.
A small navigation bar at the bottom of this content page is IMO a good idea.
It appears on screen when I need it - when I finished reading the content
and want to go to the next page - and provides orientation to those who
entered the page from an external page. If I stop reading the content in
the middle of the page it is just one hit on the scrollbar (or the equivalent
keystroke) to reach this navigation bar.
Ciao, Claus scho...@ert.rwth-aachen.de
> Instead of "navigation frames" I prefer fullsize orientation or index
> pages that guide me to the content I'm interested in.
..
> When I've found the content I'm looking for, I want to read that
> page. The content should occupy the whole browser window.
Right!
These days I find I'm hardly ever using a framed site as the author
intended, but instead I right-click on the frame I'm interested in and
open it into a fullsized window, and then forget all about the frame
clutter until I've dealt with that issue.
The author could, of course, make it easier by not designing the
frames in the first place.
-----BEGIN PGP SIGNED MESSAGE-----
In article <341E5D...@forestmeister.com>,
Joseph Zorzin <red...@forestmeister.com> wrote:
> Of course Netscape could fix this bookmarking bug by showing the URL of
> the framed site.
It's not really a *bug*, it's a serious design flaw. Although it would
be possible to show the URL of each document in each frame, it is
*not* possible to address a specific frameset with the current set
of documents displayed in it. There just isn't a syntax for it.
- --
E-mail: gala...@stack.nl .................. PGP Key: 512/63B0E665
The WDG web site is temporarily down. Sorry for the inconvenience.
-----END PGP SIGNED MESSAGE-----
>>However, we are looking at cheaper, faster bandwidth in the next few years
>>with cable modems and the like. Will designers then get sloppy and design
>>bandwidth-clogging sites?
[snip]
Anyone remember the days when a programmer would be laughed at if he
wrote a spreadsheet program or database application that gobbled up more
than 64K? Off-topic, I know, but just curious.
John
--
Altered Images
http://www.jersey.net/~usns
>Anyone remember the days when a programmer would be laughed at if he
>wrote a spreadsheet program or database application that gobbled up more
>than 64K? Off-topic, I know, but just curious.
Oh Yeah, Remember loading programs from a cassette?
http://www.harry-the-planet.demon.co.uk/photogal.html
If anyone can tell me how I could have presented this page better, I'd
be genuinely interested to hear it.
Since something like 90% of browsers support frames, I don't see that
it is "an exceedingly hostile move" [Alan J. Flavell] not to offer a
'no-frames' version.
I am still waiting for someone to object to my extravagant use of
graphics on this page.
On the other hand, the commercial pages on my site are designed to be
viewed on a 640x480 monitor, and do not use frames.
But to declare ALL frames-based pages inherently 'exceedingly
hostile', or commercially invalid, is surely striving for some lowest
common denominator of Website design.
Personally, I'd rather do without a lot of the Javascript gimmicks,
which rarely seem to communicate, but do provide distractions from the
lack of content.
Best wishes
harry
Cliches are holes in the bucket of life.
>Since something like 90% of browsers support frames, I don't see that
>it is "an exceedingly hostile move" [Alan J. Flavell] not to offer a
>'no-frames' version.
The frame model is full of weaknesses, and the only reason to use it
is to cater for browser which (still) don't do anything useful with
the LINK element.
Perhaps you could tell us your _intentions_ re: frame usage, then
we'll tell you how to accomplish what you want without them.
--
Becky!, Agent and Opera - now what was it I needed Netscape for?
>Anyone remember the days when a programmer would be laughed at if he
>wrote a spreadsheet program or database application that gobbled up more
>than 64K? Off-topic, I know, but just curious.
You mean back when that little upstart, wossname, William Gates III,
crammed a BASIC interpreter into 4 kB of ROM? :-)
> Wow!
> Luddites unite.
Yes, let's get rid of those kludgy mass-market browsers and move
forward to the real thing.
..
> Since something like 90% of browsers support frames, I don't see that
> it is "an exceedingly hostile move" [Alan J. Flavell] not to offer a
> 'no-frames' version.
I think you've missed an important part fo the argument. I come into
contact with a wide range of web users, and all of those who have an
opinion on the matter at all seem to dislike frames, for various good
reasons. Since their browsers mostly have no ability to turn frames off,
it makes sense not only to give them a no-frames alternative, but also
to give them an explicit way of getting to that alternative.
[Myself I prefer not to make the framed site at all, but I'm not trying
to stop those who want to from doing so - I'm just trying to get them to
see the benefits of a viable non-framed alternative.]
..
> But to declare ALL frames-based pages inherently 'exceedingly
> hostile',
Please re-read what you quoted. That isn't what I said.
> Personally, I'd rather do without a lot of the Javascript gimmicks,
Huh? Reminds me of the old Music-Hall joke: "cup of tea with no
sugar please" - "sorry, we've got no sugar, will you have it without
milk?".
> These days I find I'm hardly ever using a framed site as the author
> intended, but instead I right-click on the frame I'm interested in and
> open it into a fullsized window, and then forget all about the frame
> clutter until I've dealt with that issue.
Unfortunately Netscape opens a new window for this purpose
(as it does with links to an unknown target.) Thus, I end up with
10-15 browser windows on my screen ;-(.
I wish, I could tell Netcsape to use the same window.
Anyway, I'm using Netscape 2.02. IMHO it is better than 3.* and 4.*.
Opening the frame in a fullsize window isn't that comfortable with
that version. If I see frames I either leave the page or switch to lynx.
Lynx has still the best and most user-friendly frame implementation.
> The author could, of course, make it easier by not designing the
> frames in the first place.
Right!
At least the authors should take a look at their work using lynx.
How many framesets have I seen, that tried to tell me lynx wouldn't
support frames?
Ciao, Claus scho...@ert.rwth-aachen.de
> Of course Netscape could fix this bookmarking bug by showing the URL of
> the framed site.
No. A specific framed display doesn't have a URL, that's an inherent
limitation in the design. The URL only denotes the initial state of
the frameset.
Well, some sites seem to think it's a benefit, as it makes it impossible
for readers to get directly back to the information, forcing them to
revisit lots of other frames on the way.
> Since this bug seems to aggravate so many people,
> especially here, I'm surprised that they don't fix it.
It's not fixable. It's inherent in the design. As they were told,
right back when they implemented it, but they didn't want to know.
Claus Schotten <scho...@teefax.ert.rwth-aachen.de> writes:
>
> Anyway, I'm using Netscape 2.02. IMHO it is better than 3.* and 4.*.
> Opening the frame in a fullsize window isn't that comfortable with
> that version. If I see frames I either leave the page or switch to lynx.
> Lynx has still the best and most user-friendly frame implementation.
It sounds like you should take a look at Opera. It's compatible with
Netscape 2.x, but faster and you can turn off frames. (In fact, it's
probably the most configurable browser after Emacs-W3.)
The URL is
http://traviata.nta.no/opera.htm
>If anyone can tell me how I could have presented this page better, I'd
>be genuinely interested to hear it.
I can see no reason to display the thumbtack gallery and the individual
images at the same time. The thumbtacks don't add anything to the viewing
experience of the big image, but they rather divert from it and mess up the
display palette.
Don't assume that people will reboot in order to change their color
resolution only because you tell them so.
Don't assume your photographs are best viewed in the context of your Web
page with the Nxxxxxxx browser running on a Windows platform 16 or 32 bit
grahics and some prescribed screen resolution and window size.
Your photographs are best viewed with a dedicated image displaying or
processing software after they have been downloaded with any odd browser
running on any odd platform which does not need to be identical to the
platform used to view the images.
Don't assume potential customers of a photographer are interested in viewing
your web pages - but assume they are interested in viewing your photographs.
Don't assume potential customers won't scrutinize your non-commercial
pictures as well. So make it easy for your customers to do so. including the
<IMG> tags within <A HREF=..> tags to make downloading easier will show that
you take your visitors serious. Consistently including technical information
(stock type, lighting, exposure time, aperture, lens) with your photographs
will help.
>Personally, I'd rather do without a lot of the Javascript gimmicks,
>which rarely seem to communicate, but do provide distractions from the
>lack of content.
Unfortunately, some pages using Javascript gimmicks actually do provide
content, so this is not a sure sign that a page is to be avoided.
Since you mentioned the distracive element yourself: try looking at your
photographs within a frame set and without the navigation frame. Which
version makes it easier to give the picture the full attention it deserves ?
--
int m,u,e=0;float l,_,I;main(){for(;1840-e;putchar((++e>912&&941>
e?60-m:u)["\n)ed.fsg@eum(rezneuM drahnreB"]))for(u=_=l=0;79-(m=e%
80)&&I*l+_*_<6&&20-++u;_=2*l*_+e/80*.09-1,l=I)I=l*l-_*_-2+m/27.;}
I have to disagree - somewhat.
For users who are going to make the effort to familiarise themselves
with a system, that makes sense (although it's often very poorly
implemented in practice). A word processor or an Intranet database - yes.
But in the context of the WWW, if you hide information that isn't
currently accessible, only the diehards will find it at all.
In my Self-Organizing Website, registered users can add new documents
to the site, in directories where they have permission to write. Self-
registration is available to any user, via a "register" toolbar link
in every page.
However, the "add new document" link is, as you might expect, hidden
until the user is registered and is in a directory where she has write
permission. Result: WWW visitors don't realise it's interactive, and
don't bother to register.
Of course, it works fine in an intranet, where users have a good idea
what the system's about.
> Face it: NOBODY will navigate and read the contents at the SAME time.
But if it's a site I already know the contents of?
Maybe I visit periodically to query the database, order a product
and read the latest news from the site's operators. I really don't
need to spend time reading the introductory front page and description
of the service, which I saw first time I visited the site. Give me
convenient buttons to go to where I want!
> Instead of "navigation frames" I prefer fullsize orientation or index
> pages that guide me to the content I'm interested in. These pages can
> provide much more information about the content and organzation of a
> web site than a small "navigation frame".
Sometimes.
A small navigation frame - or embedded toolbar - gives you shortcuts.
Now a browser that pre-fetched any <link rel> pages and offered them
as a popup menu could be very nice indeed.
> A small navigation bar at the bottom of this content page is IMO a good idea.
Well, if you have a fast link, or don't mind waiting for the bottom of
a page... I prefer it sooner.
--
Nick Kew
WebThing virtual office: personal and groupware desktop on the Web
Mail Client, Mail Server, Calendar Server, FileServer, Conferencing
- <URL:http://www.webthing.com/>