Welcome to the Web Content Hub!
The CMS Writer's Guide is an introduction to Technical Content Management
Technical Content Management (TCM) is the holistic approach to content management at the enterprise-level of CMS website development. TCM covers it all, whether it's writing the content, fixing the page itself, changing menus, or interacting with the CMS developers.
It’s a well-known fact in the Content Management System (CMS) world that WordPress does a better job of wooing users by their focus on ease-of-use and their armies of entrepreneurs, bloggers, YouTube channels, and podcasts that are all constantly putting out how easy WordPress is to use.
You might be surprised to hear it, but Drupal, Concrete5, or Moodle can be just as easy—I can even make you a site that’s easier to use than a cookie-cutter WordPress blog site in the same amount of time and it will be more extensible more quickly. But who’s talking about making life easier for content teams? After looking around the internet for several years, I can tell you that no one is talking about it—if they are, well, then they’re not being heard.
Drupal doesn’t come off as simple to use because your typical Drupal build needs some kind of impetus to use Drupal instead of another CMS. API integrations, security, or custom code work that just happens to be better-defined in Drupal than in other CMSs. It’s usually something to do with security.
In the end though—most content editors, writers, or managers don’t really have a say as to what CMS their company chooses—freelancers definitely don’t have a say in it. And yet these users (all of you) are the reason developers build the sites in the first place. It seems odd that the primary use-case would be so low on the list of priorities, doesn’t it?
There are a lot of other considerations to make about how time and resources are spent when ordering a new CMS. New features, functionality, integrations, updates, security, etc. Actually writing and displaying the content kind of just goes without saying as far as what the site needs to do.
Or, in another sense, how does the content of the site stack up when the powers that be start writing RFPs for a new site? The developers are well-paid, get plenty of time, and are usually granted extensions as the project wears on and other things are found to be needed.
How many of those contracts, proposals, and plans give the content team sufficient time to write, test, and give feedback on the site? How often is content the reason for deadlines being missed? If you’re running a content strategy company—would you need 3 or 6 months to go over legacy content and decide what the best way to categorize and display it in a new system would be? Why wouldn’t you get that if you’re being tasked as an employee to do the same thing for your company? Isn’t the end result just as important?
I would be very, very surprised to hear of a large company giving 6 months’ worth of time to going over and organizing web content before a migration to a new system happens. If you’re in that position, how is it? It sounds like it’d save lots of time in the long run. I’ve always wondered.
As for the reason that I’m writing this guide—I graduated Utah State University with a degree in English with an emphasis on Professional and Technical Writing. I focused on web content and was able to get a job with a Drupal development agency where I manually migrated several thousand pages from their legacy system to their new Drupal (7) site. It was difficult, it was confusing to both sides, and it put a strain on contracts.
After that gig was up, I ran the websites for a local municipal government where we also migrated from a legacy system (several, in fact) into a Drupal (also 7) site. This time I had more than 80 Content Managers (writers and editors) to train and get up to speed before we went live along with the migration of the legacy content. At one point, I was in the elevator heading back to my office after working with someone from the content team and the other person in the elevator looked at me and asked if I needed to head home and get some sleep. I looked awful, I felt pretty awful, but I’ve never been more proud of that work. Every second I spent training and helping those content managers was an investment in the overall outcome of the project.
At that point I headed off into the world of Drupal development where I’ve been ever since. Now, faced with the EOL for Drupal 7 in December of 2021, and generally liking most of the CMS websites I’ve worked on, I’ve decided it’s time to put the focus where it should be. On the people who use the Content Management Systems every day—not as a visitor or a developer, or even management—but as a writer, editor, or freelancer.
My aim here is to give writers all the tools necessary for them to not only competently use any CMS (in whatever form it may be), but also for them to excel and (maybe) even enjoy doing so.
If you’ve been pulling your hair out and losing sleep—or if you’ve heard that you’ll be using this CMS or that CMS next and you want to get ahead of the curve—this is the guide for you. If you’re not 100% happy with the information I share here, or even if it doesn’t get you to where you want to be, email me at owen@webcontenthub.com and if I don’t know or can’t find the answers for you, I’ll find someone who can.
Ultimately, content teams run the show, they keep the lights on, and they’re the ones grinding web content day-in and day-out. If the system can’t empower the team, then what’s the point? Their success is paramount and ought to be right at the top of mind when a large, complicated Drupal website is put together.
No one visits an empty website, no matter how well-designed it might be.
-Owen Morrill
Technical Content Management
Pre-order "The CMS Writer's Guide" now!
Schedule a one-on-one chat with Owen to discuss the business goals for your web content.