Trying to fix an organization’s content problems by installing a content management system (CMS) is like trying to save a marriage by booking a holiday. We know that a successful web project needs a content strategy—but when it comes to the CMS, we stop thinking strategically. Despite all the talk about user-centered design, we rarely consider the user experience of the editorial team—the people who implement the content strategy. We don’t design a CMS, we install it.
The problem: tools aren’t magic pixie dust#section2
Any web project more complex than a blog requires custom CMS design work. It’s tempting to use familiar tools, and try to shoehorn content in—but we can’t select the appropriate tool until we’ve figured out the project’s specific needs.
Wireframes are aspirational fantasies#section3
As Karen McGrane says, it’s easy to sketch a faceted navigation on a wireframe. It’s more difficult to implement a CMS to power the implied taxonomy, and to commit to ongoing editorial maintenance over time. A wireframe without a corresponding content strategy and a realistic CMS design is a work of fantasy. A CMS that could realize one of these fantasy wireframes would need plenty of magic pixie dust. We need content strategy to help us decide which of our aspirations is feasible; CMS design is an essential part of that decision.
Use a design process to select and customize a CMS#section4
Most of the time we select a CMS by popularity, cultural affiliation, or corporate edict—that is, without properly considering the content we’re supposed to be publishing. This is crazy. Instead, we should use a design process to select and customize a CMS, based on our content strategy and the editorial team’s needs. This article will show you how. But first, let’s take a step back: what exactly is a CMS?
A CMS is a bunch of features#section5
We’ll define a CMS as a set of software tools that enable non-technical people to manage web content. There are a bazillion different CMS tools out there. They tend to be sold on their features—and boy, do they have a lot of them. Here’s a taste:
- content creation and editing,
- content delivery,
- taxonomy management,
- curation and page composition,
- editorial workflow, and
- …continued ad infinitum.
Now, I love me a good CMS feature. But features alone can’t solve strategic, editorial, or governance problems. Too often, CMS projects become solutioneering, or throwing technology at problems. So what should a CMS give us, apart from a bunch of features?
A CMS should add semantic richness#section6
To get value from a CMS, think beyond editing web pages. As Jeff Croft argues:
…[content management] ought to include structuring, organizing, searching on, filtering, and easily modifying your content… [allow you to] quickly define new types of content… [and] facilitate establishing meaningful relationships between disparate pieces of content. It ought to make your content more useful simply by virtue of the content being in the system.
Web pages are where our content ends up, but using a tool that can only edit pages is like marking up document headings using the div element; it might look fine on the surface, but proper, semantic heading elements are more useful. So a CMS needs a rich content model that can generate semantic web pages.
A CMS should be customized for a project’s needs#section7
A product can’t fix content problems out of the box. Every CMS started out as a solution to a specific problem, later generalized to fit a wider range of problems. It’s an open secret that CMS tools need to be customized before they can be used on a real website. As D. Keith Robinson argues:
In truth most CMSs end up being custom, regardless of how they start out. From those that bill themselves as one-size fits all to the highly specialized systems which deal with specific industries or types of content. It’s just a matter of how much hacking you’ll need to do to get to what works for your people.
So a CMS is a bunch of powerful tools that add semantic richness to content, and that require customization to fit a specific project’s needs. Before we learn how to to apply them to a content strategy, let’s take a short history lesson.
Content strategy is shaking up the CMS industry#section8
The rise of content strategy is dealing the content management industry a huge kick up the backside. In the web’s Wild West era, the CMS was run by the IT department—or sometimes a lone webmaster who knew HTML—so CMS choices were based on features, price, and cultural fit, rather than web or content strategy. It was the classic IT drill: selection committees, feature matrices, and business lunches with men wearing neckties.
The times they are a-changin’. According to Lisa Welchman, the web is now “the organization’s primary communications, sales, marketing, and transactional vehicle.” A CMS vendor’s target audience used to be the IT Director, and a successful outcome meant each department could easily update their content silo. Now, the target audience is an organization’s internal editorial infrastructure; and a successful outcome is a complex mix of achieving business objectives, implementing a content strategy, and crafting a user experience. The game just got more serious.
A process for selecting and customizing a CMS#section9
We choose CMS tools for crazy reasons. See if you recognize any of these scenarios.
- Choosing a tool because someone you admire uses it—and expecting results like theirs—is like buying the type of guitar Jimi Hendrix played and hoping to fill Madison Square Garden next week. (Giveaway: “All the cool kids use ACME product.”)
- Choosing a tool based on your cultural attachment to it makes the project more about you than your client’s objectives and your users’ needs. Avoid holy wars. (Giveaway: “ACME product should be your next CMS.”)
- Choosing a tool because the IT department says you have to is like accepting an artistic commission while handcuffed; it’s possible to do good work, but you’re set up to fail. (Giveway: “The client requires ACME product.”)
It’s as if we’re considering every factor apart from the content. Let’s take the advice of Karen McGrane and Jeff Eaton, and “reframe the conversation”:
Shift the discussion about the CMS away from “features” and towards “task flow.”
So what does a grown-up CMS selection process look like? Here’s a workflow diagram:
Fig. 1 Workflow of a CMS design process.
The inputs are the content strategy, which is made up of substance, structure, workflow, and governance; our editorial resources, i.e., the editorial team’s ongoing time commitment; and our technical resources, made up of infrastructure (e.g., hardware) and our technical team’s time commitment. Using the complementary design processes of content modeling and task analysis, we’ll create a CMS selection & customization plan, that describes which tools to use, how we’ll customize them, and how we’ll maintain them over time. Let’s take each in turn.
The gold mine: content strategy deliverables#section10
First off, don’t panic: The content strategist is here to help. (No content strategist? Consider doing it yourself.) Jeffrey MacIntyre’s Content-tious Strategy is a practical overview of the various flavors of content strategist, and their respective deliverables; taken together, these documents are a gold mine for making smart CMS design decisions. Here are some highlights:
- An editorial strategy (“product development for content”) might include an editorial calendar, editorial workflows, and a style guide.
- A content analysis might include a content inventory, a gap analysis, a taxonomy, and a migration plan.
- Copywriting and IA-related gems include content templates (also called page tables), copy-decks, and annotated wireframes.
The three types of metadata#section11
We haven’t mentioned metadata—commonly defined as “data about data”—because the term itself is confusing. In fact, Deane Barker argues that the distinction between data and metadata isn’t helpful. But let’s consider Rachel Lovinger’s definition (PDF link), which defines three types:
- descriptive metadata is taxonomy: classification systems for content;
- administrative metadata specifies behind-the-scenes status of content, normally managed by the CMS itself; and,
- structural metadata defines the content model.
Instead of using the same word for three distinct concepts, we’ll talk about taxonomy, administrative data, and the content model.
Content modeling: types, elements, relationships, oh my!#section12
Based on the strategy, we’ll design a model to describe the website’s content: Types, elements, and relationships. You can think of a content model as a semantic structure for content, or a database schema; it’s part of the information architecture. (Don’t confuse it with the site map, which specifies top-down navigation.) Content modeling isn’t a straightforward, mechanical process; it requires human judgement and experience, and there’s no single correct solution.
Balancing semantics and granularity#section13
Content modeling is about striking a balance between semantics and granularity. We can encapsulate it as the answer to two questions:
- What does this content represent? (Semantics)
- How much detail should we go into? (Granularity)
To demonstrate, suppose we’re designing a content model for a company that runs conferences. First, we’ll consider which content types are needed. (These aren’t media types like video or text: Each content type represents a separate entity in our model.) It’s easy to brainstorm possible content types: Events, presentations, speakers, attendees. But how much detail do we need? Should we model multiple conference “tracks” and schedules, or are presentations and speakers enough?
At the same time we’ll consider which content types are related to each other, and how. For example, if we model tracks, each presentation is related to a track; without tracks, each presentation is related directly to an event. We’ll also consider whether relationships are one-to-many or many-to-many (the technical term is “cardinality”). Next we’ll consider elements: What makes up each content type? In our example, do we need a “URL” element for each speaker, or is the “Biography” element sufficient? Finally we’ll decide which content types need classification, and which taxonomy to use.
Derive the model from the strategy#section14
If this sounds a bit abstract, don’t worry. We won’t sit here all day debating the nature of the world; we have a content strategy to implement. Based on the deliverables outlined above, we might design this content model:
Fig. 2 Example content model for a conference website.
Each box represents a content type, and lists a few possible elements; the lines represent relationships between pieces of content. We’re modeling an event as a number of tracks, each featuring a number of presentations, each presented by one speaker. This semantic richness gives us the flexibility to present content in powerful ways. For example:
- From the speaker biography we could link to their presentations at past events.
- For each presentation we could automatically show what’s on before and after, and what’s happening simultaneously in other tracks.
- Search could return intelligent results, e.g., a speaker and the events they’re due to present at.
- There’s scope for a personalized conference schedule that attendees can use to plan their day.
Don’t design the perfect model#section15
Consider a conference you’ve attended; does this content model make sense for that conference? It probably doesn’t: What about events with a single track, or panels with several speakers? Or more significantly, what if the editorial strategy is based on publishing high quality videos of presentations? We’re not striving for the ultimate model; we need a pragmatic design that accommodates the real-world constraints of the content strategy. We won’t get it right first time: content models evolve, so we’ll allow for iteration and change over time.
Task analysis: what’s an editor to do?#section16
But a model isn’t enough; an editor needs to create, edit, publish, and care for the content that lives in it. In real life, the editor will be short of time. Using task analysis we can make our content model more realistic by considering feasibility. It’s a great way to identify assumptions about the CMS interface upfront, and it lets us inform the project team about the true cost of content and features—taking into account ongoing editorial and technical time.
Web editors are users too#section17
For web professionals, task analysis isn’t new. We’re always thinking from the user’s point of view, making tasks as straightforward as possible. But how often do we apply the same type of thinking to web editors? Here’s a four step guide:
- Brainstorm key tasks (based on the content model, editorial calendar, and content inventory).
- Sketch workflow diagrams for each task.
- Sketch wireframes of key interfaces.
- Estimate the editorial time required to complete each task.
An example task analysis#section18
Continuing with our conference example, how does our content model stand up to task analysis? It’s straightforward to list an editor’s key tasks: Publishing a news item, adding a speaker, adding a new presentation, etc. Here’s what the CMS task flow might look like for adding a new presentation, given our content model:
Fig. 3 Example task flow for a conference website CMS.
The diagram shows the five processes and two decision points involved in this task. A typical implementation might include five separate screens; we’ll estimate that an editor will take 10-20 minutes to complete it. We’ll also sketch simple wireframes for each process. (Would an Ajax-enabled design work better? We’ll need detailed sketches showing how the auto-complete or show/hide magic works.)
If we apply task analysis to the whole system, we can derive sensible estimates of the editorial time required to complete each task. We can then prioritize our scope based on the actual time available. It might turn out that parts of the content model are over-ambitious, while others need to be extended. This process helps us find a realistic balance between modeling and task flow based on strategic priorities rather than haphazard assumptions.
There’s another benefit: Identifying assumptions within the content model about the publishing process. For example, our task flow requires an editor to select a track before adding a presentation. Is that a valid assumption? What if we need to publish presentations before the tracks are finalized? And how will the front-end website present tracks anyway? Finding these assumptions before implementation saves time, money, and grief.
Decision time: CMS selection and customization plan#section19
At this point, we have a revised content model, and a task analysis that specifies how editors will interact with the CMS. We also know which tasks are most important, which will help us to prioritize backend interface design work. This puts us in a strong position to shortlist and select CMS tools, and to scope customization.
There’s no silver bullet for CMS selection. The key is to specify the problem as clearly as possible, and then to insist on realistic time estimates for customization and implementation. We’re ready to ask the following questions:
- Can this tool handle our content model? Natively, or will it need customization?
- How much customization will be required to implement this task flow? How long will that take, given our technical resources?
If you aren’t a technical expert, you’ll need to consult your technical team, vendors, or online communities. Although there are other important factors to consider when selecting a CMS (e.g., platforms, licensing, hosting), don’t let anyone use them as an excuse to avoid answering these basic questions. If the tool can do what we’ve outlined, and there’s enough time and money to customize it, great. If not, we either need to consider a different tool, or scale down our plans so they’re feasible. A CMS project needs technical resources after launch day too, so be sure to get estimates for ongoing design changes and maintenance.
The output of this process is a project plan. We know which tools we’re using, and we’ve scoped the work required to get them to fit our needs. Now, buy yourself a drink.
That final arrow: back to the drawing board#section20
We’re not quite finished, though: We can’t just pour in some content strategy, customize the CMS, and leave. CMS design is part of an ongoing, iterative process: Our selection and customization plan provides information about feasibility which will influence the content strategy itself. In practice, we’ll dream up ambitious plans which require unrealistic amounts of editorial and technical time to implement. So we’ll use the workflow diagram’s final arrow, go back to the drawing board, and scale down our plans to make them more realistic.
Regain control of your CMS#section21
Our websites have been held back for too long by lackluster publishing tools. In this article we’ve explored ways to apply strategic thinking to CMS selection and customization, through design. It’s time to regain control of our content management systems by harnessing the power of content strategy.
“Choosing a tool because the IT department says you have to” In larger businesses/corporates a CMS is always a compromise, often the requirements and spec were developed years ago and the system is not capable of keeping up with current trends. Changing a system in these circumstances can take years and costs are potentially astrononical. CMS teams end up spending most of thier time working out creative ways of providing what the business wants within the constraints of the system they have. (People who know me and where I work will know this!)
Seperating content from the presentation layer is vital as it means you should not have to rework you content if a new design is implemented – if its ina database all the better. However most sites are designed for the now rather than for the long term and layout frameworks are not considered. All to often the designer/agency (no fault of thiers) is not involved with long term running of the site and all the what if they want this and thats are not considered.
Also commisioning marketing departments(for example) often do not include the CMS teams in the design process at all. I have often been presented with a completed design and asked to retro fit it into our CMS which isn’t great.
The better CMS systems out there (I use ExpressionEngine for personal projects which is superb) are too new and considered not scaleable enough for large corporate use by reticent IT procurement teams.
In today’s economy, the promises of a new technology is not going to pass muster unless multiple stakeholders see the value in the decision. Gone are the days of software being chosen because the the IT department says you have to.
That said, I have seen technology solutions becoming the rallying point that has helped streamline disparate people and processes. I agree with your point that the process has to start well in advance of technology selection.
I think the momentum to separate content from the UX has shifted, the tricky and political part is to separate, reconfigure and distribute content at the the people layer and that can be completed through technology like a shiny and new CMS.
This article is very deep. I’m sitting here trying to get down to the nitty gritty for a lot of us designers that have relied on CMSs up to this point. It really boils down to two things:
1) Comfort of knowing a tool you’ve managed to get by with and that you’ve gotten decent at molding to different needs.
2) Fear of the unknown.
As someone who never truly committed to a programming language, it’s easy to let an off-the-shelf tool dictate a site’s architecture. We’ve dabbled in PHP, ColdFusion, Asp, etc. but never truly felt empowered to build stuff that wasn’t cookie-cutter. I’m not saying we lack professionalism or an appreciation of craft. A lot of us are accomplished in front-end coding and the nuances of good visual design but there’s that chasm: where we’re currently at in our career and the holy grail (custom solutions built around frameworks like Rails).
One look at your diagram of the database structure should leave no doubt in our minds that there’s more at work than meets the eye. That perhaps we’re doing our customers a disservice by abstracting the database layer to a CMS. Can we truly feel empowered if we don’t know what’s going on behind the scenes?
As a designer peering in and getting serious about development, it’s not easy; actually, it’s a little overwhelming sometimes and scary. That’s where I think the community could do a better job of helping move people like me forward. It’s about being able to communicate the message: *invest in your future*. Off-the-shelf isn’t going anywhere and I think a few CMSs do a nice job of adapting beyond simply title and body. But with a little effort and enthusiasm for learning, there’s a whole trove of people like me that can add value to our clients bottom lines and the web development community as a whole.
@theFreelanceDesigner, thanks for your insightful comment. I agree that implementing content management can be overwhelming and scary. I think that as a community we tend to distract ourselves from this issue, and from the complexities of content in general, which is why we’re so keen to talk about gimmicks, features, the latest whizz-bang product. Our clients are too, mind: installing the latest Web 3.0 widget is a lot easier than tackling the organization’s disaster area of existing content.
The mechanics of content management stop being scary when we start talking about the real issue: content strategy. I think the biggest challenge for people who make websites is to shift the conversation away from features and towards strategy: why are we doing this? Once a realistic strategy is in place, content modeling and task analysis aren’t so scary any more.
I’ve been trying to implement a CMS at my place of work for 5 years. Requirements have come and gone, but no one, not technical or editorial teams, understand the complexities of CMS. Everything you wrote eloquently describes what I’ve witnessed and what I’ve been trying to promote: focusing on business processes, and not relying on technology to be the silver bullet.
That being said, the CMS platforms that I have encountered handle semantics poorly and are difficult to use on one end, and develop on the other. I wonder how your recommendations can be effectively followed with the limitations present in today’s CMS platforms.
I’ve got to second the mention of “ExpressionEngine”:http://www.expressionengine.com/ – it’s customizable content management abilities are second to none. “The graphic”:http://www.alistapart.com/d/strategic-content-management/content-model.png in the article about a conference website’s content model can be perfectly re-created in EE without the slightest difficulty, relationships and all.
I am a website owner and have started to get more into SEO and content management and such. I have to say I never realized how much work this takes and to do it effectively is a whole other ballgame. Trying to keep up with this stuff.
While your article rings true, I can’t help but think that this is what Knowledge Management, Personal Knowledge Management, Information science and Health Informatics has been researching for decades. There are so many useful papers and best practices already out there in the ACM archives and in Trec archives. What I see happening here and in other areas of the web is that now that web development/design are facing the issues, they believe the issues are new and no one has dealt with them until now. While not all of the issues have simple solutions ( or any solutions sometimes), I think business could learn a lot from the areas of research I mentioned above. Instead of redefining the same problem we should work together in much the same way Academics are discovering that problems need an inter-disciplinary approach. I’ve seen too many web developers ignore computer science because it doesn’t teach today’s best practices, but then not learn how to program or never learn how data structures can ease their problem solving needs. The same mistakes are being made in this articles domain.
Thank you for articulating such a straight forward approach to selecting a CMS. I’m going to add your article to my suggested reading list for anyone interested in providing true content management capabilities to their organization.
This was a good read and hit all of the tenets squarely on the head. At the end of the day it’s about business process and using tools that allow you to aide in smoothing that process. Far too often clients and businesses are confounded that technology hasn’t solved their problem. Usually with a “What is everyone else doing?” question. Without asking the question if it’s right for their own business.
Thank you for this piece, more and more people are joining the daunted hunt for the right CMS daily.
@gsal: While I have to agree that technology can be no “silver bullet”, there are certain companies which have recently rolled out the red carpet for content management systems that have cutting-edge curation analytics capabilities. I am a tech comm and my company just adopted MindTouch 2010 and it’s already given us helpful feedback on our online documentation. MindTouch offers a free trial system so you can walk away with no strings attached if you believe that your content issues aren’t “technology-deep”. But MindTouch might just give you the feedback you need on really whatever content issues you’ve been harboring. Here’s the article on Mindtouch 2010’s curation analytics that won us over: http://www.cmswire.com/cms/enterprise-20/mindtouch-2010-includes-curation-analytics-for-content-and-documentation-008045.php
Liz
This was a great article and I think most of us agree with all of your points. The ultimate challenge is getting the *stakeholders* to invest both time and money into content strategy rather than just signing on the dotted line for a tool.
I have learned that you really have to be blunt in explaining the important of developing content first. I have actually told a friend of mine, “your site sucks because your content sucks” and he quickly understood. That’s more difficult to tell a client who is paying thousands of dollars for your services.
A very good article!
It’s nice to see some more focus on content modeling, and the value of creating a semantic structure for the content in a CMS. As a vendor, we’ve had semantic content and content modeling technologies as one of our most important areas of R&D for several years now(http://www.webnodes.com/ontology-engine), as we see it as one of the most important factors in creating good websites, both for visitors and editors.
However, I do not agree with the presumption that:
“Any web project more complex than a blog requires custom CMS design work.”
Of course, we might have different interpretations about what constitutes custom CMS design work. What do you define as “custom CMS design work”? Could you give an example? To me customizations are changes to the CMS that are outside the scope of the intended built-in flexibility of a CMS.
Such customizations should only be done as a *last resort* IMO. Most likely, you have selected the wrong CMS, if it isn’t possible to solve your problems within the built-in flexibility.
I’ve seen so many customizations over the years done to different content management systems and other IT systems that have turned out to be extremly costly over the lifetime of the solution. This has mainly been due to upgrade problems, and a limited number of people that knows how the customizations are set up.
Thanks for the kind words, guys!
@blainsmith:
bq. The ultimate challenge is getting the stakeholders to invest both time and money into content strategy rather than just signing on the dotted line for a tool.
Exactly!
@vidar_webnodes:
bq. What do you define as “custom CMS design work”? Could
you give an example? To me customizations are changes to the CMS that are outside the scope of the intended built-in flexibility of a CMS.
I go into a bit more depth later on, starting with, “A product can’t fix content problems out of the box.” Whether or not customizations are within the scope intended by a software vendor, web teams need to spend time customizing tools to their needs. Software vendors tend to talk about “solutions”, which is presumptuous: solutions to which problem?
The “intended built-in flexibility” of proprietary tools is beyond the scope of this article. If you approach a software vendor/tech team/open source community with a clear idea of your content model and task flows, they should be able to estimate how much time and money is required to customize the tools for the project’s needs.
bq. If you approach a software vendor/tech team/open source community with a clear idea of your content model and task flows, they should be able to estimate how much time and money is required to customize the tools for the project’s needs.
Sure, they should be able to estimate how much time it would take to customize the tools for the project’s needs, but there are several potential pitfalls. Yes, you can hack most CMS tools to support a given data model, but there’s a *BIG* difference between supporting a data model within the “intended built-in flexibility” of the data model, and hacking together support in a system never intended for such a data model.
How much will it cost to upgrade when the next version arrives? How well will it work? How polished will the customization be compared to the built-in functionality? How well will it scale with lots of traffic?
Thought provoking article, but the choices we really have are way more limited than you’d suggest.
Most web development firms are working with just three of four different platforms, representing different bands of the cheap ‘n’ simple, to enterprise-level spectrum. The choice will always be between your favourite 3 (or so) CMS because:
1) You can’t be really good at more than 3 or 4 systems if you’re undertaking lots of custom implementations
2) Supporting too many platforms as a supplier introduces risk and sustainability: how do you retain the knowledge of a system if you have any staff turnover?
3) If you choose a platform on project fit alone, and it isn’t something you know well, you won’t be building something that meets all the best practices for that tool – these essential nuances to a build are developed over time
When choosing a CMS the real question is, which of my (3 or 4) favourite systems is a good fit. And failing that, should I build the required features in a custom application?
As the article points out content modelling is essential in understanding this.
Buts let’s keep it real, there are never 1000s of options on the table, but a maximum of 5. Maybe a few more if you include low cost, hosted solutions like Ning, Shopify etc.
I heard a talk about Expression Engine not too long ago and it seemed to be highly versatile. I’ve been using WordPress since its conception many years back and have watched it grow from a little blog tool to one of the most powerful free CMS’ out there.
I am doing an hour long talk about history of WordPress and where 3.0 is at today, MU, Buddypress, etc. I feel with the hundreds of thousands of plugins and themes already available it is hard to promote anything else.
Thanks for a great article and discussion piece! It’s refreshing to see this perspective clearly articulated. I work for a custom web dev and design shop who, for the last 12 years, have focused on always building custom solutions for our clients. It’s worked well because, before anything, we work with our clients to determine their needs and present our plan for a solution before we even lay down any code. No crowbars to hack up other, pre-fab CMS’s but instead a unique product created just for them.
Anyone can buy a frozen dinner and try to doctor it up with some salt and pepper but wouldn’t you rather have a chef cook to your own tastes?
Thank you for sharing your thoughts about this topic. Making us remember what really a CMS is.
@marksteven:
bq. When choosing a CMS the real question is, which of my (3 or 4) favourite systems is a good fit. And failing that, should I build the required features in a custom application?
I think your logic is backwards. Of course I’m not suggesting we should survey all of the thousands of tools out there—that would be impossible. But focusing on “building something that meets all the best practices for that tool” sounds to me like a classic distraction from the content strategy question. It’s an excuse to stick with tools you know rather than involving yourself in a strategic process. The tool isn’t the thing: the content is.
The focus on content in your article is much appreciated, as well as your basic outline of content modelling (I was trained as an information analyst and produced many diagrams and flowcharts). However, on the web things change much much faster than in most administrative worlds so you cannot rely on your initial analysis to last for more than maybe a year. Your carefully selected CMS should stick five years. Therefore I don’t think a content model should be translated into code or a database tables. Ideally webmasters/editors should be able to change not only the descriptive and administrative metadata but also the structure of the content and even workflow – within the CMS. Systems do exist that have those capabilities, e.g. Drupal. And yes, that is a feature 😉
I’m the “Chicago Humanities Festival’s”:http://www.chicagohumanities.org webmaster. Last year, we rolled out our new site that is similar to the hypothetical site described in this article, with the addition of serving as a multimedia archive. We didn’t develop the site in-house, and my role during the development was, in part, client liaison to the development team. My background is in web design and development, so I enjoyed the unique experience of sitting on the fence between client and firm, with my legs dangling over the client side.
Our development partner had a good internal understanding of a lot of the concepts discussed in this article. One part of the trip that was pretty rocky, however, was in the evolution of the content model beyond the initial model. The article suggests “Don’t Design the Perfect Model,” positing instead that content models _will evolve_, and iteration should _be allowed for_.
While I agree that striving for perfection in the initial model is futile, my experience in overseeing the development of our site suggests that an explanation of how content models evolve — and how this evolution is managed — is warranted.
Left on their own, content models will evolve (or devolve) independently on both sides of the client/firm fence. The client’s model tends to expand, bounded only by imagination. The firm’s model tend to become more concrete, or even whittled down, as the development team uncovers challenges and butts into the (perhaps hitherto undiscovered) limitations of the given CMS. Sometimes the client’s imagining results in a possible enhancement, which then has the potential to become a change order, which is great for the firm. However, there is also the possibility that the client’s imagination and exploration will uncover a flaw in the initial content model, or that an unforeseen limitation in the CMS breaks the model.
How can this be avoided? What kind of communication and management strategies need to be in place to effectively manage model evolution? How can a firm establish scope of work and yet leave the content model open to iteration?
Lots of great comments here agreeing that content modeling is important, and several pointing out that ACME product can handle any content model you throw at it. There’s less talk about the task analysis piece, which is telling: it’s the messy, politically challenging piece which technology people have generally managed to ignore up until now.
So I’ll say it again: it doesn’t matter how smart your content model is, and how well your chosen tool is able to model it—if the organization’s editorial staff can’t perform their key tasks in the time they have available, the project will fail. If you haven’t done task analysis, and run it past the actual editors who’ll use the system, the content strategy will be hampered and the project won’t achieve its goals.
@dulybookmarked:
bq. an explanation of how content models evolve — and how this evolution is managed — is warranted. … How can this be avoided? What kind of communication and management strategies need to be in place to effectively manage model evolution? How can a firm establish scope of work and yet leave the content model open to iteration?
Fantastic questions, which I didn’t have space to address in the article. Not that I have all the answers!
This would be a great topic for an article. Why don’t you write it? 😉
There are a lot of good points in here most of which I have experienced first hand. I do not understand where clients get the idea that WordPress is an enterprise level solution for their gigantic website. Even for smaller sites I still prefer to use Drupal or Expression Engine.
I think many developers make the mistake of expecting a client to understand whatever platform they choose for their client. I’ve had many clients come to me and asked me to switch them to a better platform that was easier for them to manage their content.
I really enjoyed that. Very interesting article, which has got me thinking – what is the most important aspect of a Content Management System? Well, to me personally, it is to be ease of use. I couldn’t bare to use a CMS which has a bucket load of features yet isn’t easy to navigate and post from. That would drive me crazy. A CMS has to be easy to use or the whole concept becomes pointless in my opinion.
i know quite a lot about this stuff as I myself is a developer but reading such great posts always helps one to in improving his/her skills. It has helped clearing few doubts i had about using CMS, from my mind.
Indeed helpful!
This was a very interesting read, but I think the design side needs more focus. Design by itself is a much broader entity than art direction—it includes art direction. Art direction is a form of design. I think you need to focus your definition of design before the distinction between the two becomes useful
I can’t help but draw a wider circle, and see mishandled approaches to CMS integration as part of a global phenomenon where IT makes the call and manages the solution. Probably what’s fundamentally changed in business practices over the last 20-30 years is the way technology (be it the workstation on the desktop of the corporate intra- or internet website) has given stationery suppliers, actuaries and filing clerks a one-way ticket to redundancy. All three (I’m sure someone can add to the list) once had a secondary role, a lot further down the chain of command. IT and its mystic, inaccessible ways came along and required specialists to install and run it. Unfortunately, at some point they managed to convince management that they also were the only people technically competent enough to make decisions, and took on a management and deciding role that no procurement, statistical or storage division within a company would ever have been given. Maybe it’s time MBAs came with a compulsory unit of study on “understanding technology and keeping it in its place”…?
Our clients often have more questions than answers about selecting their Web Content Management Software. Many see Drupal, or WordPress as a simple solution because of the ever increasing visibility. Thank you for taking an approach that does not start with a solution and work backwards such as touting why one CMS is better than another!
Our clients often have more questions than answers about selecting their “Web Content Management Software”:http://www.duoconsulting.com/ Many see Drupal, or WordPress as a simple solution because of the ever increasing visibility. Thank you for taking an approach that does not start with a solution and work backwards such as touting why one CMS is better than another!
Thank you dor this article which is very deep. The quality of contentis very important but sometimes it’s hard de write. I often spin my content with online tools. I save lot of time.