Deane Barker (@gadgetopia) is a CMS expert. He's been working in web content management for as long as we've had browsers. How is Web CMS different today from two decades ago? What does a future CMS look like? Read our Q&A below.

How are CMS systems different and similar today compared to two decades ago?

Two big changes come to mind, years apart.

The move from decoupled to coupled was a big deal 10-15 years back. The original batch of CMSs were basically static site generators. You managed content, then published it by generating a bunch of static assets which were placed in your delivery environment. The CMS itself only managed the content -- it didn't actually deliver it. Once you published, the CMS was out of the equation.

Then, once we moved to coupled CMS, we gradually moved from management to marketing as the primary function. In some senses, we solved most management problems and the key issue became how to optimize content during delivery. Personalization became a big deal, along with integration into various marketing suites. Today, you have some systems that are the barest amount of management functionality basically wrapped around analytics and optimization tools.

Weirdly, the first change -- decoupled CMS -- is making a huge comeback, partly because the second change -- marketing and optimization tools -- are starting to integrate at the client/browser level. The industry moves in circles, it seems.

You have a new book out. Describe your emotions the day it was published?

When I started writing it, a friend said "Congratulations! You're pregnant." So, in some sense, it was like giving birth, but without the acute physical pain. Do not tell my wife I said that.

What's funny about writing a book is the stuff you leave out. There's so, so much more that I wanted to include, but I was pushing 400 pages and I had to get the thing out the door. I kept telling myself, "This is what the Second Edition is for."

If you're interested in a much deeper dive of how the book got written, I did a podcast a few months ago specifically about the writing process: Write Now Podcast, Episode 8.

Tell us more about the book?

Note: for more information on the book, visit: http://flyingsquirrelbook.com/

It's a broad look at the principles of content management systems and their implementations.It's not a programming manual (it's not CMS-specific, so what CMS would I talk about programming for?).

I discuss what content management is, the major features that a modern CMS includes, some of the history about how we've managed content over the years, and how implementations work, from migrations to working with third party integrators.

If you're looking for a manual on how to implement something like Evoq, this isn't it. But if you're not sure you totally understand web content management and want to take a step back and get the big picture, then this is your book.

Tell us about Blend Interactive?

We're a CMS integrator. We're the company that takes your plans and wraps them in an actual CMS that does what you need it to do.

We work with 7-8 different platforms, so we have broad experience across the industry. It's worth mentioning that we did a nice Evoq implementation for the National Music Museum down at the University of South Dakota (note: see the museum's homepage, above).

What we are not is a marketing or digital strategy firm. We might be an outlier in this respect, but we implement CMS to make your digital strategy work, we don't come up with the strategy itself. In fact, about 50% of our work is for external agencies with projects that need more CMS expertise than they have in-house.

Some people don't realize you can split those disciplines -- one company can come up with the strategy, and another can implement it. We call it BYOA -- "Bring Your Own Agency."

In terms of verticals, we tend to do a lot of work in what we call the "institutional" market: higher education, government, religious, non-profit. We solve big, messy content problems for these organizations. Large sites, with tens or even hundreds of thousands of pages of content.

What questions should IT Managers ask when selecting a Web CMS?

The most pedestrian question is what your technical environment looks like. Are you going to host it yourself? If so, what server environment to you have available? Are you going to implement it yourself? If so, what languages does your development group work with?

These questions seem impure to some people. In a perfect world, of course, we would evaluate purely on functionality and need, but the fact is, CMSs have to be hosted and implemented, and restrictions around these can be very rigid.

Know what these restrictions are before you start looking. You don't want to fall in love with a CMS only to find out that you can can't host it, can't implement it, or both.

Assuming you have no such restrictions, then you need to ask yourself what you want from a CMS. Just management, or do you want a lot of marketing and optimization functionality? If the latter, do you want that from your CMS, or are you going to get that from other vendors and technologies, and just integrate them into your CMS?

Answer those two questions and you can narrow the field considerably.

If I’m a CMS author using a new CMS, what should I do before jumping right in?

I've long-maintained that CMS training and expertise exists on two levels:

Implementation-specific: how do you do the things you need to do for your specific implementation for your specific organization?

System-specific: how does the CMS work at the defaults, beyond what you're using in your implementation? What is its scope and overall architecture?

In my experience, learn a little bit about the grand architecture and principles (#2) just so you have a big picture, then dig into the specifics of your implementation and work process (#1).

Circle back to the big picture (#2 again) as you get comfortable and continually try to expand that scope of knowledge over time.

Knowing the big picture lets you understand how things work beyond the boundaries of what you're specifically doing at any given moment, and this gives you opportunities to improve your processes and implementation down the road.

You can step back and say, "We're doing X now, but I know the system is capable of Y and Z, which would probably be a better fit as our needs change."

Who’s making the buying decision on a CMS: IT or Marketing?

This has shifted in the last 10 years from IT to Marketing. We see far more decisions originating in Marketing now.

Not only that, but they're moving hosting and implementation to outside vendors, so that IT isn't involved at all anymore. Marketing is basically making end runs around IT to avoid dealing with restrictions.

And, in many cases, this goes both ways. We've seen IT departments gladly wash their hands of the public website with an attitude of "good riddance," as they have their hands full just managing infrastructure and line-of-business applications.

When issuing an RFP for a CMS implementation, what is the biggest mistake you see made?

Organizations think that their RFP is a requirements document. Too often, I see RFPs which are basically just a long list of features that an organization would like to see in a Web CMS.

This document invariably asks, "How much to implement this?" and my response is usually "...implement what?" It's like showing a contractor your Pinterest account and saying, "How much to build this house?"

Fact is, I've seen virtually no RFP that had enough information to actually build a website. Every project has to start out with discovery, and organizations should issue an RFP for that project first, then take all the resulting discovery documents -- wireframes, functional specs, etc. -- and bundle those into a second RFP for implementation.

If you force an integrator to give you a firm number on an RFP that never has enough information, they'll do one of two things:

1. Bid low with some contractual escape clause that lets them re-scope later when they really understand what you want, or
2. Pad the bid sky-high to cover all the things you have in your head but never told them.

Discovery and requirements development is its own project. Treat it like one.

How do CMS vendor selections differ when implementing a public website vs. an intranet?

Lots of things.

Intranets don't have a marketing component, so systems which offer large amounts of content optimization and anonymous personalization tools are probably wasted.

Public websites are often more tilted towards dynamic and artistic page composition -- drag Widget X here, and position Widget Y there -- where intranets are more about pure communication.

Most of the content on an intranet is heavily templated.

Intranets are more two-way than public websites. Most public websites are anonymous, while intranets will usually always know the identity of the user. The user, in turn, might be expected to contribute content to an intranet, so it blurs the line between the editor and the content consumer.

Finally, in terms of implementations, intranets can count on an "indoctrinated user." Public websites have to assume ignorance -- every visit is potentially the first visit. Intranets can assume the visitor has been there before, that they probably visit every day, and that they might even have had some formal training on how to use the website.

While intranets are often perceived as boring, the user base's general familiarity with them often allows intranets to do more creative and interesting things.

Where are CMS vendors missing the mark?

I think the emphasis on marketing is causing some vendors to fail at the basics. In the book, I'm very explicit and consistent on what I call "the four pillars of content management":

1. Content Modeling
2. Content Aggregation
3. Editorial Workflow
4. Publication Management

Those basics can get ignored because a vendor wants to integrate with the latest marketing trend, or hop on whatever bus has caught the attention of the user base.

Although it's tough to blame vendors, really. Some prospects base their buying decisions on whimsical, pipe-dream factors that have very little actual value to them. Vendors just respond to the market.

...and there's your first dose of cynicism for the day.

What does the future hold for Web CMS?

I think (hope?) the future is distributed. I think we're moving away from the monolithic CMS that purports to do everything, but doesn't do much of anything well.

The ideal CMS of the future is one that admits that not all the content it delivers will originate from within it, and that other vendors provide functionality (especially marketing functionality) that should be integrated.

This CMS will be a "big tent." It will unselfishly embrace content and functionality from other sources and work to manage it all under an umbrella of larger foundational services, like search, workflow, user management, etc.

That's where I'd like to see the industry go, anyway. But CMS vendors have never been keen on voluntarily giving up market segments, so it might be a stretch for them to admit that other companies do some things better than they do.

...and there's your second dose of cynicism for the day.

WEBSITE REDESIGN:

How Texas Hospital Association Redesigned Their Site on a New CMS