Drupal needs to better accommodate end-users and content teams
It’s a well-known fact in the 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 constantly putting out how easy WordPress is to use.
You might be surprised to hear it, but Drupal is just as easy—good developers can even make you a site that’s easier to use than a cookie-cutter WordPress blog site. But who’s talking about that? After looking around the internet for several years at this point, I can readily tell you that if anyone is talking about it—well, they’re not being heard. So if you’re reading this with that same idea, just know that there’s at least the two of us.
Drupal doesn’t come off as simple to use because a typical Drupal build needs some kind of impetus to use Drupal instead of another CMS—it’s so easy to use WordPress instead. API integrations, or custom code work that just happens to be better-defined in Drupal than in other CMSs. Maybe even security. Recently, W3C (super important, I promise) decided against using WordPress for their redesign due to accessibility issues with Gutenberg.
In the end though, most content editors, writers, or managers don’t really have a say as to what CMS their company chooses—freelancers especially 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?
Well, there are a lot of other considerations to make about how time and resources are spent in Drupal. 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?
I would be very, very surprised to hear of a large company giving 6 months’ worth of time for 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.
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 site. It was difficult, it was confusing to both sides, and it put a strain on the contract. Deadlines were missed.
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 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 in 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 2022, and generally liking most of the Drupal 8 and 9 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 Drupal websites 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 you all the tools necessary for you to not only competently use Drupal (in whatever form it may be), but also for you to excel and 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 Drupal 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, you run the show, you keep the lights on, and you’re the one grinding web content day-in and day-out. If we can’t empower you, then what’s the point? Your 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.