Website overhaul

This is a collection of ideas for the Xiph.Org Website overhaul. Note that this was initially considered in July 2003, so some of the content may be outdated for a recent point of view.

Rational

The Xiph projects have a number of websites, including:

• xiph.org
• vorbis.com
• icecast.org
• speex.org
• theora.org
• opus-codec.org
• xiph.org/flac

These sites have varying amounts of information about the different projects, and in general this collection of websites is not well or consistently organized.

During the Website overhaul, we will implement and consistent organization and design upon the whole of the Xiph projects. This will considerably improve how people find information and learn about these projects, as well as greatly improve our public image as a well organized and well run project.

Jack’s Proposed Solution

Jack proposed to migrate the websites onto Plone, which is a Content Management System built on top of Zope — or maybe onto Zope by itself.

This would allow a much greater level of community participation in the website that is currently possible on any of the sites or with any of the current sites' implementations.

How would this allow for a greater level of community participation above and beyond what we already have? We have a Wiki for community participation.

Allowing users to write generic documents, not just special things like “news” or “software item” would allow pretty much anyone who can write to submit things into the workflow. So people's documentation for things we've not yet gotten around to documenting could actually show up on the site relatively quickly. Also, since each person has a personal folder (in plone, this is on by default and in zope we can do it there too, but it's not automatic) they can share their Xiph knowledge in their own way. —jack

Personal folders don’t seem like a must-have for a collection of sites with an associated Wiki. In fact, a Wiki sounds like a perfectly fine staging area for most, if not all documents created on “the outside”.

A team of volunteer developers would help create the new sites on Plone. A team of volunteer editors would handle approval of content and basic site maintenance. Content could be added to the site from anyone willing to write it, and it would move through the built in workflow process to be approved and then published.

The idea is that a well-run project accretes people to help with the support load, just as it does with development. That's why it's so important to make it easy and effective to contribute.

Nathan’s Objections to Plone and Zope

These are opinions made on June 10, before I have made significant inroads into using these products.

• Both Plone and Zope, at the very least, seem too complex for our needs; CSS, SSI, and a smidgen of PHP or similar for the odd bit of database work should be less of a maintainance hassle if only because one does not need to learn the CMS system and how to customize it in order to contribute.
• Plone sites tend to look like one another; this worries me as I don't want to have to go through ungodly contortions just to get a decent, unique look that can be largely shared cross-site.
• It is fairly easy to get Apache up and running on another system for testing layouts and content; this is much less certain for both CMSs mentioned by Jack. This is an issue largely because I cannot get ping times to motherfish-ii.xiph.org below 100 milliseconds; this makes editing and testing a hassle. Plone and Zope allow editing on the server in a browser window, but this is a far cry from a decent text editor since it lacks both syntax highlighting and indentation assistance. Oh, and the tab key plain doesn't work.
  In general, I would rather fight the markup and style rather than a lumbering, semidocumented CMS, and do not see enough benefits to outweigh the hassles in switching to a vastly more complex system in one fell swoop.
• The ExternalEditor zope product gets around the textbox problem. Also you can export objects on Zope so a testing isn't a big deal. Also the whole point in a cms is that you need to know very little in order to contribute (to the content). —someoneelse

Proposed Layout

The following layout is proposed:

• The main site will be http://www.xiph.org/
• Vorbis will be at http://vorbis.xiph.org/
• Speex will be at http://speex.xiph.org/
• Icecast will be at http://icecast.xiph.org/
• MGM will be at http://mgm.xiph.org/ (maybe, since it's so small and not under current development)
• etc.
• vorbis.com, flac.net, and icecast.org will be maintained as they currently are since we have zero desire to break incoming links (I've noticed the odd link to www.ogg.org, something I've never used personally)

Other Stuff

At some point, we should start to publish Ogg Traffics on the new xiph.org page, and not necessarily only on Vorbis.com, since with the addition of new projects and codecs, OT is never about just Vorbis anymore.

Sure. When Xiph.Org ceases to be ugly (say, within the next ten weeks)

One should always be able to reach a Xiph project by visiting http://(projectname).xiph.org (case-insensitive).

Ogg isn't part of Vorbis (2003/09/09 01:39 EST)
Since Ogg is no longer about just Vorbis, the bitstream specs should be moved out of the Vorbis section (with forwarding).

Simpler donate page URL! (2003/10/05 06:51 EST)
http://www.xiph.org/ogg/vorbis/donate.html is too long and not all that sane to expect any normal person to remember. While you're making subdomains for everything else, donate.xiph.org sounds nice. :-)

Standard look and feel across each of the sites is needed (2003/10/21 00:09 EST)
All the associated sites should maintain a standard look and feel. Problems for the organization and users of the websites can be minimized by using a standardized set of HTML across all the sites. One current problem is the icecast site which does not display properly in some browsers. Other sites seem to have any old layout they want. A standardized core of HTML and rules for layout can simplify things for everybody. The people working on the sites should still be able to include their nice graphics but only within the constraints of agreed upon rules for construction of these sites. Keep it simple so that developers can get down to the business of Ogg and codecs instead of webpages.
This assumes that the Ogg and Vorbis developers do webpage stuff (they don't, noncoders do). We plan to have a much more unified look between different projects (ogg, vorbis, speex, flac, etc.) The Icecast (and Speex, for that matter) site(s) may very well not look nice in antiquated (4.x) browsers, and it's simply not worth our time and sanity to work around their bugs. —Nathan Sharfi

Website CMS Idea (2003/11/05 11:23 EST)
Why don't you base the entire site on a Wiki? Have the front pages for each subdomain forward you to different pages on the Wiki, and make a nice template, ex: wikipedia.org.
The URLs would be too flat. We'd lose editorial control. (Yes, there are wikis out there that allow for limited editing; however, we have better things to do than police all the annotations that people make.) None of this, however, precludes a wiki. —NathanSharfi

Not sure that Plone is such a great idea (2004/04/29 02:43 EST)
Sorry that I'm Anonymous Coward, but I use ogg a lot and I thought I could help in some small way. Plone is nice, but wouldn't it be more prudent to use something based on Apache? I have had to review a million open source CMS systems for various projects, and the nicest, simplest and most easy to maintain one I have come up with so far is Mambo - http://www.mamboserver.com/ it is a GPL-ed PHP/MySQL? CMS, miles ahead of the various *nukes and derivatives, uses templates and is similar in functionality to Plone. IME The Nuke sites are too inflexible for anything other than Slashdot clones. I'm happy to offer some volunteer work at weekends —jonathanischoice@yahoo.co.uk Cheers!