research design laboratory

CMS: Comparing Notes

 

 

Omeka. Wordpress. StaceyApp. Indexhibit. Drupal. Joomla. Murkutu.

I'm thinking through all of these CMS -- not only the way they deliver content but also the politics that underlie the platforms and the communities of users they inspire. What follows is a preliminary set of reflections on the various CMS I've used, as well as the contexts that defined the delivery and shortcomings of each.

There are many many other options not mentioned here, perhaps for later consideration...

I've started working as a curator at Lori Emerson's Media Archaeology Lab (at UC Bouder) and one interesting conversation (happening also with the MAL Board over email) has been around the use of a CMS for the lab's upcoming website. For this particular project, the two favoured CMS so far seem to be Wordpress and Omeka... and so begins my exploration...

As part of the Archinodes philosophy, I tend to avoid thinking of online projects as mere mirrors of material collection, but rather as extensions of ideas and concepts already anchored in the material world, such as the MAL. What can the web offer this lab? A lot. The lab is filled with incredible machines, each with a rich but untold trajectory, and each with its own undocumented quirks and personality. The lab is also a space for artist interventions, media archaeological research, host to gaming nights and opportunities to play with what Johanna Druker calls "undead media." So which CMS can be best customized to highlight and bring to life the lab and its activities?

Omeka seems tailored to archive and museum collections because it prioritizes metadata handling. For large and ongoing collections of "web objects," this seems to be the way to go, if the idea is to uphold more traditional archival modalities. In their own words, they provide a

collections-focused web publishing platform that offers both rigorous adherence to standards and interoperability with the collections professional’s toolkit and the design flexibility, interpretive opportunities, and ease of use of popular web authoring tools.

I'm saying "seems" because I'm on my third (failed) attempt at installing the CMS, despite my prior experience with such processes. I will test it out properly and blog about it in a few days...

My first impression is that Omeka is heavy: it takes a very long time to upload -- depending on your internet connection, give yourself 30 minutes an hour (which is 5 to 10 times longer than Wordpress or Drupal for some reason.) However, I'm not sure that this is a disadvantage of the CMS per se, as you do this only once, but it's heavy! The real failure is due to the CMS being without its .htaccess file, which required some perusing through their forum to get the code to create my own and fix this seemingly common installation glitch. I feel like this step is above most users heads. I'll be able to report back soon on wether or not this is a proven solution..

From the examples online, I anticipate Omeka morphing into a very rich platform over time and as its community of user-developers grows, especially for institutional and academic projects. For now, I think its main competition remains Wordpress (or Drupal, for more advanced folks), which, while not metadata-oriented, still offers more flexibility, familiarity and extensibility. And loads way faster. 

Wordpress is currently my favorite CMS, especially with the growing base of html5 themes and the recent core release which makes managing large image collections very smooth (thanks for the tip, Matt Soar and Jeremy Clarke!) and also offers a lot of potential for dealing with maps and locative media. That being said, Omeka's Neatline feature blows my mind for the way it integrates timeline and map functions. Again, I haven't tested it out yet but from a viewer/user p.o.v, I'm impressed. I'm into maps these days, so while this may not be especially pertinent to the MAL project (but who knows?), map handling scores big with me.

Wordpress is great when you have a team contributing to several aspects of a site, with levels of permission/access. From experience, levels of permission are often used to limit what people have access to -- not in a strict permissions way -- but rather to narrow the risk of them f'in up anything by removing features they don't need in order to contribute their share to the project. Anyway. Wordpress integrates everything seamlessly -- maps, analytics, social media, galleries -- you name it. And it keeps getting better, with its huge user base and dedicated developers and designers. While you can always tell a Wordpress site from a Drupal site from an Indexhibit site and so on based on style and layout, Wordpress themes are so good right out of the box that sometimes they start to look & feel like... a box.

Onto StaceyApp and Indexhibit...

For my PhD research-creation project last year, I used a combination of Indexhibit and StaceyApp. The two merged quite beautifully design-wise though they presented important conceptual and technological differences for my project, both in terms of practice and final display.

Indexhibit first caught my attention because it came out as a portfolio-centered CMS while everything else at the time seemed to revolve around the blog. The CMS was developed in no small part out of frustration with clutter and gimmicks shaping the web. Indexhibit developers favoured the list view (i.e. index) and un- combersome access to content (i.e. exhibit). They explain:

The more websites that use this structure, the more archetypal / invisible the structure becomes, and the more emphasis is placed on content.

Back in the day, Indexhibit was free. While I happily donated the suggested 15 euros back then, I'm not sure the CMS will survive with its new mandatory pay model - we'll see. I hope so.

Indexhibit became my research archive where I stored mostly notes (in various media formats) -- an archive of an archive. The trickier (though not impossible) parts were creating a forum for comments and integrating social media. Indexhibit is ideal for a personal research archive or artist portfolio but it very much remains a personal repository, in my opinion. If you plan on having a community of contributors, this is not your CMS of choice.

For my PhD exhibition, I opted for StaceyApp. StaceyApp doesn't rely on a database, which made it extra easy to copy and share the contents of the site for both the University archive and the community with whom I was working. It also made it easy to set up again, on a different server. While it is possible to do this with a database driven CMS, the process is definitely more involved.

StaceyApp describes itself as "lightweight," and this attribute is indeed a major advantage of the CMS. It start you off with  three typographically-driven templates which is a nice touch. The CMS is simple: no login screens, no admin interface, just some fiddling directly on your server. Everything is organised according to folders and .txt files, and while it does have its own (always evolving) logic and vocabulary, it's very easy to learn through an iterative process. Their documentation is clear and 

While this is changing rapidly, at the time it was really the best CMS for dealing with video. Indexhibit also handles video very well, then and now. Other CMS still seem to have much more functionality dedicated to embedding third-party content, which is likely a result of those developments being funded by said third parties. Hard to say for sure, but embedding a video in Wordpress is still a workaround that highlights a bias toward YouTube and Vimeo hosting and streaming than serving video from one's own server. 

Drupal is where I first started my adventures into CMS years ago. It's been a long time since I've personally set up a Drupal site because I feel that as a designer I plateaued long before I achieved what I wanted, and got stuck up on structural decisions that impeded the site design I was trying to acheive. So while I still recognize Drupal as possibly the most extensible of all CMS (up there with Joomla, which I've never tested), for me it remains an overwhelming endeavour. That being said, with Archinodes we use it frequently and have been able to develop some of the most amazing custom tools, especially for internal communications and file management. Drupal requires more of a commitment to the platform and overall tech savvy.

Finally: Murkutu. I thought I'd get around to testing this one out too but it's late now and Omeka is *still* uploading so I'll save my thoughts on that one for a later post, along with my assessment of Omeka. I wanted to mention Murkutu here because as a "platform for managing and sharing
 digital cultural heritage, built for indigenous communities, archives, libraries and museums" it is sure to offer a lot to the conversation and comparison. To be continued....

So here are a few hasty conclusions:
  • Strategy: Think of what you're trying to do, who you are trying to speak to and reach, and how you want to communicate your project before choosing a CMS (each has their pros and cons)
  • Delivery: Combining CMS can mean not having to choose one to do everything you need. 
  • Maintenance: CMS are dynamic, and because they change rapidly, consider updating your project with a new CMS is that's what the project calls for.

* Thanks to Corina MacDonald for her 2 cents on this topic.

 

 

Process
Web
Research
node/145