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:11:52 GMT
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