Drupal uses weird words for everything (node, entity, content type) and/or takes existing words and changes their meaning to something "Drupalish" (view, block, module, page, plugin, etc.). These do not match users' existing mental models, which is a constant source of friction in literally every usability test/training/etc. and is our biggest barrier to adoption.

A few quotes/observations from UX testing:

  • "I want to see Add Page." When user thinks of a page, they conceptualize the whole page, but Drupal thinks a page is one tiny-tiny thing.
  • Compared to Wordpress, "You don't have to figure out how to place your block inside your view inside your region inside your homepage."
  • "If all you use is Drupal, you're not going to be able to make any other kind of website."

We can work around this issue in Drupal 8 with text/video training/tour that introduces users to Drupal terminology, but longer term we should really conduct a full-scale terminology review, maybe using something like tree testing, in order to determine what might be more "universal" names for some of these concepts.

See also https://simple.wikipedia.org as a starting point for language we should be targeting.

Comments

tkoleary’s picture

tkoleary’s picture

See comment in #2513400: Add text/video training/tour that introduces users to Drupal terminology about wikipedia simple english

I think that could inform this as well

webchick’s picture

Title: Conduct a full-scale terminology review of Drupal » Conduct a full-scale terminology review of Drupal (Fix Drupal terminology so that it is more accessible to users)
Issue summary: View changes

Adding Kevin's suggestion to this issue where it is more appropriate.

webchick’s picture

Another nice suggestion from Kevin was to use a "Better Drupal English" translation to facilitate easy testing of different terms we want to try.

MattA’s picture

My personal favorite example of something like this, that even a knowledgeable user would appreciate, is under Administration > Structure > Display modes. You have "form modes" and "view modes".

So right now, pick one:
Does "view modes" mean how content is shown? -or- Is "view modes" related to the Views module?

(and no, the help text is useless for answering this, it just says "Manage custom [form|view] modes")

catch’s picture

Version: 9.x-dev » 8.1.x-dev
Category: Task » Plan
Priority: Critical » Major

We could do a lot of this in 8.x. Parts of it might end up 9.x-only but would end up being implementation issues.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

ifrik’s picture

This should probably also include and update terms explained in the glossary on d.o: https://www.drupal.org/glossary

yoroy’s picture

Status: Postponed » Active

How would we go about this?

Gábor Hojtsy’s picture

Translation teams like German have terminology indexes for translation, see https://localize.drupal.org/node/1263 for example in German. Other teams have similar solutions in some cases even better/complete. I think those could be used to quickly collect key words.

ifrik’s picture

catch’s picture

So off the top of my head:

- get a list of all the content entity type labels
- get a list of all the config entity type labels
- get a list of all the Drupal alternatives for these that are already used or have been used in the past (i.e. node type vs. content type, text formats vs. input filters, 'post' vs. either node or comment per #431612: Stop using post as a noun)
- put them into some kind of priority for revisiting, not sure past that point.

ifrik’s picture

The existing style guide on which words (not) to use in documentation could also be useful.

I will compile all the resources people come up with until the next Usability meeting next week, and so we can take it further from there.

DuaelFr’s picture

@Gábor Hojtsy
In France we use this glossary with a handy browser extension that highlights terms from the glossary in l.d.o and show their translation in a tooltip.

criz’s picture

WordPress is encouraging localizers to create a glossary and a styleguide for every language: https://make.wordpress.org/polyglots/handbook/translating/glossary-style... As WordPress is such widely adopted it can be beneficial to have a look on how things are named there. Of course, as Drupal has much more technical terms, concepts like "bundles" or "view modes" are not present in the WordPress world, it is much harder to create a full Drupal terminology that makes sense for most users.

I also think that it can be handy to list terms that shouldn't be shown during content creation or typical editorial tasks (= to the editor target group). For example I think we should get rid of the term "node" completely in this context. This is mostly done in D8, but is there some sort of guide for things like this?

ifrik’s picture

Drupal.org also has a glossary, but it's neither widely known or systematically maintained: https://www.drupal.org
/glossary

webchick’s picture

At UMN what we talked about doing was a "terminology review" ... I can't remember what software they used for this, but basically it was a series of web forms where you'd get the description of the thing without using the thing's name anywhere in it, and asked to fill in the blank for what you think that thing should be called. You do this some large sampling of the general public, and find the terms that converge.

The example they gave was "What would you call the building with exercise equipment and swimming pool?" Most people said "Gym." On their website it was called something like "Recreational Health Facility" and they were wondering why no one could ever find it. XD

ifrik’s picture

Two other resources:

ifrik’s picture

I had a look at these resources and there are too many terms too 'just' have a hand-written glossary that users, site builders and developers could consult.
Together the Drupal 8 User guide glossary and the glossary on d.o. have about 160 terms for Core and wider tech and Drupal community, and there are still terms missing that are introduced in D8 or used much more widely since then.
It also misses terms from widely used modules, which are part of the Drupal that users encounter on most sites.
(The quality of the explanations, or guidance on when what term should be used are also very varied. See for example entries for "entity=chunk of data".)

Consolidating the existing glossaries, and maybe adding more terms from a range of books about Drupal would be possible as a one-of, but it's hard to sustainably maintain. So we neither have a good basis for different type of users to reference, nor to use it as a basis for assessing and improving current terminology.

Maybe we need a technical structure first to keep track of terminology? Possibly as part of an overhaul of the help system?

One approach could be to include a "glossary file" into modules in which developers are asked to define the terms introduced in this module, and then displaying a glossary of all these terms as part of any website; similar to the help page that includes the help texts provided by all enabled modules.
This would give users a reference for the terms used on that specific site, but it could also provide more solid term definitions - and it would show us more easily where things are vague or where terms are used in different ways etc.

yoroy’s picture

Maybe we can do a tryout for a specific part of Drupal? Thinking of #2701541: Rename Drupal Upgrade UI to Migrate Drupal UI here.

mikeryan’s picture

Here's a DX-side one... In the outside world, one speaks of data migration using an "extract, transform, load" model - extract data from the source, transform it into an appropriate form, and load it into the destination store. When I've contemplated naming things in the Drupal migration system to fit this model, I immediately run into the fact that in Drupal's APIs "load" means exactly the opposite - pulling data out of storage rather than pushing it in. So, our model is "source, process, destination"...

yoroy’s picture

Issue tags: +ux-interfacetext
ifrik’s picture

I've made a related issue to deal with UI texts (and some terminology) as it currently stands: #2738393: Compile UI (Text) Standards for module developers

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.