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.