Contented Management laughing buddha logo

Contented Management

Contented Management

What makes different WCM different?

NMNH beetle specimens by Mr T in DC

I’ve recently been working on a number of web content management system selections. My preference is to carry these out in a two-stage process (see the one-sheet guide to selecting a WCM). The first stage pre-qualifies suppliers according to client attitudes to cost, risk and technological preferences. The second stage then gets into the real tasks that you want to perform, discovering how the WCM enforces and informs processes.

Like most other people in this business, I approach this from the point of view that there is no best WCM, just different products that may be viable for different kinds of tasks. It’s about finding a product that will allow you to get started as quickly as possible without precluding later ambitions. I try to show clients what a WCM could do for them, and in turn client aspirations suggest product features. These usually centre around a number of core areas:

Editorial interface

How is content updated? Is it through a browser, a document template, or some other application? If it is through a browser, which browsers does it work in? Does it require a plug-in? How viable are those constraints within the organisation? If the organisation is planning to devolve editing, how appropriate are WYSIWYG and in situ editors? If content entry needs to be more controlled via forms, how will users preview their work? Can the WCM offer different editorial interfaces for different types of users? And hand in hand with the interfaces, if you have lots of devolved editors, how does the WCM assure concurrent contribution and secure access for different kinds of users?

Pages vs. elements

Some WCM only really have the concept of pages and associated assets, making it hard to re-use fragments of content across the site. This simple model is generally appropriate for two scenarios: where there are many devolved, occasional contributors who would be confused by having to perform multiple tasks to get a piece of content to update on one part of the site and wouldn’t immediately understand the implications of a more complex editorial change; and for sites which have quite user journeys with little information appearing in more than one place.
For sites which need to re-use content a lot, where there’s a central editorial team assuring that changes are propagated correctly, more advanced systems that use “fragments” of content in multiple locations across the site in an “edit once, publish many” model can bring significant business benefit. These content management models usually bring more flexible templates but they can also make it more difficult to audit content: what did a given page look like on a specific day and who made the content changes? They are also reliant on robust link cohesion, so that if you move a piece of content, the WCM continues to link to its new location.

Content structures

Absolutely central to most WCM is the concept of a content type. This is the model that allows you to define which fields editors need to complete to publish a page and the constraints on those: e.g. title (no more than 200 characters), summary (plain text), main body text (rich text), location (postal code), category (list of valid values), etc. These structures are important for a number of reasons. They allow you to create business rules for linking content, such as get me the three latest news items about Germany. They allow you to create different presentations for different types of content, so am event looks completely different from an FAQ. And they allow you to contol which information must be completed before content can go live and how it will be presented on different platforms once it’s been published.
There are other metaphors that WCM use to relate complex content: hierarchical metadata structures such as folders, categories or channels enable you to group content together in more complex ways. Flatter metadata structures also allow you to “traverse” across website structures and relate content in differnt part of the information architecture that don’t sit into this hierarchy. It’s often useful to have multiple kinds of metadata, particularly faceted taxonomy, if your content is particularly complicated and needs a lot of content relationships in order to achieved desired user journeys.

Technology

Where the WCM isn’t a standalone application but needs to integrate with other systems in a web platform – user directories, CRM, eCommerce, transactional tools – you need to validate how it will communicate with other systems. Is it through the Application Programming Interface (API), web services, or some other method?
The maintenance and extensibility of the system can also be important requirements. If I need to change a content type, what does that involve? If I need to get data from another application, can I do this in a de-coupled way?

Some other factors may come into play, such as workflow, internationaisation and personalisation. If one product is particularly strong in one of these areas and it’s a key requirement, then it may get into a shortlist even if it’s weaker in some of the other areas identified above.

This all brings me to the recent debate about whether WordPress is a CMS, with numerous contributions on Twitter as well as from:

My experience of WordPress is that it’s really good at two key features where some established content management systems are relatively poor: search engine optimisation and comments. On SEO, it ties your blog post title to a friendly URL, enables good internal linking (as long as you don’t move any pages), allows tagging and categorisation and offers some great SEO tools. Comments meanwhile can be quite tricky for some WCM that operate separate content contribution and consumption environments, but WordPress does this easily, with useful anti-spamming tools and the ability to follow the comment conversation by RSS or email.

When it comes to the question of whether WordPress is or isn’t a WCM, the best analogy I could come up with was a camera phone. A camera phone does take pictures, it is convenient, some phones even have a flash and autofocus. But would you get a camera phone specifically to use as a camera? I think not if you’re serious about photography, It is a camera, but a very limited one.

WordPress is a blogging tool with some shared characteristics of a WCM. If you apply some of the many available modules to it you can come up with a really nice proposition, up to a point. But you’re effectively hacking the software to get it to behave as many WCM already do. You can get any software to do pretty much anything in the end, but that still doesn’t make it a WCM.

WordPress is widely used by many organisations as a web content management system and there are a lot of photos taken on camera phones. But you need to understand the product’s limitations and if these don’t affect you and you’re achieving what you want, then no one should criticise you for your choice. But let’s be sensible about it and say that even if there’s no such thing as the best WCM, you know that it wouldn’t be WordPress.

Philippe Parker on , , | 4 March 2010 | Tweet this |

Contented Management

The importance of good metadata

There’s been some debate on the role of metadata in content management: is metadata the future of content management, an integral part of the content, or are we making an artificial distinction?

Let’s start by setting aside the technological issues, because these are largely irrelevant. Metadata may be stored in a database separate from a file, or in a distinct table, or marked up differently, but this isn’t the determining thing that makes it different from other data or content held in a system. It can even be an inherent part of a document. What makes metadata different is how it’s used.

Metadata is used for classification. It’s used to relate one piece of content to another and to help people and systems find relevant information. If it’s not serving that purpose then it’s not metadata.

This may lead you to the conclusion that I’m saying everything is metadata. But it’s not. Some content that is marked up as metadata isn’t really metadata at all, or is at best poor metadata. Take a look at the UK’s National DNA Database, for example. This database records ethnicity and skin colour as a way to search for people, but one person’s view of their ethnicity may not be shared by another’s. This disparity has effectively rendered this metadata set useless. The records on ethnicity and skin colour are potentially useful as content, but unreliable as metadata.

So if you’re looking to define metadata types and corresponding taxonomies for your content, you have to consider how those doing the classification will apply the metadata and how other people are going to use that classification. If it’s not useful, it’s not metadata. If it is useful, you’ll be on your way to managing your content.

Philippe Parker on | 18 September 2009 | Tweet this |

Contented Management

Ditch useless content

Historically, web content management and records management have been at two different ends of the content management spectrum: web was all about time-to-market while records were about defining what you could get away with deleting. As web has increasingly become a channel for storing and sharing business-critical content (both within and beyond the firewall), you need to consider how long you can afford to hold onto your web content for.

Typically, retention policies are based on regulatory requirements, but it’s also a matter of reducing clutter. Most information we have at our disposal is useless: getting rid of it is going to help you get to useful content far more quickly.

So how do you sift wheat from chaff and decide what should stay and what should go? You have a number of options:

1. Stock-take

Spider your website every six months to get the last updated date for every page. Assign someone to go through every page that’s over six months old and decide if it’s valuable. If it is, update its last updated date; if not, remove it.

Pros: simple to implement.

Cons: a time-consuming and pretty blunt instrument.

2. Rolling assessments

Slightly more effective than a six-monthly stock take is a rolling approach, which you can do by setting a workflow status in your CMS to alert you to review each piece of content six months after its been published. The review cycle is therefore becomes business as usual rather than an arduous project.

Pros: spreads the workload, covers content that isn’t spider-able (such as reserved, non-public content).

Cons: still treats all content as equal, irrespective of its real value.

3. Pre-classification

Use either of the above methods in combination with metadata attached to the content. When you first publish your content, classify it as strategic or tactical. You can also add classifications for legal purposes (such as content covered under the data protection act). The different classifications then attract different review cycles: you review strategic content every year but tactical content after 6 weeks. You can add as many classifications as suit your needs and tie them to content types automatically within the CMS; for example, research publications are always strategic while press releases are always tactical. You can also automate the removal of these pieces of content using the CMS workflow.

Pros: flexible, extendable approach to retention; simple to implement with editorial guidance.

Cons: you’ll probably need to do an initial stock take of your existing content in order to perform the initial classification.

You still need to decide how you archive your web content: do you simply delete a page completely, or do you archive off a section of the site to a flat-file copy so that you can refer to it if necessary?

Whether you archive or delete, removal of useless content is an essential activity for all large website owners. Implementing a web content retention policy will bring real benefits to your organisation beyond the world of compliance. Less clutter brings easier content management, simpler information architecture and better access to relevant information for your user base. It’s an essential de-tox, so get deleting!

Key reading:

Philippe Parker on | 2 June 2009 | Tweet this |

Contented Management

Content type essentials

The concept of content type is so fundamental to CMS that you could argue any system lacking this definition really isn’t a CMS at all: it’s a blogging platform or page builder.

At the most basic level, content types are a classification tool used to distinguish groups of content. Typically, websites will have site sections, news stories, reports, and so on. But this basic classification is handled easily by metadata: just tagging a page as a “news story” and using that tag as a link to other news stories is very straightforward. It’s not really making any use of the content type metaphor.

So what are the benefits of content types?

1. They provide structure.

Larger sites need structure for several reasons: it helps contributors to enter the right kind of information (title, summary, event dates); it helps them to put content into the right areas of the website or intranet; and, it assures consistency in site design across pages that have the same function but different content.

2. They scale the system.

Being able to distinguish between a job, an event and a personal profile is essential if you have a large site with lots of contributors. Content types help with the information architecture of your site for public users and contributors alike; they enable you to introduce navigation that you just would be very difficult achieve without this concept.

3. They enable devolved ownership.

Most websites are “owned” by a marketing or communications team who are keen to ensure house style across the main publication, but who would be happy for other departments to own and maintain their own content that doesn’t require editorial review. If you don’t have content types, it’s a pretty difficult task to set up areas of the site that one department can contribute to without having free reign to change everything, particularly if you want to ensure that public website navigation doesn’t simply reflect your departmental structures. If you have structured content that doesn’t require editorial intervention (press releases, jobs, events, etc.) you can simply assign ownership of these content types to internal teams without compromising the editorial quality of your overall website.

If you’re struggling with findability or devolving ownership of content on your site, there’s a good chance that it’s because you’re lacking the structure to cope with the increasing size and complexity of your site content. Revisiting your defined content types could well be a good place to start.

Philippe Parker on | 21 January 2009 | Tweet this |

Contented Management

Managing content management software

InfoWorld publishes annual awards for data management applications. It selected Oracle UCM (formerly Stellent) as the best enterprise content management application and SDL-Tridion as the best web CMS. Both of these products have their strengths: UCM enables you to share documents stored natively in Microsoft Word as web pages relatively easily, while Tridion boasts impressive workflow capabilities likely to meet any web publishing need. Nevertheless, these products have a common shortcoming in a significant area.

While content management software is designed to manage content — words and media are processed, stored and delivered in a controlled fashion — this management itself needs to be managed: workflows need to be created, users added and withdrawn, permissions changed. The most important aspect of this management is changing how content is defined. This generally takes two forms: management of a taxonomy or classification system, and management of the “content types”, or schema that defines whether you’re looking at a press release, event or personal profile. It is extremely unlikely that you’ll get all these definitions right when you first set up your CMS, so the ability to alter and extend the systems is paramount.

Tridion and Oracle both struggle in this area. As a static publishing system, if you want to update a component (content type) in Tridion, you need to republish your schema, add content definitions in each place you’ve made a schema change and then republish the content. In UCM meanwhile, if you can navigate to the relevant administration area to actually make the change and fathom out the unnecessarily ugly interface, you still need to republish the schema and all the affected content even though it’s dynamically driven! You even need to do this if you make a change to the metadata schema, because this isn’t stored in the database as an index, but as a string in a field. This is something you’d expect Oracle to correct pronto with the 11g release due Q4 2008.

You might have thought this kind of thing would be pretty high up most vendors’ agenda, but this is a problem for many CMS. Vignette works ok unless you customise the schema, which many users do. You probably need to look at Mediasurface Morello if you think your content types are likely to change. The product allows you to rename and add fields as required. You need to change the presentation template if you want to see the field you’ve added displayed on a web page, and you run into trouble if your new field needs to be mandatory since your existing content won’t include this information, but it’s considerably easier to manage the content management this way than to republish an entire site.

So caveat emptor. Updating your schema should be an essential part of any CMS product selection, irrespective of awards.

Philippe Parker on , , , , | 17 March 2008 | Tweet this |

Contented Management

Introducing taxonomy

Lots of people talk about taxonomy in content management, but its meaning and importance can be confused, so I’m going to try and provide a more concrete definition.

Taxonomy is about classification. It describes ways of naming, arranging and ordering things within a system. Those things may be books in a library, or plants and animals in biology.

Taxonomies are usually hierarchical and based on restricted terms. In biology, for example, there are a limited number of kingdoms, phyla, and classes. In the Dewey Decimal System, these restricted terms are based on numbers: Phonology (414) is an element of Language (400). These relationships are often described as ontological.

Dewi Decimal taxonomy: 400s as a subset of Language

Some things can belong in more than one place in certain classification systems. For example, a dish on a menu may be available as both a starter and a main course. These ways of looking at the item are often termed “facets”; so a Greek salad is both a type of dish (salad) and a course (starter).

Image showing Greek salad as a side and starter, while Russian is available as a starter only.

The “thing” in question may also have one or more synonyms which form part of a taxonomy. There is some overlap here with the functions of a thesaurus.

A recent innovation brought to the fore by websites like del.icio.us and Flickr is the concept of “folksonomy”. This allows participants to “tag” any page, image, or document according to their own vocabulary. As more people tag pages, these become related by shared terms, building up the classification system. This taxonomy is unrestricted: what one person calls design, another may call art, creativity, or even Photoshop.

How are taxonomy and content management related?
Content management typically addresses a number of key areas:

  • Production: providing the tools to enable people to create content.
  • Authorisation: ensuring that only relevant people are able to view and amend content.
  • Workflow: delivering content to people within the system once it passes through certain stage gates.
  • Storage and retrieval: providing a mechanism to store, find and re-use content held in the system.

Content management systems (CMS) can make use of taxonomy for authorisation and workflow, but they are dependent on taxonomy for storage and retrieval. Each page, document, or other asset held in the CMS is stored according to a predefined classification method.

There are different metaphors for this method. The taxonomy may be represented as types of document (e.g. contract), as departments with their own document silos (e.g. legal, marketing, human resources), as folders that represent some other business function (e.g. project start-up, initiation, execution, closure), or flagged with a value from a predefined list. Most CMS will use a combination of these classification systems so that content can be retrieved more easily.

Taxonomy vs. metadata

Taxonomy is often applied as metadata: that is data about data. Office documents have metadata assigned to them such as author and revision date. (To see this in your Office application choose File >> Properties and click on the summary tab.) Web pages also have metadata. There are a number of ways to view this, but the simplest is to choose View >> Source in your browser menu. Close to the top of the page you’ll see some HTML tags beginning meta name=”". The name attribute is the type of metadata they describe (description, copyright, keywords, author, etc.) while the content attribute holds the metadata itself. Metadata is often assigned from pre-designated classifications, so is an important part of any taxonomy project.

Where can I see taxonomy on the web?

In its simplest form, taxonomy on the web is represented as website navigation. Many of the techniques applied to develop taxonomy are used to develop more user-friendly websites. This includes activities like card sorting.

More complex taxonomies can be found at dmoz.org (a directory of websites) or, for medical research, GoPubMed.

Philippe Parker on , | 9 October 2007 | Tweet this |