At 09:24 PM 01/13/02 +0800, Stas Bekman wrote:
>What I'm trying to say is that we don't have a technical problem. It's
>not an issue of how the configuration file is constructed. It's an issue
>of most of the titles being long and not fitting into the menu. I doubt
>you can shrink them, if you could they won't be long in first place.
Well, maybe we can at least get rid of the $Id$ tags in some titles ;)
>Before we go any further and waste time trying to build an expandable
>menu. Go to any of the docs dirs and try to construct an expanded menu
>that will fit into a left "narrow"(!) column.
No, that's not exactly what I'm suggesting.
>If we could apply our content to an expandable menu that would be the
>perfect solution, but as you realize we cannot.
I don't think that the mod_perl site is that unique. There are many sites
that contain similar content, and easy to navigate at the same time.
>The only way we could do
>that if we have taken the whole width of the page's top for this
>purpose, which can be a good solution.
Can you show me an example of a site with navigation on the top of the
page? I don't see how you can do that without pushing content off the
bottom of the screen. That's why side-bars are so popular.
Again, I don't want to offend anyone, as I realize and appreciate how much
work people have put into this, and naturally, everyone is protective of
what they have done. But I don't want that to inhibit anyone's (including
mine ;) constructive opinions.
I think it's workable, but I also think generating an entire site from .pod
is a tough job. pod is very structured which is great for documentation,
but not real friendly for a web site. (Yes, I know HTML can be a source.)
I don't think it's a real problem since the top-level page's HTML can be
built from HTML pages (top/bottom). The top-level pages are probably going
to need more hand tuning.
Back to the menu:
An expanding menu is probably not that useful -- it works better when the
menu expands for <a name="foo"> type of links (jumping down in a large
page), or when the *content* is deeper or more of it, such as a tutorial
which has ten pages: you click on the tutorial link and it expands to show
you the various tutorial topics that are on sub pages.
Currently, most of the menu items point to a index.html file in some
directory. That index.html is built from the NAME sections from the
individual pods. That index.html can have an "abstract" as defined in the
config, but is basically, just a table of contents.
It's that index.html that I think is not that functional, as it's just one
more layer people have to go through (please ignore the docs directory for
a minute), and it's a design problem since navigation is changing from a
side-bar to a TOC format.
I think it would be more useful to have the menu like:
Mailing lists
mod_perl users
announcements
mod_perl dev
mod_perl advocacy
Embperl
ASP
Mason
Which, from the home page, a) shows the layout of the site, b) allows
direct navigation to where you want to go, which is a bit more user-friendly.
Clicking on the "Mailing lists" link would still bring up the index.html,
but I think that instead of just a table of contents, instead it should
list each link, followed by either an abstract defined in the config.cfg
file, or if that doesn't exist, the first X chars or first paragraph from
the .pod file.
What that does, of course, is provide a useful summary of all the mailing
lists on the index.html page. New users can go there to understand what
list is what, and experienced users can use the sidebar to go directly to
the list they want.
The cool thing about DocSet is that you should be able to drop in a .pod
file, modify the config.cfg, and rebuild the site. In reality, I don't
think life can be that easy. If the abstract is just the first paragraph
of the DESCRIPTION then the site is a bit stale since following a link from
a given index.html page brings you to another page with the exact same text
repeated. Yuck.
In other word, since humans are reading the site, it's probably going to
need a human touch on at least the top and one level down pages.
I should have some time next week to try out some of these ideas. (It's a
lot easier for me to talk about design than actually produce it.)
I think I've made all this points before, but in *my opinion*:
- Sorry to say, but I still think we will need to use tables. I understand
Thomas' arguments, unfortunately, I don't think the clients out there are
ready yet. The current CVS now does not render in MSIE 5.5sp2. It's just
too new of a "standard" to use, especially considering that we are
depending on a MS product (msie) to work correctly with standards, let
alone reasonably new ones. Tables are not that evil considering that
realistically the vast majority of people will be viewing the site with a
web browser and not on their PDA or WAP cell phone. I like the reasons to
not use tables, but I'm not sure how practical it is at this point in time.
- I think the site needs to be designed more for mod_perl newbies -- the
home page should be designed as an introduction to mod_perl. To make it
useful to experienced users the menu needs to be expanded to include second
level links.
Yes, I know the content is not really in the site yet. I just think that
it's important that we keep that point in mind.
Pick some related technologies' web sites and see how they all have links
for brand new users at the start. http://linux.com has that big Tux to
introduce new users, but php, phython (ugly site), mason, embperl, TT
(could be better), all have a description or link right at the start for
newbies.
- design-wise, for me, I think the current site's font is too big and the
graphical lines are overused.
A lot more navigation can be put into the area that the current side-bar
menu takes up.
The sites I like best use a contrasting background and boxes to define
areas of the page (content, navigation, search). I also feel like <ul> to
produce bullet lists is unnecessary in most cases -- just use links.
I think the headings, in general, overpower the look of the site.
Again, just my opinions, but I think they are basic enough design ideas. I
think http://digital-word.com/ is a reasonably summary.
--
Bill Moseley
mailto:[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
