The success of a CMS project ultimately depends upon the content it contains. No matter how “on-time” or “under-budget” a project might be, editors have to be able to create and manage content, and they need to be able to do it without feeling the need to pull their own hair out.
If editors on your team do not like the editorial experience, disillusionment will begin to set in, and that disillusionment can cascade throughout your organization. Remember, your editors are likely the most prolific users of your website. If they don’t like it, your CMS implementation is headed for the scrapheap.
How do you balance ease-of-use with the constraints of your design system? Are there common things that can be done that ensure editors have a good experience? And how do we define “good?”
What is “good?”
For this article, we’ll use the following standard: A good editorial experience is one that allows an editor to add content in accordance with the organization’s goals with minimal frustration. If there are strict standards and safeguards in place, an editor still feels empowered and does not feel the desire to circumvent these safeguards.
We are not shooting for a perfect editorial experience. That will never exist. This is still software we are talking about. It has to conform to a lot of requirements, and many of those requirements will conflict. But we want to be careful to ensure that we don’t make the perfect the enemy of the good, and the standard above allows for some compromises and tradeoffs.
You will also notice that this standard means that what is “good” can differ from organization to organization. Content goals vary, the preferences of editorial teams vary, and so we need to allow for some subjectivity.
But there are still some baseline commonalities we can recognize.
We want to be careful to ensure that we don’t make the perfect the enemy of the good.
Common best practices
What are some best practices that apply to any CMS and organization? These are good anchors to start with because, if you have these, it’s harder to get distracted by shiny new tools and approaches.
Jumping from editing one content type to another should carry some familiarity. As much as possible should be the same from form to form, down to colors and font sizes. This gives editors less they have to think about, which results in less confusion.
Different fields and options might exist, but give editors some anchor points, so they don’t get lost. For example, have common fields, like Title and Author, appear in the same place on all forms that have them.
Do not have multiple ways to include images or videos. Do not have one text field that allows direct embedding of an img tag but another that only allows a special embed code. This is a recipe for frustration. Choose one way to do it, and stick with it, and if it needs to change, apply the change consistently.
2. Clear, relevant labeling
Fields should be labeled, and additional helper text should provide relevant context. This seems obvious, but sometimes it is so obvious that you can forget to pay attention to it. Often this text is written and placed by developers, and so they bring their own bias and context, and what they put in is, at best, unhelpful and sometimes downright confusing.
Helper text should make sense to editors and use the language they are familiar with. It should explain things in a way so they can predict the results of their actions.
Bad helper text: “This is an image field.”
Good helper text: “An image that will be displayed at the top of the article and be shown when the article is in a list. The minimum size is 1000x600.”
Bad helper text: “The categories this article belongs to.”
Good helper text: “Add links to one or more category pages. If you input 'apples, oranges,’ links to 'mysite/apples' and 'mysite/oranges' will automatically be displayed on the article, and this article will be included in the lists on those pages.”
Keep things contextual, not just factual. Editors usually don’t care about technical details, but they do care about the hierarchy of the page and the effects on the site that they can see.
This is a place where usability tests can really help. Run them to find places where people are getting confused and craft text that addresses their questions and uncertainty. Make an intentional effort.
3. Make the right things easy and the wrong things hard
Your experience should be designed to encourage your editors to do the right things.
One common example: should all images embedded within content have “alt” text? (The answer to that is yes). Make “alt” text required for every image so the content cannot be saved unless it is filled in. For background images, they should have empty alt text so screen readers will skip over them, so just don’t show an alt text field for those and let your CMS handle putting in the empty attribute.
Should each update to content create a new revision so changes can be rolled back? If so, that should be easy to do. Make it hard for someone to mess this up: don’t even show them the option.
Don’t make onerous formatting requirements that editors have to ensure themselves. Make proper formatting easy.
Have you ever been frustrated by an online form that requires you to enter a phone number with exact spacing and parentheses and offers no help? It's like trying to put a puzzle together, but all the pieces are flipped to the side with no picture, and that’s an extra cognitive load your editors don’t need.
4. Clear, obvious error handling
If an editor does something wrong, don’t be coy. Don’t leave them guessing. State the error clearly and be specific, making the message hard to miss. Ideally, the error will show up next to the problem in question, though this isn’t always possible to do. Clarity is the most important.
Bad error message: “An error has occurred.”
Better error message: “The ‘summary’ field allows a maximum of 160 characters.”
Error messages should make it obvious that something went wrong, and some colors communicate “wrong” more than others. Therefore, don’t highlight errors in green. Also, take into consideration editors who might be color blind or have other visual impairments, so do not rely on color alone to signify an error.
5. Simplify to necessity
Plan and design for the 80%. Do not have lots of fields and options that most editors will never use. Do your best to slim down the experience to only what is necessary. Do not, in other words, present your editors with a form that includes everything, even the kitchen sink.
What about the other 20%?
Once you have figured out what that 20% actually is, a process driven by your business goals and not by what people think they want, accommodate the need.
For example, only a small number of your articles might have a Featured Video, so most editors will not use it. That field should not clutter their experience. But video is still important, so certain editors should be able to find it and use it with no trouble.
This can be accomplished via permission management. If only some editors need the field, you can hide the field from others by denying them access.
If all editors need access, just sporadically, the Featured Video field could be moved under a tab labeled “Advanced” or to a sidebar labeled “Add Video.” The fields are there, but they do not distract from the main editorial path.
Long, confusing forms sometimes result from a single content type being responsible for lots of different contexts and page designs. An “article” might be used for a blog post, a news release, a video post with a transcript, and a podcast. This requires lots of fields to take into account the different uses.
But this heightens the risk of confusion and burnout.
Sometimes, simplifying will mean revisiting your content model and having distinct content types for each audience and/or presentation.
Having sensible defaults also helps simplify things. Default to what the 80% needs, but make it easy for the 20% to change that default.
6. Easy wayfinding
Good navigation and architecture aren’t helpful only for your site visitors. Your editors would also appreciate not feeling lost when they need to edit a specific page or content block.
Pay attention to the organization on the administration side. Are your editors forced to use your normal site search, the one for visitors, to find the content they need? Maybe that’s fine. If it isn’t, though, have you provided a good alternative?
Some of this depends on how big your editorial team is and how they work. If a team is responsible for a few categories, make it easy to filter by their categories. If you have a system of revision approval, make sure the process is clear and that the next steps are easy to figure out.
Inline editing can be helpful here, but it can also be overrated and difficult to integrate with certain workflows. As long as an editor has a clear path to get where they need to go, that is often enough.
7. Avoid busywork
Don’t enforce things “just because.” Don’t require editors to fill out fields that are not really required for any business logic.
For example, some systems have a revision log field that is required whenever content is updated. This can be helpful for large teams, but sometimes, the only person who ever reads those revision logs is the ghost who lives in the server. AKA “no one.”
Don’t make your editors fill out stuff that nobody cares about. There might be legal requirements for you to store information, and in that case, someone obviously needs to care about it. The question then becomes: how do I make the process better?
Likewise, do not make every piece of content go through a five-step approval process if only one person needs to give approval. Do what is necessary to ensure standards are met, but having faith and trust in your team is better than arbitrary safeguards.
Drupal-specific tools to help
Drupal has a lot of functionality, out of the box, that will help you deliver a good editorial experience, like places for form element helper text, requiring alt text on images, good form validation, and the ability to set default values.
Drupal core also gives you the ability to have different “form displays” for each content type, though taking advantage of them requires a bit more work.
Text formats and WYSIWYG
Drupal comes with a robust text format system, and editors can have access to different formats based on their permission level. Take advantage of these. Do not leave extra buttons on the WYSIWYG editor that no one uses. Keep it simple.
Drupal includes drop-down links for privileged users at various places on a site, allowing editors to easily jump to the edit form of a block or content type. Additional links can be defined with custom modules.
If you are creating listings with Views, Drupal provides a way to add contextual links to each result that is shown. This can be an easy win.
Drupal comes with a shortcut menu that each editor can easily access. You can set up permissions in a way for editors to choose their own shortcut set, giving them some say in their own experience. Set up some sensible defaults for the most common tasks, and let them tweak.
This is simple in concept but can go a long way in improving the overall experience.
Inline Form Errors
This module is included in Core but is disabled by default. When enabled, error messages are placed next to the relevant form elements themselves instead of just as a summary at the top of the form.
Contrib extras to help you craft a good editorial experience
There are other tools and groups of modules you should pay attention to when building an editorial experience in Drupal. Using them does not guarantee a good experience, but they can make it easier to achieve one.
- Field Group - Perfect for simplifying your forms and hiding less-used fields. A great tool for catering toward the 80%. If you end up grouping fields according to a specific pattern(field type, whether a field is required, frequency of use,) stay consistent from content type to content type.
- Field Permissions - Another way to limit and simplify your forms, but with more explicitness. Useful for larger teams with a hierarchy of editors where access to some fields need to be enforced beyond just moving them around visually.
- Entity Browser - A widget for entity reference fields, this allows more user-friendly selection beyond simple autocomplete. If set up correctly, it also allows inline creation of other entities before they are referenced. This can drastically improve the usability for editors. However, it depends on good practices and discipline for field naming and descriptions, so you cannot ignore the basics.
- Embed - You can also set up easy embedding for custom elements and structured data, tying them to a button on the WYSIWYG.
- Entity Embed - Integrates with Embed to trigger Entity Browsers to enable embedding in text fields. It’s easy to go overboard with this module and cause more confusion, so be intentional about what you use it for.
- Inline Entity Form - Another widget for entity reference fields. Good for creating content to reference. If you don’t need to re-use content and don’t need to search for content to reference, this can work better than Entity Browser in some situations.
- Allowed Formats - Drupal core allows you to limit text formats by user role, but Allowed Formats will enable you to do it per field. It is very common for a text field to allow only links, for example, enabling you to have the appropriate format selected and all others hidden. This is a great way to make the wrong things harder.
- Entityqueue - Sometimes, editors need to be able to explicitly define the order of content on a page and not depend upon things like a published date or other metadata. This makes it easy for them to reference content and order it how they wish.
- Automatic Entity Label - Used for content that is only referenced by other content, so editors do not have to worry about creating labels. This can help avoid some busywork.
- Override Node Options - Limit access to default fields on nodes. This fills in some gaps from Field Permissions.
- Chosen and Select2 - If you have long select lists, either of these can make them more usable.
- Linkit - If your editors link to lots of internal content and files, this module makes it easier to perform those tasks.
- Require on Publish - Sometimes there are fields that editors do not want to fill out until content is actually published, and they just want to save their work or view a preview. This has provided a huge boost in usability for some editorial teams.
When editors are happy…
There is no such thing as a perfect editorial experience, but you can provide a good one that will keep your editors happy and help them avoid frustration. Don’t ignore the most prolific users of your website.
If your editors are happy, it is much more likely that your business objectives will be met, there will be less turnover and burnout, and your CMS has a better chance of sticking around for a while.
At Lullabot, we have seen the good, the bad, and the ugly of CMS experiences. Part of our work in design and strategy is to figure out how to empower your editors and not leave them behind. And we would love to help you. Reach out if you have any questions