Back to blog

Content Modelling shouldn’t be a pain for content editors


October 28, 2013 - Posted in blog Posted by:

Tags: , , ,

Estimated reading time: 5 minutes

I’m totally on-board with the content modelling idea for structured content. It is one of those things that just makes sense.

The traditional approach of flat content stored as HTML on a webpage means whether or not anyone sees it is at the mercy of whatever web spider comes across your content, or whether someone happens to retweet your article. It’s a tried and tested (and old) approach that relies on people coming to you to read your content within the confines of your safe website.

Taking a structured content approach to the information is a different angle; removing the reams of static HTML and refactoring it to as much metadata as is possible.

Lets take a (simplistic) example

Say that you look after the wristwatches division of your company. Well, you could create a microsite, have a separate page for each watch, add a table in to each one showing what the strap is made of, what type of movement it uses, where it was made, how large the diameter is… That’s all very useful and it is what people want to know when they’re looking up about your watches, but it requires people be there, at your site, to find out about it.

So, realizing that you’re coming at it from the wrong direction you think to yourself “My old mantra of ‘Build it and they will come’ is outdated. I need to make my content available where ‘they’ already are. I’ll make my content available to anyone, however they want to use it”.

Yes, that’s much more sensible. You’ll do some content-modelling – break everything down into metadata:

Watch Manufacturer:
Model Number:
Watch Movement:
Case Diameter:
Automatic Y/N:
Strap Material:
Country of Origin:
Power Reserve:
Lug Size:
Jewel Count:
Manufacturer Date:
Date Window Y/N:
Day Window Y/N:
Water resistance depth:

And on you go.

“Perfect”, you say. “Now I can use this content wherever it’s necessary! Someone else in the business wants a page discussing the different strap materials? Well I have all the data here, they can just use this and their page will take care of itself!”

But you know what? Your current bespoke CMS with it’s easy to use WYSIWYG content editor doesn’t work with this new-fangled metadata tagging approach to content.

Herein lies the problem

It reduces the act of entering content from a visual Microsoft Word / CKEditor style approach down to the most hated of UIs – Forms. Long forms. Forms that you will have to fill in again-and-again. Every day. This is now the job of the content creators; filling in forms.

This is a problem because, frequently (although not always) the person who actually inputs the content isn’t the technical person who understands exactly why the content needs to be added like this. Perhaps they are copywriters (if you are lucky) perhaps they are specific content-administration teams. Perhaps it just gets done by the office manager because everybody is doing something else? And you know what? These people do not know nor care about why they should be thinking up suitable category names and properties for things, or whether a check-box should be ticked or not. They just want to write the words and get on with their day.

WYSIWYG editors made these peoples tasks more pleasant. They got to write content. Now they have to fill in forms all day instead. The User Experience for the content administrators as been significantly impacted, and they probably won’t thank you for it.

So, how to address this issue?

Well currently I am working on an internal project where we’ll get (within reason) a bit of a free reign to build it how we like. Just a little Intranet-type project, but one with a good potential for content-modeled content (employee details, vacancies, news, that sort of thing). So we’re going to try something out.

A custom admin system – probably built on-top of Django as that gives us more flexibility with how the admin system operates – with content-modelling in mind, but also one that is pleasant for the administrator to use.

While we can’t go full WYSIWYG for the content entry (and is WYSIWYG even appropriate for any content management system in these days of responsive web and Google Glass… – but that’s a question for another day) we can create some decent live previews to show how this content they’re producing can work, and what it is going to be used for. And we can handle the form front-end in a better way than using standard HTML fields. There is scope to try out something different here.

The Concept

The idea here is to show the administrator how their content will be used when they’re actually entering it, thereby illustrating the benefits of this content approach. Not only visually via previews but display it in context. Not only this, but I want to improve the means of content entry away from ticking checkboxes, selecting dropdown options and typing into fields.

My first thought was to use the concept of MadLib forms that was mooted a few years back, but I discarded this approach as I felt that scattering fields throughout inline text would make it more annoying for repeated use (which would be the case for a CMS) than just presenting the fields in a vertical column. However I liked the idea of building up a story with the form, rather than just presenting a label and a field, so I’ll be looking to progress down this thought route.

So yeah, if you got this far expecting a big revelation and ‘the answer’ then I’m afraid that I’m not there yet. As it’s an internal project the budget is basically zero – so that means very little time and scope for anything other than just building the thing in pieces (ooh, agile!) and seeing how it gets received, but for an internal project it’s an ideal test. I’ll be sure to write something about what route we end up taking for this admin system as well as how well the approach tests with actual users. If we can make their work easier then that’ll be the ideal outcome. Well that and some useful content too!

Leave a Reply

Your email address will not be published. Required fields are marked *