Yes I think there has been quite some discussion on a move to a more
dynamic, with delegated administration style of website.
I'd like to throw in WordPress as perhaps a better website content
system than Wiki.
Several open source projects have in the past used Wiki as a basis for a
web content system, to be honest it was confusing navigating between
Ofcourse modifying the layout maybe able to assist here, and I'm sure it
can be done with Wiki, but this is something WordPress does for free.
To modify wiki layouts is going to take quite some effort I'd imagine,
we may find the layout we want is available from some WordPress
Since WordPress is primarily a blogging tool, and secondary a content
management tool, it already allows you to create pages, and change the
layout of those pages fairly easily.
I'm no WordPress expert, but I have seen folks do many different things
with it, for example it's quite popular with virtual airline websites.
There is also large community of layout designers and plug-in developers
that we can draw on, and as it is also PHP based, so it could run on the
same webserver as the wiki (depending on capacity naturally) if that was
Some different examples from the http://wordpress.org/ showcase list;
And as I just got caught myself, there are two sides to WordPress;
The hosted blogging site http://wordpress.com/
The community self-hosting site for "WordPress" the software
Either way, yes a more dynamic and easily delegated administered site is
a good thing.
On Sun, 2010-10-10 at 12:06 +0200, Gijs de Rooy wrote:
> last week, James dropped the idea of moving our website (partly) over
> to the wiki. So far I have "discussed"
> this with a couple of people, all of which have different opinions.
> Therefore, I would like to ask anyone that
> cares about our website to reply.
> I think we all agree that our current website cannot continue like it
> does right now. We've had multiple discussions
> in the past, even leading to some test website (like the ones by
> Pete), but none of them led to something.
> I have listed a couple of pro's and con's (IMO, and based on a small
> IRC duscission) below. This list is dynamic,
> as pro's can become con's and vice versa.
> + Easy to update: wiki articles can be edited by all people, in stead
> of just a single man (Curt :P). As we have
> seen in the past (and even till today), our website is often out of
> date. A "good" example of this is the CVS/Git
> page, which hasn't been updated since May (!), and still does not
> contain any useful info if I want to use Git.
> Of course we don't want some of our important pages (main page,
> download etc.) to be edited by just anyone
> with a wiki account. Luckily, we can add usergroups at the wiki and
> assign permissions to them. Thus, important
> pages can be locked (on the edit part) for the ordinary users. We've
> been doing this with all Newsletters, which
> can be edited only by wiki-admins after their publicication. We could
> create various groups, and people can be
> within multiple groups at once.
> + Easy to link to detailed documentation: rather than providing an
> external link, we can add internal links to
> each word (okay, that's a little too much). If a text mentions
> $FG_ROOT, we can make that "word" link to the wiki-
> article about it. This will decrease the amount of "useless" questions
> at the forum (which are replied by a link to
> the wiki), which is meant for special, personalised help and
> + Download page: since the wiki already contains quite some
> information per aircraft, it could be used to auto-
> generate a more detailed aircraft download page. Each aircraft on that
> page can link to the aircraft's "private" page
> (if existing) and thus provide manuals, status info etc. immediately
> to the user, even before downloading the aircraft.
> As we've had quite some complaints from people that are disappointed
> after dowloading. The wiki can provde various
> screenshots per aircraft (eg. interior, exterior), so users can
> + Publicity of the wiki: new FG users will be immediately aware of the
> existence of a wiki, and therefore be
> stimulated to start developing themselves. This will again decrease
> the "useless" questions at the forum.
> - Less attractive layout: currently the FlightGear wiki doesn't really
> look like a website. This could be solved
> though by creating/adding a different style/layout.
> - Less open system: for example, it will be harder to implement
> additional features (gallery's, search engines)
> etc. However, the alternative is a CMS system, which isn't much
> - Not much examples: of a complete wiki website about projects like
> ours. This could be a pro as well, as it will
> allow us to be "renewed" and "different".
> Jester (IIRC) mentioned that it is important to check whether pages
> are cached at the wiki, so they won't have
> to be pulled from the database each time. If so, we should enable
> cache. A possible other solution is to have a
> "static" frontpage, which could be nice in various ways, other than
> the cache...
> I look forward to receiving your ideas/opinions/questions! When the
> list grow, we might benefit from setting up a
> wiki article to collect ideas/opinions.
> Beautiful is writing same markup. Internet Explorer 9 supports
> standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
> Spend less time writing and rewriting code and more time creating great
> experiences on the web. Be a part of the beta today.
> _______________________________________________ Flightgear-devel mailing list
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 & L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
Flightgear-devel mailing list