perl-docs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Moseley <>
Subject Re: Navigation
Date Sun, 06 Jan 2002 18:03:59 GMT
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>>]

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).

One note about that site.  They use bread-crumbing.  Notice it's
not *that* valuable of information, since it looks like it's directly from
the URL path segments -- it's not like it gets you someplace you can't get
On the other hand, it's placement on the page is not overwhelming, hardly
notice it. 

>2. Using expandable menu as the only means of navigation.

Can we all keep an eye out for nice examples on the web? 

>- 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.

>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?).


>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.  

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).

>I think you simply don't realize that the content/build code is 
>incomplete. Once everything is in place you will have what you want. 
>Again feel free to help make things happens sooner :)


>But you forget that this [wyput] site has hardly any content, so I dare to
>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?

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 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

Bill Moseley

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

View raw message