The truth of the matter is that, no one really cares how your website works as long as it does. Well almost no one: I think I’m an exception to this rule, but then I’ve been looking at websites for a long time, and have a lot of opinions on the matter. Given that the Cyborg Institute Site is rigged together in a reasonably unusual way, I think it’s worth a bit of (potentially ongoing) discussion.

Lets start with what you can see: the theme. Our theme is a pretty straightforward derivation of the hemmingway theme for wordpress. Mostly I just changed the font and took out a lot of features that I didn’t need or like, and did some minor tweaking to other aspects of the layout. I wanted a simple, basic theme, that was easy to navigate through but that could handle a lot of different kinds of content, and I think I succeeded at that. I’m not a graphic designer, and I prefer to leave that kind of work up to the professionals.

The second thing that you might notice is that the site isn’t powered by WordPress. Don’t get me wrong, WordPress is great software and it’s perfect a great many sites. I recommend and do a lot of consulting around WordPress, but the truth is that WordPress is developed to power blogs, and while you can use it to manage other kinds of blogs, the harder you push the less effective it gets to be. When I’m working on a WordPress project I try to be really mindful of WordPress’ strengths, and it’s never let me down. At the same time, I knew that this site was the kind where I’d have to push a lot, so I took a different strategy.

While the Cyborg Institute has a blog the central focus of the site isn’t the blog. In fact, most of the content on the site is pretty static. Pages about what we do, and our projects take prominence over “the latest blog post.” While these pages might change from time to time, they don’t change much. And then there’s the wiki, which is also full of pages that don’t change very often. Not to mention the rest of my list of “things to do with the website” which are also not-blogs. I fear I’d be spending more time fighting with WordPress than actually working and writing.

I wanted a system that was flexible enough to deal with new kinds of content and information as I needed to deploy them, but that was also lightweight: I didn’t (and don’t) need a modular plugin architecture, database server, and template API to regenerate every page every time someone views it for a website that changes a few times a week (at most.)

My solution? I’m using a number of tools to generate static content that the web-server just hands out as is. The result is a site with pages that load very quickly, and a collection of tools that are all ideally suited to the task they perform, rather than being suitable as a result of their integration with WordPress (or the CMS of choice). I’m using Jeykll and ikiwiki at the moment, and I hope to continue to extend their use and find other tools that work similarly.

I think as we begin to be able to more accurately interpret our needs for websites, as network services mature, and as the web continues to develop, these kinds of “ad hoc”/”lo fi” systems will become increasingly more attractive.

At the same time, there is a cluster of functionality provided by high-powered content management systems beyond simply managing “managing content” that alternative systems need to address in some way.

1. Editorial administration, content workflows, and user account registration: Traditional content management systems (CMS) make it easy for site owners to administer their sites, to delegate responsibility to an editorial team, and make it possible for users to authenticate with the website.

   • Ad hoc systems like the one that the Cyborg Institute uses don’t require users to authenticate with the website, verifying identities by way of Open ID, or direct authentication with the server itself using secure encrypted connections for editing content directly.

   • Without user accounts it’s difficult to delegate editorial responsibility without a central administrator needing to review any changes additions. While traditional CMS’s relieve stress on a central editor, they add more than an equivalent amount of stress with regards to their technical upkeep. This trade off is more than acceptable, in the ad hoc case, particularly given that on low volume sites with small editorial teams, centralized workflows are almost always preferable.

2. Uniformity and Template Systems. Traditional CMS’s make it possible to easily implement a uniform template so that all pages on your site “look the same,” and that if you change the template for one page the entire site can change.

   • It turns out that designing an effective template system is incredibly difficult. If it’s too flexible, it’s easy write templates that don’t work consistently across all pages, and if it’s not flexible enough users won’t be able to produce the necessary outputs.

   • Generally, the best strategy that leads to separate content from both the structure of the page, and the presentation (CSS), and any content/structure/presentation that’s common to more than one page should reference the same copy of the content. This is quite easy to accomplish using simple includes (transcludes?) and other methods of static page compilation.

3. Traditional Content Management Systems provide a framework for commenting on content and facilitating other interactive features for readers to participate in ongoing discussions. Which is easier to do with dynamic pages and user accounts.

   • Services like Disqus, and IntenseDebate demonstrate that it’s possible to “outsource” some of these features and experience an increase in functionality. Even more, they show that we don’t really need to have “content” and “interaction” in the same system for effective content publication or discussions to take place.

   • Facilitating participation is always a social problem rather than a technological problem, and there are ways of facilitating discussions in any technology.

So that’s what we’re working with. While this is very much a “meta” conversation, I think that this site is interesting not just because it’s awesome (heh) but because I think it bucks the conventional wisdom regarding the kinds of web-infrastructure needed to run a site like this, and thus raises some interesting questions about the best ways to present and organize information. Thoughts?