InfrastructureIssues - WebSite - DownloadPages

These are the central pages where Jakarta releases (and other artifacts) can be downloaded.

http://jakarta.apache.org/site/binindex.cgi and http://jakarta.apache.org/site/sourceindex.cgi

A Bit Of History

The download pages (in their current form) were devised when Jakarta releases were moved onto the mirrors. The aims were:

• Create a single page for all Jakarta downloads. This page is much easier to monitor than all the old download pages in all the subprojects.
• Stop users download releases from the main ASF servers.
• Educate users about the need to verify releases downloaded from the mirrors.
  

In those terms, it was a great success. But usability and scalability never featured amongst the aims and they were sacrificed.

The Long Term Problem

As the number of releases increases, the current design is not scaling well. The usability problems that the page has always grow greater as the number of releases that need to be shown grows.

Change Suggestions

Rethink Education Strategy

At the moment, there's a lot of talk at the top of the page. It was put there to educate users.

Really, users need only worry about checking MD5 sums. Signatures are very useful for Apache purposes but are not useful unless the user understands about signatures, webs of trust and so on. I'm inclined to give shorter, more precise advice at the top of the page (maybe moving the content to a subsidary page) and emphasis the MD5s by putting them directly on the page (rather than linking them). Maybe even move the KEYS and signature links onto a separate page intended for expert users who either understand the mechanics or who are willing to read up on it.

This might result in a website that is more usable as well as being better at encouraging users to check the releases in the right way.

Index for Releases

Create an index for all releases near the top of the page so people can more easily find each product.

Use a table for the releases

One of the problems with the current page is the amount of scrolling needed. This is mainly because each product uses several lines.

It seems to me that if the information were reorganised in a table, with one row per product release, a lot of the navigation problems would be resolved.

For example:

[The KEYS column could be eliminated by making the product name a link to the keys.]

Discussion

HowardLewisShip: I'd love to eliminate the need for the PGP key, since it can't be automated via Ant. The tabular output would be very, very useful as well ... just that HiveMind and Tapestry (3.1) use a combined bin/src distro (in .tar.gz and .zip) and a seperate documentation distro (.tar.gz only) ... so we need to be careful on the column headings!

I've also used XML entities inside the binindex.html and srcindex.html files to make it easier to identify and link to the current ("stable") release of those two projects; I would suggest others follow suit. Don't Repeat Yourself.

Finally, a Forrest conversion of the home pages would be very useful; we could define custom documents for the downloads and create the binindex.html, etc., more programatically and uniformly. Using Forrest, plus a little bit of Ant, we could also avoid the ugliness of today's approach ... checking in the documentation into CVS, just so that it can be checked-out on top of the live site. With HiveMind, etc., it is easier to package up the documentation into a tarball, copy it up to the server, and unpack it there (HiveMind ant scripts do this for HiveMind, user merely provides the account password).