You are viewing a plain text version of this content. The canonical link for it is here.
Posted to docs-dev@perl.apache.org by Bill Moseley <mo...@hank.org> on 2001/12/27 20:03:43 UTC
Comment from the outside
Hi,
I assume most of you saw that I set up an archive for the doc-dev list.
(Stas, we should move those to perl.apache.org instead of
search.apache.org/docs-dev/).
I only just subscribed to the list when setting up the archive for testing,
so I'm WAY out of the loop. But, I have a friend that's a print-ad
designer by trade, but now his firm does web design, too. And actually,
web design has been his focus or a few years. I'm not sure, but I think
they are reasonably high-end -- I asked him, for example, what it would
cost to design a simple site like mod_perl and his response was that
between $10,000 - $15,000 usd which sounds like a lot of cash to me.
He had some comments that I thought I'd pass on. Most of it you already
know, and is probably not that constructive, especially at this point. But
sometimes it is interesting to hear from another point of view. I don't
agree with everything, but here it is.
This is probably obvious, but they never design in html. He says they
spend weeks with the clients learning what the client is trying to present
(their "brand") to their customers, and that's the toughest part. Then
they carefully rank what needs to be presented, keeping in mind who the are
designing for (new users?) and stay focused on those.
(My view is that the mod_perl site should be designed to attract new users
and to make it look professional enough to be accepted by IT managers as a
real technology. More jobs! I also assume mod_perl users can find what
they are looking for quickly regardless of the site. I don't go to the
modperl home page to get to the Guide).
Then they design in photoshop, and design to a little smaller than 800x600
(better to fit in a window than extend beyond). They don't worry about
html at all. Any text elements that are important visually will be
converted to images, as that's the only way to control the look. Then they
battle it out with their "producer" that converts the design into html.
It's my friends job to make sure the designer and producer keep the
elements of the "message" (as he puts it) in the final page. I guess it's
the designer's job to make people want to stay at the site, and his job to
make sure the message is clear.
Is http://www.bullitt.suite.dk/mod_perl_site/var_c/ the current design?
He thought it's a nice design. Of course it's a battle between visual
design and packing in all the info that you think should be there. And
that's where one tries to stay focused on that "message" thing again, and
exactly who you are designing for.
>From a designer point of view he thinks there's a little confusion in the
design -- something most people don't even think about. His comment was
that the mod_perl/camel logo and the "welcome to mod_perl" are in
competition -- "your eye doesn't know where to start" was his comment. He
says there needs to be "air" above the "welcome to mod_perl" box to let
your eye flow (more like the about page where the bread crumb is above
forcing the title lower) -- specifically he said move it down to the line
of the feather or below.
By "air" he said blank space is really ok, even if that seems like a loss
of valuable "real estate". He also said that "air" can also mean some
graphic (something to give that warm mod_perl feeling, I suppose?). Just
something to let your eye flow.
The other main point was that there's two table of contents -- the left nav
bar and the table of contents below. He thought that was somewhat
confusing, and maybe just integrated with the sidebar nav (or some title
bar nav (site vs. content navigation)).
He also said the side bar navigation design in boxes makes you want to
click on the box, yet with the style sheet design you have to click on the
actual text. I agree that's a bit awkward.
Finally, I never saw the argument for not using tables (I suppose I could
search the archive ;). I think it's cool when CSS works, but there's a
large number of clients where it doesn't work. Netscape 4.0x is still very
common, and it doesn't work in that browser. Any idea what percent of
browsers visiting modperl.apache.org are browsers that won't render that
page? I doubt people will upgrade their browsers just because the
modperl.apache.org site doesn't display correctly.
Sorry for the ramblings.
--
Bill Moseley
mailto:moseley@hank.org
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: Comment from the outside
Posted by Stas Bekman <st...@stason.org>.
Thomas Klausner wrote:
> Hi!
>
> On Tue, Jan 01, 2002 at 01:26:23AM +0800, Stas Bekman wrote:
>
>>>>I suppose that we can use a conditional require() for the style sheet in
>>>>the <head> section and serve a different CSS for older NS. That's
>>>>possible right? (I didn't do html for a long time)
>>>>
>>>Oh is the site going to be dynamic? Different tempaltes for old clients is
>>>one way to go.
>>>
>>Nope, it's going to be static. You can decide which CSS to fetch at run
>>time, via require(). I think this has something to do with JS if I'm not
>>mistaken. So you can check the agent and fetch a proper for this agent
>>CSS file. I suppose this doesn't contradict with the fact that we don't
>>want to use JS for usability. This JS should work behind the scenes and
>>if it's disable or not available the default CSS should be brought in.
>>I'll leave again to the experts to comment on whether it's going to work.
>>
> IMO there are two ways of doing this (I did the seconde once..)
>
> 1) Put some JS in the HTML to check the browser version and have the JS
> generate the "require style sheet" part.
>
> 2) Generate the CSS dynamically. That is, require something like
> /cgi-bin/css.pl and have that script return the corresponding style sheet
> for the requesting client (with Content-type: text/css). The problem here is
> that each request triggers a CGI process. But it works even if JS is disabled.
>
> Maybe one way to get the best result would be to first load a CSS file the
> normal way. Afterwards have some JS check the browser type and load another
> CSS file according to the browser type.
That's exactly what I've meant. You always have the
<noscript></noscript> or whatever it is (I don't remember) used for
doing things for browsers with no JS (or disabled).
We definitely don't want to pick CSS dynamically.
> So if someone with an old browser, but JS enabled views the page, s/he first
> gets the "standard" CSS file and afterwards the JS-generated browser
> specific CSS. As the C stands for Cascading, the later loaded CSS file will
> override the "standard" file, and thus those styles will be applied.
>
> If someone with a new browser (i.e. standard compliant) but JS turned off
> requests a page, s/he gets only the default standard CSS file, which the
> browser can render.
>
> So we don't force users with new browsers to use JS to get the best view of
> the mod_perl site, AND we can make a nice-looking page for old browser with
> JS enabled. Old Browsers without JS (or lynx, etc) just get the very basic
> layout (like http://hank.org/images/style6.png )
>
> But I'd prefer to do this fine-tuning /after/ all current issues (i.e.
> prev/next and download widget) have been dealt with.
That's fine, there is no hurry, we just need to remember which things to
deal with.
Once you decide on more or less stable layout (templates wise), please
send me the tmpl dir and I'll put it under modperl-docs cvs repository
so we can all work with the same source. I've ported most of the content
already, after adding the tmpl dir we can do some alpha previews for people.
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: Comment from the outside
Posted by Jim Smith <jg...@moya.tamu.edu>.
On Mon, Dec 31, 2001 at 07:20:20PM +0100, Thomas Klausner wrote:
> 2) Generate the CSS dynamically. That is, require something like
> /cgi-bin/css.pl and have that script return the corresponding style sheet
> for the requesting client (with Content-type: text/css). The problem here is
> that each request triggers a CGI process. But it works even if JS is disabled.
Or pre-generate them and have a mod_rewrite rule that selects the correct one.
--jim
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: Comment from the outside
Posted by Thomas Klausner <do...@zsi.at>.
Hi!
On Tue, Jan 01, 2002 at 01:26:23AM +0800, Stas Bekman wrote:
> >>I suppose that we can use a conditional require() for the style sheet in
> >>the <head> section and serve a different CSS for older NS. That's
> >>possible right? (I didn't do html for a long time)
> > Oh is the site going to be dynamic? Different tempaltes for old clients is
> > one way to go.
> Nope, it's going to be static. You can decide which CSS to fetch at run
> time, via require(). I think this has something to do with JS if I'm not
> mistaken. So you can check the agent and fetch a proper for this agent
> CSS file. I suppose this doesn't contradict with the fact that we don't
> want to use JS for usability. This JS should work behind the scenes and
> if it's disable or not available the default CSS should be brought in.
> I'll leave again to the experts to comment on whether it's going to work.
IMO there are two ways of doing this (I did the seconde once..)
1) Put some JS in the HTML to check the browser version and have the JS
generate the "require style sheet" part.
2) Generate the CSS dynamically. That is, require something like
/cgi-bin/css.pl and have that script return the corresponding style sheet
for the requesting client (with Content-type: text/css). The problem here is
that each request triggers a CGI process. But it works even if JS is disabled.
Maybe one way to get the best result would be to first load a CSS file the
normal way. Afterwards have some JS check the browser type and load another
CSS file according to the browser type.
So if someone with an old browser, but JS enabled views the page, s/he first
gets the "standard" CSS file and afterwards the JS-generated browser
specific CSS. As the C stands for Cascading, the later loaded CSS file will
override the "standard" file, and thus those styles will be applied.
If someone with a new browser (i.e. standard compliant) but JS turned off
requests a page, s/he gets only the default standard CSS file, which the
browser can render.
So we don't force users with new browsers to use JS to get the best view of
the mod_perl site, AND we can make a nice-looking page for old browser with
JS enabled. Old Browsers without JS (or lynx, etc) just get the very basic
layout (like http://hank.org/images/style6.png )
But I'd prefer to do this fine-tuning /after/ all current issues (i.e.
prev/next and download widget) have been dealt with.
--
D_OMM +----> http://domm.zsi.at <-----+
O_xyderkes | neu: Arbeitsplatz |
M_echanen | http://domm.zsi.at/d/d162.html |
M_asteuei +--------------------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: Comment from the outside
Posted by Stas Bekman <st...@stason.org>.
Bill Moseley wrote:
> At 12:46 AM 01/01/02 +0800, Stas Bekman wrote:
>
>>>http://hank.org/images/style6.png
>>>http://hank.org/images/style7.png
>>>
>>>Actually, that simply style7.png is kind of nice to look at.
>>>
>>So 7 is "almost" OK, what about 1-5?
>>
>
> Well, no they are really mostly all the same. Like I said, Netscape seems
> to get confused -- 7 looks "almost OK", but if I resize it then it looks
> like 6. They all look about the same, really. Netscape 4.0x just doesn't
> know how to render it. For a table layout in Netscape I think you are kind
> of stuck with <table>.
:(
>>I suppose that we can use a conditional require() for the style sheet in
>>the <head> section and serve a different CSS for older NS. That's
>>possible right? (I didn't do html for a long time)
>>
>
> Oh is the site going to be dynamic? Different tempaltes for old clients is
> one way to go.
Nope, it's going to be static. You can decide which CSS to fetch at run
time, via require(). I think this has something to do with JS if I'm not
mistaken. So you can check the agent and fetch a proper for this agent
CSS file. I suppose this doesn't contradict with the fact that we don't
want to use JS for usability. This JS should work behind the scenes and
if it's disable or not available the default CSS should be brought in.
I'll leave again to the experts to comment on whether it's going to work.
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: Comment from the outside
Posted by Bill Moseley <mo...@hank.org>.
At 12:46 AM 01/01/02 +0800, Stas Bekman wrote:
>> http://hank.org/images/style6.png
>> http://hank.org/images/style7.png
>>
>> Actually, that simply style7.png is kind of nice to look at.
>
>So 7 is "almost" OK, what about 1-5?
Well, no they are really mostly all the same. Like I said, Netscape seems
to get confused -- 7 looks "almost OK", but if I resize it then it looks
like 6. They all look about the same, really. Netscape 4.0x just doesn't
know how to render it. For a table layout in Netscape I think you are kind
of stuck with <table>.
>I suppose that we can use a conditional require() for the style sheet in
>the <head> section and serve a different CSS for older NS. That's
>possible right? (I didn't do html for a long time)
Oh is the site going to be dynamic? Different tempaltes for old clients is
one way to go.
--
Bill Moseley
mailto:moseley@hank.org
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: Comment from the outside
Posted by Stas Bekman <st...@stason.org>.
Bill Moseley wrote:
> At 02:46 PM 12/31/01 +0800, Stas Bekman wrote:
>
>>>Well, it's not really "un-readable", but it doesn't render that well. I'll
>>>attach a Netscape 4.08 on Windows screen shot.
>>>
>>But this is a different design, isn't it? We are trying to decide
>>whether we can go with table-less skeleton from Thomas?
>>http://domm.zsi.at/modperl-site-domm/meta.html
>>
>
> For those try the following links: Note that although they are different
> renderings, it's not really dependent on style6 vs. style7. Netscape seems
> to get confused, as they both start out looking like style7, but then (in
> the case of style6.png) redraws the screen when I scroll or resize. I've
> had to limit my use of some sytle settings with Netscape.
>
> http://hank.org/images/style6.png
> http://hank.org/images/style7.png
>
> Actually, that simply style7.png is kind of nice to look at.
So 7 is "almost" OK, what about 1-5?
I suppose that we can use a conditional require() for the style sheet in
the <head> section and serve a different CSS for older NS. That's
possible right? (I didn't do html for a long time)
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: Comment from the outside
Posted by Thomas Klausner <do...@zsi.at>.
Hi!
On Mon, Dec 31, 2001 at 06:14:48AM -0800, Bill Moseley wrote:
> For those try the following links: Note that although they are different
> renderings, it's not really dependent on style6 vs. style7. Netscape seems
> to get confused, as they both start out looking like style7, but then (in
> the case of style6.png) redraws the screen when I scroll or resize. I've
> had to limit my use of some sytle settings with Netscape.
>
> http://hank.org/images/style6.png
> http://hank.org/images/style7.png
This is caused by a bug in Netscape. If you resize your browser and the page
is using CSS, then all CSS information is lost an the page is rendered as if
there were no style sheets. If you press RELOAD after resizing your
browsers, the CSS stuff is there again. As someone said on the mod_perl
mailing list, compared to NS 4.x, Win 95 looked bugfree :-)
> Actually, that simply style7.png is kind of nice to look at.
Today I got my hands on a Netscape 4.X on Windows, it looked just like
style7.png to me. The only problem I see there is with the "ad" stuff (Did
you know...), but that could be solved by inserting some <br>s at the right
place there...
--
D_OMM +----> http://domm.zsi.at <-----+
O_xyderkes | neu: Arbeitsplatz |
M_echanen | http://domm.zsi.at/d/d162.html |
M_asteuei +--------------------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: Comment from the outside
Posted by Bill Moseley <mo...@hank.org>.
At 02:46 PM 12/31/01 +0800, Stas Bekman wrote:
>> Well, it's not really "un-readable", but it doesn't render that well. I'll
>> attach a Netscape 4.08 on Windows screen shot.
>
>But this is a different design, isn't it? We are trying to decide
>whether we can go with table-less skeleton from Thomas?
>http://domm.zsi.at/modperl-site-domm/meta.html
For those try the following links: Note that although they are different
renderings, it's not really dependent on style6 vs. style7. Netscape seems
to get confused, as they both start out looking like style7, but then (in
the case of style6.png) redraws the screen when I scroll or resize. I've
had to limit my use of some sytle settings with Netscape.
http://hank.org/images/style6.png
http://hank.org/images/style7.png
Actually, that simply style7.png is kind of nice to look at.
--
Bill Moseley
mailto:moseley@hank.org
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: Comment from the outside
Posted by Stas Bekman <st...@stason.org>.
Bill Moseley wrote:
> At 12:33 PM 12/31/01 +0800, Stas Bekman wrote:
>
>>There is no need to make group decisions. The mod_perl site should be
>>properly viewable by *all* users using rendering user agents (aka
>>browsers) implemented according to the wide open standards. We aren't a
>>commercial body that decides to cut some users off, because let's say
>>90% is good enough for their profit making machine.
>>
>
> Actually, I was kind of making the point the commercial sites might not be
> on the cutting edge of the standards so that they don't cut people off,
> where we might be able to expect people looking at the mod_perl site to be
> using newer browsers.
that's actually very opposite in reality. But in theory you are correct.
What if we add the very minimum tables, so it'll look good with browsers
not supporting CSS at all (or having a broken one).
>>Do you say that Thomas' design makes it un-readable for someone? I think
>>in the worst case, if the browser doesn't support CSS, the user will get
>>the menu on the top, followed by the content. Am I wrong?
>>
>
> Well, it's not really "un-readable", but it doesn't render that well. I'll
> attach a Netscape 4.08 on Windows screen shot.
But this is a different design, isn't it? We are trying to decide
whether we can go with table-less skeleton from Thomas?
http://domm.zsi.at/modperl-site-domm/meta.html
Does Thomas' layout look as bad?
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: Comment from the outside
Posted by Bill Moseley <mo...@hank.org>.
At 12:33 PM 12/31/01 +0800, Stas Bekman wrote:
>There is no need to make group decisions. The mod_perl site should be
>properly viewable by *all* users using rendering user agents (aka
>browsers) implemented according to the wide open standards. We aren't a
>commercial body that decides to cut some users off, because let's say
>90% is good enough for their profit making machine.
Actually, I was kind of making the point the commercial sites might not be
on the cutting edge of the standards so that they don't cut people off,
where we might be able to expect people looking at the mod_perl site to be
using newer browsers.
>Do you say that Thomas' design makes it un-readable for someone? I think
>in the worst case, if the browser doesn't support CSS, the user will get
>the menu on the top, followed by the content. Am I wrong?
Well, it's not really "un-readable", but it doesn't render that well. I'll
attach a Netscape 4.08 on Windows screen shot.
Re: Comment from the outside
Posted by Stas Bekman <st...@stason.org>.
Bill Moseley wrote:
> At 10:30 PM 12/30/01 +0100, Thomas Klausner wrote:
>
>>IMO (and w3.org's too) tables shouldn't be missused for page layout. The
>>problem with most so called web designers is that they know nothing about
>>how the web work (or how it should work). Just because everyone uses
>>Frontpage et al to generate bloated, bad HTML is no reason for me to do the
>>same.
>>
>
> I don't want to argue about how the web should work. How it should work
> and how it's used are different things.
>
> Anyway it's a simple issue: Decide as a group what is an acceptable percent
> of requests that won't be able to view the mod_perl site at this time.
> Then look at the perl.apache.org logs and see if we are currently above or
> below that level.
>
> That's all I was pointing out.
There is no need to make group decisions. The mod_perl site should be
properly viewable by *all* users using rendering user agents (aka
browsers) implemented according to the wide open standards. We aren't a
commercial body that decides to cut some users off, because let's say
90% is good enough for their profit making machine.
Do you say that Thomas' design makes it un-readable for someone? I think
in the worst case, if the browser doesn't support CSS, the user will get
the menu on the top, followed by the content. Am I wrong?
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: Comment from the outside
Posted by Bill Moseley <mo...@hank.org>.
At 10:30 PM 12/30/01 +0100, Thomas Klausner wrote:
>IMO (and w3.org's too) tables shouldn't be missused for page layout. The
>problem with most so called web designers is that they know nothing about
>how the web work (or how it should work). Just because everyone uses
>Frontpage et al to generate bloated, bad HTML is no reason for me to do the
>same.
I don't want to argue about how the web should work. How it should work
and how it's used are different things.
Anyway it's a simple issue: Decide as a group what is an acceptable percent
of requests that won't be able to view the mod_perl site at this time.
Then look at the perl.apache.org logs and see if we are currently above or
below that level.
That's all I was pointing out.
Thanks,
--
Bill Moseley
mailto:moseley@hank.org
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: Comment from the outside
Posted by Thomas Klausner <do...@zsi.at>.
Hi!
On Thu, Dec 27, 2001 at 11:03:43AM -0800, Bill Moseley wrote:
> Finally, I never saw the argument for not using tables (I suppose I could
> search the archive ;). I think it's cool when CSS works, but there's a
IMO (and w3.org's too) tables shouldn't be missused for page layout. The
problem with most so called web designers is that they know nothing about
how the web work (or how it should work). Just because everyone uses
Frontpage et al to generate bloated, bad HTML is no reason for me to do the
same.
As far as I got it (in 1994 when I started using the WWW) it should work
like that:
Use HTML to structure your content.
Let the browser render it as it seems fit.
(added ~95/96)
use CSS to tell the browser how to render.
Finally most browser are actually rendering CSS correctly, so I see no need
to use all those ugly hacks anymore.
> page? I doubt people will upgrade their browsers just because the
> modperl.apache.org site doesn't display correctly.
www.webstandards.org
--
D_OMM +----> http://domm.zsi.at <-----+
O_xyderkes | neu: Arbeitsplatz |
M_echanen | http://domm.zsi.at/d/d162.html |
M_asteuei +--------------------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: Comment from the outside
Posted by Bill Moseley <mo...@hank.org>.
At 10:40 PM 12/27/01 +0100, allan wrote:
>> The other main point was that there's two table of contents -- the left nav
>> bar and the table of contents below. He thought that was somewhat
>> confusing, and maybe just integrated with the sidebar nav (or some title
>> bar nav (site vs. content navigation)).
>
>i agree on this point but dont see a proper way to avoid it
>in the current designs around
One thing is commented on (although I don't know if it was a suggestion)
was to use the side bar for navigation to direct people to places you want
them to see. Kind of a tour of mod_perl, but then use top-bar navigation
to get everywhere. How to implement I'm not sure. I should ask him for
some sites he considers good examples.
>> He also said the side bar navigation design in boxes makes you want to
>> click on the box, yet with the style sheet design you have to click on the
>> actual text. I agree that's a bit awkward.
>
...
>doubleclick :-)) so in that sense i think they'll soon get
>the hang of it:-)
Sure. We get into our web habits, of course.
>
>you mention it
>(http://www.bullitt.suite.dk/mod_perl_site/var_c/) does not
>work in Netscape 4.0x. do you mean it looks like crap or is
>it something that litterally doesnt work? i use netscape
>4.79 and everything is ok (only slighly worse than ie 5.0
>and opera 5.0, all macintosh)
Sorry, I hate it when people say "it doesn't work" ;)
Well on my Netscape 4.08 the "Welcome to mod_perl" is only an inch (sorry,
2.5cm) wide and all the text is in a column directly below it (the same
width).
Thanks for all your work!
--
Bill Moseley
mailto:moseley@hank.org
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: Comment from the outside
Posted by Thomas Klausner <do...@zsi.at>.
Hi!
On Thu, Dec 27, 2001 at 04:58:04PM -0500, Philip Mak wrote:
> It's actually possible to put some JavaScript that will make it so that
> the boxes themselves light up on mouseover, and are clickable. It involves
> putting a mouseOver and mouseClicked event on the <TD> tag that represents
> the box.
-1
Please no JavaScript (unless it is /necessary/).
IMO the mod_perl site should be just like mod_perl:
--
D_OMM +----> http://domm.zsi.at <-----+
O_xyderkes | neu: Arbeitsplatz |
M_echanen | http://domm.zsi.at/d/d162.html |
M_asteuei +--------------------------------+
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: Comment from the outside
Posted by Jim Smith <jg...@moya.tamu.edu>.
On Fri, Dec 28, 2001 at 12:56:39PM +0100, Eric Cholet wrote:
> --On vendredi 28 d�cembre 2001 11:39 +0000 "Jonathan M. Hollin"
> <ne...@digital-word.com> wrote:
>
> >:: -1 on using JS for usability improvements. If we have
> >:: usability problems
> >:: we should solve them, not to look for workarounds which don't work
> >:: across all browsers.
> >
> >+1 Surely every browser supports JavaScript these days?
>
> Not every user supports JavaScript.
Agreed. I'm:
-1 on using JS to provide missing functionality
0 on using JS to make the page pretty
I usually browse with JS turned off, esp. in Mozilla since it can do
style sheets without it (Netscape 4.x requires JS to render CSS - go
figure... and then doesn't even do it right - at least on Solaris).
--jim
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
RE: Comment from the outside
Posted by Eric Cholet <ch...@logilune.com>.
--On vendredi 28 décembre 2001 11:39 +0000 "Jonathan M. Hollin"
<ne...@digital-word.com> wrote:
> :: -1 on using JS for usability improvements. If we have
> :: usability problems
> :: we should solve them, not to look for workarounds which don't work
> :: across all browsers.
>
> +1 Surely every browser supports JavaScript these days?
Not every user supports JavaScript.
--
Eric Cholet
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: Comment from the outside
Posted by Stas Bekman <st...@stason.org>.
Philip Mak wrote:
> On Fri, 28 Dec 2001, Jonathan M. Hollin wrote:
>
>
>>:: -1 on using JS for usability improvements. If we have
>>:: usability problems
>>:: we should solve them, not to look for workarounds which don't work
>>:: across all browsers.
>>
>>+1 Surely every browser supports JavaScript these days?
>>
>
> Apparently 12% of people have JavaScript disabled, according to this:
> http://www.thecounter.com/stats/2001/December/javas.php
>
> I'm the one who suggested JavaScript in the first place, but I think the
> suggested alternative of putting underlines on the links in the navbar so
> that they don't look like buttons is good too. If that will solve the
> problem then we don't need to use JavaScript in the first place (which is
> a bit more complicated to code, and isn't visible to 12% of people
> apparently).
I'm mostly against using JS in general because of cross-platform
problems. I'm so glad I don't have to write JS anymore :)
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
RE: Comment from the outside
Posted by Philip Mak <pm...@animeglobe.com>.
On Fri, 28 Dec 2001, Jonathan M. Hollin wrote:
> :: -1 on using JS for usability improvements. If we have
> :: usability problems
> :: we should solve them, not to look for workarounds which don't work
> :: across all browsers.
>
> +1 Surely every browser supports JavaScript these days?
Apparently 12% of people have JavaScript disabled, according to this:
http://www.thecounter.com/stats/2001/December/javas.php
I'm the one who suggested JavaScript in the first place, but I think the
suggested alternative of putting underlines on the links in the navbar so
that they don't look like buttons is good too. If that will solve the
problem then we don't need to use JavaScript in the first place (which is
a bit more complicated to code, and isn't visible to 12% of people
apparently).
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
RE: Comment from the outside
Posted by "Jonathan M. Hollin" <ne...@digital-word.com>.
:: -1 on using JS for usability improvements. If we have
:: usability problems
:: we should solve them, not to look for workarounds which don't work
:: across all browsers.
+1 Surely every browser supports JavaScript these days?
Jonathan M. Hollin - WYPUG Co-ordinator
West Yorkshire Perl User Group
http://wypug.pm.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: Comment from the outside
Posted by Stas Bekman <st...@stason.org>.
Philip Mak wrote:
> On Thu, 27 Dec 2001, allan wrote:
>
>
>>>He also said the side bar navigation design in boxes makes you want to
>>>click on the box, yet with the style sheet design you have to click on the
>>>actual text. I agree that's a bit awkward.
>>>
>>akward, but you'll soon get the hang of it :).
>>
>
> It's actually possible to put some JavaScript that will make it so that
> the boxes themselves light up on mouseover, and are clickable. It involves
> putting a mouseOver and mouseClicked event on the <TD> tag that represents
> the box.
-1 on using JS for usability improvements. If we have usability problems
we should solve them, not to look for workarounds which don't work
across all browsers.
If you think that boxes aren't good for navbar, we can keep the text
underlined in these boxes. Then users won't want to click on the box.
> This can be done without loss of compatibility to non-JavaScript browsers,
> too (although people using them will have to click on the link, not the
> box).
--
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: Comment from the outside
Posted by Philip Mak <pm...@animeglobe.com>.
On Thu, 27 Dec 2001, allan wrote:
> > He also said the side bar navigation design in boxes makes you want to
> > click on the box, yet with the style sheet design you have to click on the
> > actual text. I agree that's a bit awkward.
>
> akward, but you'll soon get the hang of it :).
It's actually possible to put some JavaScript that will make it so that
the boxes themselves light up on mouseover, and are clickable. It involves
putting a mouseOver and mouseClicked event on the <TD> tag that represents
the box.
This can be done without loss of compatibility to non-JavaScript browsers,
too (although people using them will have to click on the link, not the
box).
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: Comment from the outside
Posted by allan <la...@inet.uni2.dk>.
hello bill
it is really great to hear your and your friends comments.
> Is http://www.bullitt.suite.dk/mod_perl_site/var_c/ the current design?
no, that is more or less my version - sort of an idea domain.
> design -- something most people don't even think about. His comment was
> that the mod_perl/camel logo and the "welcome to mod_perl" are in
> competition -- "your eye doesn't know where to start" was his comment. He
> says there needs to be "air" above the "welcome to mod_perl" box to let
> your eye flow (more like the about page where the bread crumb is above
> forcing the title lower) -- specifically he said move it down to the line
> of the feather or below.
i think most people agree here, and if we are lucky someone
will come up with a new and better logo.
> The other main point was that there's two table of contents -- the left nav
> bar and the table of contents below. He thought that was somewhat
> confusing, and maybe just integrated with the sidebar nav (or some title
> bar nav (site vs. content navigation)).
i agree on this point but dont see a proper way to avoid it
in the current designs around
> He also said the side bar navigation design in boxes makes you want to
> click on the box, yet with the style sheet design you have to click on the
> actual text. I agree that's a bit awkward.
akward, but you'll soon get the hang of it :).
well, in a way im serious. i think i see what your point is
but in my opnion too many nice designs have gone out of the
window because of either userability-reasons and/or hanging
on to old-skool conventions. at one point in my
web-experience i found it strange that some links wasnt
underlined, today that is pretty normal and accepted. have
you ever looked at un-experienced web-users? it is not like
they afraid to click on anything on a page (and often
doubleclick :-)) so in that sense i think they'll soon get
the hang of it:-)
> Finally, I never saw the argument for not using tables (I suppose I could
> search the archive ;).
you'll find some
> I think it's cool when CSS works, but there's a
> large number of clients where it doesn't work. Netscape 4.0x is still very
> common, and it doesn't work in that browser. Any idea what percent of
> browsers visiting modperl.apache.org are browsers that won't render that
> page? I doubt people will upgrade their browsers just because the
> modperl.apache.org site doesn't display correctly.
i think if we keep strict html/css there will be minor
damage for non-css browsers.
i mean it is not like those users cannot read the content
and navigate on the site, it will just not look the same (i hope).
you mention it
(http://www.bullitt.suite.dk/mod_perl_site/var_c/) does not
work in Netscape 4.0x. do you mean it looks like crap or is
it something that litterally doesnt work? i use netscape
4.79 and everything is ok (only slighly worse than ie 5.0
and opera 5.0, all macintosh)
thanks again
./allan
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: Comment from the outside
Posted by Stas Bekman <st...@stason.org>.
Bill Moseley wrote:
> Hi,
>
> I assume most of you saw that I set up an archive for the doc-dev list.
Nope, how could we know?
I see it now, it's great! Thanks Bill!
> (Stas, we should move those to perl.apache.org instead of
> search.apache.org/docs-dev/).
What do you mean by 'move'?
Thanks for passing the design comments, I'll let the experts among us to
comment on these :)
_____________________________________________________________________
Stas Bekman JAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide http://perl.apache.org/guide
mailto:stas@stason.org http://ticketmaster.com http://apacheweek.com
http://singlesheaven.com http://perl.apache.org http://perlmonth.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org