I've read the 'xml-deviant' column on xml.com and found it extremely
interesting for a couple of reasons:
1) it's an xml-centric and non-apache-centric view of this project
2) it's a user-centric, show-me-the-stuff-that-I-need perspective
Now, from that perspective, our site sucks. Big time.
1) it's slow and heavy, for no reason [this is fixed with the new
layout]
2) it's sub-project oriented: gives no overview of the Apache XML
Project
Overall impression: it's a rusty container.
Why should I (user) trust the technologies it contains?
- o -
I personally volunteer to change this and improve it because I don't
want people coming to xml.apache.org to stop there, I want them to keep
on getting back and visit our site.
Here is the plan:
1) change the layout in order to speed up the browsing experience
[this is done with the new layout]
2) revamp and rewrite the common sections
3) place a newscolumn and a project status column on the homepage (just
like I did several years ago for java.apache.org, go there and take a
look)
4) write the "evolutionary software map" along with explainations on
where to find stuff, overlap between them, reasons for this overlap,
community directions and all this.
Cocoon will generate the site.
I will write a script (probably an Ant build file) that will gather the
XML documents from the various CVS modules and then run Cocoon on top of
those to generate the site and place it live.
Then I'll write a section of the site that explains how this works and
where to modify stuff for making it appear there.
The goals are:
1) users must have the impression that the site is 'live' and well
maintained
2) users must have the feeling of the quality of our software from the
site
3) users must find it useful to get back frequently to the site
4) users must find it interesting to explore the site and discover our
technologies but without requiring deep interaction with the code in
order to get a feeling of it.
I also have a personal itch to scratch: I would like to have a simple
way to know the following information from all the different projects:
downloads:
- downloads per version per week
- total downloads per version
mail messages:
- mail messages per mail list per week
- total mail messages per mail list
mail list subscribers:
- subscribers per mail list per week
- total subscribers per mail list
CVS commits:
- CVS commits per module per week
- total CVS commits per module
The idea is to have a cron-ed script (Perl?) running weekly (on sunday)
on the apache servers that append this data in comma-separated files,
for example (numbers are invented):
cocoon.downloads:
year,week,downloads
2001,43,3898
2001,44,3849
...
cocoon.downloads.totals:
year,week,download-totals
2001,43,348498
2001,44,352849
...
and so on for every subproject.
Brian, do you see any problem for this? Don't worry, I'm not asking you
to do it, we'll provide the scripts, but we need root access to run them
and add to the cron list.
Cocoon is then able to transform the above into XML files, process them
with XSLT stylesheets that generate SVG graphs and then rasterize them
into graphical images embedded into the site pages.
Results are:
1) the site remains static, no additional load on apache.org machines
2) everybody can have a simple window on the status of the subproject
(not only users, but developers from the other projects and apache
people outside of xml.apache.org)
3) we show off the power of XML technologies for publishing.
I volunteer to do all the above (but I'll need some help on the above
scripts since I'm no Perl guru of sort).
As for DTDs, I'll try to stick with the DTDs we have and adapt the
stylesheets to the different DTDS (or write adapting stylesheets between
the various DTDs) In case this is not possible, I'll present here
alternative plans.
But keep in mind that the idea is to simplify your life: if this is not
the case, I have failed and I need to fix that.
Comments?
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<[EMAIL PROTECTED]> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
In case of troubles, e-mail: [EMAIL PROTECTED]
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
