forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <rgard...@apache.org>
Subject Re: improving menus and linking (Was: vague issues with Forrest use)
Date Wed, 02 Nov 2005 09:07:44 GMT
Paul Bolger wrote:
>>Because this is no longer Vague - you have made a very concrete
>>suggestion. The change of subject makes it much easier to read the
>>archives where subject is all that is initially seen when searching.
>>
>>
>>>if this has already
>>>been implemented isn't there a case for making the
>>>'#project.menu-scheme=directories' the default, and letting those who
>>>need extra flexibilty choose the other option if they need it?
>>
>>Does it actually work the way David suggestd? Seems daft that we don't know!
> 
> 
> Thinking more about this I can see one drawback: one wouldn't be able
> to control the order in which links appear in menus. I don't think
> this is necessarily a fatal problem though, particularly if the user
> were able to 'freeze' the site structure to the site.xml file.
> One could always hack the order by just renaming the source files,
> 01_foo.xml, 02_morefoo.xml etc. I realise this is probably horrifying
> stuff for programmers... but a lot of website builders like to mess
> around with the usability side of their site structure - nav, nesting
> of sections etc. This would make restructuring very quick and easy.
> There's a lot to be said for using an interface (the OS directory
> structure) which most users are very familiar with.

Yes, that is why, in the resume plugin, the technique is only used for 
the list of resume's for people. It makes sense to sort these 
alphabetically. But not for most other content.

As for mangling the names to get the right order - it makes me shudder!! 
But if users would prefer it then it could be made an option.

>>Here are a couple of advantages (there are others I am sure):

...

> I tend  to use SSI's for nav. I also use CSS to filter the output of
> those includes. For instance the developer manuals would be
> class="dev" and in the user site .dev would have a display:none value.
> That's if I needed the the two lists completely merged into user, dev,
> user, dev etc.

The problem with the 'CSS to exclude stuff' approach is that you are 
using bandwidth to send informaition that is not being displayed. This 
may not be significant in low traffic sites (like my own). But for 
something like the Apache sites it mounts up very quickly, that is 1 
million lots of 100 extra bytes adds up to lots of bandwidth.

The reduction of bandwitdh use is one of the goals of the project.

Ross

Mime
View raw message