I'm doing some file cleanup and stumbled across a copy of a "CM Briefing" from several years ago - CMb 2005-13, entitled "More Users=Simpler CMS." It was written by James Robertson of Step Two Designs, an Australian consultancy with a specialty in intranets. I've known James for years, he has a solid background in intranet design, content management, user-centered design and knowledge management.

I'm writing this quick post because this briefing opens with:

In many projects, the plan is to deploy a new content management system (CMS) across the whole organisation. In these organisation-wide deployments, an assumption is made that a “big” CMS will be needed to meet the “enterprise” needs. In practice, a better rule is that the more users that will be accessing the CMS, the simpler (and more usable) the system should be.

YES! Less is more, even in the world of linked data. For years we've seen attempts at building very large, very complicated ontologies, taxonomies and metadata schema for public use. The big ones are fine, but for the right reason, in fewer scenarios. What we've seen gain adoption on a larger scale are some relatively simple frameworks: Dublin Core & FOAF; more recently Open Graph Protocol and Schema.org.

Are there times when a large ontology is needed? Absolutely. Do you need one to get started? Heck no. Start small and simple.

First determine what you need: a simple schema with small controlled vocabularies? A lightweight ontology? That will depend on your goals for publishing data and the kinds of questions you want users to be able to ask of your data.

Next decide on the smallest number of elements you need to get the important data modeled. For example, an Address Record. You need a Street, Building Location, City, State and Zip Code (in the U.S.). Having a controlled vocabulary for the States will make your life much simpler. That's it; you're good to go. Move on to the next data problem.

Finally, encode in a way that will allow it to grow, integrate with other data sets, be usable in many applications and have reasonable maintenance requirements.

Keep it simple, until you need more.

I am building an Exhibit (see the Guide for Authors) for a personal project. I have a 1300 line spreadsheet that I decided to make more user friendly by putting it up on Google Spreadsheets and creating a more-easily searched, sorted and filtered view of it via a webpage.

Building the Exhibit itself was simple - uploading the xls and tweaking headers and formats, creating the json feed, building the views. What I'm spending the most time on is data cleansing - four-fold more time manipulating the data over publishing it. It's not that the data is bad to begin with - it's quite good, actually. I've found but a handful of word choice errors (as opposed to spelling errors) as I've gone through the sheet. All of the information required for this project is there. No one would ever complain about the quality of the data in its original format, in fact, its authors are to be commended for the hard work they've put into it.

What I'm having to tweak is the model itself. I am going line by line modifying the primary label where needed, simply so the rest of the information is clustered and displayed in Exhibit in a reasonable way - less confusing to the reader and to my personal standards. Should I lower my standards? I could. But I can't. The hours that I spend tweaking this file will make a world of difference for my audience. In fact, I am sub-optimizing my tweaks to get it done quickly. If I do this project again next year, I will do some things a bit differently and allow myself more time before the event to do it better. My audience is happy, but there's always more that can be done to delight them. One step at a time!

Keep this in mind as you embark on migration and integration projects. What looks great on its own may require additional work after it's modified in some way. Plan for it to avoid frustration and critical response from your audience. Do no harm! If what you deliver isn't better than what they already have, you've failed. Be agile and deliver often, if that's your strategy, but be sure it's quick and the messaging is on target. Be open about the next steps. Your users will appreciate the transparency.

Greetings and thank you to all the folks who came to our talk on Saturday afternoon at SXSW! We had a good time, learned lots, and are grateful and glad to be part of the family of SXSW presenters.

You can find a copy of the presentation here on our site. We're going to be updating it as the animations we used during the live talk don't work on the sites we usually use!

For those of you who would like to play with our demo app, you'll find it at http://triviumrlg.net/eol/. (Opens in a new window.) Please remember it's pre-alpha!!! Right now it works best in Firefox.

Please feel free to send us feedback. It's still very much a work in progress. Thanks!

This code is based on open source libraries will be made open source and posted soon. Watch this blog for the announcement.

We're off to enjoy the rest of SXSW. If you'd like to keep in touch, use the contact for linked from above right, or follow us on Twitter: @cjmconnors, @kevinjohnlynch, @sortelli. Cheers!