We’ve been using GatherContent in a particular way now for a few months and across a number of projects. Following the addition of some new team members and comments and reflections from established team members, I’ve been wanting to take stock of our approach.

“The model”: Our use of GatherContent

I wrote a post on our “new” model for using GatherContent a few months ago. I called it a “model” then knowing it was a different way of using it from the way we’d used it before and possibly even from the way other people use it. But I didn’t give “the model” a name.

In previous usage, like say when we’ve been putting together content for our print prospectus and related online channels, we’ve come up with a few highly specialised templates containing lots of fields. We’ve had a template for subject areas containing descriptive fields and fields for stats. And we’ve used a template for course pages containing several multiple choice options and restrictive text fields for fees and entry requirements and so on.

But in our new model the templates have been much less specialised. I’ve set up templates like “page container” consisting of a title field and not much else. There are templates like “body content chunk” which are literally just two fields: a title and a content area.

It’s not just the degree of specificity that distinguishes the two models. That wouldn’t be enough to call them separate models. It’s also the fact that the placement of the templates within GatherContent’s hierarchy is considering crucial information about that item.

So the simple body content chunk may only contain a title and text but it’s where it is, how far down it is nested, will determine the type of title – it could be an h2 header if it’s nested directly beneath a page container or it could be an h3 if it’s nested within a body content chunk which is itself considered an h2.

The point is that there is setting within the template itself that says “consider this header an h2”. The pieces are simple and abstract but their relationship with each other tells us more about them and how they should be used than in the previous prospectus example.

So let’s call the first model, with our subject and course content, the “templatised model”. And let’s call our “new” “model”, if we’re going to call it that, the “nesting model”.

Reasons for

I thought of the “nesting” model to help solve a number of problems we’ve encountered when working on content previously.

1. Encourages discipline around writing

There’s a well-known study about how users of the web tend to read in F-shaped patterns and I was conscious of that when I thought about how we might embed principles about writing for the web into the nesting model.

In theory, having simple component template parts should encourage a certain type of thinking about the content itself.

I wanted to encourage thinking about content in short chunks or fragments with frequent use of headers which itself would encourage a style of writing more sympathetic to reading on the web – scanning, looking for relevant labels or words until something catches the eye.

2. Standardises the code

Thinking in shorting chunks of content also meant thinking in terms of components that would be rendered on the page. I wanted the code in each rendering which would eventually be used on the actual webpage to contain all the relevant code and be standardised.

For example, this article on using section tags correctly explains how they should wrap the headers and content on each page. As far as I was aware, no-one in the team was doing that correctly or even thinking about the ordering of headers on a page. Sometimes, pages would be created without an h2 but with plenty of h3s or h4s.

When we’ve written directly in our CMS previously in the page all of the semantic stuff in the source code is something that has to be done manually or is not at all. And if it’s done manually that requires a lot of discipline and/or a lot of automated testing and quality assurance on our pages. Our content writers aren’t coders and we’re not yet at the point where we’ve systematised quality assurance. There hasn’t been the interest to put resource or time into it.

So the “nesting” model and subsequent rendering takes care of that. If one of our content writers wants a header and some text, they just use the simple body content chunk, the nesting takes care of the architectural bit, and the rendering takes care of adding <section> tags and id properties for anchoring and so on.

3. Means content is backed-up

Our CMS – both of our CMSs – have lost us content in the past. I’d like to say never again…

But further than that, GatherContent has a good versioning system, automatically recording who is making changes and when, and employing a “Save” button so you can manually specify what should be considered a draft or key revision.

4. Allows workflow and discussion/comment

Working outside our CMSs has allowed other members of the team – our Marketing Officers, for example, who have the most interaction with our subject matter experts (or, as we’ve tended to call them, Information Owners) – to comment on the content as it gets written.

And the workflow is something that allows us to be specific about what stage each item – even down to each little chunk on a page – is in.

5. Saves time (in theory)

Our CMSs are also pretty slow. Working on GatherContent, in theory, should be faster to just get the writing done. No fiddling around with formatting or code, and no waiting for entire content trees to load.

More on that later.

6. Division of labour

Finally, I really wanted to get to point where the writers in the team could think about the building of a site when everything had been agreed and finalised.

That is, they could keep structure and order fluid up until the point where the site itself needed to exist in reality. Then the job of building could be a simple, orthogonal task, pretty much following the instructions each Content Officer had laid out for themselves.

I was even hoping at one point that the site-build could be outsourced or given to a new role within the team at some point.

Reasons against

So I’ve outlined all the reasons I can think of for using GatherContent in the way that we have.

But, of course, having been working this way for a few months now across several projects, we’re starting to reflect and see the problems. Here they are lined up with the advantages given above.

1. Prevents flowful thinking

A couple of people within the team have remarked to me that they like thinking in whole pages and chunking everything up is actually not that helpful.

They’ve found themselves wanted to draft the entire page and then separate it into chunks once they have it pretty much finalised.

This isn’t a bad way to work but our current nested model doesn’t help facilitate that very well and can create more work.

2. Renderings need building

So we’ve thought about creating some new, slightly more specialised templates to help with that. But at the moment only I can do that – we don’t have deveolpment resource within the team at present – and I don’t have much time.

This isn’t so much a problem with the model but with the fact that the team isn’t resourced to do this. I have been talking to people outside the team to and resolve this.

3. Ordering is not backed up

As alluded to earlier, GatherContent’s versioning system is a really useful way of seeing what has changed about an item over time. You can even rollback to previous versions of a piece of content.

However, there is no overall project history. So the ordering of items, and the way that they might have been nested in the past, is not viewable. One cannot roll back to a different configuration of items, only to a version of the content within them. This is a flaw of using this model in GatherContent.

4. Discussion happens outside GatherContent anyway

I’m not completely sure on this one and I want to find out more, but much of the discussion around content tends to happen outside GatherContent anyway. Content writers and Marketing Officers might comment on items or specific bits of text, but currently our stakeholders see screenshots and print-outs of renderings of the pages rather than look at items in GatherContent.

In a way they have to because the content is so chunked in GatherContent it doesn’t make a whole lot of sense to look at it in that way (see problem #1).

5. Takes time (in practice)

If nothing else, GatherContent should remove the distractions of working within a CMS. But it should also be quicker as a system or interface than our CMSs, which are slow..

Unfortunately, it’s not clear that either situation is the case.

Firstly, the need to re-order items in a separate area to the writing of the content in those items is actually quite fiddly and can take a lot of time. Given ordering and nesting are crucial to the model this is a serious set-back.

Also, the renderer itself takes time to pull all the content from GatherContent’s API every time which makes it slower than it should be.

6. Labour is not divided

Although, I’d envisaged a situation where content writers could focus on writing content and web adminstrators could focus on piecing together what they mock up, that just isn’t the reality right now. The make-up of the team does not currently reflect what I’d originally envisaged – that’s a resourcing issue and a case I might have to make to people higher up.

However, there might be a question as to whether the work should be divided in this way or if, for some of the reasons given above, actually it makes sense for content writers to build as they go.

Ideally, in future, all of these components we’ve created, this approach should be integrated into a CMS. I’m not sure any CMS approaches the problem I’ve wanted to tackle in this recursive way – but then perhaps that way of thinking does not lend itself well to writing content anyway.

Next…

So on Wednesday I’m running a little workshop with the team to find out more about how they’re using it, what works well, what doesn’t, and what can be improved, if anything.

The eventual outcome may be that we take a different approach altogether.

This is my first blog post in my new role as Acting Head of Content where I’m temporarily leading the team until a decision is made about the role as a whole.

It’s been a busy time, not least because I’ve still had most of my old role to look after until recently, and because my partner and I moved house recently. But I hope to get back into blogging regularly, even habitually, very soon.