commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark R. Diggory" <mdigg...@latte.harvard.edu>
Subject Re: [all][site] Site menu proposal
Date Fri, 12 Mar 2004 17:15:05 GMT
I really like the way they setup the top level site navi as well.



Mark R. Diggory wrote:

> I think we should take a lesson from the WS group on documentation for 
> building the site! A simple page like this would very helpful for all of 
> us working on building the top level site. Lets start this in motion by 
> at least creating the xdoc to hold this info under a developers/release 
> manager section.
> 
> http://ws.apache.org/howtobuild.html
> 
> -Mark
> 
> 
> 
> Mark R. Diggory wrote:
> 
>>
>>
>> Dirk Verbeeck wrote:
>>
>>> OK, most people want the component specific menus & the Project 
>>> Documentation together.
>>> http://cvs.apache.org/~dirkv/commons-site2/dbcp/index.html
>>>
>>> What is left is the question if we want a list of (sandbox) 
>>> components in the left menu or not.
>>>
>>> The current proposal (option 1) is to have 2 collapsed menu items in 
>>> the top menu.
>>> (a) http://cvs.apache.org/~dirkv/commons-site2/index.html
>>>
>>> They are only expanded when you are on the componets/sanbox page.
>>> (b) http://cvs.apache.org/~dirkv/commons-site2/components.html
>>> (c) http://cvs.apache.org/~dirkv/commons-site2/sandbox.html
>>>
>>> On the other general pages and on the component specific pages they 
>>> are collapsed.
>>> (d) http://cvs.apache.org/~dirkv/commons-site2/contributors.html
>>> (e) http://cvs.apache.org/~dirkv/commons-site2/dbcp/configuration.html
>>>
>>> This has the advantage that if a new component is created only a few 
>>> pages have to be updated (b or c).
>>> The [+] is also nice because it is a visual reminder there is more to 
>>> find behind the item.
>>>
>>> Option 2: same menu but do not expand the menu on pages b & c.
>>>
>>> Option 3: expand the components menu on a,b,c,d (and move to bottom)
>>>
>>> Option 4: expand the components & sandbox menu on a,b,c,d
>>>           (and move to bottom)
>>>
>>> Option 5: expand the components menu on a,b,c,d,e
>>>           (and move to bottom)
>>>
>>> Option 6: expand the components & sandbox menu on a,b,c,d,e
>>>           (and move to bottom)
>>>
>>
>>> My preference is to the current one (option 1). Option 5 & 6 would 
>>> require a full site rebuild of all components when a new component is 
>>> added. Option 3 is not very fair to the sandbox components wanting 
>>> more visibility to grow.
>>>
>>
>> 1.) Ideally the site will be rebuilt on a regular basis to keep 
>> everything uptodate (ie Once a week would be respectable for the 
>> entire commons) so I'm not concerned about when projects are 
>> added/removed from the commons as a whole.
>>
>> 2.) It obvious people do not want the components expanded on top of 
>> the project documentation, thats what got us here in the first place.
>>
>> I'd vote +1 for Option 6 or +1 on Option 2.
>>
>> (-1 for Options 1,3-5).
>>
>>> I would put 2 tables with all components on the homepage. Implemented 
>>> with reusable XML entities the tables will be the same as on the 
>>> components & sanbox pages.
>>
>>
>>
>> You could (should) use velocity tags in the xdoc's to iterate over the 
>> reactor projects and include their contents, using the entities is not 
>> optimal for generating a list of the projects. You have to edit the 
>> file when you add/remove projects. If you use the reactor, then the 
>> list is built off the included project.xml descriptors, this is the 
>> same for the navigation, the navigation.xml project list can be built 
>> the same way.
>>
>> -Mark
>>
>>
> 

-- 
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message