Drupal is the Content Management System behind EdWeb 2 (and also EdWeb). As a Drupal contributor I’ve been working with others in the community to help improve the clarity of the language used within Drupal, to make it more accessible and inclusive. 

If you’re familiar with Drupal, you will have learned its language. You will be familiar with words like Views, Blocks and Paragraphs and you’ll appreciate their respective features and functions. But for those new to Drupal, getting to grips with what words mean can mean a steep learning curve. 

Why I wanted to help clarify Drupal’s vocabulary

My background in Content Design means I’m interested in words and particularly how people use and interpret them in the context of tasks they want to complete. In my role heading up the User Experience Service at the University I’m always looking for ways to make our staff and student experiences of our digital products and services better, and to this end I have worked on making our language more user-centred in several contexts: 

• Collaborating with others as part of the Editorial Working Group to manage the Editorial Style Guide (including the Inclusive Language Guide) 
• Developing content for component pages as part of the Design System project
• Starting an initiative to look at how we use technical language  

Read more about these pieces of work in these blog posts:

• A revolutionalised Editorial Style Guide – creating a single source of truth
• What’s in a component? Content considerations for a crucial part of the University Design System
• How the University talks about technology – a new UX project to investigate technical language

Since Drupal is an open source system and therefore can be shaped by the community for the community, working towards a better Drupal vocabulary was an exciting prospect as it meant having a hand in shaping Drupal for the future. I was struck by the parallel between Drupal and its language which will both need to shift and evolve over time, influenced by all those who contribute to it and maintain it.

Language is humanity’s most spectacular open source project  – Gretchen McCulloch, from ‘Because Internet: Understanding how language is changing’

The start of the Drupalisms issue

User research to improve the Drupal administration User Interface (UI) raised an interesting finding. When the Drupal community was asked to complete an exercise where they grouped terms from the UI into categories that made sense to them, the results showed people were unable to place some of the terms. Further investigation indicated that people weren’t sure what these outlier terms meant (and therefore they had struggled to sort them).

How we speak Drupal matters

Myself and my fellow Drupal contribuotrs wanted to address this finding from the research because we recognised the importance of people understanding Drupal terminology to enable and empower them to use Drupal confidently and competently. We strongly felt that Drupal language shouldn’t be a barrier to people new to the community learning and we wanted to take the opportunity to address this. It felt like the most logical place to start was to identify Drupal terms that caused confusion – ‘Drupalisms’. With a core team of community volunteers behind it, issue 3381734 was begun.

Issue 3381734 on Drupal.org

First endeavours to identify Drupalisms

With the issue live, we set to work, picking out terms that matched the ‘Drupalisms’ brief – in other words, terms which we felt were confusing to new Drupal users. Our initial list included words like: ‘Node’, ‘Blocks’, ‘Structure’, ‘Entity’, ‘Paragraphs’. As the issue queue gained momentum, more words flooded in, and people expressed opinions on aspects of Drupal terminology – for example, questioning Drupal’s use of ‘Site Builders’, ‘Developers’ and ‘Themers’ to describe the roles and functions of the Drupal community.

Drupalisms BoF at DrupalCon Lille

Attending DrupalCon Lille presented the chance to run a Drupalisms BoF with Aaron McHale to encourage people from the community to come together and collaborate on this issue. We spent the time looking at our initial list of terms, thinking of more, and thinking about how we would describe them to people new to Drupal. This exercise helped us appreciate the importance of preventing language being a blocker to new Drupal users and therefore affirm the importance of the issue.

Read more about DrupalCon Lille in my related blog post:

DrupalCon Lille 2023 – A UXer’s perspective

Establishing regular meetings to work together

Coming together after the BoF, we reflected on possible ways forward. We established that our original goal to identify Drupalisms was part of something bigger, an impetus to make sure our language opens up Drupal to everyone, to ensure we are being as accessible and inclusive as possible. We all agreed this was not something fixable quickly, and we committed to a regular pattern of fortnightly meetings to work on the issue.

Acknowledging challenges and opportunities

Our initial meetings were spent discussing the issue in more depth. We thought about the varied mental models, expectations, native languages and levels of understanding people bring to Drupal, and how their prior experiences (sometimes with other Content Management Systems) shapes their language perceptions. We considered the roles that glossaries tooltips and micro-copy can play in helping people make sense of our terminology in different contexts. We thought about the past – and how historic events had led to the language we use in Drupal today, and then ahead to the future, thinking about the impact of changing terminology and the possible consequences. We also established that language is an emotive subject, and therefore that making decisions about language should be based on evidence over opinions.

Adopting a methodical approach towards a controlled vocabulary

Ralf Koller from our group suggested an objective, multi-step approach to working on the issue inspired by various sources including Abby Covert’s book ‘How to make sense of any mess’,  Sophia Prater’s Object-Oriented-User-Experience (OOUX) methodology and the writings of other content design specialists like Erica Jorgensen. The stages we are working through are as follows:

1. Noun foraging – making a full list of all the Drupal terms
2. Evaluating/prioritising the most confusing terms based on responses from the community and also how easy it is to define them
3. Deciding which terms to include in a controlled vocabulary
4. Producing translations of these terms
5. Developing a ‘words we don’t say’ list
6. Establishing a process to maintain the vocabulary going forwards

Collaborating with other open-source Content Management Systems

Addressing issues of Content Management Systems (CMS) language more broadly, and acknowledging that Drupal is not alone in wanting our vocabulary to be intuitive and easy-to-understand, I’ve reached out to others in the wider open-source CMS community to think of ways we can use our collective force to develop a more consistent approach to CMS terminology. It’s early days but there is interest, and we’re looking to establish a date for an initial meeting.

Where we are now and next steps

We’re working together on the first stage of the process the noun foraging part of the process, gathering terms from many sources. Our current list stands at around 400 terms and we know there will be more. If you work with Drupal and you would like to join in helping us with this piece of work or you are interested to know more, please comment in the issue queue, join the #drupalisms-working-group on Slack or email me directly at emma.horrell@ed.ac.uk.

You can also find the ongoing meeting notes linked from the issue queue:

Issue 3381734 on Drupal.org