The problem

At The Evergreen State College, web content creation occurred in a distributed authoring system. How could we design a system that addressed all authors, regardless of their different technical abilities, levels of attention, and frequency of content updates?

Historical pain points

• Accessibility – Authors regularly used the H1 tag just to make text very large. Even an attempt to make this text “ugly” ended up being used to draw visual attention.
• Style cohesion – The CMS in use when I arrived primarily used a templated page with a title and a chunk of HTML with a WYSIWYG bar across the top. Authors copied and pasted chunks they saw on other pages in order to get tables or callout boxes.
• Variable levels of training and usage – Editors of different sections would edit as frequently as a few times a week, or as infrequently as a few times a quarter. Any training we provided could only go so far. We were also unable to add instructions to web templates.

The evolution

Designing content types for cohesion and accessibility

When we migrated to Drupal 7, in designing our main content type I was able to break up the fields into multiple sections that corresponded with the pieces of the overall site design. Authors had not just a title and text, but an “Introduction” statement that always appeared the same way, and a “Secondary Content” area that was styled differently depending on screen size. I added instructions to go with these fields, so that someone who had gotten training six months ago could still know what each thing would do. I picked which HTML elements were available through the WYSIWYG, paying attention to usage and errors our team had seen over the previous years to decide what elements were most necessary. 

We saw improvements in HTML structure with Drupal, but issues still remained for authors who needed more complex layouts, or to present data that was being drawn from other parts of the site: events, news posts, or directory entries.

In the planning for Drupal 8, we considered a variety of options to meet those needs. In Drupal there are many different ways to get to the same process, but I assessed that Paragraphs was in the right spot of being well-supported and flexible enough for our needs. The designer and I built a list of common patterns that we might build in a more structured way moving forward, and I built those out as Paragraphs. We included a few options that were only available to a set of admins on our team for advanced needs.

Enabling ongoing education

During the development process with Drupal 7, we conducted usability testing with authors, and we had an extensive testing phase for authors to learn while we were still building. They provided feedback that allowed me to make adjustments. The number of total authors ranged from 50 to 75, but there have always been a handful of power user authors who are very engaged even if they are not especially technical. These authors are people I could just email, call, or visit with and talk to frankly and comfortably to get a good sense of what was and wasn’t working.

In preparation for Drupal 8, we again conducted usability testing and also brought authors into the updated site as it was being developed. We weren’t able to work on that as thoroughly as we wanted to, because of the demands of working through the pandemic. So it wasn’t until after we had launched that we discovered the biggest flaw of the system I’d built: the way Paragraphs works innately is like layers of content that sit on top of each other, and some of the types we’d created really worked best if the main content flowed around them. 

I had an existing model of this sort of “interrupting” content with how images are inserted, including blocks of image+caption, and so I looked into whether it was possible to handle callout boxes and similar content in the same way. I found a module that would do that, installed and configured it, and we were able to jump pretty easily to this new model. Immediately the authors who had noted their frustration were excited for the new feature.

Improvements since launch

Similarly, after launch, we looked into ways to help these engaged authors improve the SEO performance and social media appearance of their pages. I added a new field for them to create a “summary” that would be used in on-site search indexing and results and integrated with a module to automatically use it in the summary meta tag and whichever HTML values are being used by social media sites.

Over the years, content design at Evergreen was a steady process of iterating: looking at the content of the site, seeing where authors had trouble both in their training — which I co-wrote — and in practice, asking questions, tweaking existing fields and developing new tools. The desired end state was a site that is accessible, visually coherent, and well-structured without being overly cumbersome to use: in short, to make the right thing easy and the wrong thing impossible. It was not an end state that I was able to completely achieve, but every iteration got closer.