Reorganising the content in the FEniCS web site

After going through the existing web site, I have ferreted out the kinds of information it tries to present. I have reclassified this content into 4 basic categories:

1. Basic information _about_ the FEniCS Project
2. Information pertinent to new _users_ of the project
3. Information pertinent to _developers_ of the project
4. Highlighting major _applications_ of the project

What follows are details within each of these classes, in the form of a basic content/URL tree.

HN: I replaced the clean URL tree with something clean enough that can be handled via MediaWiki. Notice all URLs are fpo/Foo, instead of fpo/wiki/Foo as they are currently.
HN: A simple .htaccess 503 redirect can be added to ensure old links work and search engines find new locations.

1.
fpo/About -- Information about the FEniCS Project
fpo/History -- Where it's been
fpo/Philosophy -- Goals and where it's going
fpo/Components -- An overview of the component projects
fpo/Contributors -- Get to know the contributors

HN: The cool hg visualisation video can be featured prominently somewhere in this section.
HN: Some important papers can be featured in this section. Perhaps in History?

2.
fpo/[Users] -- Information pertinent to new users[1] of the project
fpo/Obtaining -- Fetching (and installing) the software (should this link to source code?)
fpo/Using -- Tutorials and user documentation (including manuals)
fpo/Citing -- How to cite the project(s)
fpo/Support -- Getting help (mailing lists, lp answers, ...)

3.
fpo/Developers -- Information pertinent to developers of the project
fpo/Architecture -- Details about component projects
fpo/Documentation -- Developer documentation (including manuals), Doxygen
fpo/Contributing -- Practical information on contributing (lp use, bzr use, coding standards, licensing, buildbot status, lp bug reporting) (This should be minimal, and should link to tutorials elsewhere on the web.)
fpo/Discussion -- Support and discussion (mailing lists, lp blueprints, lp bugs, ...)

4.
fpo/Applications -- A gallery of highlighted applications of the project
fpo/Foo -- Information about a particular application, where each app page contains:
. about/blurb
. major results (preferably pretty pictures)
. obtaining
. using
. citing

HN: The above standard should be enforced across all app pages, or the pages don't get featured on the fpo/applications section.
HN: Apps need some special sort of flag to clarify they are app pages and therefore need a select colour or some other differentiating factor. (To clarify that FEniCS devs aren't exactly responsible for the contents of the pages or the quality of the code.)
HN: The apps should be classified into a set of 4 different things (e.g., utilities (tritetmesh), solvers (cbc.solve), ...) as well. This allows for an arbitrary number of apps in the future without messing the design.

[1] [users] is in square brackets, because even though this information is intended for users, the word 'users' is not part of the URL. This is the default information one will see when they go to fpo.

AL: What does "fpo" mean?
HN: http://fenicsproject.org (or in general, a place-holder for what the lawyer friendly new domain-name will be.)

AL: Having obtaining - using - citing - getting help as main links sounds good, but where are the entry points for about - developers - applications?
HN: As I've pointed out in the spec., the entry point defaults to the entry point for users. The other cases (developers, application developers, etc.) will form a menu on top (not yet worked its way in to the visual design).

AL: The category tree is much better than what we have now.
HN: Good, I think so too. But then again I'm biased. :)

AL: Need to figure out if and how to use a wiki.
HN: I am now contemplating a mixture of static/wiki (I will construct a MediaWiki theme out of the sections I think should be user-editable), or another CMS entirely. I will try stuff out and let you know.

The Wiki does have the advantage of having a very low barrier to entry (both in terms of getting in to change things, as well as the Wiki markup). Right now, I am thinking static pages for the main pages that (should) rarely change, and the Wiki for pages you don't mind people messing up. Somehow, having a user-editable landing page for the website seems odd (and very exploitable).

MR: Show finite element solutions somewhere prominent to clarify what the project is about.
MR: Enforce something like the guidelines for different apps for each of the component project pages.