xml-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Improving the Apache XML site
Date Wed, 12 Dec 2001 10:27:20 GMT
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.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



---------------------------------------------------------------------
In case of troubles, e-mail:     webmaster@xml.apache.org
To unsubscribe, e-mail:          general-unsubscribe@xml.apache.org
For additional commands, e-mail: general-help@xml.apache.org


Mime
View raw message