perl-docs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <>
Subject Re: Navigation
Date Mon, 07 Jan 2002 04:38:20 GMT
Bill Moseley wrote:

> At 07:24 PM 01/06/02 +0800, Stas Bekman wrote:
>>1. [prev|up|next] vs [text|up|text]
>>This issue is arguable. I argue that I do want to know what's the next 
>>document is because why should I click on 'next' otherwise?
> I guess it would depend on what you are reading.  Reading an article it
> might be enough to say [more>>], but a tutorial might want to say:
>        [on to Method Handlers>>]

Yup, that's exactly what I mean :)

> Like what you said about Brian's interview, perhaps my point was don't let
> the navigation dominate the page.  So it might be enough to use simple text
> links in subdued colors.  I've also used graphic [next] links with alt tags
> that give a full description (but not thrilled about that).

Won't it be better to simply disengage the navigation from the content 
box? This will solve all the problems, IMHO.

>>2. Using expandable menu as the only means of navigation.
> Can we all keep an eye out for nice examples on the web? 

:) that's what I do now

>>- long titles.
>>- many titles.
> Well, what I did was build a hash that maps the long titles to short titles
> for use my menus.  Many titles is a problem, but I was just thinking of
> sidebar menus for 1st and 2nd levels.  (e.g. main menu item might ==
> directory, 1st level == files, 2nd level == sections in files.)  Maybe this
> is something that could fit in the config file for each directory.

That's the whole point of the new site, every document should be 
self-containing. So when you add a new document you drop it in and voila 
it fits the rest of the documentation.

I know already what I'm going to add to fix the abstract problem in the 

As for 1st and 2nd levels, please check the hierarchy, it's much deeper 
in docs branch so just exposing the 2nd level won't help much.

>>I think this may be doable, if we don't put the menu on the left side, 
>>but put it on the top instead. Because in that case we need all the 
>>horizontal space we can get.
> I think it's better to stay with the common design of the menu on the left.
>  People will want to start reading content, not a table of contents.


>>3. Spacing
>>I think it's a good idea to add more space between items of TOC, 
>>especially on the index.html pages. This should improve usability. 
>>Should we simply add <br> before </li>?
> Like on the maillist page (which is just a table of contents), how about
> pulling in the description from the pod?  Like or (I
> like better) which has
> lots of white space and uses [more>>].  Could run it through a TT filter to
> truncate if too long (or at the first paragraph break?).

Yes, will do that. The problem that currently the pods lack description.

So they need to be added first.

>>Agreed, but this is the price you pay with automating the process. Chime 
>>in and help to make the tool more customizable and this kind of a 
>>problem can be avoided.
> Yes, I understand.  I'll try to help the best I can.
> With the Pod::HtmlPsPdf I tried to build an entire site with pod (because I
> already have docs in pod format), but it was hard and I ended up with just
> linking to the Pod::HtmlPsPdf generated html.  

I know, that's why I rewrote it. It should be much more scalable now!

> It's probably easier for a web designer to start with an image and make the
> data fit it, than to start with the data (pod in this case) and make it fit
> the image.  But, it's completely possible, of course.  After all, the pod
> is just data, right?  It's probably not as powerful as if the data was xml,
> but doable, especially since you have config files that can bridge any gaps
> in the pod format (like mapping long titles to short titles).

In our case this is not a problem. The design and content aren't tied to 
each other (well almost, the length of certaint titles imposes 
limitation on design)

>>But you forget that this [wyput] site has hardly any content, so I dare to
> say 
>>that it's a bad example. Show me a site with lots of autogenerated 
>>content, and which is supposed to be handled by a single person with 10 
>>minutes of free time a month and still have a site which is of good 
>>usability to its users.
> Do you suppose the site is auto-generated?

most likely.

> And Stas, you have more than ten minutes! I've seen it -- sometimes you are
> off-line for one or two hours between 4am and 6am.  How much free time do
> you want! ;)

But that's my target, spending 10 minutes a months on the maintance and 
doing more coding, I've spent too much time in the last few years doing 

> But really, I can't thank you enough for all your work over the years.
> Plus everyone that is putting time into the new site is very much
> appreciated.  Hopefully once it is up it won't require too much time to
> maintain.


BTW, I'm going away for a few days, so I won't make much noise on these 
days :)

Stas Bekman             JAm_pH      --   Just Another mod_perl Hacker      mod_perl Guide

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message