Editor’s note: We’re excited to get some insider tips from the Drupal experts at DevCollaborative. Johanna Bates shares her insights into how to build a content management system that makes life easier for all the different people who update your website.
Content management systems (CMSs) provide a series of powerful online forms that, in theory, make it easy for anyone to update a website. These forms should be intuitive, helpful, and easy to understand. But how often is that really the case?
Over our years of working with organizations, we’ve developed some strong opinions about how to make the Drupal content editing forms as helpful as possible. Our colleague Eileen Webb, content strategist at webmeadow, talks about this as “AX,” which stands for administrative experience (think UX, but for content editors). We think AX is particularly relevant in the nonprofit sector, where there is often uneven funding for technology and frequent staff turnover that can result in a loss of organizational knowledge.
We like to think about every Drupal website as two websites: one facing the public users and one for the content administrators. For your public site, in an ideal world, you research your users’ needs and habits, and you use that research to inform the design of the site’s information architecture, UX, and visual style. If you’re proactive, you’ll build in regular reviews of your site’s design and structure, at least annually, so you can make adjustments as your users, content, and organization evolve.
The process for giving attention to the AX of the editor-facing site is similar, but often neglected. However, during a new build, or when reviewing an existing Drupal site, you can gather information about content editors and how they’re using Drupal—what they do most often, what they need to do and can’t, and what they find confusing. Do you notice any snags in their workflow? Use that information to make modifications. This process could be lengthy, involved, and expensive, and involve a whole custom design for editors. But it doesn’t have to.
If you have in-house Drupal expertise, devoting one to three days to AX will reap many more benefits than ignoring those issues. Editors’ top pain points, if you don’t know them already, could be uncovered in a single brainstorming meeting, or via internal survey. From there, you can identify priorities and low-hanging fruit.
Fairly simple modifications to the editing interface could include adding clear labels and help text to your top ten key fields; removing irrelevant items from the Drupal admin menu; making a customized toolbar or menu block for editors that includes links to their most needed tasks; or linking directly to your organization’s style guide from within the content editing forms, right where referencing it will be most useful to editors.
There are a handful of modules that we almost always use to improve the Drupal AX when we are building a new site. The Label Help module allows you to put help text above the field rather than below it, a small but incredibly helpful tweak. With the Field Group module, there are many quick and easy ways to group fields together into horizontal or vertical tabs to make the content editing forms less overwhelming. Quickbar is a role-based toolbar that allows you to set up a menu bar with links specifically curated for content editors, giving them only the links they need. And finally, be sure to log in as a content editor or use Masquerade to test the process exactly as your content editors will see it.
If you have a large team and/or a complex Drupal instance, or if you don’t have in-house expertise or capacity, treating the AX enhancements as a small to medium-sized project might be a better approach. Some more complex enhancements might include removing unnecessary WYSIWYG buttons and adding custom styles, adding conditional fields so that some fields don’t appear unless they are relevant, or adding automated editing workflows or image cropping in the editing form.
Even if you approach AX as its own project, your internal needs and priorities will determine the scope of the project and the price doesn’t have to be exorbitant. If you have a vendor in charge of ongoing Drupal support, it’s worth checking with them to see if they can support these modifications, or look around for trusted small companies or Drupal contractors who have the skills to tackle this work. Your content editors will thank you!
To geek out more on the topic of improving AX, see our blog post “Content Editors Are Users, Too” at http://devcollaborative.com/ax.