Re: A website for subversion.apache.org
On Jan 11, 2010, at 11:04 AM, C. Michael Pilato wrote: > Hyrum K. Wright wrote: >>> 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? > > Perhaps not. I mean, as presented in the larger scope of a website and as > accessed only via links from elsewhere, definitely not. I guess I was > thinking primarily about how in general order is to be valued over chaos, > and throwing 100 HTML files of multi-various purpose and target audience > doesn't strike me as orderly. Ah yes, from a maintainability standpoint, I much prefer a layered approach than a casual free-for-all (much as we don't put the entire source code in one directory, either). To some degree, the structure of the hierarchy manners, but not too much (/release/notes/1.6 vs. /release-notes/1.6 vs. /r/e/l/e/a/s/e/n/o/t/e/s/1/6 ) >> 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. > > Fair 'nuff.
Re: A website for subversion.apache.org
Hyrum K. Wright wrote: >> 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? Perhaps not. I mean, as presented in the larger scope of a website and as accessed only via links from elsewhere, definitely not. I guess I was thinking primarily about how in general order is to be valued over chaos, and throwing 100 HTML files of multi-various purpose and target audience doesn't strike me as orderly. > 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. Fair 'nuff. -- C. Michael Pilato CollabNet <> www.collab.net <> Distributed Development On Demand signature.asc Description: OpenPGP digital signature
Re: A website for subversion.apache.org
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
Re: A website for subversion.apache.org
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 CollabNet <> www.collab.net <> Distributed Development On Demand signature.asc Description: OpenPGP digital signature
Re: A website for subversion.apache.org
Mark Phippard wrote: > On Fri, Jan 8, 2010 at 3:55 PM, 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. >> > > I have not had to do a website like this in years as I've usually been > doing Java web stuff or like what you have on hosting sites. It is > not clear to me why we need a generator though. Most of the look and > feel would just come from style sheets. It seems like there must be > something we can do either in the style sheets or with server-side > includes or something to stick the standard navigation on each page. > That seems like the only bit where a generator helps. > I agree. Given that we won't have a huge site, we can afford to be a bit careful with the content and leave it at that. Generators are evil. If we really need something more complex than an editor, I'd prefer to use a real CMS. -- Brane
Re: A website for subversion.apache.org
On Fri, Jan 8, 2010 at 3:55 PM, 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. I have not had to do a website like this in years as I've usually been doing Java web stuff or like what you have on hosting sites. It is not clear to me why we need a generator though. Most of the look and feel would just come from style sheets. It seems like there must be something we can do either in the style sheets or with server-side includes or something to stick the standard navigation on each page. That seems like the only bit where a generator helps. Back in November, I think, we tossed around some example sites that looked good and worth copying. http://felix.apache.org is one I remember that was nice and clean. They generate their site from the wiki though and I do not think we want to do that. But we could still use their styles and just come up with our own way to do the navigation stuff. I think we had some of the same content discussions back then as well, but I would like to see us spend a little more effort on user-facing information. A little evangelizing and features, where you get binaries etc. Of course all the stuff you are already putting up there is needed to. I take it as a given we will figure out the developer parts we want without problem. -- Thanks Mark Phippard http://markphip.blogspot.com/
