[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: Hyrum K. Wright <hyrum_wright_at_mail.utexas.edu>
Date: Mon, 11 Jan 2010 10:23:02 -0600

On Jan 8, 2010, at 4:26 PM, C. Michael Pilato wrote:

> 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.

That's reasonable, and I'm starting to think that if we've got something which is so complex that we *can't* do it with SSI, we're going down the wrong path.

> 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.

This is important, but ultimately a bikeshed, I think. Are there any practical differences between a hierarchical space or a flat one?

> 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.

I'm in favor of shorter pages. It forces us to do at least some organization, rather than a series of catch-all documents. Let's just make it so that folks can easily find what they are looking for.

> 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!

Agreed, agreed, agreed, and agreed.

I'm not trying to rush the process at all, I'd just like to get it done and realize that I'm not an authority (or even that proficient) at website design and organization.

-Hyrum
Received on 2010-01-11 17:23:39 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.