perl-docs-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stas Bekman <s...@stason.org>
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 
end-document.

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.


ok


 
>>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 http://www.linux.com/ or (I
> like better) http://wypug.digital-word.com/system/frontpage.cgi 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 linux.org 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 
non-coding.


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


Mime
View raw message