Skip site navigation (1)Skip section navigation (2)
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-doc" 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>