This blog post was written by Promote Drupal committee member Emma Horrell.
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 will 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.
The start of the Drupalisms issue
User research to improve the Drupal admin 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
We 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.
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 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.
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 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:
- Noun foraging – making a full list of all the Drupal terms
- Evaluating/prioritising the most confusing terms based on responses from the community and also how easy it is to define them
- Deciding which terms to include in a controlled vocabulary
- Producing translations of these terms
- Developing a ‘words we don’t say’ list
- Establishing a process to maintain the vocabulary going forwards
Collaborating with other open-source Content Management Systems
Addressing issues of 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 how you can help
We’re working together on the first stage of the process - the noun foraging, gathering terms from many sources. Our current list stands at around 400 terms and we know there will be more. If 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 Drupal Slack channel #drupalisms-working-group, message me on Drupal Slack or email me directly at emma.horrell@ed.ac.uk and I can provide more information or add you to the meeting series. You can also read the ongoing meeting notes from the issue queue.