The harsh realities of managing content on a Drupal website

Author picture
Emily Turner
Posted by
Emily Turner
Date:

Guest blogger Emily Turner, content and marketing strategist, explores the issues of Drupal UX from a non-tech perspective. 

I read with interest Five Mile’s “Elephant in the Room” blog and call for a debate around Drupal and UX for a range of audiences, including site authors. I am definitely ready to put out the bunting and get on board this party train. As a content manager and strategist who has worked across a variety of Drupal sites, this conversation is a long-time coming.

Who are the real Drupal rockstars?

I love using Drupal and completely support the ethos behind open source code, yet building from within the community comes with drawbacks. As with anything requiring volunteer input, you can only work with whoever puts themselves forward and is willing to put in free effort for the good of everyone else.

Developers and architects are heralded as the rockstars making Drupal attractive because it’s secure, stable, functional and adaptable. But another rockstar is the person out front who excites and builds an audience. In Drupal world this should be the role of the UX crew who can make Drupal easy, logical and beautiful to use for content managers and users.

Drupal.com

Another Drupal rockstar is the person out front who excites and builds an audience: This is UX

 

Content management challenges

Content managers need to upload content in the most engaging format, as quickly as possible, with the least number of actions to publish and with minimal risk of error (and that includes losing drafts).

Without UX thought, an off-the-shelf Drupal CMS is a painful experience. There’s nothing worse than seeing a Drupal page template’s multiple fields with baffling titles and trying to work out what will break when you do or don’t populate them with content.

I can list some of the common issues:

  • Open graph - if you share blogs on social then the first "image" will be stripped to show. For text-only blogs that could be the logo or, horrifically, the author pic. Sorting this means you can manually select the image to accompany the shared link.

  • Layout - having control of block layout within the CMS is so important to create interesting pages. This includes block types from text to text/pix, media blocks and having ability to have 1-4 columns or flip left to right. A locked down template makes a site author feel like they are little more than data entry. The design is part of the process.

  • Field naming - in a good CMS the fields explain clearly what they do, such as for the landing page thumbnail text, open graph text, etc. Character restrictions on headlines save time and help SEO.

  • Layout ordering - the best CMS is where you can open up all the page blocks and drag and drop the order to enhance the story. Also the ability to replicate the blog page to save time if there is a particularly successful layout

  • Scheduling - many posts are written in batches or started and finished later when info comes in. There's nothing worse than publishing to wonder where the hell it is on the landing page for ages before realising that it has kept the draft date rather than publishing date. A good CMS picks up the publish date or overrides the draft date with scheduled publishing date.

Drupal has modules that do the above and much more but they are not standard off-the-shelf. Good agencies understand that the success of their portfolio depends on how easy they make it for the people managing the website to use. I’ve worked with UXers, devs and architects who really care about those templates, carefully naming fields, adding explanations of what that field does and adding modules to catch human errors and make publishing super smooth.

Controlling block layout within the CMS creates interesting pages. So why not in Drupal?

Controlling block layout within the CMS creates interesting pages - and it's crucial for Drupal



Budget rabbit holes

Usually all the project money is spent on architecture and front end design, with little thought about designing and customising the back end for the site authors.

The danger of this is your website will look great for launch and then will slowly wither as content managers give up using the functionality because it is too hard to use and understand.

The worst solutions are when the build team doesn't involve site authors until content needs uploading into the new site. Often there isn’t enough time built into delivery for content layout and upload, or there isn’t sufficient training budget for site authors to learn how to use the site efficiently and effectively for SEO.

When there is an issue, all too often site authors are told to use the workaround until the issue reaches enough business value points to enter a spring. Sadly, the workaround can be translated as, “Add another 10 minutes to complete a task that should take two minutes.”

The most worrying thing is the specialist support site authors need to make the most of Drupal. The budget rabbit hole is why many site authors are operating on locked down templates with little ability to control the look and feel without constant dev budget drain. It is not easy to customise quickly, so you can’t react to real-world events unless you have an in-house dev. If you have to go out to an agency each time, you lose the moment.

The open source battle is raging

The race is on for the first open source solution to enable big corps to empower internal teams without compromising UX, stability and security. There will always be a big project redesign and migration to a new release, but the day-to-day needs to come back in-house.

It’s not just about the mega bucks, as there are millions of entrepreneurs out there needing websites too. This is where WordPress has built a solid market, becoming known for being beginner-friendly.

Drupal has always struggled with its marketing and it needs to understand that the more it empowers, the bigger it can grow.

For me, I've worked in a team which has set a very high bar in terms of multi disciplinary working. I've worked with a tech architect and developer to build a Drupal CMS backend of dreams. I would explain the problem clearly, demonstrate the time wasted, show the workaround and ask for suggested solutions.

If Drupal's community does look at the UX, and let's hope it does, then site authors need to be a primary audience. Without them, the experience will also be poor for the users.

About Emily

During her arts degree Emily spent her spare time in a newsroom learning about storytelling. After a post-grad in journalism with the NCTJ, she joined the world's oldest newspaper. From there she moved into crisis communications, dealing with major corporate disasters, and digital projects. During the last 10 years Emily has worked across the private and public sectors, working on huge marketing campaigns online and offline for global companies.

Want to be a guest blogger for Five Mile?

Got something interesting (and challenging) to say about Drupal, comms and the wider tech world? Then drop us a line!