Below are proposals to alter some of the Nomenclature of Drupal based on usability testing.
Views
Testing has shown that meaning of “views” is completely opaque to the new user and provides absolutely zero potential for unguided wayfinding. Also “views” conflicts with “view” in the context of content as well as “preview”. We are testing a change to “content lists”
Taxonomy
Testing has shown that users cannot understand what taxonomy is or why they would need it. We are testing a change to “categories”.
Modules
In response to people not understanding that modules are things you can download to extend your site’s functionality modules was changed to “extend” in D7. We think that this is still not clear to the user and that a verb in the IA is an antipattern so we are testing a change to “extensions”.
List...
The verb “list” appended to menu items has been applied inconsistently: Modules/list, Menu/list links, edit menu. “List” primarily serves to differentiate the list from the edit action as in the case of modules, list, update but the same differentiation can happen if the action item has a verb. . Further confusion is caused by the fact that “list” appears so often. All Drupal IA would benefit from the simplification of removing list wherever it appears in favor of just the noun. So instead of:
modules/list, people/list, list links, list themes..
we would simply have:
modules, people, links, themes
Regional and language
This is not grammatically correct. Test a change to “Region and language”.
Comments
while terms like views,
while terms like views, taxonomy & modules are well-established within the community, i feel the suggested alternatives are more intuitive and would work well.
one concern for changing those terms still would be having to align code - rename those modules for a solid experience. in this case i still prefer the short name views instead of content_lists
The only suggestion here I
The only suggestion here I would object to is changing "Views" to "Content lists". The latter totally does NOT capture what Views is all about. It makes more sense to entertain changing the nomenclature to Queries, since that is what they are. Yet I would not suggest that either.
I can live with an external relabeling of Taxonomy to Category (or Classification), although I do not believe it is necessary.
Not meaning to be a pest :)
Nomenclature - everyday language
If Drupal is ever meant to be understood by non-developers/sitebuilder ("layman"), it must use everyday language. For all projects, I rework the Drupal UI so that it makes sense to (non-tech) client users.
When considering nomenclature, think if there is an everyday word/phrase that is comparable.
While, for example, "query" is an everyday word for a programmer, how often have you used that word in conversation? ....er, outside ComicCon. :-D
A non-tech user -- content creators, editors, site admins -- cannot distinguish "View" content from other content they see. But, when explaining it, I call it "automatic" (or perhaps "dynamic") content. Saying that Drupal can display content in different ways on a page. That has a visual reference. "Dynamic" isn't a very often used word in conversational English to mean flexible, so that is iffy too.
So, something like "content display" is a bit more understandable, IMO.
Taxonomy: "Categories" is
Taxonomy: "Categories" is understandable, in plain "everyday" language. Also, both WordPress and Joomla* use this term. So, transitions well for migrators.
Modules: I think that "add on" (and perhaps "plug in") also is a good, commonly understood term. WordPess (?), Joomla, Firefox, etc. use this term for 'extensions'. However, at least Joomla and Firefox use several terms to mean something similar ("extensions", "plug ins", "add ons"). Please, let Drupal never go that route. ...Mobile device users certainly are familiar with the word "app" ("applications") as a term for an 'extension'. But, that isn't the best non-tech word.
Add-on vs. Extension vs. Plugin
Why not? I think Mozilla has done some good thinking on what those words mean. This StackOverflow response explains it pretty well, I think. I don't know how correct that answer is, but if it is, I think adopting similar terminology in Drupal could be helpful.
In Drupal 8, we already have the word "plug-in" in use, though not yet in any UI text that I'm aware of. Similar to what the word means in Firefox, in Drupal, it means something that is plugging in to a specific API. For example, "desaturate" is an image effect plugin, "Convert URLs to links" is a text filter plugin, etc. Module developers need to understand the plugin concept in order to add plugins to their modules. Site builders never add plugins (they only ever enable modules, which may include 0, 1, or many plugins), but they sometimes select plugins within a particular UI (for example, when configuring an image style, they select which image effect(s) to use). So far, we've kept that word hidden from the UI and I hope we continue to do so, to avoid confusion with CMSes that use that word to mean what "module" means in Drupal.
"Add-on" seems like a useful word to refer to anything that a site builder can download and install in their Drupal site: module, theme, translation, etc.
I think what FireFox calls "Extension" is very synonymous with what a module is in Drupal. So I'm interested in what the results of the usability test for that term is.
Keep Taxonomy!
I could get behind the rest of the changes (although Content Lists is kinda long to say), but keep Taxonomy. It really means something specific and it's correct.
How is Taxonomy more correct than Categories?
@kscheirer: Reading http://en.wikipedia.org/wiki/Taxonomy, I see a lot of information on taxonomy as it applies to biology, but most Drupal websites are not about biology. In the "Non-biological taxonomies" section, I see this:
In Drupal, vocabularies can be configured to be hierarchical or flat, closed or open, and can be organized scientifically or in a "folk" way. So, I don't quite get what meaning is left in "taxonomy" that doesn't exist in "categories" and that applies to Drupal. Can you enlighten me?
From
From http://www.drupalusability.org/
From the very first usability tests we've done this issue with the taxonomy label. Familiarity over correctness here.
I could be equally snarky about using the word nomenclature in the title of a topic about using simpler words ;-)
Thanks for the input
While I agree that taxonomy means something specific and is the "correct" terminology, verbal precision is not the primary objective in information architecture. The primary objective is immediate user comprehension because the goal is to get the largest number of users to the desired task as efficiently as possible.
A good real world example of sacrificing verbal precision in favor of broad user comprehension is the use of the word "flammable" on liquids that can catch fire. The precise term in english for that is "inflammable" (capable of being inflamed). The word "flammable" was invented to avoid the confusion created by the prefix "in" which might lead the user to think that the liquid could not catch fire.
I'm not suggesting we invent a new word, but the word category is a grade 6 vocabulary word and taxonomy is college level.
Views, Taxonomy & Modules
This is only my 2 cents worth and I'm a relative beginner in Drupal (but have made it my development platform of choice for the last 2+ years) although I am primarily a designer/conceptualist.
I would be interested in seeing how much exposure this thread gets in the larger community but if "The primary objective is immediate user comprehension" then there is a counter argument, at least mine, that we shouldn't change either Modules or Taxonomy terminology and perhaps not Views either.
My view on this stems from the desire for precision and comprehension of Drupal terms but not just in terms of immediate interface usability. Drupal is a uniquely powerful and flexible system and I thought I wasn't alone in describing Drupal as a "modular" system (hence liking the term module). However, as Drupal is also clearly extensible then "Extension" wouldn't be a bad second choice. Except that having an "extensible" architecture is not the same as having a "modular" architecture. Drupal is both highly extensible and modular and it is part of its unique proposition in the marketplace.
Changing Taxonomy to Category (or Categories or Categorise or Classification) is if anything a better example. Drupal's Taxonomy system goes a long way beyond the simple tagging/categorisation of content. Being fully fieldable in its own right and fully integrated into Views gives the Taxonomy module some serious content-generating abilities of its own that go a long way beyond merely categorising other content. Equally, users coming from other, simpler systems might (and usually do) find Drupal's taxonomy system highly confusing until they realise what it really does. Is this a fault of the name or the documentation? And therefore would a name change really help?
The words Taxonomy, Modules and Views are a lot shorter than their longer counter-parts which is a factor when you take into account the preference for shorter terms for the D8 move towards responsive/adaptive layouts (and admin system to go with it).
Finally, changing "Views" to something like "Content Lists" surely is plain wrong. Generating lists of content is such a ridiculous over-simplification of what Views really does that it's an insult to the authors. In fact Views is so integral to even the most average Drupal site that Views practically IS Drupal. The reality that new users have no idea what "Views" is also is NOT a reason on its own for changing the name. You would have to rename Drupal to "A Content Management System" using the same logic. Creating and arranging "views" of existing content is a very nice allegorical descriptor. "Displays" might be better common-word/laymans term for what Views actually does but it's hardly a one-word explanation and I suspect that finding a common word/term to explain "visual SQL building" will remain elusive. On another tact, with Views heading into core will we even need separate descriptor? I.E. How will the various functions that currently make up the Views module be integrated into the core user interface anyway? Under a single heading? Or distributed around the interface? And what will the core "modules" be called if not "modules". You can hardly call them "extensions". Clearly this isn't just a nomenclature issue but a UI issue?
Finally, a slightly defeatist (but pragmatic) concern over changing these Drupal-critical terms is the vast amount of existing user documentation, blog-content, forum-posts, etc, etc that have been accumulated over the last decade. Drupal's user documentation is perhaps the worst usability aspect and enemy of making Drupal a better, more user-friendly experience - so how are we anticipating updating Drupal's own documentation in this sense? Just out of curiousity that is.
Sorry if that sounded negative @tkoleary. It didn't meant to be but in summary I think that changing the Modules and Taxonomy terms isn't sufficiently advantageous to be worthwhile weighted against the user-documentation turmoil the change might make. However, changing Views to "Content Lists" is a complete non-starter. Something like "Displays" if not the more pragmatic "SQL Builder" may be worth sounding out but is it even necessary if Views functionality is being integrated into and distributed around Drupal core anyway?
Q
Is taxonomy really "more correct"?
I would argue that "categories" may actually be more accurate a term than "taxonomy." Generally, taxonomy implies hierarchical, mutually exclusive grouping of things based on shared characteristics. So cats and dogs are in different family groups (Felidae and Canidae), and both of those families are in the same order (Carnivora), but you would never have one organism which was simultaneously in two different orders, or two different families.
There are some taxonomies in Drupal which enforce this sort of hierarchy, but there are many more which do not. Free tagging, for instance, does not at all fit in the taxonomy concept as I understand it.
Categories, on the other hand, is a much looser term. It still implies groupings of things based on shared characteristics, but categories can overlap. They need not be hierarchical, or mutually exclusive. A single node can be labeled "dog," "furry," and "big" in the same vocabulary.
Given this, along with the simple fact that "category" is a far more intuitive word than "taxonomy", I would support the change.
Content Lists is an inadequate replacement to Views
I'm +1 to improving terminology in Drupal's UIs, +1 to collecting feedback via g.d.o., and +1 to usability testing our hypotheses, so thank you for starting this thread.
I'm tentatively +1 for Categories and Extensions, and I left some responses above related to that.
But I agree with others here that Content Lists is not a correct replacement for Views, because:
Yes. In the UI, there needs to be a link to take you to the page that shows you your list of (what we now call) Views. That link needs a label. Currently, that label is "Views". The proposal of this thread is to change it to something else.
I agree
It is insufficient. Kendall Totten made that same comment the other day on our customer panel. Based on her interactions with many clients trying to explain what views is and what it does she hit on the idea of calling it "Smart lists" which she borrowed from Apple (smart playlists).
I think this is brilliant because it neatly encapsulates the core functionality of views, which is displaying a number of things based on a database query. The user may not know what a "query" is but the word "smart" in the software context is now commonly understood to mean "the system goes and finds the things for me".
Smart List still potentially problematic
I like Smart List more than Content List, but I think List is still misleading, because:
In the abstract, the word "list" can encompass both use cases, but I'm concerned that the people we're trying to optimize this for will not expect to accomplish either use case with the word "list".
Also, I'd like to point out that the word View is used by every database system to mean almost exactly what Drupal means by it (Drupal just adds the extra ability to configure how the results should be displayed (as a list, as a table, as a slideshow, etc.), whereas database systems generally don't concern themselves with presentation). Now, I appreciate the desire to make Drupal friendly to people who don't speak database language, but I think there's a strong segment of site builders and IT decision makers who do have experience with a database system or two, so let's make sure we consider the impact on those people too.
Better
Smart lists is better than content lists, no doubt. Clever way to convey how views works.
I'd still be somewhat concerned about the issue that views can, and often is, used as to create a "list of one." Using the word lists might not make that clear.
I'm not sure what word would be better to use, though. Smart displays, for example, sounds like a fancy TV set at first glance. Smart... views?
;)
List of one
That use case will go away when blocks and pages also have conditions and contexts as is planned by scotch team.
Hi, I'm new to this thread..
But I absolutely agree that ditching Taxonomy in favor of Categories would be a huge Good Thing for usability.
It boggles my mind in hindsight how long I avoided anything to do with Taxonomy just because I didn't really know what it was for. The word "Categories" makes it a lot more clear for those new to Drupal, IMHO.
John
Re Taxonomy
I agree that Taxonomy is a term that confuses. At the same time, it is the correct term to use for what it is/does. I suggest that in the description of Taxonomy, a link could be provided to the Drupal documentation page on Taxonomy, http://drupal.org/documentation/modules/taxonomy , so that the proper term could be used, and people could learn about how it works in Drupal.
Best, Marilyn
I think others above have covered...
...the fact that taxonomy is not, in fact, more precise label. So let me just comment on the idea of a link.
Imagine you are on your way to an important meeting and you are driving down a road and you come to a four way intersection with a sign that says "flop". Under the word "flop" it says "to learn more about the flop sign, and how it should be used turn left here and go 100 yards to the flop informational sign".
See what I mean?
Despite my personal fondness
Despite my personal fondness for Taxonomy, dictionaries treat it as a more-specific term than what is being recommended here. For example, the American Heritage Dictionary's entry is:
tax·on·o·my (tăk-sŏnə-mē)
n. pl. tax·on·o·mies
1. The classification and naming of organisms in an ordered system that is intended to indicate natural relationships, especially evolutionary relationships.
2. The science, laws, or principles of classification.
3. An ordered arrangement of groups or categories: a taxonomy of literary genres.
This makes it clear that only certain groupings/categorizations/classifications are actually taxonomies.
The current combination of Taxonomy and Vocabularies is far less straightforward, understandable, and general than the recommendation for Categories and Category.
Not disagreeing at all Bob as
Not disagreeing at all Bob as the same dictionary's definition of the meaning of 'category/categories' is equally applicable but neither of the two sets of definitions explain what the Taxonomy module (by any other name) really does over and beyond 'categorising' content.
cat·e·go·ry (kătĭ-gôr′ē)
Share: cat·e·go·ry
n. pl. cat·e·go·ries
1. A specifically defined division in a system of classification; a class.
2. A general class of ideas, terms, or things that mark divisions or coordinations within a conceptual scheme, especially:
a. Aristotle's modes of objective being, such as quality, quantity, or relation, that are inherent in everything.
b. Kant's modes of subjective understanding, such as singularity, universality, or particularity, that organize perceptions into knowledge.
c. A basic logical type of philosophical conception in post-Kantian philosophy.
3. Linguistics
a. A property or structural unit of a language, such as a part of speech or a type of phrase.
b. A specific grammatical defining property of a linguistic unit or class, such as number or gender in the noun and tense or voice in the verb.
4. Mathematics A class of objects, together with a class of morphisms between those objects, and an associative composition rule for those morphisms. Categories are used to study a wide variety of mathematical constructions in a similar way.
On the one hand 'Category/categories' is a much more self-evident label than Taxonomies but on the other, taxonomy suggests more thought and effort has gone into the grouping and relationship aspects of the work involved.
If I had three hand I would probably have to concede you guys are right. "Taxonomy" has too much biological resonance in it and not enough "web tech".
Q
Taxing words
I think categories is a fine word to use compared to taxonomies. Taxonomies makes sense for hierarchical, highly-ordered categories, but that's not how all vocabularies are set up. So taxonomies are actually a subset of the broader types of categories. More common word, more easily understood, good way to go.
Categories has a very specific meaning in Joomla, so categories may be a more difficult term for people migrating from Joomla. I'd make sure to point that out if you have any documentation for Joomla migrations.
Extensions seems like an ok word to replace modules. It's a longer word, though. I'm not sure why extensions would work better than extend, since it's a longer, more complicated word. I would hope that extensions will be given similar usability testing as was done for extend.
I also agree that Content Lists is a bad replacement for Views. That just doesn't fully describe what Views does.
Another thing to keep in mind that Jared Spool talks about a lot with usability. You have to be careful with any redesign. You're not just making this easier for new users. By changing labels, you're also potentially making things harder for existing users. Yes, it would be great if the number of new users far exceeds our existing user base because we make it so easy. Just remember that in the short term, there is a very real cost for changing labels for people who are experienced with Drupal.
Categories and extensions is a pretty easy leap for people to make. But I'd be careful with Views. It's so key for almost all Drupal sites, and choosing an imprecise label could cause big problems for people.
"Smart lists" is the best
"Smart lists" is the best replacement of Views I've heard so far. It's not perfect, but it's probably a step in the right direction. And the "list of one" issue doesn't seem like a problem to me. The fact views are often not displayed in list form is a bit more troubling.
A view is a view is a view
The fact of the matter is that the Views ecosystem provides "views" of data. That is why the DB community long ago settled on use of the term.
A view may be a list. It may be empty. It may return just one row of data.
Moreover, views are dynamic, which is a key to Drupal's core value proposition. The data a view returns changes along with changes in the data it is dependent on.
Also, there are many uses of Views, from production of simple "listings" of content to development of powerful search forms to being the basis for bulk operations to being used to export data to the of powering feeds, and so on.
I believe that adoption of any other term simply obfuscates what Views is and what it does. And nobody who wants to use Views can do so without an investment of time and effort to explore and learn its mechanisms -- side-by-side with learning Fields/CCK. That is central to the Drupal learning curve.
To characterize Views as simply a "lists" mechanism strikes me as a grand folly and a disservice to the community.
Views already insulates the user from Drupal's data API and from SQL queries and joins and so on.
It is not a "listing" mechanism. It is how content is selected and presented for VIEWING by end users, and for other purposes.