[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: A website for subversion.apache.org

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Fri, 08 Jan 2010 17:26:52 -0500

Hyrum K. Wright wrote:
> We need a website at subversion.apache.org. We've put up some
> placeholder pages, and I recently started playing with an
> Anakia-generated site in it's place. I've come across a few questions,
> and they are thus:
>
> * What information should be presented?
> * How should we present the information?
> * How do we glue the two together?
>
> The first question is about content, the second about style, and third
> about how we should generate the site (manual editing, templating
> mechanism, etc.) I've got some ideas about where to shift the content,
> but I've no eye for style at all. As for the third point, I've spent
> some time playing with Anakia (as recommended by the Incubator), but it's
> kinda unwieldy. In any case, I'm interested in what others think.

Let's do this backwards.

Regarding the site generation, I say don't. We have (or should have) a
static header, a static footer, and a static left-nav. Surely we can just
SSI those three bits into the right spot in an HTML template file that's
copied each time we need a new file. I'm not terribly thrilled about having
to mess with some silly Java program just to generate HTML from almost-HTML.

Style is largely a matter of opinion. Not sure I want to dive into the
larger bikeshed of fonts and colors right now. But there are some style
matters that we should discuss because changing our minds later can come at
some cost.

First, we need to decide if we want a hierarchical URL space or a flat one;
if we want self-describing document basenames or if we don't care. It's the
difference between /svn_1.6_releasenotes.html and /releases/notes/1.6.html
(or maybe /release-notes/1.6.html), if you need a practical example.

Another style matter is page length. Some folks think monolithic documents
like our hacking.html are good because they reduce clicks. Others
acknowledge that click reduction was a fine goal ... in 1998.

And as for navigation, I *don't* want to see a left-nav that's essentially a
site map (too big) or one as positively useless as the one on subversion.t.o
right now (too specialized). Further, I'd prefer that the left-nav contain
no offsite links (and yes, that includes the current "ASF" link) -- put that
junk in the content of relevant pages where it can be described and not give
the impression of linking to a part of the site itself, or at least set it
off from the "main menu" (as an ad button or somesuch).

As for the content itself, I think we largely have the right kinds of stuff
in place today (on s.t.o). I'd drop stale stuff like the Testimonials. I'd
consider dropping the Links, too -- it's Google's world now. I'd never put
anything like merge-tracking design docs in our public website again -- for
crying out loud, we can just point people to the repository URLs for those
things!

And I'd be sushi to get some spaghetti into th-- oh dear. It appears I'm
too hungry to continue thinking about websites, and it's making me grumpy.

-- 
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Received on 2010-01-08 23:27:31 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.