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 allan <la...@inet.uni2.dk> on 2001/12/20 00:18:13 UTC
mod_perl_site [design discussion]
hello all and thomas and carlos and stas
this is my first post to this list so i might have missed
something :-)
regarding the new design for the mod_perl site i have made a
rough suggestion.
since i dont know how we should aproach this idea of working
together all of us i have just thrown this into the ring.
it is based on thomas design and carlos topbar with a bit of
ASF-colors and a little bit of my own tidbits.
the reson for that is entirely because of the majority of
comments from the mod_perl_list voters.
please note the following.
it is only one html page (i havent had the time to try and
incorporate it in a build, which would also be a waste of
time before everyone can agree on a final design.)
it is non-functional.
it is currently only tested on a macintosh in ie5+ and
netscape 4.7+.
stas:
some of the html that is produced in the build procedure
just isnt valid. can we fix this somehow?
ok, the adress is
http://www.bullitt.suite.dk/mod_perl_site/var/download/binaries_example.html
be seeing you
./allan
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: mod_perl_site [design discussion]
Posted by Thomas Klausner <do...@zsi.at>.
Hi!
On Thu, Dec 20, 2001 at 11:22:08PM +0100, allan wrote:
> i dont really see a great need for the
> "toc"-inline-reference, so i think we should throw that away.
> and the "top"-reference really should not be like any other
> navigation style as it will always point to the current page
> page.
While I hardly ever use top-toc links myself, I think they might be useful
for some people. Therefor IMO they should be very unobtrusive, like they
were in Stas' original design (and in mine, BTW): simple, blue text links
(TOC TOP), no fuzz, easy to ignore, but still there if you need them.
> about link colors. no matter what any experts i think
> designers should choose any link-color they want as long as
> they are cinsistent through the site. i might be we loose a
I agree.
> > I don't like the idea of using HTML tables to structure a site. Tables are
> > good to present tabular data, but (IMO) shouldn't be used for page layout.
> while i agree on this point i have never found it pracically
> possible to avoid tables.
My current sugestion is table-free. The only "problem" is with old browser
that don't support CSS properly, but as the page degrades IMO very well,
that's no real problem. My suggestion doesn't want to /look/ the same on each
browser, but to /be usable/ with each browser, which it is. It probably is
not that nicelooking on browser with broken CSS support (like NS 4.x), but
there you can turn CSS off.
> 2) i am simply too busy during the next couple of weeks (im
> moving to vietnam)
wow, vietnam? I guess it's warm there, something clearly missing in Vienna
at this time.
--
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: mod_perl_site [design discussion]
Posted by allan <la...@inet.uni2.dk>.
Stas Bekman wrote:
>
> Thomas Klausner wrote:
>
> > Hi!
> >
> > On Fri, Dec 28, 2001 at 12:52:57AM +0800, Stas Bekman wrote:
> >
> >>So what do you think, should we drop [toc] or [top]? or should we keep both?
> >>
> > I'd say we drop TOC.
> >
> > * as both link to nearly the same place, I think one is enough
> > * TOP is understandable to people that don't speak english that well. TOC
> > (as an abbrevation of Table Of Content) is a little harder to understand
> > (at least I didn't know what it should mean when I first discovered it, but
> > after clicking on it and finding myself on a Table Of Content I got it...)
> > So I'd prefer TOP
>
> +1 on dropping TOC.
+1 on dropping TOC.
./allan
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: mod_perl_site [design discussion]
Posted by Thomas Klausner <do...@zsi.at>.
Hi!
On Fri, Dec 28, 2001 at 01:51:26AM +0800, Stas Bekman wrote:
> Yes we "will have/have" it already, I was just thinking that since we
> have a lot of empty space under the menu we could actually make some of
> the most significant sites outstanding. e.g.
>
> Sisters:
> --------
> ASF
> Apache
> perl.org
+1
--
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: mod_perl_site [design discussion]
Posted by Stas Bekman <st...@stason.org>.
Thomas Klausner wrote:
> Hi!
>
> On Fri, Dec 28, 2001 at 12:52:57AM +0800, Stas Bekman wrote:
>
>>So what do you think, should we drop [toc] or [top]? or should we keep both?
>>
> I'd say we drop TOC.
>
> * as both link to nearly the same place, I think one is enough
> * TOP is understandable to people that don't speak english that well. TOC
> (as an abbrevation of Table Of Content) is a little harder to understand
> (at least I didn't know what it should mean when I first discovered it, but
> after clicking on it and finding myself on a Table Of Content I got it...)
> So I'd prefer TOP
+1 on dropping TOC.
>>news@take23.org to start with. May have more in the future.
>>
> is take23.org actice still? The last post there is dated 2001-06-07.
I don't know. It may come back, we can always remove the link :) But I
think we do want to link for example to ASF and httpd.apache.org?
>>Alternatively I suggest to have two menu bars once for the internal
>>content and second for outgoing links? I dunno, just an idea. I'm not
>>
> What about a "Links" section?
Yes we "will have/have" it already, I was just thinking that since we
have a lot of empty space under the menu we could actually make some of
the most significant sites outstanding. e.g.
Sisters:
--------
ASF
Apache
perl.org
then we can add a feed from perl.org and other cool stuff
_____________________________________________________________________
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: mod_perl_site [design discussion]
Posted by Thomas Klausner <do...@zsi.at>.
Hi!
On Fri, Dec 28, 2001 at 12:52:57AM +0800, Stas Bekman wrote:
> So what do you think, should we drop [toc] or [top]? or should we keep both?
I'd say we drop TOC.
* as both link to nearly the same place, I think one is enough
* TOP is understandable to people that don't speak english that well. TOC
(as an abbrevation of Table Of Content) is a little harder to understand
(at least I didn't know what it should mean when I first discovered it, but
after clicking on it and finding myself on a Table Of Content I got it...)
So I'd prefer TOP
> news@take23.org to start with. May have more in the future.
is take23.org actice still? The last post there is dated 2001-06-07.
> Alternatively I suggest to have two menu bars once for the internal
> content and second for outgoing links? I dunno, just an idea. I'm not
What about a "Links" section?
--
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: mod_perl_site [design discussion]
Posted by Stas Bekman <st...@stason.org>.
>>So what do you think, should we drop [toc] or [top]? or should we keep both?
>>
>
> i always thought both were too much so i defineltly vote for
> toc only (this will also keep the widget small and not too obstructive).
Good. What others think?
>>But that's the whole deal about having a consistent look and feel.
>>Believe me once user gets lost and goes out of our site, he will notice.
>>
>>I doubt anybody notice where they are at the current site :) or :(
>>
>
>
> are you joking, with that breadcrumb, no-one is getting lost
I was talking about perl.apache.org as it is now. Not current design we
work on.
>>>>I agree though that we may want to mark specially outgoing links in the
>>>>menu, e.g. some small icon?
>>>>
>>>>
>>>which ones are outgoing from the menu?
>>>
>>news@take23.org to start with. May have more in the future.
>>
>
>>Alternatively I suggest to have two menu bars once for the internal
>>content and second for outgoing links? I dunno, just an idea. I'm not
>>sure whether news@take23.org should go down. Unless someone decide to do
>>the news on our site :)
>>
>
>
> well to my thinking i dont think any outgoing link belongs
> anywhere in the mod_perl menu.
> the mod_perl menu should be for mod_perl menu_items (items
> that you can read about 'on-site').
>
> but maybe two menus is not so bad an idea ...
+1 from me, what others think. Let's move to the voting system we use
here. First give your +1/+-0/-1 the give the reasoning, things will go
faster than.
The only problem I have with this particular link (take23) is that it's
a part of our site, the reason that it's outside is because some people
just couldn't wait forever to get the current site better, so they just
created their own.
Ideally we should have our own news section. Let's finish this design
and then see if we can tackle this issue as well.
In any case, let's solve the rest of the issues and leave this one to
the end. Sounds good?
_____________________________________________________________________
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: mod_perl_site [design discussion]
Posted by allan <la...@inet.uni2.dk>.
Stas Bekman wrote:
> > http://www.bullitt.suite.dk/mod_perl_site/examples/top/top_ex.html
> very neat, I like it (the button). But it should link to #toc and not #top.
ok, agreed
> So what do you think, should we drop [toc] or [top]? or should we keep both?
i always thought both were too much so i defineltly vote for
toc only (this will also keep the widget small and not too obstructive).
> But that's the whole deal about having a consistent look and feel.
> Believe me once user gets lost and goes out of our site, he will notice.
>
> I doubt anybody notice where they are at the current site :) or :(
are you joking, with that breadcrumb, no-one is getting lost
> >>I agree though that we may want to mark specially outgoing links in the
> >>menu, e.g. some small icon?
> >>
> >
> > which ones are outgoing from the menu?
>
> news@take23.org to start with. May have more in the future.
> Alternatively I suggest to have two menu bars once for the internal
> content and second for outgoing links? I dunno, just an idea. I'm not
> sure whether news@take23.org should go down. Unless someone decide to do
> the news on our site :)
well to my thinking i dont think any outgoing link belongs
anywhere in the mod_perl menu.
the mod_perl menu should be for mod_perl menu_items (items
that you can read about 'on-site').
but maybe two menus is not so bad an idea ...
./allan
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: mod_perl_site [design discussion]
Posted by Stas Bekman <st...@stason.org>.
allan wrote:
> Stas Bekman wrote:
>
>
>>Now I don't follow you. The only thing I was saying is that I think
>>prev-up-next and toc-top widgets are serving a similar role, so it'd be
>>nice to have them look alike.
>>
>
> ok i give in :-)
> lets keep them similar somehow, see a top-suggestion (:-))
> involving an image though, at
>
> http://www.bullitt.suite.dk/mod_perl_site/examples/top/top_ex.html
>
>
> not sure if they (top-widget) should be kept left-aligned ??
very neat, I like it (the button). But it should link to #toc and not #top.
So what do you think, should we drop [toc] or [top]? or should we keep both?
>>Remember that perl.com is also a commercial company so they may want to
>>realize the user that beware, you are about to leave our site and go
>>into unexplored, unsafe grounds. Not we, why do we want to distinguish
>>exiting points? A user can always click back. Adding to the fact that
>>it's going to be very clear once we finish the look-n-feel-the-same design.
>>
>
> well that might well be, but from a user-friendly point of
> view i just like the fact that i the user can see beforehand
> that this navigation goes to another site (commercial or
> whatever) and i even think in our case more so, because it
> is so full of information and a new user might get lost
> inside the wealh of information. also it is not always true
> that a user just can click back (some sites redirect the
> back function to their own sites - well not those we link to
> of course .-))
But that's the whole deal about having a consistent look and feel.
Believe me once user gets lost and goes out of our site, he will notice.
I doubt anybody notice where they are at the current site :) or :(
>>I agree though that we may want to mark specially outgoing links in the
>>menu, e.g. some small icon?
>>
>
> which ones are outgoing from the menu?
news@take23.org to start with. May have more in the future.
Alternatively I suggest to have two menu bars once for the internal
content and second for outgoing links? I dunno, just an idea. I'm not
sure whether news@take23.org should go down. Unless someone decide to do
the news on our site :)
_____________________________________________________________________
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: mod_perl_site [design discussion]
Posted by allan <la...@inet.uni2.dk>.
Stas Bekman wrote:
> Now I don't follow you. The only thing I was saying is that I think
> prev-up-next and toc-top widgets are serving a similar role, so it'd be
> nice to have them look alike.
ok i give in :-)
lets keep them similar somehow, see a top-suggestion (:-))
involving an image though, at
http://www.bullitt.suite.dk/mod_perl_site/examples/top/top_ex.html
not sure if they (top-widget) should be kept left-aligned ??
> I don't think this is a good idea. We are going to have many internal
> links in the documents. They should be clearly visible. If you look at
> the current guide (http://perl.apache.org/guide/), I've removed the
> underlining in the index.html and each document's Table of Contents,
> because it's obvious there that all the items are links and having them
> underlying makes things look worse. However inside the text it should be
> very clear whne things are links, when they are just <CODE></CODE> and
> <i></i>.
ok, fine.
> Remember that perl.com is also a commercial company so they may want to
> realize the user that beware, you are about to leave our site and go
> into unexplored, unsafe grounds. Not we, why do we want to distinguish
> exiting points? A user can always click back. Adding to the fact that
> it's going to be very clear once we finish the look-n-feel-the-same design.
well that might well be, but from a user-friendly point of
view i just like the fact that i the user can see beforehand
that this navigation goes to another site (commercial or
whatever) and i even think in our case more so, because it
is so full of information and a new user might get lost
inside the wealh of information. also it is not always true
that a user just can click back (some sites redirect the
back function to their own sites - well not those we link to
of course .-))
> I agree though that we may want to mark specially outgoing links in the
> menu, e.g. some small icon?
which ones are outgoing from the menu?
./allan
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: mod_perl_site [design discussion]
Posted by Stas Bekman <st...@stason.org>.
>>>prev-up-next-navigation (widget-style)
>>>top/toc-navigation (maybe this should just be good image? or
>>>a unique font)
>>>
>>These two should be of the same style IMHO. They are the in-document
>>navigation widgets.
>>
>
> well again i dont 100% follow you here.
> if by in-document you mean: all these pages belongs to
> "about", and all these pages belongs to "download" etc then
> i can understand you to some degree.
> the idea of this is similar to sites having certain colors
> or looks for a particluar item in their menus, no?
> only we use - luckily - the same colors across menu items.
> i think that from a webusers point of view it is more
> confusing than gaining.
> thomas mentioned these top|toc shouldnt be obstrctive and i agree,
> but any widget i guess will be a bit obstructive.
Now I don't follow you. The only thing I was saying is that I think
prev-up-next and toc-top widgets are serving a similar role, so it'd be
nice to have them look alike.
>>please no images for text, if later on we want to add another link next
>>to TOC/TOP we may not be able to create the image of exactly the same style.
>>Though I do think that we want to add a small images < and > indicating
>>the prev and next in the box [foo | up | bar]. I guess 'up' could be
>>replaced with a neat arrow up with ALT="^" for text browsers.
>>
>
> i did try an arrow up instead of the word "up". the problem
> with arrow up is
> that it points up and thus some might think it points to top
> of current page.
I agree.
>>I think the biggest problem is taking the underlying of links away. The
>>colour is less of a problem. It's not really needed in the menu, since
>>it's usually a graphics menu, so users are used to it. Not so for other
>>widgetry on the site.
>>
>
> well i just like the idea of underlining links "out of the
> house" (eg http://www.perl.com) to visualize for the users
> they are leaving the mod_perl site
> maybe we just have to compromise somewhere?
I don't think this is a good idea. We are going to have many internal
links in the documents. They should be clearly visible. If you look at
the current guide (http://perl.apache.org/guide/), I've removed the
underlining in the index.html and each document's Table of Contents,
because it's obvious there that all the items are links and having them
underlying makes things look worse. However inside the text it should be
very clear whne things are links, when they are just <CODE></CODE> and
<i></i>.
Remember that perl.com is also a commercial company so they may want to
realize the user that beware, you are about to leave our site and go
into unexplored, unsafe grounds. Not we, why do we want to distinguish
exiting points? A user can always click back. Adding to the fact that
it's going to be very clear once we finish the look-n-feel-the-same design.
I agree though that we may want to mark specially outgoing links in the
menu, e.g. some small icon?
_____________________________________________________________________
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: mod_perl_site [design discussion]
Posted by allan <la...@inet.uni2.dk>.
Stas Bekman wrote (Fri, 21 Dec 2001 06:54:32):
> which one is breadcrumb?
eh, home/download/etc (a breadcrumb is like a path
bascially, right?)
> > prev-up-next-navigation (widget-style)
> > top/toc-navigation (maybe this should just be good image? or
> > a unique font)
>
> These two should be of the same style IMHO. They are the in-document
> navigation widgets.
well again i dont 100% follow you here.
if by in-document you mean: all these pages belongs to
"about", and all these pages belongs to "download" etc then
i can understand you to some degree.
the idea of this is similar to sites having certain colors
or looks for a particluar item in their menus, no?
only we use - luckily - the same colors across menu items.
i think that from a webusers point of view it is more
confusing than gaining.
thomas mentioned these top|toc shouldnt be obstrctive and i agree,
but any widget i guess will be a bit obstructive.
> please no images for text, if later on we want to add another link next
> to TOC/TOP we may not be able to create the image of exactly the same style.
> Though I do think that we want to add a small images < and > indicating
> the prev and next in the box [foo | up | bar]. I guess 'up' could be
> replaced with a neat arrow up with ALT="^" for text browsers.
i did try an arrow up instead of the word "up". the problem
with arrow up is
that it points up and thus some might think it points to top
of current page.
> I think the biggest problem is taking the underlying of links away. The
> colour is less of a problem. It's not really needed in the menu, since
> it's usually a graphics menu, so users are used to it. Not so for other
> widgetry on the site.
well i just like the idea of underlining links "out of the
house" (eg http://www.perl.com) to visualize for the users
they are leaving the mod_perl site
maybe we just have to compromise somewhere?
./allan
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: mod_perl_site [design discussion]
Posted by Stas Bekman <st...@stason.org>.
allan wrote:
> but i think we should agree on how we seprate navigation-styles.
>
> i see 4 major element-types:
>
> menu-navigation ("boxed" or plain link style)
> breadcrumb (some unique style or possibly in a "long-row"-style)
which one is breadcrumb?
> prev-up-next-navigation (widget-style)
> top/toc-navigation (maybe this should just be good image? or
> a unique font)
These two should be of the same style IMHO. They are the in-document
navigation widgets.
please no images for text, if later on we want to add another link next
to TOC/TOP we may not be able to create the image of exactly the same style.
Though I do think that we want to add a small images < and > indicating
the prev and next in the box [foo | up | bar]. I guess 'up' could be
replaced with a neat arrow up with ALT="^" for text browsers.
> i dont really see a great need for the
> "toc"-inline-reference, so i think we should throw that away.
> and the "top"-reference really should not be like any other
> navigation style as it will always point to the current page
> page.
that's fine. It's mainly there to make the design future extendable. So
if want to add extra links next to the TOC or TOP, whichever you prefer
to stay there, it'll be ready and won't require new discussion. So keep
the two there for now and at the end we will <!-- --> the second button.
I do like the alternating reversed colors though :)
> about link colors. no matter what any experts i think
> designers should choose any link-color they want as long as
> they are cinsistent through the site. i might be we loose a
> little on userbility on link colors but we also have to look
> at our potential "customers". i reckon anyone visiting the
> mod perl site will be able to navigate it even if the link
> colors differs from the standard and even though they are
> not underlined. also i guess, they will apear standard on
> non-stylesheet complaint or off-stylesheet browers.
I think the biggest problem is taking the underlying of links away. The
colour is less of a problem. It's not really needed in the menu, since
it's usually a graphics menu, so users are used to it. Not so for other
widgetry on the site.
_____________________________________________________________________
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: mod_perl_site [design discussion]
Posted by allan <la...@inet.uni2.dk>.
here are my comments from the latest discussions.
Stas Bekman wrote:
> :: * The TOP^ link is not obvious that it's link. I think it'd be nice to
> :: have it of the same style as [prev - up - next] widget, so it'll be
> :: clear what are navigation widgets.
> ::
> :: * The [prev - up - next] widget is neat but should be centered and
> :: appear on the top as well. Before the table of contents I guess.
Jonathan M. Hollin wrote:
> I strongly agree with both of Stas' points here. From a useability point of
> view, I'd also recommend that you don't deviate from standard link colours
> (blue - unvisited, purple - visited) - navigational cues are critical to any
> sites success. Bruce Tognazzini, Vincent Flanders, David Siegel and the
> irrepressible Nielson have all lectured widely as to why, so I don't think I
> need to reiterate here.
i dont agree 100% on this.
but i think we should agree on how we seprate navigation-styles.
i see 4 major element-types:
menu-navigation ("boxed" or plain link style)
breadcrumb (some unique style or possibly in a "long-row"-style)
prev-up-next-navigation (widget-style)
top/toc-navigation (maybe this should just be good image? or
a unique font)
i dont really see a great need for the
"toc"-inline-reference, so i think we should throw that away.
and the "top"-reference really should not be like any other
navigation style as it will always point to the current page
page.
about link colors. no matter what any experts i think
designers should choose any link-color they want as long as
they are cinsistent through the site. i might be we loose a
little on userbility on link colors but we also have to look
at our potential "customers". i reckon anyone visiting the
mod perl site will be able to navigate it even if the link
colors differs from the standard and even though they are
not underlined. also i guess, they will apear standard on
non-stylesheet complaint or off-stylesheet browers.
> * Finally the font looks quite bad on mozilla/linux. There is not enough
> vertical spacing and I guess there are better standard fonts, to make it
> easier to read. I think Thomas' font selection was very good
well in my own opnion microsoft have done _one_ good job in
creating the best screenfont currently in existence.
this is probably a matter of personal taste and i certainly
dont mind helvetica.
by the way both letter-spacing and line-height is easly fixable.
> which also means that the original Thomas' design problem wasn't solved
> yet. If the page has a little or no content the content box will shrink
> and look bad when you browse pages. And it'll move the left part of the
> page closer to the center. Somehow we must make it fixed, so when you
> flip between pages, the main parts of the page don't move.
either i dont understand this problem or it doesnt happen on
any of my browsers.
the left navigation is has a fixed width (200px).
the content is relatively fixed so as when you decrease the
window-size tonly the content area scales down (*var_b*).
Thomas Klausner wrote:
> I don't (want to) work to gurantee cross-browser capability, but standards
> complienance. If the browsers are not standard compatible, it's the
> browser manufactureres problem, not mine. You only have to inform the
> users politly that, if they are seeing crap, it's their browsers fault.
i agree 100% with this
> I don't like the idea of using HTML tables to structure a site. Tables are
> good to present tabular data, but (IMO) shouldn't be used for page layout.
while i agree on this point i have never found it pracically
possible to avoid tables.
> Some new comments:
> I think that the background color of the breadcrumb trail (never knew it
> was called that, BTW) and the Table of Contents can be done better using
> CSS.
well i must disagree, those are ASF-colors and i honestly
think they are quite great. in fact i was quite surprised to
see such a great color-scheme from the ASF when i revisited
the site. (they are quite new arent they?)
> Allan, do you think you could do a "proper" release of your new design, so
> we can work on that?
i really would love to but
1) shouldnt we first all pin-point down a more narrow design guideline
2) i am simply too busy during the next couple of weeks (im
moving to vietnam)
Thomas Eibner wrote:
> What ever you guys decide on in the end I hope you will come up with
> something that enhances the documentation and doesn't distract from the
> actual content.
very good point which is often forgotten ...
./allan
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: mod_perl_site [design discussion]
Posted by Stas Bekman <st...@stason.org>.
Thomas Klausner wrote:
> Hi!
>
> Just some comments on the stuff posted so far
>
> Stas:
>
>>* The menu is not fixed and may grow, so it's probably the best to keep
>>it as a single column on the left (but trying to keep it as narrow as
>>possible). Also in order to avoid unnecessary scrolling on short pages,
>>it's probably the best to keep the head of the page as short as possible.
>>
> I'd also prefer the navbar on the lefthand side.
>
>
>>* The [prev - up - next] widget is neat but should be centered and
>>appear on the top as well. Before the table of contents I guess.
>>
> I agree with that.
>
> Jonathan:
>
>>This isn't a problem. Use HTML's <Table>, use a fixed with for the column,
>>and set the main tables width to 100%
>>
> I don't like the idea of using HTML tables to structure a site. Tables are
> good to present tabular data, but (IMO) shouldn't be used for page layout.
>
> I know that a lot of sites are doing this, but this isn't a reason to do
> it, too (cf Microsoft).
>
>
>>:: I think that this problem can be fixed by making the 'where I'm in the
>>:: site' widget bar of a fixed size? Or is it a bad idea?
>>Bad idea - what happens at different resolutions? Horizontal scroll bars
>>at low res and masses of whitespace at high res.
>>
> I would suggest a fixed width, either in pixels or in percent, or a
> mixture.
>
> In my initial submission I used fixed widths for the left navbar, and a
> percentual value for the content box. The only problem was when text
> inside a <pre> tag was bigger then the browser window (but I think that
> would happen too if you use tables)
You miss one problem that I see at least with mozilla (check your
original design). When the content part is empty or there is too little
to fill the whole width, what happens is the main box's border shrinks.
What we want is to have the skeleton fixed, so when you flip through
pages, you see the content changed but not the base. Can you reproduce
the problem?
e.g. see:
http://domm.zsi.at/modperl-site-domm/stats/index.html
We still have the problem with <pre> which is too wide, but I think
what's you've created is pretty good. So we can probably live with this
inconvenience. The document writers should be aware of this problem and
try to make the code sections under 80 chars width. (You have the same
problem when you write a book). Basically I say this is not a designer's
problem so we delegate it to the author.
But I still don't like the idea of having the main box's fixed width. I
like Jonathan's idea of ensuring that there is always enough width to
make the box stable.
Hmm, may be you always insert
print ' ' x 80; ? but we lose then one line, let's how it works out.
>
>
>>All but very basic CSS is still a
>>non-starter if you want to guarantee cross-browser capability.
>>
> I don't (want to) work to gurantee cross-browser capability, but standards
> complienance. If the browsers are not standard compatible, it's the
> browser manufactureres problem, not mine. You only have to inform the
> users politly that, if they are seeing crap, it's their browsers fault.
>
> BTW, one of the big advantages of CSS is that you can switch them off, and
> that sites using CSS are usable with non-graphic browser (lynx, etc)
I agree with Thomas here.
> Some new comments:
> I think that the background color of the breadcrumb trail (never knew it
> was called that, BTW) and the Table of Contents can be done better using
> CSS.
>
> Allan, do you think you could do a "proper" release of your new design, so
> we can work on that?
>
> What about putting the site distribution in CVS somewhere? I have got a
> CVS running here, I think I could put it there, but maybe Stas wants the
> src part more accessible to him? Should we split the distro into src and
> tmpl ?
It'll be all in cvs. The problem is that I didn't decide yet how exactly
to layout the docs. The problem goes like this:
We have 3 repositories.
modperl-2.0
modperl-docs
modperl-site
Now both, modperl-2.0 and modperl-site want to share modperl-docs, since
you want to find the pods in the modperl-2.0/docs of the source
distribution and you want to be able to use the same docs for the
modperl-site repository. And now remember that there will be a
transition period where the old site is still there and the new one is
not ready for the production.
Originally I wanted to kill modperl-site rep completely, but then I
realized that modperl-docs shouldn't include the non-docs, so it's going
to be like this:
modperl-2.0/docs <-- modperl-docs
modperl-site/src/docs <-- modperl-docs
simply you set the CVSROOT/modules to embed modperl-docs at the desired
subdirectory (using -d).
Hence if you prefer to store the design temporarely elsewhere it'd be
great. I believe that I'll get back to work on the layout and new site
next week and so I will start doing the cvs reps changes. But may be
it'll take longer.
As for the separation of src and tmpl, there is no problem. Leave the
src as it is, and just work on the tmpl with whatever is in src. The two
things are unrelated (which is great!). Also Allan mentioned that some
of the src docs are not standard complient, that's fine, we will fix
that later.
Once tmpl is more or less satisfying we just grab it and use it.
Is that OK?
> I don't know if I find some time to make a new design suggestion in the
> next few days (Christmas is coming ...), but I think I'll do something
> before New Year.
Yeah, let's make a nice present for the modperl community for the New
Year! :)
_____________________________________________________________________
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: mod_perl_site [design discussion]
Posted by allan <la...@inet.uni2.dk>.
hello guys
what great input!
there are plenty of ideas flying around ... impossible to
react on all of them
i know thomas is quite busy at the moment and so am i.
so i havent had much time to react on much, but for the
curious there is a small revision (var_b) of yesterdays
desigb, here:
http://www.bullitt.suite.dk/mod_perl_site/var_b/download/binaries_example.html
(ie5 && netscape > 5 ) (!)
actually theres also a pseudo layout for "about". click on
"about"-link or go to:
http://www.bullitt.suite.dk/mod_perl_site/var_b/about/about.html
i will post all my comments later tonight - too much to do
right now, sorry.
./allan
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: mod_perl_site [design discussion] front page
Posted by Stas Bekman <st...@stason.org>.
Thomas Eibner wrote:
> On Fri, Dec 21, 2001 at 03:24:21AM +0800, Stas Bekman wrote:
>
>>[adjusting subject]
>>
>>Thomas Eibner wrote:
>> > I like the idea in the picture. It just makes it hard to follow up on the
>> > pages underneath it without following the colors of it.
>>
>>Sorry, I didn't get what you mean.
>>
>
> I just don't like the idea of having a different frontpage (layout-wise)
> than all pages underneath. It makes it seem a bit messy to me, but then
> again I never was able to come up with anything really good either.
Agreed, I liked it because it makes the front page very attractive. Well
we could use these squares on the pages as well (only a single relevant
square), something like:
mod_perl logo | content
------------------|
square 'download' | goes here
But I guess we can try this later if you like the idea.
_____________________________________________________________________
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: mod_perl_site [design discussion] front page
Posted by Thomas Eibner <th...@stderr.net>.
On Fri, Dec 21, 2001 at 03:24:21AM +0800, Stas Bekman wrote:
> [adjusting subject]
>
> Thomas Eibner wrote:
> > I like the idea in the picture. It just makes it hard to follow up on the
> > pages underneath it without following the colors of it.
>
> Sorry, I didn't get what you mean.
I just don't like the idea of having a different frontpage (layout-wise)
than all pages underneath. It makes it seem a bit messy to me, but then
again I never was able to come up with anything really good either.
--
Thomas Eibner <http://thomas.eibner.dk/> DnsZone <http://dnszone.org/>
mod_pointer <http://stderr.net/mod_pointer>
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: mod_perl_site [design discussion] front page
Posted by Stas Bekman <st...@stason.org>.
[adjusting subject]
Thomas Eibner wrote:
> On Fri, Dec 21, 2001 at 03:00:00AM +0800, Stas Bekman wrote:
>
>>On unrelated issue, one of the users who wished to remain anonymous have
>>send me this (attached) for the front page. I love this! What do you
think?
>>
>
> I like the idea in the picture. It just makes it hard to follow up on the
> pages underneath it without following the colors of it.
Sorry, I didn't get what you mean.
_____________________________________________________________________
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: mod_perl_site [design discussion]
Posted by Thomas Eibner <th...@stderr.net>.
On Fri, Dec 21, 2001 at 03:00:00AM +0800, Stas Bekman wrote:
> On unrelated issue, one of the users who wished to remain anonymous have
> send me this (attached) for the front page. I love this! What do you think?
I like the idea in the picture. It just makes it hard to follow up on the
pages underneath it without following the colors of it.
--
Thomas Eibner <http://thomas.eibner.dk/> DnsZone <http://dnszone.org/>
mod_pointer <http://stderr.net/mod_pointer>
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
Re: mod_perl_site [design discussion]
Posted by Stas Bekman <st...@stason.org>.
Thomas Eibner wrote:
> On Thu, Dec 20, 2001 at 06:05:20PM -0000, Jonathan M. Hollin wrote:
>
>>Thomas,
>>
>>:: I'd also prefer the navbar on the lefthand side.
>>
>>Navigation is critical to the whole site, I'm sure you'll agree. When I
>>design a website I consider the BIG sites (amazon, yahoo, imdb, etc, etc)
>>and learn from them. They have all evolved their useability criteria over
>>the years based on user testing, public feedback and log analysis. We
>>should all take advantage of the experience and knowledge they've paid for.
>>
>
> Navigation is indeed critical, more so for sites like Amazon that have
> a LOT of things they would like for you to be able to see. So I don't
> think you can compare the two types of sites like that. I too use a
> navigation bar on the top of the page for most of the projects I've been
> working on. But it doesn't necessarily mean it's the best choice for the
> job.
Having the menu on the top, meaning stealing from the valuable top
space. Which means that if you have short pages you are doomed to scroll
even if the page could fit into one screen. That's probably an
important factor, but currently most of the documentation pages are
long. Though there will be split version of the docs coming in the future.
What I don't like about the menu on the top is that when you add new
items, it may become visually unballanced, whereas the menu on the left
is always ballanced, since it's a single column.
On the other hand, if we have nothing on the left side, we can better
fit into a single page without horizontal scrolling. But according to
the usability experts, it's hard to read long lines, so having the menu
on the left size makes the content narrower and easier to read.
Also remember that our menu is relatively big, and if you put two pages
side by side (with the menu on the top and on the side) you will
probably find out that it's easier to locate the items on the single
column menu (left), rather than multicolumn one (top). That's again
human's habit, unless you read japanese :)
well I realize that I'm just bragging here, I'll leave to you the
experts to decide what's the best way to go.
On unrelated issue, one of the users who wished to remain anonymous have
send me this (attached) for the front page. I love this! What do you think?
_____________________________________________________________________
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/
Re: mod_perl_site [design discussion]
Posted by Thomas Eibner <th...@stderr.net>.
On Thu, Dec 20, 2001 at 06:05:20PM -0000, Jonathan M. Hollin wrote:
> Thomas,
>
> :: I'd also prefer the navbar on the lefthand side.
>
> Navigation is critical to the whole site, I'm sure you'll agree. When I
> design a website I consider the BIG sites (amazon, yahoo, imdb, etc, etc)
> and learn from them. They have all evolved their useability criteria over
> the years based on user testing, public feedback and log analysis. We
> should all take advantage of the experience and knowledge they've paid for.
Navigation is indeed critical, more so for sites like Amazon that have
a LOT of things they would like for you to be able to see. So I don't
think you can compare the two types of sites like that. I too use a
navigation bar on the top of the page for most of the projects I've been
working on. But it doesn't necessarily mean it's the best choice for the
job.
> I would suggest that the primary menu occupies an area at the top-left of
> the screen, the breadcrumb trail be sited as close to the top of the
> document as possible and an additional panel of links at the bottom of each
> page.
What ever you guys decide on in the end I hope you will come up with
something that enhances the documentation and doesn't distract from the
actual content.
--
Thomas Eibner <http://thomas.eibner.dk/> DnsZone <http://dnszone.org/>
mod_pointer <http://stderr.net/mod_pointer>
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
RE: mod_perl_site [design discussion]
Posted by "Jonathan M. Hollin" <ne...@digital-word.com>.
Thomas,
:: I'd also prefer the navbar on the lefthand side.
Navigation is critical to the whole site, I'm sure you'll agree. When I
design a website I consider the BIG sites (amazon, yahoo, imdb, etc, etc)
and learn from them. They have all evolved their useability criteria over
the years based on user testing, public feedback and log analysis. We
should all take advantage of the experience and knowledge they've paid for.
I would suggest that the primary menu occupies an area at the top-left of
the screen, the breadcrumb trail be sited as close to the top of the
document as possible and an additional panel of links at the bottom of each
page.
Why?
1) Today, most users expect to see navigation in the upper left of the
screen - don't disorientate them.
2) The top of the document is the most natural location for the breadcrumb
trail (read any of Neilson's articles about muscle memory and hot edges to
appreciate why).
3) Users usually finish reading a page at the bottom, so primary links
there are more than just a convenience.
I hate to keep on with the shameless plugs but, again, look at
http://wypug.pm.org/. Also look at amazon.com, yahoo.com, and so on.
:: I don't like the idea of using HTML tables to structure a site.
:: Tables are
:: good to present tabular data, but (IMO) shouldn't be used for
:: page layout.
I still argue that tables offer the most control over positioning. However,
I have NOT considered textual browsers such as Lynx. Does Lynx ignore
tables? Is Lynx an issue? I've never even seen it in my web logs.
:: I know that a lot of sites are doing this, but this isn't a reason to do
:: it, too (cf Microsoft).
This is where I disagree. "A lot of sites are doing this" - for a reason.
Learn from their mistakes/research/testing... don't start over.
:: In my initial submission I used fixed widths for the left navbar, and a
:: percentual value for the content box. The only problem was when text
:: inside a <pre> tag was bigger then the browser window (but I think that
:: would happen too if you use tables)
As far as I'm aware you will never get around this. "<pre> ... </pre>"
tells the browser that the content between the tags is pre-formatted and
that the browser should therefore not impose any additional formatting.
This is correct behaviour and totally appropriate.
:: BTW, one of the big advantages of CSS is that you can switch
:: them off, and
:: that sites using CSS are usable with non-graphic browser (lynx, etc)
Granted.
:: Some new comments:
:: I think that the background color of the breadcrumb trail (never knew it
:: was called that, BTW) and the Table of Contents can be done better using
:: CSS.
I agree. I don't oppose using CSS, that's not my argument. I too use CSS
for font control, colours, etc.
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: mod_perl_site [design discussion]
Posted by Thomas Klausner <do...@zsi.at>.
Hi!
Just some comments on the stuff posted so far
Stas:
> * The menu is not fixed and may grow, so it's probably the best to keep
> it as a single column on the left (but trying to keep it as narrow as
> possible). Also in order to avoid unnecessary scrolling on short pages,
> it's probably the best to keep the head of the page as short as possible.
I'd also prefer the navbar on the lefthand side.
> * The [prev - up - next] widget is neat but should be centered and
> appear on the top as well. Before the table of contents I guess.
I agree with that.
Jonathan:
> This isn't a problem. Use HTML's <Table>, use a fixed with for the column,
> and set the main tables width to 100%
I don't like the idea of using HTML tables to structure a site. Tables are
good to present tabular data, but (IMO) shouldn't be used for page layout.
I know that a lot of sites are doing this, but this isn't a reason to do
it, too (cf Microsoft).
>:: I think that this problem can be fixed by making the 'where I'm in the
>:: site' widget bar of a fixed size? Or is it a bad idea?
> Bad idea - what happens at different resolutions? Horizontal scroll bars
> at low res and masses of whitespace at high res.
I would suggest a fixed width, either in pixels or in percent, or a
mixture.
In my initial submission I used fixed widths for the left navbar, and a
percentual value for the content box. The only problem was when text
inside a <pre> tag was bigger then the browser window (but I think that
would happen too if you use tables)
> All but very basic CSS is still a
> non-starter if you want to guarantee cross-browser capability.
I don't (want to) work to gurantee cross-browser capability, but standards
complienance. If the browsers are not standard compatible, it's the
browser manufactureres problem, not mine. You only have to inform the
users politly that, if they are seeing crap, it's their browsers fault.
BTW, one of the big advantages of CSS is that you can switch them off, and
that sites using CSS are usable with non-graphic browser (lynx, etc)
Some new comments:
I think that the background color of the breadcrumb trail (never knew it
was called that, BTW) and the Table of Contents can be done better using
CSS.
Allan, do you think you could do a "proper" release of your new design, so
we can work on that?
What about putting the site distribution in CVS somewhere? I have got a
CVS running here, I think I could put it there, but maybe Stas wants the
src part more accessible to him? Should we split the distro into src and
tmpl ?
I don't know if I find some time to make a new design suggestion in the
next few days (Christmas is coming ...), but I think I'll do something
before New Year.
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
RE: mod_perl_site [design discussion]
Posted by "Jonathan M. Hollin" <ne...@digital-word.com>.
:: I like this workaround, but do we really want to add almost half
:: a kilobyte
:: to each webpage for this? It just looks like such a waste of bandwidth
:: (unless of course it's gzip-ed).
Use mod_gzip definitely. But also consider that the mod_perl site will have
no graphics (bar the logo) and thus I think we can manage 512 bytes.
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: mod_perl_site [design discussion]
Posted by Thomas Eibner <th...@stderr.net>.
On Thu, Dec 20, 2001 at 06:18:38PM -0000, Jonathan M. Hollin wrote:
> <!-- Table auto-fill -->
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> <!-- end -->
I like this workaround, but do we really want to add almost half a kilobyte
to each webpage for this? It just looks like such a waste of bandwidth
(unless of course it's gzip-ed).
--
Thomas Eibner <http://thomas.eibner.dk/> DnsZone <http://dnszone.org/>
mod_pointer <http://stderr.net/mod_pointer>
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-dev-unsubscribe@perl.apache.org
For additional commands, e-mail: docs-dev-help@perl.apache.org
RE: mod_perl_site [design discussion]
Posted by "Jonathan M. Hollin" <ne...@digital-word.com>.
:: So you add it to all pages, no matter how much content do they have.
Yes, it's on the template itself so no additional work need ever be done.
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: mod_perl_site [design discussion]
Posted by Stas Bekman <st...@stason.org>.
Jonathan M. Hollin wrote:
> Stas,
>
> :: OK, perhaps you can explain in more details of what do you mean by
> :: adding nbsp's. Do you always add them, or only when your script learns
> :: that the widest line in the autogenerated content is not long enough?
> :: Can you give an algorithm of nbsp's insertion: when, how many.
>
> I presume the site is to be template-based? If so, then you can either
> script them or just add them to the template. Looking at the WYPUG site I
> realise that I did the latter (as opposed to scripting the insertion as per
> my original suggestion), but either way works.
>
> So my template contains the following:
>
> <!-- Table auto-fill -->
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> <!-- end -->
>
> Notice the normal space after each " "? This is really important -
> without this you end up with one big, non-breaking line. Reduce the screen
> resolution or window width and, you guessed it, horizontal scroll bars.
So you add it to all pages, no matter how much content do they have.
Sounds like a really smart idea! That most probably fixes the caveat of
Thomas' table-less design with "slim" pages. Folks can you please try to
apply this? Thanks!
> The above looks rather heavy, but the impact on the page is minimal (see ...
> blah, blah, blah). On high resolution displays (or large window widths)
> you'll never know they're there. On small windows (or resolutions) you just
> get a whitespace at the end of the content. It's a kludge I know, but
> infinitely better than distorted tables.
>
> I'll stress again, if anyone knows of an alternative solution (regardless of
> the outcome of the mod_perl site design) please let me know.
>
> Regards,
>
> 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
>
--
_____________________________________________________________________
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: mod_perl_site [design discussion]
Posted by "Jonathan M. Hollin" <ne...@digital-word.com>.
Stas,
:: OK, perhaps you can explain in more details of what do you mean by
:: adding nbsp's. Do you always add them, or only when your script learns
:: that the widest line in the autogenerated content is not long enough?
:: Can you give an algorithm of nbsp's insertion: when, how many.
I presume the site is to be template-based? If so, then you can either
script them or just add them to the template. Looking at the WYPUG site I
realise that I did the latter (as opposed to scripting the insertion as per
my original suggestion), but either way works.
So my template contains the following:
<!-- Table auto-fill -->
<!-- end -->
Notice the normal space after each " "? This is really important -
without this you end up with one big, non-breaking line. Reduce the screen
resolution or window width and, you guessed it, horizontal scroll bars.
The above looks rather heavy, but the impact on the page is minimal (see ...
blah, blah, blah). On high resolution displays (or large window widths)
you'll never know they're there. On small windows (or resolutions) you just
get a whitespace at the end of the content. It's a kludge I know, but
infinitely better than distorted tables.
I'll stress again, if anyone knows of an alternative solution (regardless of
the outcome of the mod_perl site design) please let me know.
Regards,
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: mod_perl_site [design discussion]
Posted by Stas Bekman <st...@stason.org>.
> :: The problem is the site is autogenerated, you cannot and shouldn't do
> :: manual adjustments like padding with nbsp. The aim is to be able
to drop
> :: in any document in "any" format and it'll automagically fit into
> :: the site.
>
> I don't see the problem. My WYPUG site is also 100% dynamic. I
developed
> using IE6 on Windows and thought everything was great. I tested with
IE on
> the Mac - still great (once I'd found a transportable font combination),
> then I tested with NS6 - and it all fell apart. The non-breaking spaces
> (inserted automatically by my script) pulled it all together. I
haven't yet
> seen it with Konqueror or NS on *nix, but I have Linux users and
haven't had
> any negative feedback. The spaces are obviously invisible and don't
seem to
> have any detrimental effect whatsoever, regardless of the length of
content
> I publish.
>
> To summarise, the non-breaking space solution works. If you find an
> alternative that has the same effect please let me know as I'd
implement it
> myself on WYPUG
OK, perhaps you can explain in more details of what do you mean by
adding nbsp's. Do you always add them, or only when your script learns
that the widest line in the autogenerated content is not long enough?
Can you give an algorithm of nbsp's insertion: when, how many.
Thanks.
--
_____________________________________________________________________
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: mod_perl_site [design discussion]
Posted by "Jonathan M. Hollin" <ne...@digital-word.com>.
Stas,
:: but how do you know which is the right width? Think of different
:: browsers/platforms/screen sizes/
That's exactly what I was thinking about. :-)
:: The problem is the site is autogenerated, you cannot and shouldn't do
:: manual adjustments like padding with nbsp. The aim is to be able to drop
:: in any document in "any" format and it'll automagically fit into
:: the site.
I don't see the problem. My WYPUG site is also 100% dynamic. I developed
using IE6 on Windows and thought everything was great. I tested with IE on
the Mac - still great (once I'd found a transportable font combination),
then I tested with NS6 - and it all fell apart. The non-breaking spaces
(inserted automatically by my script) pulled it all together. I haven't yet
seen it with Konqueror or NS on *nix, but I have Linux users and haven't had
any negative feedback. The spaces are obviously invisible and don't seem to
have any detrimental effect whatsoever, regardless of the length of content
I publish.
To summarise, the non-breaking space solution works. If you find an
alternative that has the same effect please let me know as I'd implement it
myself on WYPUG
:: > :: I think that this problem can be fixed by making the 'where
:: I'm in the
:: > :: site' widget bar of a fixed size? Or is it a bad idea?
:: >
:: > Bad idea - what happens at different resolutions? Horizontal
:: scroll bars at
:: > low res and masses of whitespace at high res.
::
:: Well, too bad stylesheets/html don't have a concept of something like
:: width="at least 30%" or something like that, so you could let the pages
:: to autogrow (and add the horizontal scroll bar) when there is a very
:: wide content but keep the minimum width for empty or narrow
:: content pages.
I agree totally - maybe in the next revision eh. Web-designers are well
used to work-around solutions by now. All but very basic CSS is still a
non-starter if you want to guarantee cross-browser capability.
Kindest regards,
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: mod_perl_site [design discussion]
Posted by Stas Bekman <st...@stason.org>.
Jonathan M. Hollin wrote:
> :: * The mod_perl box in the upper left corner is a way too big :) I think
> :: Thomas' transparent mod_perl box is neat. Should be there, but not to
> :: try to be too outstanding. There is not much added value to it once you
> :: know you are on the mod_perl site and it distructs from the rest of the
> :: content.
>
> I agree that the box is too big, but I think it's naive to suggest that
> there is "not much added value to it once you
> know you are on the mod_perl site" - if this were a commercial site, then
> I'd talk about branding and so on. In this case, it's all about identity
> and reinforcement. I'd wager that it's one of the mst important elements of
> the site but, of course, it depends on your point of view.
you are right, The only argument left is that it's too big :)
> :: which also means that the original Thomas' design problem wasn't solved
> :: yet. If the page has a little or no content the content box will shrink
> :: and look bad when you browse pages. And it'll move the left part of the
> :: page closer to the center. Somehow we must make it fixed, so when you
> :: flip between pages, the main parts of the page don't move.
>
> This isn't a problem. Use HTML's <Table>, use a fixed with for the column,
but how do you know which is the right width? Think of different
browsers/platforms/screen sizes/
> and set the main tables width to 100% (so that it will grab all available
> space). To prevent the table from "collapsing" when there is minimal
> content, pad the table out with a series of non-breaking spaces (HTML -
> ). Do NOT use the "invisible pixel" trick to pad the width out, else
> you will end up with a display that's not totally scalable for different
> window sizes and/or screen resolutions. See the source of any page on the
> WYPUG website (http://wypug.pm.org/) for an example.
The problem is the site is autogenerated, you cannot and shouldn't do
manual adjustments like padding with nbsp. The aim is to be able to drop
in any document in "any" format and it'll automagically fit into the site.
> :: I think that this problem can be fixed by making the 'where I'm in the
> :: site' widget bar of a fixed size? Or is it a bad idea?
>
> Bad idea - what happens at different resolutions? Horizontal scroll bars at
> low res and masses of whitespace at high res.
Well, too bad stylesheets/html don't have a concept of something like
width="at least 30%" or something like that, so you could let the pages
to autogrow (and add the horizontal scroll bar) when there is a very
wide content but keep the minimum width for empty or narrow content pages.
_____________________________________________________________________
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: mod_perl_site [design discussion]
Posted by "Jonathan M. Hollin" <ne...@digital-word.com>.
:: * The mod_perl box in the upper left corner is a way too big :) I think
:: Thomas' transparent mod_perl box is neat. Should be there, but not to
:: try to be too outstanding. There is not much added value to it once you
:: know you are on the mod_perl site and it distructs from the rest of the
:: content.
I agree that the box is too big, but I think it's naive to suggest that
there is "not much added value to it once you
know you are on the mod_perl site" - if this were a commercial site, then
I'd talk about branding and so on. In this case, it's all about identity
and reinforcement. I'd wager that it's one of the mst important elements of
the site but, of course, it depends on your point of view.
:: * The TOP^ link is not obvious that it's link. I think it'd be nice to
:: have it of the same style as [prev - up - next] widget, so it'll be
:: clear what are navigation widgets.
::
:: * The [prev - up - next] widget is neat but should be centered and
:: appear on the top as well. Before the table of contents I guess.
I strongly agree with both of Stas' points here. From a useability point of
view, I'd also recommend that you don't deviate from standard link colours
(blue - unvisited, purple - visited) - navigational cues are critical to any
sites success. Bruce Tognazzini, Vincent Flanders, David Siegel and the
irrepressible Nielson have all lectured widely as to why, so I don't think I
need to reiterate here.
Also, well done for including a breadcrumb trail. Good show! :-)
:: * Finally the font looks quite bad on mozilla/linux. There is not enough
:: vertical spacing and I guess there are better standard fonts, to make it
:: easier to read. I think Thomas' font selection was very good
I've found that <Font Face="Arial, Verdana, Helvetica"> seems to be able to
render across most browsers/platforms.
:: which also means that the original Thomas' design problem wasn't solved
:: yet. If the page has a little or no content the content box will shrink
:: and look bad when you browse pages. And it'll move the left part of the
:: page closer to the center. Somehow we must make it fixed, so when you
:: flip between pages, the main parts of the page don't move.
This isn't a problem. Use HTML's <Table>, use a fixed with for the column,
and set the main tables width to 100% (so that it will grab all available
space). To prevent the table from "collapsing" when there is minimal
content, pad the table out with a series of non-breaking spaces (HTML -
). Do NOT use the "invisible pixel" trick to pad the width out, else
you will end up with a display that's not totally scalable for different
window sizes and/or screen resolutions. See the source of any page on the
WYPUG website (http://wypug.pm.org/) for an example.
:: I think that this problem can be fixed by making the 'where I'm in the
:: site' widget bar of a fixed size? Or is it a bad idea?
Bad idea - what happens at different resolutions? Horizontal scroll bars at
low res and masses of whitespace at high res.
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: mod_perl_site [design discussion]
Posted by Stas Bekman <st...@stason.org>.
> this is my first post to this list so i might have missed
> something :-)
Nope, you didn't miss anything :)
> regarding the new design for the mod_perl site i have made a
> rough suggestion.
> since i dont know how we should aproach this idea of working
> together all of us i have just thrown this into the ring.
>
>
> it is based on thomas design and carlos topbar with a bit of
> ASF-colors and a little bit of my own tidbits.
> the reson for that is entirely because of the majority of
> comments from the mod_perl_list voters.
Looks good. My "minus" comments :) :
* The title should be on the left. The humans are used to read left to
right, let's not break the expectations.
* The menu is not fixed and may grow, so it's probably the best to keep
it as a single column on the left (but trying to keep it as narrow as
possible). Also in order to avoid unnecessary scrolling on short pages,
it's probably the best to keep the head of the page as short as possible.
* The copyright's place is in the tail, there is no added value for
users to eyeball it unless you work for ORA :)
* The mod_perl box in the upper left corner is a way too big :) I think
Thomas' transparent mod_perl box is neat. Should be there, but not to
try to be too outstanding. There is not much added value to it once you
know you are on the mod_perl site and it distructs from the rest of the
content.
* The TOP^ link is not obvious that it's link. I think it'd be nice to
have it of the same style as [prev - up - next] widget, so it'll be
clear what are navigation widgets.
* The [prev - up - next] widget is neat but should be centered and
appear on the top as well. Before the table of contents I guess.
* Finally the font looks quite bad on mozilla/linux. There is not enough
vertical spacing and I guess there are better standard fonts, to make it
easier to read. I think Thomas' font selection was very good
> it is only one html page (i havent had the time to try and
> incorporate it in a build, which would also be a waste of
> time before everyone can agree on a final design.)
which also means that the original Thomas' design problem wasn't solved
yet. If the page has a little or no content the content box will shrink
and look bad when you browse pages. And it'll move the left part of the
page closer to the center. Somehow we must make it fixed, so when you
flip between pages, the main parts of the page don't move.
I think that this problem can be fixed by making the 'where I'm in the
site' widget bar of a fixed size? Or is it a bad idea?
> stas:
> some of the html that is produced in the build procedure
> just isnt valid. can we fix this somehow?
sure, but that's unrelated to the core design. We will fix those later.
So please disregard this problem for now.
_____________________________________________________________________
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