• It’s okay to have more than one taxonomy.
• Taxonomy is NOT the same as navigation.
• You want to create multiple navigation structures from a taxonomy and prevent people from creating multiple taxonomies for navigational purposes.
• Taxonomies are the organising principles behind metadata and the values that populate metadata fields.
• Not all classifications are taxonomies.
• You need clear rules for when the business will own metadata vs when technology will own metadata.
• Use metadata to drive our content models.
• Always tag by id and never by term, so that you can change terms without impacting the taxonomy.
• Need to sell business value of taxonomy to business users.
• You cannot have a single standard for metadata that will cover all types of content for the Internet of Things.  Embrace that and move on.
• You have to provide context to concepts to make them meaningful, which makes it difficult to beg, borrow and steal taxonomies from one business and apply it verbatim within your own.
• What seems like a taxonomy at first, may become a process.
• Information metabolism is about enabling the business to make information decisions faster.  You need frameworks in place for improving an organisation’s information metabolism.  Example given of Motorola going form 4 weeks to 24 hours.
• Understanding the different paces of change within your organisation clarifies a lot. You need adaptability in fast moving layers and stability in slow moving ones. Pace-Layering.
• You must pay attention to the clock speed of your process (e.g. web content (medium), e-commerce(very fast), intranet dev(slow))
• You need a universal remote control system for taxonomy.  Each application has a remote for their system, a way to implement taxonomies, but there are not universal.  They only pretend to be.
• Metaphor around moving house was valuable.  So when migrating content, you need to touch it and see where it adds values, instead of  just moving it.
• Every business case has ancillary benefits, that are harder to quantify.  Stay focussed.  Baseline, benchmark, and have a clear understanding of what value your intervention brings.
• Be clear on the relationship between maturity and capabilities, and where you as an organisation are on that journey.  Then map your process requirements within the context of known capability gaps and seek to plug them and/or address them later. Use taxonomies in different ways depending upon your maturity.
• Always build capabilities on solid foundations.  Invest in change management because whilst some folks gradually evolve with you, others have been forced into that change, so build capabilities with this in mind.
• Don’t ask data architects for taxonomies.  Ask for reference data.  That’s what you really want.
• When doing taxonomy, you must be thinking about search and SEO.
• Searchers search ambiguously.  We need to help them disambiguate their queries by giving them values.  Values derived from taxonomies.
• Beware what happens when you fix search, you find out that your content sucks.

Content producers do a lot of things – Create content, Find content, Re-use content, Value content, Review content, Tag content. The CMS also pulls its weight with content: storing, indexing, auto tagging, displaying, recommending, publishing and workflow. This requires us to think really hard about how we intelligently structure content. And that’s where the battle is waged today for both time and effort to do editorial thinking on CMS build projects.

Instead, what typically happens during the early stages of a web content project and leading through into the build is that focus lies almost entirely on the customer-facing aspects of the web-site: the simple publishing challenge. Unless we start turning our focus inwards and shining the light on the difficult editorial challenge, CMS projects will forever be slated as those projects doomed never to deliver on business expectations.

The first post in this series highlighted the issues CMS projects faced following the build path above. Today, we’re going to add another path to the project that gets us thinking more about authors.

The three stages above map onto the way creative agencies tend to engage on content projects. This is no coincidence.  A CMS build will always take creative assets as outputs. However, we need to ensure that these outputs make sense as inputs to the build process. And in order to help shape the quality of creative outputs, technologists need to step up and into the creative design process to:

•  Explain how creative outputs impact the build.
•  Demonstrate the CMS art of the possible/impossible.
•  Highlight gaps in the outputs that the project needs to plug.

For a simple site, with authors, we need to work with both paths in parallel: creative and content. Whether it’s a short-lived digital campaign, a long running micro site or the corporate web site itself, we need to consider both paths if the content is going to end up in the CMS. In doing so, intelligent value decisions can be discussed in an open and transparent way, at time when they can be acted upon:

• Should we invest in building tailored authoring interfaces that both simplify and enhance the content creation process, or rely upon the “out of the box” CMS interfaces?
•  Do we really need to single-source content for re-use across the business, and do we have the skills and backing to do that?
•  Where is the web site going? Does it need to evolve to better support multiple channels, multiple devices, multiple sites, multiple languages, multiple business units, multiple products, multiple authors, multiple blah?

Based upon these decisions, you can get a feel for how much effort needs to be placed into the content stream. It’s funny (not really) how many of these decisions are encountered during the build. It’s scary (really scary) just how many of these decisions are made by developers, unbeknown to the business, in order the get the CMS projects delivered. Why?

Instead, open the box. Look inside what goes on it a CMS build. If you’re on the creative side, re-visit your outputs and see if they are catering for content producers. For CMS folks, are you holding the line and waiting for the right outputs?  Why aren’t you rolling up your sleeves and getting involved to help mould them into something you can really work with.

This is where I see content strategy playing a vital role in pulling these two streams of people, process, and products together. The reality is that this is a really hard sell because it requires change on both side, and for the client to buy into it (literally).

It also has a lot to do with the digital maturity of the organisation, and to a certain extent, their content maturity. For media folks, where content is their product, there is no sell. They get it. They know the value of content.  So for them it’s more about their ability to execute, which points more to their digital maturity. Where we are dealing largely with marketing content, it’s a much harder sell. But with mobile firmly on the executive boardroom agenda, multi-channel content and all its disruptive challenges, things are starting to change. And with that change, maybe, we can better communicate and take these additional paths during CMS builds projects.

This post is the first in a series short posts that looks at some of the common build paths content management projects take when delivering web sites. Not every project is the same but they do tend to follow a set of common delivery patterns. Let’s start at the beginning with the simple site.

Simple Site, Design-Led

You want a new website. You have a vision and plan for how to get there. Maybe it goes something like this:

1. Brief in the creative agency.
2. Do some information architecture, interaction design and user experience.
3. Create outputs in the form of site maps, personas, user journeys, wireframes and PSDs.
4. Perform several rounds of usability testing.
5. Maybe create some HTML, supporting content (video, case studies, imagery), SEO, etc.

Great, now we have some deliverables and it’s time to get this site built people. Your project plan tells you it’s time to select a CMS (if you’re lucky) and find a solution provider to bring your site to life.

This is how the majority of web sites were delivered 10 years ago. Some still are today. Here, the CMS Build project path is a design-led effort where success is measured around just getting it live and the web site is only concerned with one channel: the web. This is CMS Build 1.0.

You’ll notice from the 3 simple steps above that all the focus is entirely on the end customer and the published site. There is little or no consideration for those folks responsible for creating and curating site content. This is not an oversight. To quote a past client:

Cleve, it’s not that I(a marketer) don’t appreciate authors. I do. But I’m targeted on end customer stats. It’s a tech problem to kept the site up to date. (Cira 2007).

CMS Build 1.0

Today, digital content projects expect more than what a CMS Build 1.0 project can possibly hope to give them. The build has to take a different path for some, if not, all of the following reasons (and more):

1. The Web is not the only channel.
2. The target audience is mobile using an incredibly diverse set of devices.
3. Digital publishing is iterative and incremental, no longer print and go.
4. Equal consideration for both content and design is required for effective user engagement.
5. Editorial tasks need to be super low effort if they are going to be useful at all for authors.
6. A CMS operates on a Garbage In, Garbage Out policy for content. Don’t put crap in and expect meaningful stuff out. Think semantically!
7. Content is no longer static. It needs to be wickedly dynamic, searchable, discoverable, customisable, personalised, localised, translateable, and so much more. It needs to be intelligent.

Every journey has a starting point, but not necessarily an end point. That’s okay. But it’s important to understand where you are before you embark upon a CMS Build. This goes beyond the content audit and into getting a better feel for an organisation’s level of maturity around digital content and it’s appetite for change. For a CMS Build 1.0 this is not really a concern, but in later posts, as the builds requirements become a little more involved, there are some things that are just not possible. The organisation is not mature enough and/or capable of achieving certain digital content goals. Understanding and accepting this early, something we techies refer to as failing fast, saves precious time and money, and sets you on a realistic build path for success.

CMS Build 2.0

CMS Build Projects needed to get smarter. They have. Technologists have to reach out to all manner of content folks within a CMS project. Techies need to step up and clearly articulate what their desired outputs and outcomes are from upstream activities, as well as communicate the art of possible with the technology they so deftly wield. We’re not there yet with CMS Build 2.0, but we’re getting closer by thinking about:

• Content Strategy: Get involved. Understand more about planning, delivering and governing digital content.
• Content Architecture: Invest time and effort in determining how technology can be used to support the content strategy.
• Author Experience: Focus on the tasks content producers perform and build structured authoring interfaces to manage that effort.
• Content Technology Platforms: Bringing all the required best practice, standards, policies, content, and processes together under a platform(s), using technology as a facilitator where appropriate.

We do this, and the business gets all things we know they want; reduced costs, lower time-to-market, optimised resources, and increasing customer satisfaction. We give them means to be more profitable. We’re happier as a result. Win-Win.

What shape is your CMS Build Project in? Are you 1.0 or moving towards 2.0?

Why? Because I love writing.  I’m not great at it and I’m okay with that.  But it’s the most effective way for me to structure and prioritise my ideas. Seriously people, I have far too many of the buggers.  Also, writing keeps you honest and engaged with others. If you think you know something,write about it.  Writing is a surefire way of finding those pesky gaps in your knowledge that others, often very much smarter than you are, will help you plug.

Looking forward to 2012.

URL Naming

A URL Naming Scheme clearly outlines how information is accessed across a Web Site.

Rationale

A clear, consistent and agreed upon URL Naming Scheme leads to better site organisation. It also has the added benefit for improved crawling of site documents by search engines.

URL Naming aims to create friendlier URLs for visitors to link to site content. Early consideration of a URL Naming Scheme addresses key questions around:

1. How content owners expect site visitors to access content.
2. What content providers should be thinking about when contributing content, and
3. How information is organised.

A clear and upfront understanding of the URL Naming Scheme informs Content Structure, which in turn informs Site Design.

Conditions

1. All letters in the URL should be lowercase.

2. Use ‘-’ to separate words in rather than spaces or underscores (‘_’).

3. All items on the URL Name Path should contribute to the understanding of the content.

4. Use

real names

for actual documents rather than

ids

where possible.

5. Opt for a ‘wide and shallow’ URL Naming Scheme over a ‘narrow and deep’ one.

6. One URL, one document. Do not have multiple URLs referring to the same document.

Examples

Consider the following URLs:

1. http://www.guardian.co.uk/politics/2010/may/08/david-cameron-faces-tory-anger

2. http://news.bbc.co.uk/1/hi/uk_politics/election_2010/8669508.stm

They both adhere to recommendations 1,2 3, 5 and 6. However, for recommendation 4, the Guardian does better than the BBC which unfortunately uses a less meaningful id of 8669508 for a similar story.

Multiple URLs for the same content can creep in by:

1. Having sub-domains access the same content (e.g. www.domain.com/mycontent.html vs. docs.domain.com/mycontent.html).

2. Mixing www.domain.com and domain.com versions of URLs within the site. Always use the www.domain.com version.

3. Using odd capitalisation of URLs (e.g. www.domain.com/MyContent.html vs www.domain.com/mycontent.html). For Windows IIS Web Servers these pages will be served back no problem, and hence you have two URLs for the same content.

Dependencies

Not Applicable.

Sources

http://www.google.com/webmasters/docs/search-engine-optimization-starter-guide.pdf

Tags

seo, url, design, domain

Using Web Standards

If you develop Web Sites, you can’t escape the URL question. It’s always there. But after years of asking the same questions, project after project, and getting the same answers, time and time again, the Web Standard embodies 90% of the common sense thinking. No need to re-invent the wheel. The Web Standard outlines the agenda. The starting point for discussion within the Web Team and between third party contributors. Feedback is given and a Web Standard specific to the project in question is the end result.

For a particular Client, a URL Naming Web Standard may hold for all its Web Sites. Or maybe for one department. Or just for its Microsites and have slightly different versions for extranets and/or intranets. What’s important is that the Web Team has a useful and useable guide for URLs that is measureable. Moreover, the Web Standard is clear, actionable and digestable. Not a verbose, obtuse, wall of text that unfortunately is the mental image most people conjure up when they hear the dirty words ‘Web Standard’. It doesn’t have to be this way.

Best Practice or Web Standard?

I get this question a lot. Is URL Naming a Best Practice or a Web Standard? Well that depends largely upon how it is enforced. Again, an example. You and your Web Team have been asked to build a new Web Site. You agree upon a URL Naming Scheme, tweaking it here and there. Finally, you’re happy and you communicate its rationale to all members of the Web Team. Now, URL Naming is a Web Standard if:

• It’s mandatory.
• Steps are taken to ensure the Web Sites URLs are compliant.
• The Web Site fails Quality Assurance because its conditions have not been satisfied.

If the use of URL Naming is optional and its application is NOT enforced, it’s considered best practice.

A Web Standard does not have to be hundreds of pages long. It doesn’t have to be approved by industry bodies or Internet task forces. A Web Standard is a means by which the quality of your Web Team’s deliverables can be measured. With this, the Web Team has a clear benchmark for success or failure. The QA Team knows how to define success. The Web Standard is enforceable. A welcome hoop that the QA Team makes the Web Development Team jump through.

Web Standard Template

Okay, I’ll leave you with an updated version of a Web Standard Template. This is a works in progress. If you have any suggestions for making this better and/or examples of your own, please leave a comment.

Name

The What: What does the Web Standard do?

Rationale

The Why: What is the reasoning behind the Web Standard; the problem its attempting to address.

Conditions

The How: The list of conditions that must be met in order to satisfy the Web Standard.

Examples

Demonstrate by example how best to apply the Web Standard.

Show how the Web Standard satisfies its conditions, highlight key trade-offs and the results of applying it.

Dependencies

What other standards, best practices, recommendations does the Web Standard rely upon?

Sources

Provide links to reference material, articles and supporting documentation.

Tags

Improve the Web Standard’s findability.

Tag with phrases the Web Team will use search/refer to the Web Standard.

For example: seo, design, authoring, workflow, accessibility.

Confession. Having worked in and for large organisations for over 25 years, I was never a Web Standards fan boy. They were always out-of-date. They were written by non-practitioners. Their format was dry and verbose. Their purpose unclear but just obey. Effecting change or providing feedback was actively discouraged.  In short, information flowed one way: down! There was not much to like about Web Standards.

However, if you can get past all, there were little gems of insight locked away in these Web Standards. Looking back through older eyes I realise that I never really hated Web Standards. I just didn’t like the way they were enforced. So I rejected them and promptly falling foul of throwing the baby out with the bath water.

Web Standard Example

Learning from past mistakes, here is a simple web standard example.

Name:

All Web Pages must be XHTML compliant.

Purpose:

XHTML is the recommended markup language for the Web. It helps to avoid accessibility problems. Has better tool support and facilitates the re-purposing of content on the page. XHTML is more predictable and widely used across different device types.

Success:

1. Open the document with the appropriate DOCTYPE and NAMESPACE.

2. All markup tags are lowercase.

3. All attribute values are wrapped quotes.

4. Close all tags.

5. Close all empty tags.

Tests:

Use http://validator.w3.org/ to determine if the Web page is XHTML compliant.

Web Standards 101

That was simple.

A Web Standard is both a guide and a measure. Web Standards are educational aids used by developers during the implementation phase. They clearly document their purpose and outline the specific steps required to meet them. As a measure, use them to evaluate compliance of project deliverables against agreed web standards.

The above Web Standard has been trimmed down for the purpose of this post. The fully blown standard would have:

• Links to the XHTML standard.
• Sample snippets for all the success cases (e.g. how to wrap all attribute values in quotes.)
• Links to related Web Standards.

Web Standards can depend upon other Web Standards. For example, XHTML is a Web Standard. That’s great because that’s one less thing you have to do.  Just reference it and move on.

Web Standards are also written within context of your organisational business objectives. If you’re a government institution, then accessibility Web Standards may be higher up on your priority list. If your company with Software as a Service (SaaS) product offerings, then Domain Name and URL Strategy Web Standards will be core to satisfying your business goals. As an organisation, there will be Web Standards that are mandatory across all your projects, while others will be optional. The optional standards tend to be Best Practices, than Web Standards that must be enforced in order for your Web Products to pass some form of quality assurance testing.

Wrap Up

Web Standards bring tangible, concrete benefits. Web Standards are the low hanging fruit from which organisations can quickly derive high value, for low risk, with minimum effort. This is because Web Sites are well understood. Web Sites are founded upon well-established protocols, industry best practice and open collaboration.

However, in spite of this, time and time again, organisations do not set, maintain and enforce Web Standards very well. It’s an all or nothing scenario here. Either do it well, or don’t do it.  But when done well, Web Standards significantly raise the quality bar on your Web Site and increase the productivity of your entire Web Team.