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, 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 always hated Web Standards. They were always out-of-date. They were written by non-practitioners. Their format was dry and verbose. Their purpose unclear – just obey. Effecting change or providing feedback was actively discouraged – information flows one way: down! There was not much to like about Web Standards.

However, when you sifted through it all, there were little gems of insight hidden away. 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. In doing so, throwing the baby out with the bath water.

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-purposed 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.

A Web Standard is both a guide and a measure. As a guide, Web Standards are educational aids. As a member of a Web Team, they serve to guide how you develop Web Sites. The best Web Standards clearly document their purpose and out specific steps required to meet them. As a measure, your project deliverables can be evaluated on their compliance to Web Standards.

The above Web Standard has been trimmed down for the purpose of this post. Typically, it would also have links to the XHTML standard. All the success cases would have sample snippets that show by example things like how to wrap all attribute values in quotes.

Note that Web Standards can depend upon other Web Standards. XHTML is a Web Standard. That’s not a problem. Just reference it and keep it simple. 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. Others will be optional. These are more Best Practices, than Web Standards.

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. The cost to all involved of doing it badly are very high.

That said, when done well, Web Standards significantly raise the quality bar on your Web Site and increase the productivity of your Web Team. There has been some great work done by folks in the Web Standard Enforcment space, but I’m out of time. I’ll pick up on these over the next few posts.

Anyway, I’ve been thinking and reading a lot about SEO, Web Analytics, Mobile, Content Strategy, Content Migration, and Content, Content, Content. Today I stumbled across Avinash Kaushik’s stunningly simple 4 insightful questions for the macro analysis of web sites from his latest book Web Analytics 2.0 and felt compelled to share. So before you deep dive and start generating reports on stuff and more stuff, ask the following questions about the web first:

• How many visitors are coming to the website?
• Where are visitors coming from?
• What do I want visitors to do on the website?
• What are visitors actually doing?

The first two questions can be answered using web analytics (metrics). Not surprisingly, these are the ones folks can pretty much quote back at you without blinking. There’re easy. The third answer is specific to your business, whilst the fourth requires you to do a bit of analysis.

So, what’s the big deal? Again, not surprisingly, there is a lack of clarity and consensus around the answers to the last two questions. That’s because there’re not so easy. But that’s where the really juice is.

Surprise, surprise!

Thanks to Avinash for framing the macro analysis of a web site in such a simple and succinct manner.

It’s not the tech

For the last five years, I’ve found that web content management solutions have not been technically challenging at all. I don’t think we have a problem with tools. I don’t think there is a problem with vendors bigging up their solutions. That’s marketing and that’s here to stay. I welcome analysts providing vendor-agnostic feedback to assist customers in their selection, but they too add to the decision making uncertainty. Also, we should not lay all the blame at the doorstep of the poor implementation provider. Shit just happens. So that leaves the customer right. Although they pay my wages (and thanks for that), they not without fault either. So if no-one is to blame, what’s going wrong with WCM?

Jon’s post conference blog captured the mood. But the following tweets were right on the money:

[jdavidhobbs]: I think the lack of common vocabulary / architectural model of CMSes is a pretty big issue.

[chrisregan]: Differences in vocab and architecture, common even within a single vendor. Either get consistent quick or slow down cross-selling.

It’s us

This is not a riddle, but answer me this, sitting in your CMS world:

What is a template vs a component?

Guaranteed, as both David and Chris allude to in their tweets, and I continue run up against is ‘The Attack of the Assumptions’. I bet you already have an answer in your mind and it will most definitely be different from mine. Better still, you’ll hit back questions.

Now everyone knows there is a skill to asking the right questions, to elicit the appropriate answers. But it’s the questions you don’t ask that come back to bite you. The unasked question leads to assumptions, which in turn manifests themselves as expectations. Unmanaged expectations leads to unhappy customers. Unfortunately, because there is no shared vocabulary between customers, analysts, vendors and implementation providers, there is a high probability that the wrong questions are asked and right answers are never provided.

This is what is broken. And we can make steps to make this better. But we will never completely fix it. Because broken is imperfect, and nobody’s perfect.

That said, this is what I’d love to see, and maybe its out there, somewhere, but I just haven’t seen it:

• A WCM shared vocabulary that is owned by the industry.
• A set of user scenarios based of this vocabulary for doing the WCM business as usual stuff.
• Vendors mapping their product capabilities against these user scenarios.
• Analysts rating them by how well they do it.
• Customers referencing these user scenarios in their RFPs.
• Everyone speaking in the shared WCM vocabulary

So yes, that’s the dream. I’m sure people, companies, communities are doing (some) this in isolation. But that will not make things better in the long term. Only in the short term whilst you are a part of that group. The true pain comes when you need to leave the group and this is a massive consideration for anyone looking to change their WCM. You not just changing a product. You’re learning to a new language, a new culture.

Delivering a web content management solution involves people, process and products. You need to put the right processes in place to support the people to make best use of their products. But before we can do that, I think we need to start speaking the same language, and to stop assuming that we are.

Three months. Three different prospects. The same problem.

We have site(s) that are part of our Global CMS Platform, but we cannot make changes without working with global. We have been put in the content contributor box but are really content owners and need the associated tools to deliver our messages to our target audience. This centralised model of content management just doesn’t work for us. Can you help?

The is not an uncommon problem. If you invest in something big, you want something bigger. So for large organisations, an enterprise CMS is a strategic piece of kit. However, depending on whether you’re on the inside or outside, your view on whether this is a good and bad thing can differ widely.

View from the Inside

For large organisations it makes perfect sense to standardise on a technology stack and leverage your company’s collective commercial weight to broker the best licensing deal possible with your suppliers/vendors. Imagine, one content management system that can scale to meet the content needs for all your countries and/or business units globally.

Now we’ve bought into the dream, lets establish a central intelligence agency to create the generic designs, templates and components that all the satellite outfits within the organisation can (re)use. No pressure. We come bearing gifts. One platform, multiple players. Everyone’s a winner.

View from the Outside

Funny, I never get calls for help from inside. I always get calls from those on the outside that want to get things done. They get the theory from central but it just isn’t working from them in practice. It’s the usual stuff:

• We would like to change the look and feel on these pages, but the estimate from central means it’ll take them months before we get it.
• All we want is a twitter component, but it requires a template change, and that is going to hurt us financially.
• Our local market is different and we can never get the features we need from central within our timescales.
• Our standards and requirements for things like accessiblity and colours are different to those at central.
• We need to improve performance and search but its all hosted remotely out of central. Can we localise / improve this?

What to do?

These are largely organisational issues and their approach to content management. However, it’s not long before you the words:

We hate the CMS. It’s crap!

Maybe, just maybe, if we can start again things will be different. But will they?

9 / 10 you don’t have a CMS problem!

I totally buy into the theory of centralised technology stacks. Truth be told, I buy part way into the practice. But when you start being pulled into a more and more discussions from disgruntled outsiders, its time to stop, look and listen to them. Something is broken!

There are many ways to do this and politics aside, all of the discussions I’ve had to date have proven that their problems are not intractable. But largely this is a political battle fought by an incumbent system integrator/vendor/business unit at central against numerous guerilla outfits wishing to do more stuff with diminishing budgets in these challenging times.

My advice is to always try and work with central. Small wins. Tactical plays. These tend to demonstrate capability, highlight benefits, but more importantly send the message that you want to play ball. Slowly but surely the strategic wheels will start to turn in your favour. Trust me. I’ve never seen a successful go it alone and/or full on assault on central bring anything of value to the global table that tastes any good.

Delivering and maintaining large web sites is hard. It requires the business team to communicate what they want and for the technology team to deliver what they need. The two groups are known for not getting on. For a web project to succeed, they must eat from the same table, talk the same language and reach consensus. Communication is the key differentiator between success and failure here. It’s essential that when someone in the business says product that a developer not only understands what a product is but can implement it. Now, business and technology folks don’t share the same view of the world (which is a plus). However, not enough effort is invested to align these two views during the project(which is a minus). Think about it. The business is entrusting their most valuable assets, their content, to software developers that may or may not get it! We don’t have to live with great content divide.

What can be done?

I’ve found the best way for the business and technology teams to reach a common understanding of the subject matter is for them to collaborate on a shared view of the business domain. Have meetings, discuss stuff, card sort, write documents, role play, build prototypes, and so on. All important stuff. Keep doing that. But there needs to be something that captures the single source of truth that is a shared and mutually agreed upon representation of the business. The essential communication link between the business and technology team. That something is the content model.

How can we get better?

I’ve already spoken about content modelling and your essential first steps. I won’t go over that again. If you takeaway anything from this post, takeaway this.

Every CMS product implements its own content model that its developers understand. On your web sites, Your developers are translating your requirements into this content model, and rightly or wrongly, filling in the your missing gaps.

Are you happy to hand over your business decisions around your content to them? How do you know if they have got it right? How do you know if its wrong? We all know the cost of fixing problems is prohibitively more expensive downstream. A short conversation upstream could have completely avoided the creation of major problems that tend to arise downstream. Parking the details for now, the content model needs to be started upstream (analysis phase) and extend into downstream (development and testing phases) activities. The content model empowers the business, provides a common vocabulary for your content, and hooks in a number of downstream folks with a vested interest in managing your content going forwards. Maybe then we can start crossing the great content model divide.

What is a site map? Its a helicopter view of a web site with all the pages arranged in a easy to view and/or accessible manner. The best site maps fit onto a single page. For the more complex sites out there, the ability to drill down into specific areas of the site but keeping to the one page rule provides an alternative site navigation scheme.

In the majority of design-led projects, the site map is presented in graphical form that provides an essential first look at the structure/grouping of pages within a web site. The problem I have with these diagrams is that they are typically presented along with the completed designs. The finished article. However, for me they are the critical starting point for the journey to the centre of the content hierarchy.

Towards a Content Hierarchy

Web site pages are arranged in an hierarchical manner. URLs are just the means to access pages and/or content residing on those pages. The first thing I do when I get a site map is pray that its open to change and then try and express in terms of a content hierarchy. Take a look at the following site map:

Flattening a site map is a great way to start putting the meat on your content hierarchy bones. Reformatting the site map highlights errors and/or glaring omissions in your content model, site pages, content types, and so on. It’s just another means to help build/validate your content model. Believe me when I say that:

A site map is an innocent picture that hides a 1000 discussions.

So take a look at the flattened site map, the beginning of our content hierarchy (sometimes referred to as a content tree):

/content/
/content/contact-us
/content/terms-and-conditions
/content/privacy
/content/business/overview
/content/business/blog/2009/05/content-first
/content/business/blog/2009/04/content-modelling
/content/business/blog/2009/04/content-modelling/comments/1
/content/business/our-understanding
/content/solutions/overview
/content/solutions/delivery
/content/solutions/services
/content/solutions/how-we-work
/content/solutions/projects
/content/solutions/case-studies
/content/solutions/case-studies/2009/the-amazing-chocolate-factory
/content/solutions/case-studies/2008/ground-transportation-system
/content/solutions/testimonials/2009/google-loves-us
/content/voices/blog/2009/05/strategy-article
/content/voices/blog/2009/03/technology-article
/content/voices/team/cleve-gibbon
/content/voices/team/stuart-dean
/content/voices/offices/london
/content/voices/offices/poznan
/content/voices/careers
/content/community/partners
/content/community/events
/content/community/events/2009/06/24/eric-evans-domain-driven-design
/content/community/technology
/content/community/press
/content/community/join-our-community

At the moment this content hierarchy is at the page level but it has already raised a number of questions around missing content and roughly how it will be access across the site. Here are some quick observations I’ve made after doing this:

• Why are the offices under voices?
• How are we going to get hold of articles archives
• Would the site be better served by blog channels (business, voices, all) that provides an aggregated view of blog style posts?
• /content/blog-channel/business
• /content/blog-channel/voices
• /content/blog-channel/all
• How can we view events for in 2009, 2008, May 2009? The urls seem easy to construct using the above naming scheme.
• What does join-our-community do?
• Are they other ways of list items other than by date, e.g. /2009/05?

So what’s the difference between the site map and the content hierarchy. Well, the content hierarchy is the beginning of something more concrete that you can start validating in parallel with your content model. But that is something I’ll leave to a future post.

In Summary

The takeaway point here is that a lot of this work can be done BEFORE the creative works start. This is information architecture and content strategy. I’m not sure where the purists position it, but as a keen practitioner, its an essential piece of work done later rather than sooner. A content hierarchy should serve as input into the creative phase and not the output.

Of course, this is just the beginning. With a sprinkle of content modelling, we start dissecting the page and pulling out the content types and subsequently mapping these onto the available URLs. Although the content hierarchy is not an exact 1-to-1 mapping onto URLs, it does provide a great insight into the URL strategy that will be applied across the web site.

Say you’ve been asked to buy a suit for someone you’ve never met. What do you do first?

1. Buy the suit.
2. Meet & Measure them.

For design-led projects, we’re buying that suit first. By damn, one way or another that content will well fit into that design and look good! Of course I’m exaggerating a little here. But if have been in a project where the content is delivered at the end and simply doesn’t fit, you never want to go there again.

Now call me odd, but wouldn’t life be that little bit easier if we sized up the content first and then designed the site to fit it. Measure, then fit. I dream of projects where we all work together to determine what information a site needs upfront, organise it, think of ways to be navigate it and then and only then do we create the designs to satisfy those requirements. What typically happens is something that lies between these to extremes depending on when I get involved.

What is Content First

Content First is a way of thinking. It’s core to you and manifests in the way you approach content-oriented projects. Content first gives you sight beyond sight. It’s not just the aesthetics. It’s about joined up site development that delivers clear and simple messages to its intend audience.

Although I’m a firm believer in Content First, I do appreciate the importance of web design. It’s got to look good and provide great user experience. However, for me, web design is one of many representations of content. Albeit an important one, but only one. There are many other channels, such as email, print, mobile devices, electronic documents, and so on. The aim is to separate and maintain a clear division between content and its target representations. To this end, its is essential to think and act in a Content First manner, something design folks have called Content Driven Design in the past.

The Challenge

There are number of challenges that make it harder to work in a Content First manner. These are not show stoppers. You just need to be aware of the constraints and wiggle a little to give yourself some room to manoeuvre.

Design is an iterative and horizontal endeavour. It’s done when its done. Typically the business engage with a creative agency. The creative agency produces some designs. When the designs are complete, the downstream activities start. The following are things that tend to happen in these scenarios:

• The Lorem Ipsum Time Bomb – Real copy is never added to the design. Real copy is added once the system has been built. The real copy does not fit the designs.
• Sample Navigation – Assumptions around the size, amount, fragmentation, relationship and kinds of content made are design time are wrong. Navigation works in part but not as first intended.
• Simple Design, Complex Delivery – Some creative ideas are fantastic but are not feasible for the target delivery channel. Worst case is that these ideas are core to the design, resulting in a doomed implementation.

Some ‘Content First’ Recommendations

• If you are being asked to manage somebody else’s content, take the necessary steps to find what that content is. Do some content modelling.
• Do not wait for the creative agencies to complete their designs. Start building out the site and let the authors and your customers touch the system early. It will influence the designs at a time when changes are not as costly to apply.
• Get the authors writing content as soon as possible. Whatever it takes, create a means for them to enter content and facilitate the discussions around it before the designs have been completed.
• Never sign off on designs that have never been road tested with actual content. Don’t buy the suit unless you’ve tried it on!
• The content folks and creative team need to work much more closely together. Have many, many joint reviews. Staged handovers. Transparent working.
• Decide early on where the priorities lie. Is it a killer site launch? Site aesthetics are top of the agenda? Is the site a marketing vehicle? Or a combination of these?

At Cognifide, we have been thinking more and more about Content First and adapting our delivery to be more align to Content Driven Development, something I’ll leave for a later post. But as promised, the next post in the content modelling series will be all about the content model.

If content has value, then take the necessary steps to manage it:

• Understand it.
• Define it.
• Measure it.
• Manage it.

Content modelling is a journey where those on the project strive to get consensus on ‘the what’ of information. The deliverable is a content model. However, the real value is in doing content modelling. Get a better understanding of what information you have and need, inspect and adapt it, define it in business terms and measure it in a way that your organisation can seek to continually improvement their business processes. Only then are you in a position to attempt to manage it.

There are many tools and techniques for doing this and yet content modelling still remains largely a downstream activity used by developers to implement the technical solution. Tech guys know the value of modelling for driving technical processes. Unfortunately, the lack of upstream content modelling is the norm for the majority of content-oriented projects. Clearly content modelling needs to start earlier with those people that see, own and want to derive the optimal value from their online content. These people are not the downstream teams such as developers, testers and system administrators. These folks are the content owners. Content modelling should start with and be continually driven by them. They should have a clear understanding on their content. And it is our job to actively help them to define, measure and manage it going forwards.

What’s Missing

I’ve found that there is not enough people and/or discussions around content modelling. Maybe I’m looking in the wrong places but I continue to draw blanks in my google searches to elicit the simplest of examples around content modelling for content owners. To that end, I’ve decided to do it myself. I would of course appreciate any feedback, tips, hints, references to relevant material on the subject matter.

Take a look at the following web page:

To start with, think of pouring all the words, images, links, etc. on the page into a big bowl. We now have a big bowl of unstructured information. This is where the majority of the web sites are today. From a content management perspective there are completely unstructured. So lets add a bit of structure and see where that takes us. Lets do a little bit of content modelling.

Enter Content Types

Imagine taking that big bowl unstructured information, kneading it into a nice light dough and rolling it out on a clean surface. On the British Library web page above I see a list of news articles. Each news article has a date and a one line summary. A news article is a content type that has two fields Date and Summary. A content type describes a family of content items that have all the same fields. I like to think of a content type as a cookie cutter that you use to find the content items. Content types are used to define structured information, where fields such as Date and Summary, denote structure. All the remaining dough is the unstructured information that we need to gather together and roll out again, and maybe start cutting out some more content items and/or find other content types.

A key part of content modelling is finding content types. There are many ways to do this, so to name a few:

• An analysis of your competitor sites. What cookie cutters are your competitors using?
• Information brought to the table by the content owners/users.
• A review of the existing web site.
• Role playing / site walkthroughs.
• Content workshops / end user interviews.

As a content modeller, the end game is not about creating as many cookie cutters as possible and chopping up the dough so that there is absolutely nothing left to roll out. You need some unstructured information. Instead, you need to strike a balance between the unstructured/structured that effectively boils down to what information is of value to you now and what information is not.

Potentially Useful Content

In the South West of England the locals are very much into Potentially Useful Material, or PUM for short. One man’s PUM is another man’s junk. So, you get a new bathroom, and instead of throwing out the bath, it becomes PUM because someday, just maybe, you might need it. If I had a nickel for every time during a content modelling session I heard a someone say, “lets capture that information because it might be useful in the future”, I’d be rich man. My stock response to that is:

Show me the value today and I’ll gladly manage it tomorrow.

Nine times out of ten, these potentially useful content types (PUCs) are dropped. Be vigilant. Be ruthless. Eliminate waste. Focus on value. Do not pollute the content model with maybes and PUCs. We are already drowning in unstructured information, lets not add to it with PUCs.

Next Time

So we agree that content modelling is a good thing. We like content types and believe that they are a good way to describe a family of content items that share the same fields. But how to we capture these content types and present them in a useful and useable way that can be continually communicated to all interested parties? Well, that’s a content model.

In my next post on content modelling, I’m going to go into a bit more detail on how to represent structured information through pictures using a content model.

What’s the problem?

Project sponsors, potential authors, design folks, marketers, seo people, solution providers must work together to determine what information should be used across the site. This is the content model.

The content model is all about the “what” of information.

Now do not confuse this with the “how” of information that is typically thrown over the wall to the geeks sitting in a darkened room to sort out. Databases, XML, the content management system, whatever. This is data modelling (the how) and something altogether different, yet related, to content modelling (the what). Now, its not uncommon for projects to go arse about face and put the “how” before the “what” – the content management system cart before web site horse. It’s like being told to prepare to store X in the larder, only to be told later that X is a bag of frozen peas. Useless.

Now this all sounds like common sense and real no brainers, but there are a number of reasons why content modelling does not happen, so I’ll cut to the chase here:

• Everyone wants to talk to ‘the business’ and it simply overwhelms them.
• The very words content model causes eyes to immediately glaze over.
• Content types are perceived as difficult, divine, dark magical technology secrets.
• There are no standards, very few guidelines, even less shared knowledge on the subject.
• Only now are we beginning to focus more and more on strategy, analysis, design of content.

What’s the answer

I’m plain out of silver bullets. But I did read up on Bob Boiko’s book, the Content Management Bible. The bible, and its that big weighing in at over 1200 pages and 1.5kg, goes into a quite a lot of detail around content types. Unfortunately, I think Bob has got one foot rooted a little to deeply in the tech, that pollutes the content model with XML and database speak. I would like to re-visit content modelling over the coming weeks and draw out the interesting parts from Bob’s book and mind meld them with what others working upstream of the build phase are thinking. For example, Stephen Gracey’s approaches content modelling from the strategists perspective. Again, an interesting outlook, but the need for greater detail compels me dig deeper.

What’s next?

If you know what to look for, content types simply jump off the page and hit you smack bam between the eyes. A bit of refinement, a few questions here and there and a content model starts to emerge. I’ll get into all this in the next few posts. But here’s the caveat, content modelling is not easy. Its not a science. Its an art. And as we’ll see, the art has three big areas, each with their inherent challenges and trade-offs:

• Finding content types.
• Assigning fields to content types.
• Understanding the relationships between content types.

See you soon…