You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@jakarta.apache.org by Henri Yandell <ba...@generationjava.com> on 2004/12/28 05:27:51 UTC
Jakarta download pages Was: download pages in j.a.o.
I spent a fair while walking circles in the basement (carrying the unhappy
baby) and thinking on the download pages.
My first thoughts were on what they exist for. From an info-arch point of
view, they are a search system in addition to the project pages
themselves. The fact that the project pages link back to them is a mistake
on the usability side (though does make our lives fractionally easier).
My next thought is, why are there separate pages for mailing lists, source
code, cvs repositories, binaries? A lot of information is repeated in
attempting to provide navigation to get to the part desired. One reason
for the separate pages is so that separate information may be obtained,
but I believe there is a different solution to that one.
So as a general direction, I think we should have a single project summary
page that provides the links to all the relevant resources. This does give
us a problem with how to handle the context sensitive message of how to
use the resource. I think that closer.cgi has the solution there:
For example:
http://www.apache.org/dyn/closer.cgi/maven/binaries/maven-1.0.2.exe
It has problems. Mainly in that it doesn't really provide much a context
sensitive message. It should be mentioning signatures, keys, md5s etc. It
also loses the navigation of the project it's on and dumps you into a
global Apache navigation. However, I think it's the right solution
architectually. A dynamic page that contains a standard message and is
filled with dynamic info.
So I see the same thing existing for cvs/svn (context message is how to
use cvs/svn etc), mail lists (usual message about politeness etc),
downloads, jars (ibiblio links?), javadocs etc.
Now, circling the basement is not conducive to coherence, or correct
spelling I suspect, so I'm going to ramble a bit here in vague
justification. Jakarta is different to other TLP's in that it's an
umbrella. One of the reasons I like the approach above is that it is
playing to Jakarta's role as an umbrella. Each project will link directly
to the dynamic resource page, ie) closer.cgi for downloads. Jakarta then
provides an umbrella navigation system for when people want to see all
this information from a single location and not click on each sub-project.
---
Baby's feed is near an end I suspect, so I need to wrap things up a bit.
Direct comments on the current binindex page (with srcindex inheriting
most of these flaws):
1) Demo Builds, Milestone Builds: Do we even use these terms regularly? We
have 1 demo build, and I thought we did RC's rather than Milestones. I'm
not sure we even need to push the nightlies at this level; the project
pages themselves should be fine as anyone looking for a nightly is
probably deeply involved with that project as a user.
2) I'm not sure we need to advertise the Apache blog or Jakarta news here.
It's on the front page, why use up valuable space.
3) Why advertise related projects? They're in the navbar about an inch
away.
4) Same complaint as Martin has. Why have the download information if we
let people click right past it. The table at the top is a noble effort,
but I think we need a lot more to solve the problem.
5) Agreed, Commons needs some kind of grouping to bring it together.
That's it. Hopefully much food for thought.
Hen
On Mon, 27 Dec 2004, Martin Cooper wrote:
>
>
> On Tue, 28 Dec 2004, Tetsuya Kitahata wrote:
>
>>
>> Just I've tried to improve the usability of Download Pages
>> in jakarta.a.o. (by Adding "Table Of Contents" in "Release Source Drops"
>> section)
>
> The problem I have with this change is that it pretty much guarantees that
> people will completely skip reading anything about the fact that they are
> downloading from a mirror site, and especially the fact that they need to
> verify the signature of what they download. If we could put that info before
> the links, I would be much happier. ;-)
>
> --
> Martin Cooper
>
>
>> http://jakarta.apache.org/site/binindex.cgi
>> http://jakarta.apache.org/site/sourceindex.cgi
>>
>> The migration of CVS repository (jakarta-site2)
>> into SVN had slipped my mind -- very sorry.
>>
>> --
>>
>> BTW:
>> Perhaps, commons-*** lines can be separated, by creating
>> /commons/binindex.cgi plus commons/sourceindex.cgi
>> and by adding these lines below to .htaccess in jakarta-site2
>> module (migrated into SVN?).
>> | RedirectMatch ^/site/binindex.cgi#commons-(.*)
>> http://jakarta.apache.org/commons/binindex.cgi#$1
>> | RedirectMatch ^/site/sourceindex.cgi#commons-(.*)
>> http://jakarta.apache.org/commons/sourceindex.cgi#$1
>> (... not sure. I am not familiar with RedirectMatch.)
>>
>> Sincerely,
>>
>> ---------------------------------------------------------------------
>> Tetsuya Kitahata -- Terra-International, Inc.
>> E-mail: kitahata@terra-intl.com http://www.terra-intl.com/
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: general-help@jakarta.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta download pages Was: download pages in j.a.o.
Posted by Oliver Zeigermann <ol...@gmail.com>.
On Tue, 28 Dec 2004 08:19:09 -0500 (EST), Henri Yandell
<ba...@generationjava.com> wrote:
>
>
> On Tue, 28 Dec 2004, Oliver Zeigermann wrote:
>
> > On Mon, 27 Dec 2004 23:27:51 -0500 (EST), Henri Yandell
> > <ba...@generationjava.com> wrote:
> >
> >> 1) Demo Builds, Milestone Builds: Do we even use these terms regularly? We
> >> have 1 demo build, and I thought we did RC's rather than Milestones. I'm
> >
> > I thought a milestone is very different from an RC. A milestone is
> > something even *before beta* feature freeze with only partial features
> > implemented. An RC is *after* beta directly before or even identical
> > to the the final release. I may be wrong, though...
>
> I thought so too, until I looked at the actual downloads we have under the
> Milestone section. They're all RC's, and a tiny handful of the huge number
> of RC's that Jakarta produces. With a night's sleep behind me, I'd like to
> kill both the Demo and Milestone sections of the Jakarta index.
>
> Sub-projects can (and will I'm sure) still make them, we just wouldn't
> bother to index them at the top level.
Slide 2.1 had at least one (real) milestone in it's release cycle, but
I guess it would be ok to have it accessible from Slide's pages only.
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta download pages Was: download pages in j.a.o.
Posted by Henri Yandell <ba...@generationjava.com>.
On Tue, 28 Dec 2004, Oliver Zeigermann wrote:
> On Mon, 27 Dec 2004 23:27:51 -0500 (EST), Henri Yandell
> <ba...@generationjava.com> wrote:
>
>> 1) Demo Builds, Milestone Builds: Do we even use these terms regularly? We
>> have 1 demo build, and I thought we did RC's rather than Milestones. I'm
>
> I thought a milestone is very different from an RC. A milestone is
> something even *before beta* feature freeze with only partial features
> implemented. An RC is *after* beta directly before or even identical
> to the the final release. I may be wrong, though...
I thought so too, until I looked at the actual downloads we have under the
Milestone section. They're all RC's, and a tiny handful of the huge number
of RC's that Jakarta produces. With a night's sleep behind me, I'd like to
kill both the Demo and Milestone sections of the Jakarta index.
Sub-projects can (and will I'm sure) still make them, we just wouldn't
bother to index them at the top level.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta download pages Was: download pages in j.a.o.
Posted by Oliver Zeigermann <ol...@gmail.com>.
On Mon, 27 Dec 2004 23:27:51 -0500 (EST), Henri Yandell
<ba...@generationjava.com> wrote:
> Now, circling the basement is not conducive to coherence, or correct
> spelling I suspect, so I'm going to ramble a bit here in vague
> justification. Jakarta is different to other TLP's in that it's an
> umbrella. One of the reasons I like the approach above is that it is
> playing to Jakarta's role as an umbrella. Each project will link directly
> to the dynamic resource page, ie) closer.cgi for downloads. Jakarta then
> provides an umbrella navigation system for when people want to see all
> this information from a single location and not click on each sub-project.
The fact that Jakarta is an umbrella and then commons is an umbrella
inside it was confusing me for a while and I know of many people who
still are confused about that. Maybe a bit OT, but I really like the
idea of Jakarta becoming an extended commons project with all larger
projects going TLP.
> 1) Demo Builds, Milestone Builds: Do we even use these terms regularly? We
> have 1 demo build, and I thought we did RC's rather than Milestones. I'm
I thought a milestone is very different from an RC. A milestone is
something even *before beta* feature freeze with only partial features
implemented. An RC is *after* beta directly before or even identical
to the the final release. I may be wrong, though...
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta download pages Was: download pages in j.a.o.
Posted by Martin Cooper <mf...@gmail.com>.
On Tue, 28 Dec 2004 18:23:37 -0500 (EST), Henri Yandell
<ba...@generationjava.com> wrote:
>
>
> On Tue, 28 Dec 2004, Martin Cooper wrote:
>
> > On Mon, 27 Dec 2004 23:27:51 -0500 (EST), Henri Yandell
> > <ba...@generationjava.com> wrote:
> >>
> >> 1) Demo Builds, Milestone Builds: Do we even use these terms regularly? We
> >> have 1 demo build, and I thought we did RC's rather than Milestones. I'm
> >> not sure we even need to push the nightlies at this level; the project
> >> pages themselves should be fine as anyone looking for a nightly is
> >> probably deeply involved with that project as a user.
> >
> > I'd be fine with getting rid of separate sections for these, and
> > simply putting RCs in the main section, but that presupposes that we
> > want to mirror RCs...
>
> Should RC's even be on this page? The reality is that currently we list
> about 3% of all the RC's made.
It would make sense for subprojects whose RCs would cause significant
bandwidth consumption. However, I think the only subproject that would
likely cause such volumes today is Tomcat, but they don't have RCs.
(Struts used to put RCs on this page when we were in Jakarta, to take
the load off the ASF servers.) So you may be right - maybe this
section should go.
>
> I'm going to kill the Demo Build section as the only link (Velocity demo)
> fails.
>
> >> 3) Why advertise related projects? They're in the navbar about an inch
> >> away.
> >
> > I think the original purpose of this section was to provide links to
> > projects that had moved out of Jakarta to TLPs. It would help people
> > who were not yet aware that a project had "gone TLP". Now, however,
> > that section seems to have a lot more in it, making it somewhat less
> > meaningful. It might make sense to reinstate the original purpose,
> > listing only "graduated" projects and renaming the section to reflect
> > that.
>
> Switching to Graduated.
>
> I've removed DB, Geronimo, Gump, HTTP Server, Incubator, Web Services and
> XML as ones I don't think came from Jakarta. Hard to say with Gump, DB,
> Web Services. I'm not sure if bits didn't exist in Jakarta.
Gump originated at Jakarta, certainly.
--
Martin Cooper
> (at least, I'm doing this. Should be live relatively soon)
>
> Hen
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta download pages Was: download pages in j.a.o.
Posted by Henri Yandell <ba...@generationjava.com>.
On Tue, 28 Dec 2004, Martin Cooper wrote:
> On Mon, 27 Dec 2004 23:27:51 -0500 (EST), Henri Yandell
> <ba...@generationjava.com> wrote:
>>
>> 1) Demo Builds, Milestone Builds: Do we even use these terms regularly? We
>> have 1 demo build, and I thought we did RC's rather than Milestones. I'm
>> not sure we even need to push the nightlies at this level; the project
>> pages themselves should be fine as anyone looking for a nightly is
>> probably deeply involved with that project as a user.
>
> I'd be fine with getting rid of separate sections for these, and
> simply putting RCs in the main section, but that presupposes that we
> want to mirror RCs...
Should RC's even be on this page? The reality is that currently we list
about 3% of all the RC's made.
I'm going to kill the Demo Build section as the only link (Velocity demo)
fails.
>> 3) Why advertise related projects? They're in the navbar about an inch
>> away.
>
> I think the original purpose of this section was to provide links to
> projects that had moved out of Jakarta to TLPs. It would help people
> who were not yet aware that a project had "gone TLP". Now, however,
> that section seems to have a lot more in it, making it somewhat less
> meaningful. It might make sense to reinstate the original purpose,
> listing only "graduated" projects and renaming the section to reflect
> that.
Switching to Graduated.
I've removed DB, Geronimo, Gump, HTTP Server, Incubator, Web Services and
XML as ones I don't think came from Jakarta. Hard to say with Gump, DB,
Web Services. I'm not sure if bits didn't exist in Jakarta.
(at least, I'm doing this. Should be live relatively soon)
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta download pages Was: download pages in j.a.o.
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On 28 Dec 2004, at 20:43, Martin Cooper wrote:
> On Mon, 27 Dec 2004 23:27:51 -0500 (EST), Henri Yandell
> <ba...@generationjava.com> wrote:
<snip>
>> It has problems. Mainly in that it doesn't really provide much a
>> context
>> sensitive message. It should be mentioning signatures, keys, md5s
>> etc. It
>> also loses the navigation of the project it's on and dumps you into a
>> global Apache navigation. However, I think it's the right solution
>> architectually. A dynamic page that contains a standard message and is
>> filled with dynamic info.
>
> I actually think that page is horrible. Almost the entire page is
> filled with stuff the user doesn't care a whit about - a big list of
> mirror sites. The vast majority of users don't care about mirror
> sites, they just want to download what they want. The list of mirror
> sites should be stashed away in a drop-down list, as we have it now.
horrible it might be but it was also horribly effective at it's job
(which was to stop using download direct from apache.org). however, i
think that users have got used to downloading from mirrors now so the
time's probably ripe for change.
> I think, if we had a standard "template" for download pages, each
> subproject could have its own download page, something like we have
> for Struts:
>
> http://struts.apache.org/download.cgi
>
> this would be a more workable approach. I don't see a need to have one
> page with all of the available downloads (with the possible exception
> of Commons, but I'm not sure we need that either).
it's better but would require some effort. it's also quite a PITA for
non-members (changes would be required to some scripts which is what
stopped me last time i thought about revising the download pages). any
members with good infrastructure links feel like volunteering...?
i actually think that henri's idea about a single summary page for each
sub-project would be a good idea containing mailing lists, a brief
description, downloads and so on. would make it easy to add redirects
later (as projects moved to top level). it'd make some sense in terms
of making jakarta more like a portal and less like an ASF mini-me.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta download pages Was: download pages in j.a.o.
Posted by Phil Steitz <ph...@steitz.com>.
Henri Yandell wrote:
>
>
> On Tue, 28 Dec 2004, Phil Steitz wrote:
>
>> Henri Yandell wrote:
>>
>>>
>>>
>>> On Tue, 28 Dec 2004, Martin Cooper wrote:
>>>
>>>> I think, if we had a standard "template" for download pages, each
>>>> subproject could have its own download page, something like we have
>>>> for Struts:
>>>>
>>>> http://struts.apache.org/download.cgi
>>>
>>>
>>>
>>> Agreed, much nicer than the closer.cgi. I'd prefer it if subprojects
>>> didn't have to really care about it; ie) they'd just link to:
>>>
>>> http://jakarta.apache.org/download.cgi/commons/lang-1.4.zip
>>>
>>
>> You can link directly now, using the anchors in the main Jakarta
>> download pages, e.g.
>> http://jakarta.apache.org/site/binindex.cgi#commons-math
>
>
> Yep. There are two poor things about this:
>
> 1) As with the new header, it means most people jump the text on
> keys/md5 etc.
Ack. Had not thought about this. I guess that's why most do not link
directly now...
>
> 2) It seems pointless from a user point of view. The bit they're
> interested in is very small compared to the size of the whole page
> they're being dumped in.
Agreed in general, though grabbing multiple commons components is
something that some people need to do now and then (at least I have).
>
> The struts download page is a lot nicer from a user point of view,
> though one criticism is that the pgp/key stuff is at the bottom of the
> page there and unlikely to be seen by a downloader too. It's also
> serving more than one file.
>
> I'd like to see each project with links to something like:
>
> http://jakarta.apache.org/download.cgi/jakarta/poi/poi-7.2.zip
>
> which would show a page that automatically does the pgp/md5 blurb, links
> to poi-7.2.zip.md5 and KEYS (in the same dir as the zip?) and handles
> the mirror stuff. We'd use the download.cgi for both binary and source.
Sounds good to me. In this case, would we rectify the old "components"
j-c page to present download links to each of the commons components?
Phil
>
> Hen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta download pages Was: download pages in j.a.o.
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
I'm late to this discussion, so pardon if I'm rehashing something said
earlier.
It would be very advantageous to consider how the ASF Repository factors
into the the download picture. I've been hoping to see some integration
between the contents of dist and those of dist/java-repository. The
ability of the repository download requests to be sent to the mirrors
using closer.cgi or something similar would be very powerful.
This url structure would be something that helped.
http://jakarta.apache.org/download.cgi/commons/lang-1.4.zip
Pointing Maven at the asf repository as:
http://www.apache.org/download.cgi/repository
http://www.apache.org/download.cgi/repository/commons-lang/jars/commons-lang-1.4.jar
would begin to use the mirrors more appropriately (if the maven client
handles redirects appropriately.
better yet, how about a separate virtual host just for downloads that is
an implementation of the ASF Repository.
http://download.apache.org/jakarta/commons/lang/jars/commons-lang-1.4.jar
http://download.apache.org/struts/distributions/struts-x.x.zip
http://download.apache.org/xml/xerces/jars/xerces-x.x.jar
http://download.apache.org/xml/xerces/distributions/xerces-x.x.zip
the download.cgi could handle all requests to the virtual host and
properly redirect the user to a mirror.
-mark
Henri Yandell wrote:
>
>
> On Tue, 28 Dec 2004, Phil Steitz wrote:
>
>> Henri Yandell wrote:
>>
>>>
>>>
>>> On Tue, 28 Dec 2004, Martin Cooper wrote:
>>>
>>>> I think, if we had a standard "template" for download pages, each
>>>> subproject could have its own download page, something like we have
>>>> for Struts:
>>>>
>>>> http://struts.apache.org/download.cgi
>>>
>>>
>>>
>>> Agreed, much nicer than the closer.cgi. I'd prefer it if subprojects
>>> didn't have to really care about it; ie) they'd just link to:
>>>
>>> http://jakarta.apache.org/download.cgi/commons/lang-1.4.zip
>>>
>>
>> You can link directly now, using the anchors in the main Jakarta
>> download pages, e.g.
>> http://jakarta.apache.org/site/binindex.cgi#commons-math
>
>
> Yep. There are two poor things about this:
>
> 1) As with the new header, it means most people jump the text on
> keys/md5 etc.
>
> 2) It seems pointless from a user point of view. The bit they're
> interested in is very small compared to the size of the whole page
> they're being dumped in.
>
> The struts download page is a lot nicer from a user point of view,
> though one criticism is that the pgp/key stuff is at the bottom of the
> page there and unlikely to be seen by a downloader too. It's also
> serving more than one file.
>
> I'd like to see each project with links to something like:
>
> http://jakarta.apache.org/download.cgi/jakarta/poi/poi-7.2.zip
>
> which would show a page that automatically does the pgp/md5 blurb, links
> to poi-7.2.zip.md5 and KEYS (in the same dir as the zip?) and handles
> the mirror stuff. We'd use the download.cgi for both binary and source.
>
> Hen
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
--
Mark Diggory
Software Developer
Harvard MIT Data Center
http://www.hmdc.harvard.edu
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta download pages Was: download pages in j.a.o.
Posted by Henri Yandell <ba...@generationjava.com>.
On Tue, 28 Dec 2004, Phil Steitz wrote:
> Henri Yandell wrote:
>>
>>
>> On Tue, 28 Dec 2004, Martin Cooper wrote:
>>
>>> I think, if we had a standard "template" for download pages, each
>>> subproject could have its own download page, something like we have
>>> for Struts:
>>>
>>> http://struts.apache.org/download.cgi
>>
>>
>> Agreed, much nicer than the closer.cgi. I'd prefer it if subprojects didn't
>> have to really care about it; ie) they'd just link to:
>>
>> http://jakarta.apache.org/download.cgi/commons/lang-1.4.zip
>>
>
> You can link directly now, using the anchors in the main Jakarta download
> pages, e.g.
> http://jakarta.apache.org/site/binindex.cgi#commons-math
Yep. There are two poor things about this:
1) As with the new header, it means most people jump the text on keys/md5
etc.
2) It seems pointless from a user point of view. The bit they're
interested in is very small compared to the size of the whole page they're
being dumped in.
The struts download page is a lot nicer from a user point of view, though
one criticism is that the pgp/key stuff is at the bottom of the page
there and unlikely to be seen by a downloader too. It's also serving more
than one file.
I'd like to see each project with links to something like:
http://jakarta.apache.org/download.cgi/jakarta/poi/poi-7.2.zip
which would show a page that automatically does the pgp/md5 blurb, links
to poi-7.2.zip.md5 and KEYS (in the same dir as the zip?) and handles the
mirror stuff. We'd use the download.cgi for both binary and source.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta download pages Was: download pages in j.a.o.
Posted by Phil Steitz <ph...@steitz.com>.
Henri Yandell wrote:
>
>
> On Tue, 28 Dec 2004, Martin Cooper wrote:
>
>> I think, if we had a standard "template" for download pages, each
>> subproject could have its own download page, something like we have
>> for Struts:
>>
>> http://struts.apache.org/download.cgi
>
>
> Agreed, much nicer than the closer.cgi. I'd prefer it if subprojects
> didn't have to really care about it; ie) they'd just link to:
>
> http://jakarta.apache.org/download.cgi/commons/lang-1.4.zip
>
You can link directly now, using the anchors in the main Jakarta
download pages, e.g.
http://jakarta.apache.org/site/binindex.cgi#commons-math
I notice that some projects use direct links like this from their
project pages and some do not.
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta download pages Was: download pages in j.a.o.
Posted by Henri Yandell <ba...@generationjava.com>.
On Tue, 28 Dec 2004, Martin Cooper wrote:
> I think, if we had a standard "template" for download pages, each
> subproject could have its own download page, something like we have
> for Struts:
>
> http://struts.apache.org/download.cgi
Agreed, much nicer than the closer.cgi. I'd prefer it if subprojects
didn't have to really care about it; ie) they'd just link to:
http://jakarta.apache.org/download.cgi/commons/lang-1.4.zip
or whatever.
> this would be a more workable approach. I don't see a need to have one
> page with all of the available downloads (with the possible exception
> of Commons, but I'm not sure we need that either).
User's have different ways of wanting to find a solution. To find 'Struts
Download', some may look for Struts, then Download; while others may look
for Download, then Struts.
That's not a justification for having a page with all available downloads,
just an attempt at a justification for my index-page idea.
Hen
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org
Re: Jakarta download pages Was: download pages in j.a.o.
Posted by Martin Cooper <mf...@gmail.com>.
On Mon, 27 Dec 2004 23:27:51 -0500 (EST), Henri Yandell
<ba...@generationjava.com> wrote:
>
> I spent a fair while walking circles in the basement (carrying the unhappy
> baby) and thinking on the download pages.
>
> My first thoughts were on what they exist for. From an info-arch point of
> view, they are a search system in addition to the project pages
> themselves. The fact that the project pages link back to them is a mistake
> on the usability side (though does make our lives fractionally easier).
>
> My next thought is, why are there separate pages for mailing lists, source
> code, cvs repositories, binaries? A lot of information is repeated in
> attempting to provide navigation to get to the part desired. One reason
> for the separate pages is so that separate information may be obtained,
> but I believe there is a different solution to that one.
>
> So as a general direction, I think we should have a single project summary
> page that provides the links to all the relevant resources. This does give
> us a problem with how to handle the context sensitive message of how to
> use the resource. I think that closer.cgi has the solution there:
>
> For example:
>
> http://www.apache.org/dyn/closer.cgi/maven/binaries/maven-1.0.2.exe
>
> It has problems. Mainly in that it doesn't really provide much a context
> sensitive message. It should be mentioning signatures, keys, md5s etc. It
> also loses the navigation of the project it's on and dumps you into a
> global Apache navigation. However, I think it's the right solution
> architectually. A dynamic page that contains a standard message and is
> filled with dynamic info.
I actually think that page is horrible. Almost the entire page is
filled with stuff the user doesn't care a whit about - a big list of
mirror sites. The vast majority of users don't care about mirror
sites, they just want to download what they want. The list of mirror
sites should be stashed away in a drop-down list, as we have it now.
I think, if we had a standard "template" for download pages, each
subproject could have its own download page, something like we have
for Struts:
http://struts.apache.org/download.cgi
this would be a more workable approach. I don't see a need to have one
page with all of the available downloads (with the possible exception
of Commons, but I'm not sure we need that either).
> So I see the same thing existing for cvs/svn (context message is how to
> use cvs/svn etc), mail lists (usual message about politeness etc),
> downloads, jars (ibiblio links?), javadocs etc.
>
> Now, circling the basement is not conducive to coherence, or correct
> spelling I suspect, so I'm going to ramble a bit here in vague
> justification. Jakarta is different to other TLP's in that it's an
> umbrella. One of the reasons I like the approach above is that it is
> playing to Jakarta's role as an umbrella. Each project will link directly
> to the dynamic resource page, ie) closer.cgi for downloads. Jakarta then
> provides an umbrella navigation system for when people want to see all
> this information from a single location and not click on each sub-project.
>
> ---
>
> Baby's feed is near an end I suspect, so I need to wrap things up a bit.
> Direct comments on the current binindex page (with srcindex inheriting
> most of these flaws):
>
> 1) Demo Builds, Milestone Builds: Do we even use these terms regularly? We
> have 1 demo build, and I thought we did RC's rather than Milestones. I'm
> not sure we even need to push the nightlies at this level; the project
> pages themselves should be fine as anyone looking for a nightly is
> probably deeply involved with that project as a user.
I'd be fine with getting rid of separate sections for these, and
simply putting RCs in the main section, but that presupposes that we
want to mirror RCs...
> 2) I'm not sure we need to advertise the Apache blog or Jakarta news here.
> It's on the front page, why use up valuable space.
Yep.
> 3) Why advertise related projects? They're in the navbar about an inch
> away.
I think the original purpose of this section was to provide links to
projects that had moved out of Jakarta to TLPs. It would help people
who were not yet aware that a project had "gone TLP". Now, however,
that section seems to have a lot more in it, making it somewhat less
meaningful. It might make sense to reinstate the original purpose,
listing only "graduated" projects and renaming the section to reflect
that.
> 4) Same complaint as Martin has. Why have the download information if we
> let people click right past it. The table at the top is a noble effort,
> but I think we need a lot more to solve the problem.
Yep.
> 5) Agreed, Commons needs some kind of grouping to bring it together.
I think Commons needs its own page to sort out all of the components,
instead of trying to deal with a large number of artifacts of one
subproject on the same page as all the other subprojects.
--
Martin Cooper
> That's it. Hopefully much food for thought.
>
> Hen
>
> On Mon, 27 Dec 2004, Martin Cooper wrote:
>
> >
> >
> > On Tue, 28 Dec 2004, Tetsuya Kitahata wrote:
> >
> >>
> >> Just I've tried to improve the usability of Download Pages
> >> in jakarta.a.o. (by Adding "Table Of Contents" in "Release Source Drops"
> >> section)
> >
> > The problem I have with this change is that it pretty much guarantees that
> > people will completely skip reading anything about the fact that they are
> > downloading from a mirror site, and especially the fact that they need to
> > verify the signature of what they download. If we could put that info before
> > the links, I would be much happier. ;-)
> >
> > --
> > Martin Cooper
> >
> >
> >> http://jakarta.apache.org/site/binindex.cgi
> >> http://jakarta.apache.org/site/sourceindex.cgi
> >>
> >> The migration of CVS repository (jakarta-site2)
> >> into SVN had slipped my mind -- very sorry.
> >>
> >> --
> >>
> >> BTW:
> >> Perhaps, commons-*** lines can be separated, by creating
> >> /commons/binindex.cgi plus commons/sourceindex.cgi
> >> and by adding these lines below to .htaccess in jakarta-site2
> >> module (migrated into SVN?).
> >> | RedirectMatch ^/site/binindex.cgi#commons-(.*)
> >> http://jakarta.apache.org/commons/binindex.cgi#$1
> >> | RedirectMatch ^/site/sourceindex.cgi#commons-(.*)
> >> http://jakarta.apache.org/commons/sourceindex.cgi#$1
> >> (... not sure. I am not familiar with RedirectMatch.)
> >>
> >> Sincerely,
> >>
> >> ---------------------------------------------------------------------
> >> Tetsuya Kitahata -- Terra-International, Inc.
> >> E-mail: kitahata@terra-intl.com http://www.terra-intl.com/
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> >> For additional commands, e-mail: general-help@jakarta.apache.org
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: general-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: general-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@jakarta.apache.org
For additional commands, e-mail: general-help@jakarta.apache.org