Preface

Back in 1995 or so, I wrote my first HTML document.

I wrote it in Notepad on my 90 MHz Pentium tower from Gateway 2000. I still remember adding a TITLE tag, refreshing the page in Internet Explorer, and watching with awe as my document title filled the title bar of the browser window (the idea of tabbed browsers was still years in the future, so the document’s TITLE tag became the title of the entire window).

That first web page quickly grew into an entire website (the subject and point of which I honestly can’t remember – I suspect it was just a list of links to other sites). Mainstream adoption of CSS and JavaScript was still a few years off, so I didn’t have scripts or stylesheets, but I had a handful of HTML files and a bunch of images (you were nobody if you didn’t have a tiled, textured background on your page of links).

Quickly, I ran smack into the first problem of webmasters everywhere: how do I keep track of all this stuff? I don’t even think the word “content” had been popularly applied yet – it was all just “stuff.”

As websites inevitably grew, so did all the stuff. Since we were largely bound to the filesystem, we had copies of everything on our local computers that we would FTP to our servers. Huge problems resulted if you had more than one editor. With two people trying to manage files, they would inevitably get out of sync and changes would be unintentionally overwritten. Occasionally, you had to sync against the server by downloading everything and overwriting your local copy, just to make sure you had the latest version of the entire site.

The process of managing a website was enormously tedious. Linking from one page to another assumed the two pages would always exist. Broken links were common, and if you decided to reorganize the structure of your site or rename pages, you had to hunt through all your files to find where the previous name might have been used.

The most valuable thing in my toolkit might have been the global search and replace utility that let me look for – and correct – links in hundreds of files at once.

This was the story of being a webmaster in the mid-'90s, before content management arrived. It was a tedious experience of manually managing hundreds of files, making sure you had multiple backups of everything, and trying to cobble together a toolset that gave you some modicum of control.

Fast-forward almost 20 years, and web technologies have evolved to remove most of the tedium. Today’s web manager largely works with abstract notions of content rather than actual files, without needing to understand the underlying technology, file system, or programming languages.

But even abstracting content from technology has still left us with eternal problems to solve: How do we structure or “model” our content? How do we allow for its organization? How do we search it? How do we work together on content without causing conflicts?

In short, how do we manage content?

Who Is This Book For?

This book is an attempt to approach web content management from the outside, without pushing any particular technology or methodology. It is designed for readers who want to understand the larger context in which a specific content management system (CMS) might work, or understand the underlying content management problems that any particular system will need to solve.

These readers might be:

• Project managers tasked with managing the implementation of a new CMS
• Experienced developers who might be new to content management in particular
• Web managers embarking on an evaluation project to acquire a new CMS
• Content producers transitioning from offline content to web content management
• Existing CMS developers wanting to step outside their chosen platform and look at their discipline from a new perspective
• Designers or content strategists wanting to understand more about the technological context of their work
• Anyone trying to understand and justify a new CMS-related project

What Is Not in This Book?

This book is not a technical programming manual. There are some code samples scattered throughout, but many are in a fictitious templating language, and all are meant to be purely illustrative, not practical.

Additionally, this book is intended to be language- and platform-agnostic. I will discuss many different systems, technologies, and platforms. I neither explicitly endorse nor condemn any of them. I have made an attempt to draw examples and screen captures from a wide variety of systems.

How Is This Book Organized?

The book’s chapters are grouped into three parts:

• Part 1: This part will lay the groundwork for the larger discussion of content management. We’ll talk about what content is, paradigms with which to compare different systems, the roles that make up a CMS team, and how your organization might acquire a CMS.

• Part 2: This part will analyze the major functional areas of modern CMSs – how they model content, aggregate content, coordinate workflow, manage assets, etc.

• Part 3: This final part will discuss the scope and structure of a CMS implementation project, and the best practices and process of running one successfully (or even just surviving one). Additionally, we’ll talk about the oft-overlook practice of migrating web content, and how you might work with an external CMS integrator, if you need one.

A Note on Generalities

A large portion of this book is about content management systems, but not any particular system. This means I’ll be trying to discuss every variety of content management system at the same time, which is a semantically challenging task.

One of the challenges of writing this book has been coming up with different phrasing to subdivide the entire domain of CMSs into groups. In the following pages, you’ll see countless phrases such as “most systems,” “some systems,” and “almost all systems,” as well as a lot of qualifiers such as “rare,” “uncommon,” “often,” “sometimes,” and “usually.”

Clearly, none of these phrases are quantifiable; they’re simply the best of a variety of suboptimal ways to handle generalities. Different phrases will mean different things to different people. If you disagree with a qualifier, then you have my apologies in advance.

A Note on Nomenclature

As we’ll discuss in the very first chapter, “content” can mean many different things, from HTML files to images to Word documents.

I will use the terms “content” and “CMS” loosely for convenience. However, understand that this is a book about web content management specifically, so I’m specifically talking about “web content” and “WCM” and “WCMSs.”

In dropping the “web” and “W” qualifiers, I am not staking claim to content as purely a web asset or problem. Rather, I am merely bowing to convention and brevity.

A Note on Sidebars

Throughout the book, you will find a dozen sidebars from other professionals working in the CMS industry. I am grateful to these friends and colleagues for taking the time to share their experiences here.

For each sidebar, a draft copy of the chapter was provided, and the author was asked to express an opinion about something in it. They were free to disagree, call out something that was missed, or put a different angle on anything they read. No attempt was made to edit their opinions.

As I say many, many times in the following chapters, content management is as much art as science, and there are no doubt countless people who will disagree with one or more things I’ve written here. I’m grateful that my guest authors were willing to provide glimpses into how different experiences often lead to different conclusions.

A Note on Bias

As a consultant who has worked in this field for almost two decades, I assure you that I have many preferences. However, I also understand that even a system I loathe still has fans. My preferences will no doubt show through, but I’ve done my best to be objective and provide adequate reasoning behind my conclusions.

I also understand that – like any consultant – my experience is likely biased toward one type of project or problem in ways that I might not even notice. Just like you can’t walk a mile in another person’s shoes, I can’t completely relate to problems that I have never been tasked with solving. Systems I find enormously lacking for projects I have worked on might be entirely appropriate for the problem in front of you.

Finally, my experience with particular systems, paradigms, and methodologies has made it easier for me to draw examples and screen captures from those systems. For this, I apologize, but there are many negative practicalities involved with bootstrapping a system with which I’m unfamiliar to obtain an image or example. I thank those in the industry whom I bothered to share their experiences with some systems I felt were important to discuss, but to which I had had no exposure or access.

Technology professionals, software developers, web designers, and business and creative professionals use Safari Books Online as their primary resource for research, problem solving, learning, and certification training.

Acknowledgments

Foremost, I’d like to thank this industry. Stepping back from this book as it came to a conclusion, I realized that nothing I wrote here is particularly original. What I’m doing is simply curating, collating, remixing, and elaborating on concepts and ideas put into practice every day by thousands of people around the world.

I’ve learned that, at the most basic level, this is what a writer does: we process information. Unless we’re reporting on original research or writing a wholly original work of fiction, we simply consume information from other sources, collect it, filter it, analyze it, reorganize it, explain it, then distribute it. Considered from that perspective, this process is not unlike the content management process itself, which we’ll spend the next 300 pages discussing.

However, some more specific acknowledgments are clearly necessary.

Thanks to my wife Annie, my children Alec, Gabrielle, and Isabella, and my goddaughter Brookelynne, for putting up with me while I was writing the initial draft, and especially after I swore it was “done”…but then kept writing anyway.

Thanks to my business partners, Joe Kepley, Karla Santi, and Dennis Breske, for giving me the time to write this.

Thanks to the unparalleled employees at Blend Interactive for helping build a business that gives me the opportunity to spend my days thinking about content management. I hope this book represents at least a vague shadow of the breadth of experience and knowledge that exists in the Blend office.

Thanks to my editor, Ally MacDonald, for taking a chance on some random guy who filled out O’Reilly’s online submission form.

Thanks to the speaker crew from the Now What 2014 conference who sat around a table in Crawford’s Bar and Grill in Sioux Falls, South Dakota, and talked me into writing this book in the first place: Karen McGrane, Kristina Halvorson, Jeff Eaton, Jarrod Gingras, Jeff Sauer, Corey Vilhauer, and Jeff Cram.

Thanks to my technical editors, Arild Henrichsen, Lynsey Struthers, Seth Gottlieb, and Corey Vilhauer. Any one of them could have ended this by simply telling me the book was no good. The fact that they didn’t was the first hurdle I had to clear.

Thanks to my assistant Kerrie Vilhauer, who did the first copyedit on every chapter and spent far too much time changing “that” to “which” and crossing out my promiscuous hyphenation. Her giddy determination at clarifying obscure rules of the English language was both appreciated and occasionally frightening.

Thanks to Tony Byrne, a close friend and mentor for many years who has helped me enormously by repeatedly putting this business and practice into context, and who did me the honor of writing the foreword.

Finally, thanks to Bob Boiko for writing The Content Management Bible. I finally finished it while on a plane that had been diverted to Kansas City back in 2006 or so. I still clearly remember closing the 1,122-page behemoth and flopping back in my seat to take it all in.