On Mon, 27 Dec 2004 23:27:51 -0500 (EST), Henri Yandell <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] http://www.terra-intl.com/ > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
