Date: Thu, 12 Aug 1999 17:43:52 +0100 From: Nik Clayton <nik@freebsd.org> To: Preston Wiley <pwiley@orthos.cadabra.com> Cc: advocacy@freebsd.org, Joey Garcia <gummibear@we.mediaone.net>, Sam Stephenson <sam@conio.net>, doc@freebsd.org Subject: FreeBSD web site (was Re: Tech News Sites Need BSD Education) Message-ID: <19990812174352.A91428@kilt.nothing-going-on.org> In-Reply-To: <Pine.LNX.4.04.9908111214460.21201-100000@orthos.cadabra.com>; from Preston Wiley on Wed, Aug 11, 1999 at 12:17:10PM -0700 References: <Pine.LNX.4.04.9908111214460.21201-100000@orthos.cadabra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Preston, (and everyone else on -advocacy) [ I've just got about halfway through writing this, and realised it's (a) quite long, (b) also appropriate for -doc, so I've cc'd this there. Reply-to not set, make sure you send responses back to the most appropriate list please ] On Wed, Aug 11, 1999 at 12:17:10PM -0700, Preston Wiley wrote: > I've got a new prototype advococy site up. It now uses a mysql database to > store the data and you can add news with an admin script. All of the pages > are CGI Perl scripts, except some of the users groups pages because I > haven't put all of the groups in the database yet. > > Check it out and tell me what you think. > > http://freebsd.tesserae.com I've had a look at this. It's a good first start, but (and I'm sorry, but I'm going to keep banging on about this), I don't think it solves the real problem. If we stop and think for a second, how much stuff on the FreeBSD site actually needs to be done dynamically? Practically none of it, I think. Look at /., stories submitted there aren't posted immediately, they're forwarded to the editors, who still have to approve them, probably tidy them up, and then post them. /.'s success was that the editors were able to skive off from their college studies and still take advantage of the bandwidth offered. It seems to be endemic in the FreeBSD community that we either have the time to do something, but lack the resources, or have the resources, but lack the time -- there are a few notable exceptions to this, obviously, but that's where we are. I *strongly* approve of the idea of keeping a lot of the content in a backend database of some sort. There's a lot of content on the current site(s) (www. and advocacy.) that's basically just lists of information that should really be stuck in the equivalent of a database table. However, none of this information actually needs to be generated on the fly. It's sufficient for the web pages to be rebuilt once a night (or every 12 hours, or maybe even every 6 hours) if new material is forthcoming. This keeps the complexity of the site down, as the number of tools you need to actually build the site drops. I think for any of these solutions to be adopted by the main FreeBSD site (and I assume that's what we're after here) they need to be simple, easy to mirror, and easy to translate to other languages. It doesn't matter how many Perl, Python, or PHP interfaces we put on it (what is it with languages that begin with a "P" anyway?), those are the big three requirements. With those in mind, I'd love for someone to take a comprehensive look at the information we're currently pumping out on the FreeBSD site, and come up with a better way of managing it. For example, we currently have several different "lists of links" sections on the site; Projects User groups Mailing lists The gallery Commercial vendors (divided into hardware, software, consultants, misc) What's New The consistency of presentation and implementation of these pages is atrocious -- we haven't had a full time webmaster who can concentrate on issues like this for some time (no disrespect to Wolfram intended, I know what his workload's been like) and, quite frankly, I've been running as fast as I can to keep up with other commitments and manage the site as best I can as well (as anyone who's had to wait 2 or 3 months for an acknowledgement of an e-mail from me can attest). What do we need? Assuming *I* had the time to do this, this is what I'd do -- this might not be the best solution, but based on my webmastering experience, this is how I'd tackle it. First, take an inventory of the site as it is now. Work out what content we have on there, go through the logs to find out what's most read, what's ignored, and get a feel for how people are actually using the site. Take a look at the inventory you've made, and try and see how many different ways a site visitor might want to approach the information. For example, they might want to see a list of all the mailing lists grouped together. Or they might to see all the information about using FreeBSD on laptops grouped together. Or everything that might be appropriate to someone who wants to read the -hackers mailing list. Or, heaven forbid, advocacy material. You will quickly find that you can't present all the information in one way so that it suits everyone, as everyone's needs are different. What you can do is: 1. Break apart the information into easily manageable chunks. 2. Tag those chunks with extra information that indicate how they're related. 3. Build an infrastructure that can put chunks together based on their relationships. For example, "advocacy@freebsd.org" is the mailing list "chunk", "www.freebsdrocks.com" is a web site "chunk", and the two are related because both are about advocacy. So, if the site visitor selects the "show me all the mailing lists" link they'll see the advocacy list, if they select the "show me all the links to other sites" they'll see FreeBSDRocks, and if they select "show me everything to do with advocacy" they'll get both. Some of you are probably already thinking that this can all be handled in a big backend database -- yes it can, but you probably don't want to. Databases are not simple, they're not easy to mirror, and the content in them doesn't really lend itself to being translated (it can do, but it's normally more hassle than other methods). There's no reason why the scenario I've sketched out above couldn't be handled by pre-generating all the pages involved, in the same way that the commercial and gallery pages are generated from flat files now. Yes, the disk space required by the site goes up (but this is text we're talking about, so the requirements are minimal) and it's a much simpler system to manage, mirror, and translate. With me so far? That covers 90% of the content on the FreeBSD site. The remaining content breaks down in to (a) Extensive documentation, the FAQ, Handbook, tutorials, and so on. (b) The presentational bumph that surrounds all the hard information. Well, (a) will eventually be getting a web site of it's own, so you don't need to worry about that. Links to this documentation form a core part of the main FreeBSD site, but the actual docs will be separate (it's easier to manage). And (b) can be handled the way we handle it now. So, who's interested? What I think we need are three or four people who are sufficiently interested in doing this and have enough time to give it a reasonable crack. It'll probably need * Site architects, who can take the above, flesh it out some more, and come up with a structure that works. * Programmers, who can build the back end that regenerates the web pages from the information held in the 'database'. * Gatherers and editors, who get and/or write the content that's going to be stored in this backend. As I say, 3 or 4, maybe up to 6 or 7 -- too many more and nothing will get done. If people are prepared to volunteer to do this I'll get the mailing list set up (don't discuss it on -advocacy or -doc, the number of participants means that conversations get dragged of track very quickly) and try and throw the resources your way so you can get started on actually trying to implement something like this. -- [intentional self-reference] can be easily accommodated using a blessed, non-self-referential dummy head-node whose own object destructor severs the links. -- Tom Christiansen in <375143b5@cs.colorado.edu> To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-advocacy" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990812174352.A91428>