An incredibly common complaint about Drupal is in that its terminology is often arcane and difficult to understand. And while the substance of these complaints are actually right, many people come to what I consider the wrong conclusion, and it's this wrong conclusion that is actually the root of what is currently wrong with Drupal's use of terminology.

Let's take a look at some actual problems with terminology.


Long complained about, taxonomy is a technical term with a very specific meaning. It seems to frighten a lot of people, and it is considered difficult for people to grasp. One of the reasons for this is that, somewhere along the way, taxonomy had been renamed categories. In Drupal 6 it was finally actually renamed back to taxonomy, which is good. After all, when I enable the 'taxonomy' module, I wouldn't expect to administer it via the 'categories' link. Taxonomy module should call itself taxonomy, darn it.

But beyond that, the term 'categories' was actually incorrect. A very long discussion pointed out that what people understand when they see categories turns out to not be what taxonomy is. This leads to an incorrect understanding which makes the problem worse, not better. Just because users understand the term category and not taxonomy is a bad reason to call something it is not. After all, oranges and grapefruit are very similar. But if I give you a grapefruit and tell you it's an orange because you don't know what a grapefruit is, have I done you a favor?

No. You'll dig into the grapefruit and probably be pissed at me because it's not an orange. If I'd just told you it was a grapefruit, you'd have the opportunity to ask "What's a grapefruit?"

Of course, this is where we fall down again. We do a terrible job of answering the question "What is taxonomy". Oh, there are web pages dedicated to it, but the fact of the matter is, when I click on administer >> content >> taxonomy, I should be able to find the answer to "What is taxonomy" right there. If it's not one click away or less, and it's not written succinctly, I have failed.


The problem with categories continues to exist in Drupal. Because the word 'node' has fairly ambiguous meaning, it was deemed a good idea to not expose the user to the word node. And in the Drupal UI, everywhere that you might see 'node' you now see the word 'post'.

This is great, except:

  1. Nodes aren't always posts. If I'm using CCK and my node is 'person', that's not a post. D'oh.
  2. The word 'node' is still all over the place. node.module is listed in the module administration page, developers refer to them as nodes, most contrib modules refer to them as nodes, and all the documentation still refers to them as nodes.
  3. 'administer nodes' permission. Not administer posts. Oops.
  4. Worse: a node type is a 'content type' in the UI. Not a node type OR a post type. Double d'oh!
  5. There is nowhere that explicitly tells the user that a node is a post.
  6. The definition of a node, as far as Drupal is concerned, isn't near the node administration pages.

My conclusion

Using familiar terminology in place of correct terminology is a recipe for disaster. The only correct solution, in my opinion, is to use the correct terminology and make it very easy to find the definition of this terminology in the places that matter. The information may be available, but it has to be available when the user needs it, not via google search. Probably the user doesn't know the right words to search for anyhow.

A proper user experience prepares the user for the unfamiliar. Yes, principles of user interface design demand that UI be as familiar as possible; and to copy other common UIs to create common experience. That said, giving the user wrong information is tantamount to lying to the user, and then being shocked, SHOCKED I TELL YOU, when the user is hurt.

Oh, PS: A 'user' is someone who 'uses' the site. 'People' could be people who aren't users. You could call a user an 'account' if you like, that's actually pretty accurate. But if you want 'people', go look at CiviCRM. Or a phone directory. There's lots of people there.


What a great diatribe on the state of naming conventions. I love the orange-to-grapefruit analogy because it's so close to what's going on with Taxonomy vs. Categories.

Nice writeup, Merlin!

And I like the improvements you've made in writing help texts. I'm in strong favor of continuing to revise Drupal's terminology towards being "pure" and technically accurate while making good help texts more accessible in the interface.

ah, nothing like a good terminology debate. this one will go on forever.

just to be a contrarian, there is a popular school of thought around the book and premise Don't make me think. When you name something taxonomy, you are going to make many people think a lot. That's bad++;

  1. [ ] Understanding what taxonomy means
  2. [ ] Understanding when categories are not what the word means?

The premise "Don't make me think" is great, but I think it's wrong when you have a concept that is, in fact, not actually familiar to users. A good UI trains users. A bad UI lies to users.

Also, remember that users should expect their first few times using a new and unfamiliar system to be a learning experience. If we provide the learning experience, and we train them, then we succeed in not making users think. Because the user is now trained in what this system provides and how to use it.

This reminds me of the very first releases of Lotus Notes/Domino that included SMTP/POP3 support. Lotus, with its excellent usability track record (NOT!), decided not to use the familiar SMTP/POP3 terminology. Instead they invented all kinds of new words. The net result was that nobody understood how to configure this new functionality and very quickly it was known as "hard to configure".

In the usability testing at the University of Minnesota, we found that Librarians and Library workers seemed to not have a problem with taxonomy. We are waiting results of testing at the University of Baltimore that is being done with non-library workers. Let's see how those tests turn out.

The introduction of a glossary, to help explain terms is a good support mechanism while we try to further simplify Drupal terminology. We spent upwards of 90 minutes watching people use Drupal and it was clear that within a few minutes, new users were overwhelmed. What's key is that they weren't overwhelmed by any one particular term, but by the collection of new terms. We call this cognitive load. Users can handle any one term, but a collection of concepts particularly overlapping terms and concepts like node, post, content, and content creation kit were collectively too much to learn. This cognitive overloading impacted everything else they tried to do.

Arguing about individual terms, the familiarity, or accurateness is not what's important. What's important is reducing the total number of concept's that new users have to understand to use the interface when first starting out.

I've just written a post examining the 109 information improvements to Drupal 6.

This debate is going to be coming to an end as we move from our second set of usability testing to the third. We have measurable research to show the problems and we will have to respond and measure new solutions.


The question here is, is it the number of new concepts, or the accessibility of the new concepts?

If the user is trained in the new concept right when that concept is introduced then the information is more useful. When returning, that information is still there, and there is a reference.

By having to go elsewhere to learn what taxonomy is, for example, the mental connection is not readily made; the time between seeing the UI and reading the explanation is lengthened, thus reducing the utility of the explanation. Worse, the time between reading about taxonomy and visiting the UI again is also lengthened, thus reducing the retention of information.

Thank you Earl, for this node post ;-) I fully agree with you that the underlying problem is the explanation of concepts, not the terminology in itself.

A lot of Drupal concepts are taken for granted (by developers, seasoned users), and never properly explained in the UI. Properly explaining "node", "taxonomy" and other concepts ("teaser" anyone?) means both using the right terminology, and being clear and concise in your explanations.

I wonder: would it be possible to include images/diagrams in these explanations, or is that a no-go in Drupal core? (Probably diagrams could be purely HTML+CSS based, so translatable.) I should still have a few images lying around, from the time when I learned Drupal.

write a detailed feature request issue, try to convince others that it is necessary, try to solve (or help with) the issue, and see what happens.

That link takes me to the front page of a website and from the titles of the news there I can not figure out which article is the one you intended to link to.

Best regards,

I'm slightly disappointed Merlin, because I initially thought you were going to come down on the side of common sense. All these obscure technical terms might be accurate, but they're a terrible barrier to entry into Drupal. I'll go one further and say I initially thought the Drupal community didn't *want* people to use the platform because of the unnecessary learning curve.

I rejoiced when Taxonomy was renamed to Categories. If you're coming to Drupal from another content management system, what do you expect to see? I couldn't get my head around taxonomy at all, but explain it as "allowing different content types to have seperate sets of categories" and you're 90% of the way to understanding.

Common knowledge might be handy for folk medicine, but it isn't enough for a content management framework. You can only dumb down a system so much before the system becomes dumb.

As a librarian who has specialized in information organization, I take umbrage at your description of my holy grail as "obscure technical terms."

As a member of the docs team, I urge you to RTF(reindly and easy to use)M.

I rejoiced when Taxonomy was renamed to Categories. If you're coming to Drupal from another content management system, what do you expect to see? I couldn't get my head around taxonomy at all, but explain it as "allowing different content types to have seperate sets of categories" and you're 90% of the way to understanding.

So the rest of my argument has no merit? No meaning?

Here, let me refute what you say anyhow:

Take a look at Wordpress. They recently retooled their category system to work like ours, because the power of taxonomy is immense. The problem is? No one can understand it. Why? Because they're calling it categories.

The fact of the matter is, the term category fits taxonomy like a square peg into a round hole. Yes you can hammer it in there, but it is incorrect.

By the way, I call a very loud bullshit on your taking the other side of the argument and calling it common sense. Common sense is that things mean what they say and say what they mean and you can figure it out. Ever heard the old adage "Let's call a spade a spade?" That's because if you call it something it's not, people don't understand what it is.

We have tons and tons of proof that the rename to categories was bad. We have had long arguments over exactly how the categories don't actually fit what taxonomy does. Please, unless you can actually refute my arguments, your response is just as useful as saying "DON'T CARE IF IT'S WRONG I HATE THE WORD TAXONOMY BLAH BLAH BLAH."

I posit that we can train people, and that the problem is we don't do it. So of COURSE people are presented with big scary words and don't know how to deal with it.

You know what? 'computer' is a big scary word. Clearly you got over it. You know all kinds of technical jargon now. What's a mouse? What's a window? What's a monitor? What's a screen?

Please, treat people like they're people and can learn, and teach them right. To do less is to lie to them, AND treat them like they're stupid.

Hi Merlin,

Ever heard the old adage "Let's call a spade a spade?" That's because if you call it something it's not, people don't understand what it is.

There is an underlying assumption that does not come to mind immediately. It is that if the word is both correct and hard to understand, it is because the concept behind the word is itself hard to understand.

Boileau said that whatever is well conceived is clearly said and the words to say it flow with ease. That it the point, I think. I would not be surprised that only a few Drupallers would be able to explain in a simple way what a taxonomy is and is not.

Taxonomy is not as much hard as a word, as it is hard as a concept. Taxonomy is a "hyperonym" for "categories" or "tags" and a hyponym for "sorting" (one can sort by user or date too, and these two criteria are not taxonomies but are still ways to sort data).


So, what is special about taxons compared to non-taxons criteria like date and user? That they are user-chosen. Well technically, more user-chosen than the others. Technically, date and username may be chosen (contrary, to, say, database id), but are not supposed to. They are heavily constrainted, while taxons are just light constrainted.

Mandatory constraint   database ID
Heavy constraint       date, user…
Light constraint       taxonmies (categories, tags…)

Now, this is both accurate and clearer. Granted, not that clear. Add up some rewording and you'll get it as clear as it possible get (IMHO).

So this is it. Think upstream. Clarify the signifier (the concept) before trying to clarify the signified (the word).

Ce que l'on conçoit bien s'énonce clairement,
Et les mots pour le dire arrivent aisément.

-- Nicolas Boileau Despréaux

One last note: Explaining something by comparing is a very good thing.

Calling a grapefruit an orange leads to sour faces and angry users.

I think a lot of Drupal developers underestimating users. I haven't run into many cases of people actually being confused by taxonomy. I mean, some people might not understand everything that taxonomy actually means but I think the idea that taxonomies are used to group things is something even the US education system has been able get across to most people.

I think this goes a step further in supporting Merlin's point. I think people making websites are generally pretty smart people and if you provide them the ability to understand what Drupal's terms are they'll become trained in how things work.

I mean, there was some day those people coming from "another CMS" had to learn what Categories meant in that system. And if they where looking for the same old thing they probably wouldn't be looking at ours.

That said, I don't have any facts to back up any of this up other than my experiences so it will be good to see the testing from Baltimore that Kieran mentioned.

You miss a very important point here, which is taxonomy was never really renamed to categories. One menu item, in the main administration menu, was changed to categories, however we still had:

taxonomy module
taxonomy/term urls
A help text which talked about taxonomy, and categories, and vocabularies, and terms.
Over 70 contributed modules about taxonomy on, and one 'categories' module which for quite a while required a core patch in order to work.

This situation confused the hell out of people. Lots and lots of people. And I spent a good bit of time during the Drupal 6 release cycle to get it tidied up - which meant retitling that menu item, rewriting the help texts from scratch, and moving a bunch of forms around.

If someone comes up with a full reworking of the module name, terminology, help texts, all the other elements (hierarchy, multiple hierarchy, vocabularies, related terms, synonyms, tags, urls etc.) - that's consistent, and doesn't directly mislead users (which merlin's orange/grapefruit analogy explains very well) - then I'm sure plenty of people will give it very serious consideration. However my efforts this release cycle will be on providing sensible defaults, and trying to make some of the administration UI elements easier (like adding lots of terms at once). Drag and drop added a lot to the taxonomy UI in terms of ease of use, but there's plenty to be done there. If we had better tools to deal with the functionality offered, then people would spend a lot less time dealing with the terms and just jump in and use it - since most people can grok tags, relationships, hierarchy, categorisation - all the stuff this obscure technical term was coined for a couple thousand years ago.

The problem with jargon and new users has been pretty well established. I'm firmly in favor of teaching users the proper terminology, but I can't think of any place on where the terms are laid out for easy reference. I just spent 5 minutes trying to find a definition for a node. I couldn't find it easily, and I'm pretty comfortable with and knew what links to follow. Imagine being new and trying to make sense of it all.

I think the burden is on us to create better materials (or a glossary) for new users. I'm not aware of any glossary if there is one. If there is a glossary, we should consider making it more prominent.

I'm sorry I have to disagree with you on several points Earl.

1. I have been studying categories (human categorization and scientific categorization) for a long time and there really isn't any fundamental difference between categories and taxonomy. Or rather they are describing the same set of phenomena from a different perspectives. Taxonomy is merely a hierarchical systematic way of organizing categories - 'naming of order'. The taxonomy module then provides different ways of organizing 'nodes' in categories (with flat or tree-like organizations). Lots of people talk about 'tags' as being something different than categories - like the way Wordpress does it - but they are really not - both in terms of human cognition or the job they do for organizing collections of terms. BUT that leads me to another point --

2. Even though 'tags' and 'categories' are fundamentally the same (both can be the subject of taxonomy), they are usually used differently in online applications. At the simplest level, tags are typed in and flat and categories are checked/selected and hierarchical. This changes people's perceptions of what they are for but also other behaviors (for instance, folksonomies would be hard to create with checked categories). This means that there can never be a terminological purity around the notion of category and online systems where categorization is a social activity. I was first annoyed at the renaming of 'Categories' - I don't see a reason why we can't think of the 'Taxonomy module' as something that manages 'categories'. But it really doesn't make a lot of difference. I'm just really dubious that it will make understanding the concept of what the module does any simpler.

3. The reason for that is that terminological purity is absolutely impossible in human languages (unlike computer languages). That doesn't stop people from trying but it is really a fool's errand. Even 'scientific' concepts like 'gene' or 'set' or 'geometry' are incredibly ambiguous when examined in the discource of people working with them. On the other hand, language and the social order have loads of tools for disambiguating these concepts in face to face or written interactions. Your post, Earl, is a demonstration of one of these ways - somebody reading might easily gain a better understanding of how Drupal works. But ultimately, it's not that difficult for humans to understand how 'post' and 'node' and 'content type' relate to one another. They're the same thing described from a different perspective (like 'coast', 'shore', and 'beach' or 'pig' and 'pork').

In conclusion, I would challenge the idea of 'the correct terminology' and 'giving the user wrong information' is actually what is happening. The users' understanding and use of given terminology is always going to evolve into something organic and the next generation of users will have to be introduced into it the same way that the current generation of users have to be introduced to the current terminology.

Just like you, I can think of examples where users have been confused by this or that and when I've had to explain node/post/content and taxonomy/category but that's just the way it has to be with humans. I'm not arguing for or against any specific changes in terminology - just trying to inject a bit of linguistic realism into any particular effort.

Reference: Lakoff, G. 1987. Women, Fire, and Dangerous Things: What Categories Reveal About the Mind.

Nice! That's a great response.

I would posit that the issue is, perhaps, less about technological purity and more about accepted definitions. I could look it up if you like, but in the issue where we renamed categories back to taxonomy, the real problem is that taxonomy has 3 technical terms and categories has 2, and mapping functionality to terminology usually meant using 1 term for two different functions, or using a compound term that made less sense.

Taxonomy has Vocabularies which contain Terms.

Categories has categories which contain tags. Except that tag and category already overlap a little, in part because category is actually a very generic term and its meaning is highly context dependent. Is the category the group of tags? i.e, I have the category 'color' and I assign the tag 'red' to a piece of content? Or am I putting my content into the 'red' category?

But beyond that, the fact that it's internally referred to as taxonomy, and in the documentation, and in the examples, and it's called 'taxonomy.module', that alone leads to a confusion because of the unresolved terminology.

A tag does actually map very nicely to a term.

I guess the point is less that you need terminological purity inasmuch as you need well defined, consistent terminology. If we had called the system categories in the beginning, and everything were consistently named, this would probably not be an issue. However, attempts to rename it properly would really require renaming taxonomy.module into categories.module, renaming database schema, and scrubbing words. And what would it gain us? I don't think it would gain us very much, because I really feel that people are overestimating how difficult it is to teach users unfamiliar terminology.

So categories are not taxonomies, because taxonomies are sets of vocabularies, where vocabularies are in turn sets of terms. Currently (in Drupal 6, that is), the taxonomy admin page does mention tags, but has no mention about how this whole taxonomy/vocabulary/term/tag thing maps to the category system that they feel familiar with.

What if we define term as either "category" or "tag", and therefore a vocabulary would be either a "set of categories" or a "set of tags", and the taxonomy admin page is where you can administer your tags and categories. If we manage to explain that terms are indeed the real categories, users won't be confusing vocabularies and taxonomies with categories.

That would, for example, imply to make the "Tags" checkbox in the "Add vocabulary" form an option element where the user can select between "Tags" (free-form terms) and "Categories" (predefined terms). Plus probably a set of other string changes, or maybe (though unlikely) even an artificial split in vocabulary naming between tag vocabularies and category vocabularies.

This is very well put. As in my reply to Gerard, I wouldn't be opposed to an attempt to rename taxonomy - if it meant a complete overhaul of everything about it so that it still had internal (and external) consistency. My main issue with node/content/post at the moment (for example) is we don't have any consistency with how these are used. Also note that the description for the taxonomy menu item has "tagging and categorisation" right there on the main admin page.

thanks Merlin

My personal pet peeve was when user avatars became 'pictures' - because "users wouldn't be familiar with the correct word". Grrrr.

By the way, does it seem strange to anyone else that only drug rehabilitation programmes and the computer industry uses the word 'user'?

...Is that user pictures were named 'avatars' because almost every piece of web forum/bulletin board software called users pictures 'avatars'. It was picked not because Dries wanted to sneak in the Hindi word for 'incarnation', but because web users were used to that word meaning 'the picture that represents you, to other users of the web site.'

That's the trick: 'usability' is about catering to users' expectations. Taking a complex topic and calling it something users are used to doesn't help if that thing isn't actually what they're used to, or what they're expecting. In the case of 'taxonomy' and 'categories', it might be useful to hide the taxonomy UI from some site-builders, and include a 'tags' module and a 'categories' module. Those would simply let admins control a single fixed list of categories to classify nodes, and a single free-tagging vocabulary to tag nodes. Both would be accurate, but simply calling 'Taxonomy' by either of those friendly names would simply set people up for confusion. That's what we discovered when we renamed 'Taxonomy' to 'Categories'.

The same can certainly apply to concepts like 'nodes'. But the answer is not to renamed 'node' to something people are used to -- it's to provide ways for people to skip over the idea of nodes entirely if they don't need to think about it.

For me, the issue boils down to the baggage that people bring (or don't bring) to their understanding of a term. Taxonomy is a strange term for folks that have never heard the word before. But scientists (particularly biologists) and librarians use taxonomies as a matter of course. That's why the librarians in the Minnesota user testing were so comfortable with taxonomy -- they have a background into what taxonomies are, what they are for, and what they can do. Had the system been called "categories", undoubtedly their understanding of its capabilities would have been limited -- or at least different.

The average user, however, doesn't know the term "taxonomy" and so they bring virtually no meaning to the term. For many people, this is scary, and they're reticent to use it just because they have no prior context. I have to admit that when I first was comparing CMSes and encountered Drupal's stiff terminology, I was in this group. I even discounted Drupal and took a long time to reconsider it because I percieved it as "too hard to use." This is where Drupal's documentation comes in, gently introducing terminology in easy to find places.

I don't buy the "Well, people had to learn what categories are anyway when they used another CMS" argument for precisely these reasons. I know what categories are because I've seen them used in other contexts, including on the web. So if something is named "categories", that's what I bring to it. Later, I may expand my learning and determine that the system is much more than what I initially understand. But unless I actually take the initiative to delve more into the capabilities of the system, I'm shackled by my own preconceptions.

One of my pet peeves is "book". Because I know what a book is. But Drupal's book is not a book like I know. I don't usually think of books as hierarchical, for example. (Sure, if I think about it some more, books do have a kind of hierarchy, but it's not a natural way to view a book.) Also, books aren't really collaborative: I can't submit a page to someone else's book. So my knowledge of what a book is actually becomes a barrier to understanding what Drupal's book is. I have to move past my own preconceptions and "relearn" what a book is.

This isn't the case with "permissions," for example. I know what permissions are, and it maps quite nicely to what Drupal permissions are. So my understanding becomes an aid rather than a hindrance. If they were named "approvals", for example, that would be a problem, because an approval brings in the concept of submitting an application for permission to do something, whereas Drupal's permissions are administrator-assigned. So permissions is a much better term.

As was said before, language is imperfect and rarely can we find the term that accurately and completely describes the system we're creating -- especially if it's something new and innovative. Still, an awareness of the typical meaning baggage that people bring when they are learning a system will go a long way toward helping them understand what it actually does.

Just to clarify one thing - the participants at Minnesota were library staff - some librarians, some not. The most important thing I took away from that experience was that only about half even reached the taxonomy task - because they'd got hung up on content, post, page, story, content type, create content, administer content before they had a chance to get there.

another suggestions for improvements

views => pagelist
drupal => blue head
Dries Buytaert => a guy from Europe (but create a link to the wikipedia article about Europe, if possible)

Blonde VS Hungary

If someone can't learn this basic drupal terminology, I would just say: don't use drupal, don't be a webmaster. (webmaster => internet repairman)

A fool with a tool is still a fool. If a user, after properly training, still can't grasp the terms taxonomy and node, then they probably will never be successful with Drupal whether taxonomy is called taxonomy or category, or whether node is called node or post. I therefore don't see any reason to dumb down the terminology and thereby treating all true users as fools.

But he concept of taxonomy and node (whatever they are called), definitely needs to be explain better. When I was new to Drupal, for more than three years ago, I too struggled to understand these concepts. In particularly, it took me a while to understand that the core doesn't actually use related terms and synonymous. That was not mentioned anywhere.

So therefore, I agree to 100 % with you Earl, we shall call things by their proper names, but make sure to explain the underlying concept better.

The orange-to-grapefruit analogy is a little unfair... because the words grapefruit and orange are known by everybody, because the 'objects' behind are known by everybody, because the difference of taste between these two fruits is known by everybody.

A more fair analogy would be:
You propose the fruit of the 'Citrus maxima' to somebody, and you say to him that it is an orange.
He tastes the fruit and understands that is not an orange, but the taste is close to a grapefruit, but not exactly.
You explain to him that you've used the word orange to be helpful and to not afraid him too much...
You explain to him too that an orange is the fruit of the 'Citrus sinensis' and that a grapefruit is the fruit of the 'Citrus paradisi', not 'maxima'.
The usual name of the Citrus maxima is 'pomelo', but in some countries pomelo is used to identify a grapefruit, so, to be more clear, everywhere in your system, you prefer to use the name 'fruit of the Citrus maxima'.

'Fruit of the Citrus maxima' is the right technical name, but people can 'catch' it; but they can understand pomelo or grapefruit, even if they are different fruits.

Today the documentation of the Taxonomy of Drupal is as an 'orange'; we need to document it as a 'pomelo'. So, on the documentation point I agree with Earl (Merlin), but I don't agree on on the 'what to' document; it's much better to say:
"We use the term Grapefruit but we explain to you that we use it as the fruit of a Citrus Maxima and here the details..."
than to say:
"Hey, come back, don't be afraid by 'fruit of Citrus Maxima' it's like a grapefruit, but not exactly, here the details...".

So for our 'Taxonomy' we need to found an 'usual' name like Grapefruit, even it's not 100% acurate on a technical point of view. If for some historical reasons, the word 'Taxonomy' must stay in the deep code, where is the real problem? Do we want to continue to ask the users to code into Drupal to be able to use it?

I don't like 'Taxonomy' (too much 'Citrus maxima'), I don't like Category (too much 'Orange'). What can be a third choice?
Classification? More generic, not perfect but surely less frightening...
Something else? I have not myself the answer.

For the 'node', it's less difficult: the term 'Content' is the most friendly (is not Drupal a CMS?).

if you call Citrus maxima as Grapefruit, you better explain that it is really just a simple Citrus maxima.

famous quote: "I was always very very confused by this multiple parent until I understood it being a simple directed acyclic graph."

There is a double edged sword here. On one hand it's good to lower the barrier to entry. Simpler words and phrases can do that with a language where we are trending towards weaker vocabularies over time. On the other hand, it hurts understanding because weaker descriptions don't really explain what's going on.

I'd prefer to keep the stronger terms, explain things better in drupal, and promote translations that translate the concepts to other languages so people around the world don't have to rely on their english vocabularies.

Yet, I have friends who have the expectation that they can pick up any tool and figure it out with little to know reading. With the words and concepts they know any tool should just work with relative easy and they are unhappy with any tool that doesn't.

The lesson I see is that we can't please all of the people all of the time. We just need to figure out the way to best serve the group we are trying to please.

I think the really important point here is to be diligent about providing explanations or terms right where the user needs them. This is the great innovation of advanced_help module which merlin has wrote. I do agree with him that a version of advanced help belongs in core.

Once we have a terrific context sensitive help system, we will feel more comfortable using unfamiliar but proper terminology.

At my previous company, we had a cms we developed inhouse and We had a similar feature for taxonomy that was called "Entities". Very user friendly! Anyway, I finally got them to change it to "Category Groups" and people seemed to get this concept a little more readily. Taxonomy is the right term, but I agree that it's not the most apparent. That being said, I do think merlin's popup help is a god send! Especially with some of the uber complex modules such as views and panels. It's hard with concepts being so abstract in a CMS, to make the labels for things proper, yet easy to understand to a new user.

This reminds me of the very first releases of Lotus Notes/Domino that included SMTP/POP3 support. Lotus, with its excellent usability track record (NOT!), decided not to use the familiar SMTP/POP3 terminology. Instead they invented all kinds of new words. The net result was that nobody understood how to configure this new functionality and very quickly it was known as "hard to configure".

What about providing a glossary in the default install that explains some of these terms? So maybe scattered throughout the admin pages there are definitions to terms as they come up, but wouldn't it be nice to have a central place that's just a click away to look up something later?

Maybe provide a hook so that contrib modules could easily define new terms that they introduce...

We actually removed the glossary in Drupal 6 (it's still there in Drupal 5) because it was at least two years out of date and no-one took on the task of updating it - in the end, it was removed rather than leave wrong information in the help system. You're one of several people who's mentioned putting one in without mentioning that there's already been one in core - which suggests that a lot of people never knew it existed.

Indeed. I had no idea that it existed, and I have about 15 sites running D5 right now...

Accurate terminology is good, all other is bad. But make sure the explanations are easy to find.

This is what I wat I wanted to comment on that blog post this one is an answer to, if it had allowed comments without registering. So I agree completely with you.

P.S.: the reason nodes are called "nodes", is AFAICT: nodes link to each other, like the nodes in a graph.

Inconsistent terminology leads to confusion and broken documentation. Changing the name of fundamental Drupal building blocks will only hurt the project.

I'm glad "categories" was changed back to "taxonomy". Consistency is a valuable commodity.

I wrote that "common complaint" mentioned above. I'm coming at this subject from a training perspective. I've spent a great deal of time teaching Drupal newbies what the terminology within Drupal represents. There are a couple of points being made in this thread all at once and I wanted break them apart and prioritize them.

  • Drupal's terminology is very meaningful to Drupal developers, but it is not necessarily meaningful end users and site admins. Nodes, fields, views and roles don't mean much to the new crop of blogging grandmothers that the Knight Foundation wants to foster through Drupal. This creates a longer learning curve for newbies, I've seen it with my own eyes.
  • Some of the chosen terminology does not accurately describe the concept. Categories is an example. It's been really difficult to teach aspects of Drupal when the terminology is plain wrong.
  • Some of Drupal's terminology is not consistently applied. While working on a recent screencast I found that the module listed as the "feed element mapper" on is listed as the "feed api mapper" when installed on your Drupal site. Again, very difficult to teach.

I'm glad we get to talk about this and I think there should be a rolling effort each release and heavily encouraged to contrib authors to rethink the terminology in each package before it goes to press. Having the most common terminology implemented accurately and consistently will contribute to a shorter learning curve and higher adoption rate for new Drupal users. And, honestly, anyone writing patches, code, and docs with thought given to training is going to get a sloppy kiss from me. Count on it.

A really important part of this is about the intended audience. Who is the intended audience. This is difficult for Drupal because it is made for and appeals to so many different types of people and uses. If there was a much narrower scope of people that Drupal was intended for the terminology would be much easier to be made appropriate to those users. If Drupal was dumbed down for the average user that would also make it much more obvious.

I'm not a fan of dumbed down applications or UIs but maybe that's because I'm a technical user. That's why I choose KDE over Gnome, Nikon over Canon, or Gentoo over Ubuntu. Either we need to a.) adjust the system to meet the needs of multiple audiences, b.) target the most common or average use, or c.) accept that Drupal is for technical people and leave it at that.

In operating systems I would argue that Windows and Ubuntu attempt the first, Mac OS X the second, and many other Linux distros the third. What does this mean for Drupal? If we want it to continue for it to be "by developers for developers" then the third option is best and this should be explained to the users. Mac OS X (and Apple in general) does a pretty amazing job of targeting the most common users and keeping everything simple for them while still maintaining a powerful system underneath that people can take advantage of. They wouldn't use terms like taxonomy or node. Finally, if the first option can be done tastefully then that is ideal.

A simple CMS for average Joe or non technical user would likely to use the terms categories and tags. A scientific or technical CMS would want to use the term taxonomy. In these cases maybe separate modules would make the most sense for the end user even though they are very similar.

If we asked the user during the install what type of user they are (basic/advanced, etc.) then the system could be setup automatically tailored to that users needs and pick between the modules and set them up appropriately. This can be extended to other areas of the system such as an advanced mode that determines what administration options to show by default, etc. This is common in a lot of applications.

As you mention above, consistency across modules, UI, help text, documentation, and is extremely important. The language should definitely stay true to it's function and intention. But there are two sides to it and two primary types of users, developers and your average, non technical end users. Most of the language that is an issue is the developer oriented terminology. The non technical users shouldn't need to see or learn about the more technical terms until they are ready or have a good reason to.

I'm all about educating the user but if they don't have a reason to learn or know a term such as taxonomy then they won't even read the help text, even if it is simple and in front of their face the whole time. Later down the road when they have a reason or desire to learn more they will do the necessary reading and learn what they want to know.

I agree with your conclusion and would add that there should be different approaches and end user experiences to the help text, documentation, UI and default modules for those two main different types of users (while still keeping the terminology consistent and correct.)

In this case it seems it would make the most sense for there to be a simple Categories module as part of core and a separate optional or contrib module for more advanced Taxonomy specific uses. That way you can have familiar, correct and consistent terminology and help text.

Regarding nodes it's not as easy. I think your proposed solution would thus require "content types" to be "node types." Even with additional help text that will likely throw off most people. To the average user "content types" with "page, blog, story, etc." are simple and straight forward. Maybe the solution is to not expose the average user to the term "node" until they are ready or have a reason to learn what it means and why it's important. That goes against what you are saying, but I have a hard time imagining them being called "node types" to the average end user.

My personal battle plans with with the Drupal project are all about accessibility for wide ranges of users, and I think you'll find lots of people on board with that. I come from a background of teaching average citizens to harness new technology for their own needs and open source projects help me and the people I serve get there.

I think obscuring terminology and concepts from end users will only fork audiences into upper and lower class users, and maintain a discrepancy of both skill and cost between people who need sites and people who build sites. I hope that "the Dries vision" comes true on a wide scale, that there will be no need for webmasters, web developers, web designers, and the people we know now as clients will be able to play all of these roles for themselves.

One of the on-going tasks to get there is keep even the words we use to describe Drupal and its concepts are as clear as possible to the greatest number of people. This puts a high premium on creating standards for benchmarking knowledge, on clarity in documentation, and on excellent training for users at any step in the Drupal knowledge ladder.


Kudos to you for your efforts around accessibility and empowerment.

I wouldn't agree with you however that it is that easy.


When I started with Drupal, it was difficult to understand the terms and structure. I wouldn't continue on by myself, but there were others telling me: this is great, go on and try to understand.
And that is the point: taxonomy and node are the core of drupal. You HAVE to understand them to see how powerful it is (when you do, you bet for drupal and start teaching others). And because they are so special and powerful, they NEED their own words. Great and different things need their own words, or would you call a PC "scaled down mainframe"?
Categories and posts are nothing special. In fact, when I start to teach someone about Drupal, I start teaching them how far taxonomies and nodes are from those two concepts. For me, what it is important is to make them see they are dealing with far better things.
It's great to explain things clearly, but we should avoid to have a treasure box, and keep it closed to say "hey, look, this box! it's cool, isn't it?"... I would feel like an idiot

I would say that there are easy remedies for these problems.

If people want a blog, then for gods sake just configure Drupal to present them with just the blogging related modules and options. Take the time to create a custom menu for your customer (no pun intended), change the names of stuff you think is confusing.

Or just give them Wordpress.

It might even be an idea for those feeling strongly about this to create a module/patch to just mass change all the strings.

I do agree with those saying that Drupal seems to like not being popular. Personally I never felt it was hard to use or get into, I loved it from the first install. I've observed others who have struggled with it. Usually it is because it can't blog out of the box. They expect Wordpress.

So, I tend to ask people what they want. If they want more than just blogging, I point them to Drupal, if they just want some pages on the net and/or news/blog, I point them to Wordpress.

I love Drupal, but I can't cope with people asking me how to do this or that after I've recommended something to them. Therefore I recommend the tool best suited for their level of experience and not least their goals.

This debate is so funny. I just spent 2 days trying to to get a module to work. I read all the documentation and tried installing it in the 3 different places the documents told me to put it. No, I'm not kidding.

And it's a function that should be part of the basic install.

I vote for making it user-friendly because I have a wicked headache.

I just wanted to circle back to this conversation! Follow up here, thanks!

Add new comment