Technically this can't be critical, since this isn't new to D8. It is, however, the single biggest barrier to entry to Drupal and the cause of much frustration/abandonment of new users, so think of this as "Major++."
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:
Long-term, we need to conduct a full-scale terminology review and actually change some of these labels, at least in the user interface, if not also the code. But that's Drupal 9. #2513398: Conduct a full-scale terminology review of Drupal (Fix Drupal terminology so that it is more accessible to users)
In the meantime, something we can do for Drupal 8 is add text/video training/tour during installation/on the front page that introduces users to Drupal terminology. (See CGP Grey's videos as a possible inspiration: https://www.youtube.com/watch?v=eE_IUPInEuc)
We should keep this resource in Help as well and let folks know that's where to find it later.
Comments
Comment #1
webchickComment #2
lewisnymanRelated: New user onramp proposal.
Comment #3
tkoleary commentedIMO making videos is not the solution for this issue. We should focus our energy on fixing usability problems, not push users off to a video explaining things that should be self evident by design.
I suggest we alter the title of this issue to "Fix Drupal terminology so that it is more accessible to all users"
As a first step I suggest we use languages and interface translation to create a "simple english" language and then "translate" the UI into that language as Wikipedia has done.
https://simple.wikipedia.org
This quickly focuses the problem since words like configuration, media, appearance, primary, secondary etc. are not in the BE 1500, and other words that are in the BE 1500 have different meanings in Drupal (Views, blocks, menus, breadcrumbs).
At the very least we can test again with simple english applied to validate the approach.
Ultimately the beauty of this solution is that users who would like to retain what I'll call the "developer english" terminology can do that easily while giving users with other roles simple english and a simpler experience.
Comment #4
webchickI absolutely agree that we do need to "Fix Drupal terminology so that it is more accessible to all users" (or at least users in our direct target audience, aka web developers, "most techie person at organization," etc.); however, it is simply not feasible from a release management POV to do this during beta, in the midst of the drive towards release. So for 8.0, we need a band-aid. For 9.0, however, we can do (and need to do) the holistic approach.
Comment #5
tkoleary commented@webchick
Right, forgot this was an 8.x issue. Still given opportunity cost, i would think that a simple english interface translation on localize.drupal.org would go further for less effort.
Comment #6
webchickThat's actually a great idea, as a way to play with possible solutions the 9.x issue in advance. But changing all the text in 8.x proper invalidates all documentation/bookmarks/links everywhere so we can't do it "officially" in core until 9, IMO.
Comment #7
lewisnymanI agree with Kevin, a perfect design should not need an introductory video, but Drupal 8 is not perfect yet :-) Intro tutorials are so common now, I don't think having one would be that unexpected or annoying.
We also have the option of keeping the intro tutorial very light, because if we need to go into detail on a specific interface or concept. We can use a tour for that.
Comment #8
mark.hazlewood commented+1 TKO. From a usability heuristic perspective, relying on docs and videos should be treated as a last resort. Learnability, recognition, etc. should be inherent in the user facing experience. Would love to help explore the terminology and mental model issues in 9.x =)
But an additional hiccup in the proposal for switching out layman's terminology using translation features is the UI and copy appearing different across users or sessions. That's no good for a number of reasons, huge overhead on existing docs being one of them.
Comment #9
merilainen commentedBut we have to keep in mind that Drupal is not a one-size-fits-all solution. There are definitely some weird naming conventions, like a view (~list?), node (~entity nowadays), but other systems are not perfect either. Quite often beginners ask me where they can find the different templates, which are called content types in Drupal and which makes a lot more sense when you are not used to the word "template" meaning basically everything and anything in the system.
Comment #10
ifrikThis should also include working on the existing glossary, and possibly linking that from the general help page. https://www.drupal.org/glossary
Another problem about Drupal terminology is less in core and more in contrib when several modules use the same word to describe different functionality. See for example "Context" that's used by modules such as Views, Ctools, Context, and Scald; or Display Suite and Scald using two different words (mode and context) to describe very similar functionality.
So besides given an easier introduction to new Drupal users, we should also think of a way to give module maintainers an overview which terms are already used with which meaning before they start naming their components.
Comment #11
ifrikComment #25
smustgrave commentedThank you for creating this issue to improve Drupal.
We are working to decide if this task is still relevant to a currently supported version of Drupal. There hasn't been any discussion here for over 8 years which suggests that this has either been implemented or is no longer relevant. Your thoughts on this will allow a decision to be made.
Since we need more information to move forward with this issue, the status is now Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.
Thanks!
Comment #26
smustgrave commentedWanted to bump 1 more time before closing
To me this could be outdated or won't fix. We have resources like Drupalizeme now and documentation is better (not perfect but better).