Problem

Usability test participants did not understand what is a module. They had pre-conceived notions of what a module is e.g. it is a small piece of content.

Before:
The text in the tooltip doesn't help either.

Renaming Modules to something that maps closer to user expectations ("Features"?) is off the table for now for it's far-reaching implications (clashing contrib modules, invalidating docs, maintain consistency across core terminology)

Proposed resolution

Changing the tooltip for the 'Modules' link in the toolbar to "Extend site functionality" as a first step to communicate what Modules are in the Drupal context

To do

Decide on where to hash out what to do next about this. In #1164760: [meta] New users universally did NOT understand that you can extend Drupal or continue in here after initial commit of this or in follow-ups.

UI changes

None besides rewording an existing title attribute.

original report:

There are two approaches to solve this:
1. HARD FIX: To conduct a terminology review and understand what users actually call "Modules" as ... what syncs with them?
2. EASY FIX: Comparatively easier fix is to provide tooltip instructions on hover to "Modules" like "Extend your Drupal functionality" followed by a clear description of a module is on the modules page.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

dcrocks’s picture

Isn't this the same as http://drupal.org/node/1164760

dcmistry’s picture

Somewhat, this is more about the fact that the terminology is an issue.

yoroy’s picture

Version: 7.0 » 8.x-dev

Moving to D8

Crell’s picture

Given that renaming "module" to "what users expect to call these things" (option 1) would mean rewriting, um, 2/3 of Drupal and every single line of documentation ever written, I think this is an area where improved documentation and education (option 2) wins. There are enough "change everything" initiatives already in progress. :-)

webchick’s picture

Yeah, I don't think we can do much to change the name of modules. And unlike other terminology that was problematic, this one at least makes some kind of sense in regular english ("modular" system, etc.)

But this is pretty stupid:

Mouseover on 'Modules' in the toolbar gets you a description that you can 'Enable or disable modules'

webchick’s picture

So apart from improving the tooltip, another option might be to make that word more indicative of what it does ("Extend" or similar).

But I feel like we've had this discussion before as part of the D7UX stuff, and it was determined that existing users really seek out that specific word.

catch’s picture

I would bet money that the people with pre-conceived notions that a module is a block, had used Wordpress before:

http://en.support.wordpress.com/modules/

If that's the case this feels like something that's restricted to people changing from one platform to another, lots of people have used Wordpress, but lots of people haven't too. If anything that suggests a handbook page for people transitioning from Wordpress to Drupal - like a phrasebook or something.

If many other projects are also using module to mean block, or if it tested really badly with people who never used a CMS or blog system before, then it's more of an issue, but even then I'd agree with Crell and webchick.

Also, http://www.google.com/search?&q=module

janusman’s picture

I bet this has been pitched before, but I'd much prefer to pick a word that better contains/embodies the idea of extending/functionality/features/etc. Like, uhm, "extensions", "plugins", "applets", "addons" and perhaps other words that are more familiar with the target audience.

(Perhaps we could ask the Mozilla guys what drove them to rename "Extensions" as "Add-ons" on Firefox).

joachim’s picture

+1 to option 2 -- better tooltip + some help text on the actual module admin page.

> I would bet money that the people with pre-conceived notions that a module is a block, had used Wordpress before.

Me too. And it's WP that's using the silly terminology.

dcrocks’s picture

And why not 2 categories or even just tags, such as the very popular 'apps' for modules that present content or 'do something', eg., a 'blog', and 'extensions' for modules that extend drupal's behavior or capabilities, eg., themer's tools. It seems it would help people find what they are looking for much more easily. Underneath they could all still be 'modules', drupal would just be making it easier for new users to find out drupal's capabilities. You might just need a new/redesigned form. And you could use 'Add-ons' for the top level selector.

didlix’s picture

> such as the very popular 'apps' for modules that present content or 'do something', eg., a 'blog', and 'extensions' for modules that extend drupal's behavior or capabilities

You mean like http://drupal.org/project/features ?

I don't think naming a feature an "app" makes sense. An "app" is what drupal is, something that extends drupal is not an app, it is an extension / plugin / module / feature / add-on.

In my opinion:

A module is something that provides or changes functionality.
A feature is a blog, which would be a collection of modules.
An app is a collection of features bundled into a separate package, for example Open Atrium.

webchick’s picture

I don't think adding more obscure terminology is the way to fix this problem, personally.

catch’s picture

I think there would be some value to deciding on a term, or consistent way to refer to things like modules, themes, install profiles, swappable includes, theme engines etc. - they aren't 'projects' because that's how they're organised, they aren't "download and extend" because those are verbs rather than nouns.

However that is not going to help people understand what modules are necessarily even then, even if we were able to come up with an overall term that people are happy with.

This is probably in the raw data on the UMN post, but did everyone have trouble knowing what a module was, or was it just the people who confused them with blocks?

dcrocks’s picture

I thought the real issue was that users didn't know how to extend drupal, not that they didn't have the proper technical concept of what a module is. I don't think they care. What should be provided is a 'presentation' of facilities available in drupal using terminology likely to be understood by both users new to cms's and/or new to drupal. If the term 'module' gets in the way, then find an acceptable terminology and map it on top of 'modules' and get on with it.

Crell’s picture

catch: I tend to use "package" for modules/themes/libraries, but that's not universal.

dcrocks: Be careful with that approach. That's how we ended up with the Category/Taxonomy confusion for years. :-)

Either way, I think we need to move having an in-system "downloadable thingie" GUI to a must-have for D8. The D7 support is nice, but really, if you know enough to be able to use it then you know enough to NOT use it and use Drush instead anyway. We need a *good* in-system downloadable thingie browser.

dcmistry’s picture

+1 for downloadable thingie :)

I am thinking may be do a terminology review for "modules". A terminology review is where people are given a description of what a particular thing does and then ask them how would they name it. Thoughts? Of course, for this we need to have a number of participants (around 25?)

webchick’s picture

This is probably in the raw data on the UMN post, but did everyone have trouble knowing what a module was, or was it just the people who confused them with blocks?

This is a great question.

The precise scenario participants were given was this:

"Your client is ready to create a registration form, but as the administrator you need to add this functionality to the site first. Add a “webform” to the conference website."

Note that we specifically don't say the word 'module' here because then that gives them a keyword to hunt for and it ruins the purity of the test. (I actually am a little concerned we didn't get a "pure" test of content creation because 'About Us' is mentioned in the description of Basic page, but that's another topic altogether.) Instead we use a similar word ("functionality") to try and clue them in to what they might need to do.

Most participants didn't get the connection that you'd have to add something to Drupal in order to do something as basic as add a registration form to the site; it was assumed by everyone that this would be included out of the box. (This by itself is interesting.) So they began by hunting around the structure and configuration menus, among other places, looking for something that said "webform".

I'm pretty sure everybody except for maybe one person had to call the help desk at this point to get a hint and be directed to the modules page. Before that, though, Nick (the facilitator) went in to ask them questions like, "What do you think this link [referring to the 'modules' link] does?"

The responses were mostly variation of either "hahaha, I have no idea what that is" or "Hm. Maybe it lets you add little boxes on the sidebars?" Not a single person got the connection that "modules" == "the place where you add more features to your website." And if people did end up there, it was only by process of elimination.

joachim’s picture

> "Your client is ready to create a registration form, but as the administrator you need to add this functionality to the site first. Add a “webform” to the conference website."

What knowledge of Drupal did they have prior to being asked to do this? Because if they had none at all, I don't see how on earth they could be expected to figure out they can extend Drupal, unless it was shouted from every single page.

webchick’s picture

All but one participant had no prior knowledge of Drupal, but most had knowledge of other platforms like WordPress that have a similar "add stuff to it" mechanism. And yes, the fact that they couldn't figure out you can extend Drupal from just purely looking around it is the entire point of this issue. This problem applies to pretty much anyone installing Drupal from "non-traditional" methods: hosting company 1-click installer, Acquia stack installer, an IT person installed it for you, etc.

It'd be nice if we could focus on solutions here, rather than critiquing testing methods and other unrelated things. The data exists. Now, let's do something about it.

Crell’s picture

Understanding the testing method is important for determining the appropriate solution. A test that assumed prior knowledge X is no good if we want to solve the situation for use case Y, and if we want to solve use case X we need to understand what X is. In this case, the assumption of the test is that the user has *not* been to Drupal.org before and seen the 15 places we link to "and download more cool stuff here!" That's important to know before we try to come up with a solution to "wait, you can download cool stuff?"

joachim’s picture

The thing is, if you sat me down for a usability test, and gave me the Acquia stack installer, and said to me 'Do X with this', *I would not think to go to drupal.org to download modules*, because I would have assumed that the boundaries of the test were the things I had been given.

webchick’s picture

Sure. I guess I felt that was already covered in the "Who did we test, and how did we test them?" part of the report that specifically said that these participants had no experience with Drupal. Guess I was wrong. :) Does #17/#19 help to communicate the target audience of this fix?

webchick’s picture

joachim: Right. The fact that they didn't know to add a new module once they finally arrived at the modules page is covered at #1164760: [meta] New users universally did NOT understand that you can extend Drupal.

This issue though is more around the fact that there is a place in Drupal core where you can manage your add-ons/extensions/whatever you want to call it, and people a) did not know "Modules" was that place, b) didn't even click "Modules" in most cases other than by process of elimination, because the term was obscure and they were given no direction. Core does absolutely nothing to orient new users about what modules are (the front page just talks about adding content), and they're pretty much the central concept.

anarcat’s picture

You know, I have barely been following this "plugin" thing for Drupal 8, but this strikes me as something that could clarify this whole thing.

People *know* what plugins are. They have firefox plugins, wordpress plugins... I will probably get shot here for saying this out loud, but why don't we just jump in the bandwagon and rename "modules" to "plugins"?

Since we seem to be rearchitecturing modules in D8, why not make the backend consistent with the frontend and be obvious about it? Creating distance between the implementation and the user is often a bad idea...

As a footnote, I notice that "plugin" may be the term *I* am most familiar with, and it may not be that ubiquitous. As an example, chrome has "extensions" and "apps" (which is confusing, btw), Firefox actually switched to "addons" (which also include themes).

(Now I just know that I will keep on receiving emails on this issue until the end of time, but I wanted to make that point, since nobody else did so far. ;)

dcrocks’s picture

Weren't people in this study ever introduced to the 'help' button on the tool bar? Couldn't it say 'in Drupal, modules are used to extend Drupal'? Doesn't it take them to drupal's modules page? The themes page? Couldn't there be 'how to find what you need' here? All this heavy breathing about terminology should be spent on a better 'help' system. A few good sentences, some good paragraphs to back it up, and a more prominent help button may be all that is needed here.
Learning is evolutionary, but the comments on the study all seem to say that the subjects didn't have a starting place, rather they would fumble around. To me, that should be the red flag.

ps. The last thing the install system should say 'visit your new site and CLICK ON 'HELP' FIRST'.

ps. ps. The first, and only the first, time a brand new site is visited a message should say, in bold, 'CLICK ON HELP TO START'.

dcrocks’s picture

I just noticed that 'help' is only available on the bottom of the 'management' menu, or the tool bar, and not viewable by non-admin users. So by default, it doesn't seem like drupal wants 'help' to be very visible, and there is no basic help available for non-admin users. Might that contribute to the notion drupal is hard to use?

webchick’s picture

Turning to help is a last resort. A couple of people did eventually, begrudgingly, end up at the help link (it's a top-level link on the toolbar), and the blurb there did bring one of them to the modules page. But this was after 10+ minutes of hunting.

We don't want peoples' first impression of Drupal to be "Go RTFM." What we want is for this important feature to be discoverable and obvious, since it's at the core of what makes Drupal amazing.

Crell’s picture

Somewhat side note to anarcat: As I noted above, renaming "module" to "anything else" is a non-starter, as that would break about 300,000 pages of documentation on d.o... and that's just the start. Also, "plugin" at least in the Drupal world already means something very different than what modules mean. We're trying to get plugins (a la Views plugins or ctools plugins) into core... NOT rename or redesign modules as "plugins". Very very (very (VERY)) different thing.

Every project has its own lingo, and English has only about 8 words that all mean kinda sorta the same thing. The solution isn't to guess which possible set of definitions users may expect; that's a losing battle even if it were technically feasible. The solution is to make learning and internalizing the Drupal definitions easier than it is now.

IMO, the question of "what do we rename the Modules toolbar link to" should be "some verb, as that implies action, and the verb should be decided on by trained UX people, not engineers." As long as that verb doesn't require us to rename 2/3 of Drupal to fit it, I care less what that word actually is. (My knee-jerk response is "Extend", but I am not invested in it.)

catch’s picture

Title: Users do not understand what "Modules" are » Core does not make it obvious that it can be extended by contrib

So the issue appears to be that if you install Drupal, and you're either offline (which people in a usability test often behave as if they are from the two I watched) or don't go hunting around on google, then it's not obvious that you can actually add modules and themes to it to get new stuff.

I'm not surprised people from Wordpress didn't realise this quickly even outside of the module/block confusion - since a lot of Wordpress sites probably don't actually have contrib plugins enabled, back in 2004/5 when I tried OSCommerce, 3rd party extensions told you which lines of code to edit and what to put there PHPBB too for some. I'm sure there are still some projects where they are mostly all-in-one and contrib has a much further back seat.

Re-titling this one.

didlix’s picture

I have spoken to a friend at Mozilla who is going to ask the add-ons team for me. No promises that I will actually get an answer back.

didlix’s picture

I have spoken to a friend at Mozilla who is going to ask the add-ons team for me. No promises that I will actually get an answer back.

Ralt’s picture

As webchick stated, the frontpage only shows an "Add content" link. I think that adding a big message "Extend Drupal with modules!" on the frontpage upon installation (or at the end of drupal's installation) would be a huge step forward. People would think "Ah! I can add plugins/extensions/stuff called modules in Drupal".

Changing the term "module" would be a huge mess IMHO, and is not so necessary if what "module" means is clearly indicated.

joachim’s picture

> I think that adding a big message "Extend Drupal with modules!" on the frontpage upon installation (or at the end of drupal's installation) would be a huge step forward

Lol... like it used to, you mean? ;)
But yes.

catch’s picture

In the first UMN usability testing, we had that link, and someone went almost immediately off-path to Drupal.org and got very lost. Anything like that needs an in-core project browser or we risk going too far in the other direction.

yoroy’s picture

Right. Solving this issue is about guidance towards whatever in-core module browser we come up with and surrounding the 'Modules' label with all the other applicable trigger words in the user interface text.

Ralt’s picture

The "Extend Drupal with modules" sentence could lead to the modules' page. But indeed, the browser module should be improved so that people understand the way it's working faster. I'll come back after thinking a little about it! :-)

Ralt’s picture

Hi, coming back after playing a little around with Balsamiq Mockups.

I first made a mockup of the existing layout.

Then, I thought about some little stuff to change.

Here are the changes :

  • Changed to checkbox to links "Enable/Disable". I think this is a lot more intuitive.
  • Added a "Search" tab. With this, I also changed the first sentence to redirect to this search page.
  • Finally, I made a mockup of what a search page could be. Of course, this is a big feature to add. It'd fetch the results from Drupal.org and would allow some quick-install workflow for modules.

I maintain my suggestion from earlier to have a big message "Extend Drupal..." linking to the modules' page. With this kind of modules' browser, people wouldn't get lost.

Also, so that people could re-use my work on Balsamiq Mockups, here are the BMML files : http://www.megaupload.com/?d=LKHUIZ2H".

P.S. : I also think that the documentation for beginners should be improved. There are some comments showing that it does not help at all. We should also see how to improve this, but this is another issue.

anarcat’s picture

Title: Core does not make it obvious that it can be extended by contrib » Users do not understand what "Modules" are

I think the mockup is a good start, but I stills seems a bit too cluttered. It floods the user with information about "updates" and "what is a module" and "oh you can also install new one, go get lost on Drupal.org". I would ditch the third line ("review available updates") completely (since we have that nasty yellow box on top anyways), and would try to make the whole thing more task-oriented. What do people want when they go on the module page, it's one out of three things that are possible right now:

1. Install new functionality
2. Update out of date functionality (or rather - turn off that scary warning)
3. Turn off functionality (probably quite rare)

To make matters worse, in Drupal, #1 is actually a two step process (disable/uninstall), but the second step (uninstall) is the one that is the most obvious: on top right, "oh! I found the uninstall link" *click* "hey, there's nothing here, wtf?".

I think any reshuffling of the modules page would need to focus on those three tasks and make them easy and intuitive. If we need to force people down into a two step process (enable/disable install/uninstall), then that should also be made obvious through the UI.

But I believe this is also offtopic for this issue, as there are other issues to redesign the modules page (see #538904: D8UX: Redesign Modules Page for an example).

I believe we should limit the discussion here to vocabulary. I think that the solution here should be a simple rename of the "modules" menu to "something else". Point taken for plugins. I still find the concept utterly confusing, but that's also offtopic here.

So far, the best solution I found was to call the menu "Extensions" (or "addons") as the other menus are nouns right now (as opposed to "actions" like "Configure", we have "topics" like "Configuration")... The problem we get in then is that people click on "extensions" but land on a page talking about "modules" - "what the heck is a module", back to square one.

The way Firefox resolved this is to /hide/ the "plugin" concept behind a more familiar "addon" nomenclature, which also includes themes. Maybe (as it is on Drupal.org) the "Extension" menu could include themes, translations *and* modules...? That would be a a major rearchitecture of the modules page, but it would be way more intuitive for users. Now, I'm not saying we should be customizing the appearance here necessarily - theme customization can be somewhere else (as is module configuration...) But where you *get* those things should be in the same place, because it effectively is ("you go on the internet! you can also upload your own stuff here!").

Regarding the title of the issue, I brought it back to the narrower focus of the nomenclature of "Modules", as there is another (meta) issue regarding the more general issue, see #1164760: [meta] New users universally did NOT understand that you can extend Drupal for that.

In summary, we can go in a lot of directions, but I think we should narrow down the issue here. For me, the question here is:

* do we present the concept of modules to users at all?
* if we do, at what point do we do this? (top level menus, contextual help, help on drupal.org, etc)

The solution I support is the following steps:

1. rename the "modules" to "extensions"
2. make themes available in the "extensions" page, and introduce modules there too
3. make the "extensions" page task-based (install/enable/update/disable/uninstall), with listing of relevant extensions in the relevant task tabs (themes need updates too!) (this should probably be taken into #538904: D8UX: Redesign Modules Page)
4. bridge the modules page with the drupal.org download/extend search pages (no issue for that, but this would fix #1164734: Upon entering drupal.org, user's website was lost without easy return.) - I would make that the landing page, actually

I think the scope of this issue is #1 and #2, and that problems with the Modules page UX and integration with d.o should be in separate issues.

Sorry for the long post.

webchick’s picture

Title: Users do not understand what "Modules" are » New users do not know to click on 'Modules' to extend their site

Hi, Ralt, did you mean these mockups for #1164760: [meta] New users universally did NOT understand that you can extend Drupal?

Partly re-titling this back. There are two issues here. This one is the problem of even finding the modules page, and the other is realizing all the things you can do with modules once you get there.

webchick’s picture

The reason I think we're kind of stuck with the word "Modules" is because of:

- 11 years of historical attachment to the term among Drupal users
- The PHP files are called ".module"
- The download section on Drupal.org is called "Modules" (and couldn't be retired until Drupal 10 at the earliest)
- Hundreds of thousands of pages of documentation needing to be updated to call these "Modules (or Snarfblatz, as they're known in Drupal 8+)"
- Millions more of forum topics/mailing list e-mails/blog posts/books/etc. that cannot be updated referring to them as "Modules"

If there were some super obvious term that was favoured by new users and old alike in a large-scale terminology review, like Dharmesh suggested in #16, I might be able to be swayed that the trade-off were worth it. But I doubt it.

So in the meantime, I think we should more focus on the fact that some percentage of people are either going to have preconceived notions or no idea what a "Module" is. So how do we inform them that the feature exists and get them headed in the right direction?

dcrocks’s picture

@webchick All your comments about the test indicated the clients didn't know where to start. The magic of graphic interfaces is the ability to provide visual clues. It seems clear that the word 'modules' on a white on black menu bar jammed at the top of the screen doesn't provide a very good clue. Using other clues, maybe only a different word, is certainly necessary but it doesn't mean removing 'module' from everyday drupal terminology. Firefox's "add-ons'->"Get Add-ons"->"extensions"->"appearance"->"plugins" could certainly be "Add-ons"->"Get Add-ons"->"Appearance"->"Modules" for Drupal. Wouldn't it be 'amazing' if drupal's 'Get Add-ons' page looked like Firefox's?

webchick’s picture

Another way of illustrating this problem is with a question:

Which link would you click on in order to add functionality to your site?

)

webchick’s picture

janusman’s picture

I thought we minimized (removed?) the use of the term "node" in the D7 UI, and we didn't have to change zillions of pages in D.O documentation.

#42: @webchick: I agree. We're at step one: we need to add findability/scent to the "Sproingles" (or whatever that would be renamed to) toolbar and other parts of the admin UI to GET users to notice and then hopefully hover or click on that.

IMO this issue is just about how to best marry a *user task* with a *link* showing up among different *places* on the UI that takes us to the place to do that task (and the place we've mostly discussed until now is the toolbar). So IMO we should clear up what the *task* is, and what the best *link* and *places* for that would be.

From the already-mentioned ideas, I would propose to:
1) Discuss the actual tasks related to this issue: will we tackle only modules? Only switch on/off, or also hunting for them/updating them?
2) Discuss renaming the toolbar term "modules" into something with more "scent"; the toolbar will be the most often-looked-at place, hence, VERY important.
3) Discuss providing calls to action to "extend drupal" (or similar) in more places. Examples could be: after/during initial installation, on the dashboard.

Followup issues could be:
- Discuss any needed modifications to D.O.
- Discuss improvement of within-Drupal browsing of available module/theme/etc.
- etc =)

Now, apologies for throwing out this question since we probably don't have data on this: has anyone thought that it *might* get confusing if, say, users can't tell how disabling/enabling a module is different from: Features, Views, Languages, etc?

yoroy’s picture

janusman: I don't think we're renaming yet. And you are right, this is about connecting the dots with certain links for certain tasks on certain pages. It's something we need to get better at, helping people work through multiple screens to get things done. Involves many bits of micro copy-writing here and there. Is that something you could help with?

From your list of three, we should probably focus on 1. Within that, focus on making modules findable and make the concept of what they do clear. Lets get a feel for how we do this interpage tasklinking for modules, then learn from it and start applying the good bits elsewhere in core too.

Your last question is indeed something we should test, not speculate on. ;-)

joachim’s picture

Off the top of my head suggestion:

- move 'modules' lower down (since its old place is gone, probably admin/config/system)
- in its place put an 'extend Drupal' item

I've grown to like having 'modules' top-level, but to be realistic it's a bit of a waste and there's a limit to how many top-level items we can have.

[edit]
One second thoughts, enabling modules that are currently in your filesystem counts as extending Drupal too.

So my modified suggestion is to move modules down below a new 'extend' item:

- Extend
-- Manage modules
-- Get new modules

Ralt’s picture

Hi,

My suggestions were a bit overboard, but originally came from this issue. When I mentioned the big message thingy, catch said this would get people lost on Drupal.org. So I proposed an interface not forcing people to get on Drupal.org, allowing them to stay on an easy to add module interface. But I agree, this is another issue. Though, I think the "get modules" part on this issue entirely depends on what the modules page for D8 will be.

Back to topic. Just to pick an example, "Theme" was changed to "Appearance" in the menu. Only this link has been changed, and "theme" remains. This should be the same for modules : give an easy name, and redirect towards the modules page.

I think #46 proposition doesn't change much the problem. "Oh, we can extend. Oh wait, these are just sidebar stuff."

We should rename the modules' links in the toolbar to a better name. Some names were proposed in this issue : add-ons and plugins seem the most relevant ones.

I'd choose add-ons, but this is just my feeling.

To sum it up, I'd rather have :

- Add-ons
-- Manage Add-ons
-- Get new Add-ons

And not changing any other name than these ones.

Jeff Burnz’s picture

@ yoroy: sounds like a task list:

  1. Focus on making modules findable.
  2. Make the concept of what they do clear.
  3. Find how we do this inter-page task-linking for modules.
  4. Apply the good bits elsewhere in core.

I'll start with 1. Make em findable:

My perspective on this (coming from work in the forums over the past years), is that users are forced to understand "modules" only after they hit a brick wall when trying to "do something" and are told about these things called "modules" and that they should download "Foo Module", or that they should enable the "Foobar module" since its part of "core".

The word "modules" does not speak to users with any clarity because its abstract and has multiple meanings, none of which users are highly familiar with. It can be a bit of a software system (Drupal notion), a section of a page (Joomla, WP notion), a part of a university course (academic notion), even describe the space a news story takes up on a page (typesetters notion).

In all these notions "modules" is a term "for something", not "how to do something". Users are looking how to do something (the "something" they are not able to do). From my perspective we need to focus on capturing this "wanting to do something", narrow in on that, find the terms that allow users to easily understand that they will "get something more if they click this".

Harking back to Crells much earlier comment, the word "Extend" seems fitting, with a descriptive tooltip "Extend your site with modules" or something to that effect.

dcmistry’s picture

Other potential idea, which could solve a bigger problem is to explore ways to orient the new users - like a super quick intro and by that I DON'T mean to re-direct to Help. One of the potential idea is a like one minute effective video?

Crell’s picture

Having super-short in-app help videos is a good idea, but I think we still need to improve the underlying system UX first so that such videos need to do less.

David_Rothstein’s picture

Status: Active » Needs review
FileSize
581 bytes

Let's start with the low-hanging fruit identified in the original post. It would be a shame to have this issue go on for 300 comments without doing that.

Attached patch renames the menu item description for "Modules" to something more sensible that actually describes what modules are. Although this clearly won't help all users, during the usability test we did observe a couple participants hovering over each item in the toolbar and reading the tooltips (at least we're pretty sure that's what they did; the screen capture software we had didn't actually display the tooltips on our monitors).

This patch would have helped those users.

Note: The new tootip in this patch doesn't explicitly say that you can disable modules in addition to enabling them (whereas the one it's replacing did); I think that's probably obvious enough not to have to mention, but if we really wanted to we could add "or disable features you are no longer using" at the end or something.

Status: Needs review » Needs work
Issue tags: -Usability, -UMN 2011

The last submitted patch, modules-1167458-51.patch, failed testing.

David_Rothstein’s picture

Status: Needs work » Needs review
Issue tags: +Usability, +UMN 2011

#51: modules-1167458-51.patch queued for re-testing.

jrabeemer’s picture

Regarding "Modules", I'm in favor of a UI change to "Add-ons", "Plugins" or "Extensions". Leave the code side alone (/modules,.module). Any of these terms would be a massive improvement over "modules" which IMO is vague, ambiguous and more inside-baseball Drupalish kind of way.

FYI, "Add-ons" is a catch all in Firefox to represent extensions, themes and plugins. FF has historically used the terms, extension (adblock, etc) and plugins (java, flash, etc). In their case, the term "Add-on" makes sense because it had no legacy meaning, and more broadly means, "anything that doesn't come out of the box".

webchick’s picture

Here's what I think we should do here.

I think we should review/commit David's patch since it's the simplest thing that could possibly work.

Then I think we should start a huge "meta" thread in the Usability group to discuss the terminology of "modules," gather additional data from user testing, as well as explore the technical challenges involved in changing the name. It might not even be possible. And I'd hate for this issue to be kept open in perpetuity for something that might not be possible.

If that discussion ends with something actionable, then we should reconvene in the issue queue, either here or somewhere else.

Crell’s picture

Status: Needs review » Reviewed & tested by the community

#51 is a no-brainer improvement, IMO.

I genuinely believe that renaming "modules" in code is a non-starter. We might as well try to change "node". :-) I do agree that the Usability group should look into changing or improving the language and documentation around "code bundles", however. (Since that's really all modules are; bundles of somewhat related code that you install together.)

yoroy’s picture

Status: Reviewed & tested by the community » Needs review
FileSize
574 bytes

I've removed a couple of instances of "your sites's" before, it's either implied or simply not true. :)

Still pretty long. Would "Extend site functionality" suffice?

catch’s picture

I like "Extend site functionality".

Also it's possible to enable new features without enabling new modules (node types, fields, blocks etc.) so best to keep things non-specific IMO.

yoroy’s picture

Patch for "Extend site functionality."

catch’s picture

Status: Needs review » Reviewed & tested by the community

Looks great.

Crell’s picture

I'm fine with #59 as well.

dcmistry’s picture

The slight problem with "Extend site functionality" is that it does not address the fact that it also disables, how do you feel about "Add or disable features"? I feel "features" is a more striking word which would catch users' attention. I realize this is very similar to what we have now "Enable or disable modules" but the problem word is "modules".

David_Rothstein’s picture

Status: Reviewed & tested by the community » Needs review

I agree we should aim for something more striking than "Extend site functionality". It should be fine to add a couple words here in order to give the sentence some personality, which is what I was trying to do with my original attempt. (After all, this text primarily appears as a tooltip; people who read it want to read an actual description, so cutting words to save space isn't as high of a priority here as it is in other places in the interface.)

"Features" was identified as a problem in #58 due to possible conflicts with other parts of Drupal core (not to mention the Features module). In my opinion, the key word here is "enable". So how about this:

Extend your site by enabling new functionality.

(As per above, "disable" is probably implied?)

I don't see why "your site" is a problem, by the way, or if it is then it's kind of a separate issue since we use it all sorts of other places in the UI already :)

yoroy’s picture

Extend your site by enabling new functionality.
or
Extend site functionality.

What more useful info regarding modules and what they can do for you is there in the former?
(there is no problem with 'your site' per sé, but what does it really add?)
re: Disable, do we really have to mention that if there's an 'On' switch, there's an 'Off' switch as well?

David_Rothstein’s picture

I think it's less about the specific usefulness of the info and more about the feel of the text. "Enabling new" provides some reinforcement (and encouragement): This is the page where you go to turn on cool new things for your site.

Either one is way better than what we currently have, though, so I'm not completely opposed to the shorter version... as long as we get this changed somehow :)

sven.lauer’s picture

I know I am late to the party, but ... one of these things is not like the others, one of these things just doesn't belong:

"Content", "Structure", "Appearance", "Modules"

Why not rename the "Modules" menu item to "Functionality"? Seems like a good "Topic"-style name about what modules are about, and with the right tool-tip (and module-page) might just be the right way to go.

It seems to me that "Appearance" is to "themes" as "Functionality" is to "modules".

David_Rothstein’s picture

Status: Needs review » Reviewed & tested by the community
FileSize
549 bytes

I'm going to go ahead and put this back to RTBC, since it's clearly better than what we have currently and it seems like we'd all like to move on and discuss bigger solutions anyway. So let's just get this in as is. (I am uploading a version with single quotes rather than double quotes, though, just to be pedantic :)

David_Rothstein’s picture

Moving forward, I really like @sven.lauer's idea of renaming the menu item to "Functionality".

It definitely does seem like the way "Appearance"+"themes" is currently used in the interface is a good model for how "Functionality"+"modules" could be used.

joachim’s picture

"Functionality" is a kinda geeky word. I'd prefer 'Features' if it weren't for there being a module called that already :/

jrabeemer’s picture

+1 #69 joachim's comment. Functionality vs features. Features is a geeky module, if not the geekiest. I'm ok with saying "Features" Dev geeks don't read tooltips, first time users do!

sven.lauer’s picture

Hm, firstly, I am not sure whether "functionality" is any more or less geeky then "features" in the current context. If you know already what modules are, you might start thinking of them as providing features to your site (though most don't), but we are thinking about people who don't know that yet.

And "I want my site to do something that it does not do currently. That is something that has to do with functionality." seems like a fairly natural thought to me (or "... that is something that has to do more with functionality then with content, appearance, or people"), while "... that is something that has to do with features" / "... that is something for which I have to enable a new feature." is not. In my opinion, "features" would be barely better than "modules".

yoroy’s picture

First time users are developers too! I too think 'Features' sounds simpler, better. But I just don't think we should start the big name-spacing discussion here. Renaming basic Drupal concepts has far reaching implications and we can't just start doing it somewhere and introduce new inconsistencies (one of the biggest core UX problems) in the admin UI texts.

This small change will very likely not be the full cure to the module/extensibility problem. We're fixing a title attribute for a link here as a first step towards making modules more discoverable. We'll need to do far more interesting work than fine-tuning individual title attributes to do that. Either as followups or a back to 'needs work' after committing this.

yoroy’s picture

Issue summary: View changes

First stab at summary, 70 comments in.

yoroy’s picture

My first issue summary in the original post ;)

sven.lauer’s picture

Oh, I am very much agreeing with David's #67, fixing the tooltip for now.

What I said in #71 was addressed more for the future---at the same time, what I am talking about is renaming the main menu item, nor anything deeper. As I said: Just as at some point, someone/the community thought it wise to put "themes" under "appearance", I think that it would be equally wise to put "modules" under "functionality".

Still, I think that, for right now, changing the tooltip is a good intermediate solution, so that is what should happen, and the rest perhaps belongs to a different issue.

Which is to say: +1 on the patch.

janusman’s picture

I'll toss this in: D.O calls a whole section "Download & Extend". In there are "modules", "themes", etc.

Not suggesting we should call the item in the admin bar that way, just mentioning it since I'd think there was some reasoning behind that decision.

We just want to give this link:

more "scent" so that we get more users saying "Oooh, this seems like a place where I can [add/change/manage/download/remove/etc] [functionality/extensions/features/plugins/etc]" vs. what we get now =)

yoroy’s picture

Janusman: it's not clear what you are suggesting. Do you have another suggestion for "Extend site functionality." (the current proposed change)?

Lars Toomre’s picture

I would prefer to use 'Extend site capabilities.' It less geekish in my mind.

NaheemSays’s picture

The page can also be used to turn off functionality, so how about a more neutral "manage" as opposed to "extend".

"Manage site functionality" or "Manage site capabilities" - the ending is not too important IMO as both work.

webchick’s picture

Can someone please start a g.d.o thread on the usability group to discuss renaming the label? This one's fixing a simple string on the tool-tip.

catch’s picture

Issue tags: +Needs backport to D7

As a one line change (in description text) we could consider backporting this to D7 depending on what happens with D7 string freeze discussions.

webchick’s picture

Status: Reviewed & tested by the community » Fixed
Issue tags: +String freeze

I'm going to go ahead and commit this to both. It's a string breakage for what is *technically* not a bug, but the string that's there right now is so utterly useless that it's pretty borderline buggy for me. The visibility of this string is also pretty hidden, and unlikely for most users to notice in case translation lag behind, so it seems safer than certain other strings.

Committed and pushed to 7.x and 8.x. Thanks.

David_Rothstein’s picture

Status: Fixed » Active

The issue summary here contains the following "todo":

Decide on where to hash out what to do next about this. In #1164760: [meta] New users universally did NOT understand that you can extend Drupal or continue in here after initial commit of this or in follow-ups.

My inclination is not to try to merge it with that meta-issue (that is big enough already). We could create a separate followup instead, but no one's done that yet and there is plenty of discussion here on the next steps, so I'm reopening it for now. (Someone can close it if they'd prefer to open a separate followup.)

I believe the proposal on the table for Drupal 8 is this:

  1. Rename the "Modules" menu item (and associated paths, etc) to either "Functionality" or "Features".
  2. Do not rename anything else; we'll still use the word "modules" in lots of places (just like we still use "themes" even though the menu item is called "Appearance").
catch’s picture

Priority: Major » Normal

Since the immediate patch has gone in I'm demoting this to normal priority.

anavarre’s picture

Subscribe

batsonjay’s picture

I just spent 4 days with 2 customers using 2 different proprietary CMS'. Both CMS' use the term "module" to refer to what Drupal calls a "block." One of these two CMS' is a fairly widespread commercial product in the media industry, while one was home-grown (but apparently took it's vocabulary from the commercial world.)

Thus, for a wide swath of potential new Drupal users, "module" means "area of related content". This divergence of the meaning slows Drupal adoption or learning.

I don't have a strong opinion about what the "solution" is; my intent is to make sure those involved in this discussion realize there's an existing world of future Drupal adopters who have an existing sense of what the word "module" means, which is different than what Drupal modules are. We're not likely to succeed in retraining an entire world of (non-technical) users; better to pick something that is similar to the capability other software provides - e.g. add-ons, plug-ins, ...

Bojhan’s picture

It is a immense legacy issue, changing a primary label of software after 10 years. We can do a lot by optimizing the page modules page and its tooltip. But I agree with batsonjay, that the final solution will be in the realm of actually changing the label to a more industry recognized pattern such as add-ons or plugins.

The "feature labeling" proposed by David makes sense, but has the side-effect that Drupal core will diverge from other places on the primary labeling. So I am not sure, we are not just trying to take a shortcut from the real discussion.

David_Rothstein’s picture

...proposed by David...

Just to clarify, that wasn't my idea :)

Todd Nienkerk’s picture

Both CMS' use the term "module" to refer to what Drupal calls a "block."

This is probably because a "module" refers to a "reuseable component" or "unit of space in a layout" in the larger design/UX industry. We run into this confusion regularly when working with a client's designers.

dcmistry’s picture

Just for argument sake let us assume that we rename "modules" to something else e.g. "add-ons". We will make it easier for the new users but we will have resistance from the community. Also, how does it work with previous versions? Modules is modules for versions before D8 and modules is add-ons for D8?

eigentor’s picture

Simple solution: Hack (ah sorry, patch :) ) a Drupal 7 version, rename Occurrencies of the word module to maybe "Plug-ins", test it on new users and experienced users alike.
Outcomes will tell.

gagarine’s picture

"It is a immense legacy issue, changing a primary label of software after 10 years."

I don't think so. Replacing one word by an other *in the UI* is not so complicated (say "modules" by "plugins" or "extension"). We already change "node" to content in the UI.

Crell’s picture

gagarine: And if you don't know that content == node, you're basically screwed the instant you go to contrib. Or look at the paths in the browser. That's even ignoring the DX fail when things have a different name in the UI than in code.

aaron’s picture

i can't wait to see d.o's handling of multiple versions wrt modules vs. add-ons. not that i'm against the idea; it's an interesting problem to solve.

jenlampton’s picture

Issue tags: +GoogleUX2012

We saw this in the 2012 Google UX study as well, so tagging. Here is just one example of a particpant struggling with the concept:
http://www.youtube.com/watch?feature=player_detailpage&v=Ho38XH3xGu4#t=1...

audster’s picture

I like just plain old "do more".

As an example, I have been building websites since 1997 but Drupal was my first foray into a CMS system.

It took me 3 days to figure out I needed a module to enable wysiwig.

3 days.

The problem was 4-fold:
1) I was too stunned by the fact that it wasn't included in the standard installation (I would NEVER have known too look for profiles or modules at this point) so it took a while for my deer-in-headlights reaction to wear off
2) It never occurred to me that such a commonplace function would require me to download and install something to get it going
3) When I did finally realize I had to add functionality I spent HOURS researching which module would be best in light of site requirements, user competence, file upload/browse server functionality etc etc etc
4) Since I was a complete and utter newbie (now I'm just an utter newbie) I didn't feel confident enough to poke around in a lot of the areas of Drupal and the word "Modules", while beloved by me now, was a link fraught with implications of "how to mangle your site before you've started".

I completely missed the whole "modules" thing until I saw it on forum posts (myriad) on trying to get WYSIWYG functionality. (and then felt far less stupid)

IMHO I can't help but think that some simple text like "do more with Drupal now" somewhere, anywhere obvious would have helped. And maybe that should break out into a list of common stuff that site builders are wanting to do like:

Text Editing
Uploading stuff
Get Social
Database Goings On

etc etc

All of which would end with lines like "there's probably a module for that!"

When it comes to newbies and the uninitiated you kinda have to think "lowest common denominator" - not in a form that assumes newbies are dumb, they're not (well mostly) but learning Drupal is a bit like getting dropped in a city with no map, no language skills and a deadline for getting to the train station.

eigentor’s picture

FileSize
42.68 KB

It has to be valued as to how important this missing information about how to extend Drupal is. If one says it is very important, it needs to be hightlighted.
I would go so far as to put a link into the shortcut bar and certainly on the modules page, that stand out quite a little. In the shortcut bar has the advantage of being removable by knownledgable users. The other one could be removable as well.

find modules

In a perfect world, this link would lead you http://drupal.org/download

But, as the download start page is of not much help to newbie users apart from confusing them, at the moment it does not help.
So either
- this page has to be reworked to primarily adress users new to drupal in the upper part
or
- there is need for a new page on drupal.org or inside the drupal installation that teases the user with what functionality he can add to his site by using modules, and explains how to do it. It probably should link to some modules that are very often used and easy to use.

It is a bit of a shame that the Wysiwyg module itself is not easy to install, so to be on the list it would have to undergo quite some usability rework.

eigentor’s picture

FileSize
50.22 KB

And here is an idea what this landing page - wherever one finds it - might look like:

Modules landing page for beginners

audster’s picture

@eigentor

I Love That page!!

It would be great if there could be a blurb in the final screen of the installation (maybe even linking to a page like yours there) and to also have that when you go to the modules page. Perhaps there could be an addition of a button to just turn that screen on/off/collapse (so that new users who now "get it" don't have to get geeky just to turn it off.)

That is a GREAT screen and if I had seen that when I started working with Drupal it would have saved me a lot of time! And I can't help but remark that a screen like that would really stave off a great deal of "buyers remorse" for new Drupalers (you know, the "I HATE DRUPAL" forum posts..) While I never really had buyer's remorse (okay fine, open-license misgivings) I certainly pondered that I had gotten in waaaaaaay over my head and would NEVER understand it - but I am nothing if not persistant so kept going. I wonder how many others though just give up and move on.

I think this screen alone would change the learning curve from vertical!

As far as wysiwig, I agree, the installation never seems straightforward as it is for other modules.

Part of this is the aspect of controlling the filters being used/set up (which also leads newbies down the road of the "order of filters" but that's a whole 'nother ball of wax)
But the other aspect is that when you are new to Drupal AND modules wysiwig setup is, well, scary.

There's got to be a way to incorporate at least minimal wysiwig that remains secure but functions right out of the box. (with say very strict filters already set up that can then be tweaked)

I know that many developers are setting up sites for their clients to then go and add content to, but my situation (and I can't be totally alone) is that my clients want me to build a site that will already have their existing content (from whatever site they already have) into the site and then let them loose on dealing with it after that. SO when I lost 3 days just trying to figure out how to get wysiwig going so I wouldn't have to hand-code html (having flashbacks to 1985 aaaaaaaaaagh!!) it was a very big deal to me - it was a huge loss of time that i needed to be utilizing towards actual site construction and functionality.

Wow, a screen like yours there makes me want to kiss the monitor.

On another note:

As I now come to understand the power of Drupal, and how ahead of the game it is, in so many respects, I am absolutely convinced of my initial choice of Drupal. We need to take a page from car manufacturers who spend a considerable amount of their advertising budget and time on advertising not aimed at selling cars but to continue to make new buyers feel as though they have made the right choice. I think there are many many opportunities for us to take the same tack with Drupal.

A

webchick’s picture

Closed #1464964: Rename "module" to a more generic term so people new to Drupal understand what it means as a duplicate. Re-pasting my summary from there:

Really what it boils down to is this:

1) Changing the word "modules" wholesale is extremely difficult.
2) Changing the label for the menu item that takes you to the modules page is extremely easy.

I think we should do #2. It works for themes (Appearance => Themes).

That mockup in #97 looks great; how about file a feature request against drupalorg project?

klonos’s picture

...coming from #1464964: Rename "module" to a more generic term so people new to Drupal understand what it means. I have to say that this issue's title makes it look more like a bug report, but I guess we can leave as is while we discuss things and retitle it to reflect the way we'll choose to go with in the end.

I think we should do #2. It works for themes (Appearance => Themes).

Yes! lets do it.

In the other issue linked above, quite a few suggestions were made of what the name of this menu item should be (originally not suggested as a menu item though, but as a replacement of the term "module"). Some of the most accepted alternatives seem to be: "features", "extensions" (clearly communicates the purpose of "modules": to extend Drupal) or "extras". The terms "addons"/"add-ons"/"plugins" were also suggested because they are used by popular software and people are familiar with it. For more info and reasoning behind each suggestion as well as some metrics of each term's popularity/commonness and comprehensibility, please read that issue (only 22 posts long).

klonos’s picture

...what would be a good word? It would be (almost) perfect if we could simply call the menu item "Extend", but I believe we also need to be in tandem with the other menu items we currently have (Appearance, Structure, Configuration). The one is a verb though :/

klonos’s picture

...I was thinking that if we perhaps changed all the top level menus to verbs it would be better:

Theme, Extend, Build, Configure

,but then again reverting "Appearance" to "Theme" (or "Skin", or "Design") doesn't quite fit there and I don't know what we'd do with the rest of the top level menu items' names (Content/People/Reports/Help). I'm out of ideas. Anyone else?

klonos’s picture

That mockup in #97 looks great; how about file a feature request against drupalorg project?

I had a similar idea (also inspired by the "Getting started" page in d.o) in #1464964-16: Rename "module" to a more generic term so people new to Drupal understand what it means, but not as a landing page for the modules admin section. I thought perhaps we could have it as a landing page right after drupal installation finishes. I was thinking that perhaps it could be a separate tour.module that would guide users through basic tasks. One of these tasks would be to extend drupal by using modules. Here's a summary of these tasks from that post (with some minor edits):

- Enable an existing module (and see some magic happen!!)
- Enable an existing theme (and see more magic happen!!)
- Disable one or both of these test "extras" (if they don't like their magic)

...by now we already got them to understand that there are "modules" that can be used to extend drupal ;)

- Download, extract/install and finally enable a new theme (downloaded from d.o)
- Perhaps do the same with a module.
- Perhaps also update an existing module/theme that is out of date.

...by now they also understand that there are "modules" included in "core" and also in "contrib" - another two drupal terms explained by example ;)

I think I'll go ahead and file a separate issue for that as Angie suggests...

sun’s picture

  1. Speaking of summary, this issue badly needs a summary of what has been discussed before, and why.
  2. The noun to extend is "Extensions", "Plug-ins", or "Add-ons."
    • Add-ons is associated with additional, possibly even commercial functionality. It has a linguistic focus on "add." It is translatable, but the implied meaning actually translates into the same term as "extensions" (at least in German that is).

      Personally, I think it sounds too "simple" and not suitable for Drupal modules to me.

    • Plug-ins is a very technical term originating from electronics and computer science. Its original meaning has nothing to do with software. The term is rarely used in software consumer products. Its technical meaning comes closest to what modules actually are and how they work internally. The term clashes with D8 plug-ins. The implied meaning for software is barely translatable into other languages (e.g., in German Plug-in belongs to the Denglish vocabulary of terms that are used in English, lacking a universally equal and correct translation).

      Personally, I think it's too technical and aforementioned issues make it obsolete already.

    • Extensions is a generic term used in many fields. It is understood by consumers. Most modern web browsers are using the term in their UIs to manage add-ons, plug-ins, and themes - not only in-application, but also for extension directories on their web sites. Joomla/Mambo uses this term since ~2003 with great success for their online extension directory (less so within the CMS, but that's due to other architectural reasons irrelevant to this discussion). It is in line with some other long-standing Drupal core development ideas and efforts (that want to ditch the formal, unnecessary separated discovery and handling of modules/themes/profiles and unify them into a single extension system [with extension-type-specific business logic on top of it]). The implied meaning is the general meaning, so it translates very well and easily.

      Personally, I think this is the most simple and most clear term we can choose.

  3. Appearance should probably live within the new top-level item as long as we don't provide any more meaningful functionality other than to enable/disable themes. Otherwise, we're separating the management of extensions and extensions (some here, some there) for no good reason.

___
FWIW, @klonos: It would be great if you could try to follow up only once... use the Preview button to make sure all of your thoughts are covered in a reply. ;) Thanks! (And really no need to reply to this note, please, thanks)

webchick’s picture

I think I agree about "Extensions" in relation to the other suggestions, but totally disagree with #3. Here you are taking a programmer-centric view "both of these things extend Drupal in some way" (which is only really true of certain themes that do add new capabilities rather than just pure skinning) rather than a user-centric view, which is "I would like to change how my site looks" (appearance) vs. "I would like to add new capabilities to my site." (Extensions) They are not remotely the same thing, and belong as two separate contexts.

<gauntlet action="thrown">
FWIW, I actually think "Features" is the most straight-forward word to use here, and don't want to see us make our main project UX more awkward just because a popular contrib module has co-opted the word for their own meaning. And in any case, Features are modules, too.
</gauntlet>

;)

Tagging for issue summary.

audster’s picture

IMHO I think that if you have a great landing screen (see #97) upon installation completion, the idea of needing to change the name of the menu link is .... well... not an issue any longer.

Especially if that landing area (I'm sure there's a better name for this) is collapsible and in its collapsed state retains text like "need to do more? click here!" or maybe better is a local task item like "add functionality" that remains...

then the confusion about just what modules are/do will be eliminated.

webchick’s picture

For the person who installed Drupal? Yes. For everyone that comes after her? No.

audster’s picture

well that's why i mentioned having a local task remain on the administrative interface..

eigentor’s picture

Keeping the discussion about the word module itself seperate from how the link in the toolbar should be named should help a lot to resolve this.
Renaming modules itself may be worth it but is sure to raise all kinds of controversy.

Much easier to rename the menu link.
"Add more functionality"
"Extend functions"
"More features"
...

Some of these are deliberately bad :)
Thing is - there is no need this be just one word, as it does not get too long. Am pretty sure we can find something that people will happily click on.

--- Edit: Feature request about modules landing page is filed: #1487662: Create 'Develop with Drupal' Section

jrabeemer’s picture

So I wrote rename_modules to rename all occurrences of "Modules". It does all the dirty work in JS so it's great for testing the "feel" of a word change.

http://drupal.org/sandbox/Giovanni_Glass/1485844

It should work well for testing purposes with regular people or maybe #D8UX testing.

jenlampton’s picture

Issue tags: -String freeze

Thanks @momendo, I think we should user-test this, and your sandbox might be just the ticket!

jrabeemer’s picture

@jenlampton Great! Let me know whatever you need.

DSheffler’s picture

I agree on testing this. I think it would be interesting to put up different versions though (maybe an A/B test if there's consensus on a top 2) and see what terminology makes more sense to people.

dcrocks’s picture

Again, why the hang-up with the word 'module'. Drupal isn't the only CMS to use that terminology. I doubt that a survey would find a clear favorite term amongst the many thousands of CMS's out there. I don't see how changing that label will have ant substantive affect on the useability of Drupal. Why not get to real issues?

jenlampton’s picture

@dcrocks it's because thousands of documentation pages may become "broken". I'm with you though, we changed "themes" to "appearance" in the UI in D7 with no problem, I think we should change "modules" to something else in D8, in the same way.

dcrocks’s picture

I looked at http://drupal.org/start and saw no mention of 'appearance'. In fact that page doesn't 'explain' anything. It is a massive collection of links with no clues. So is the 'Download and Extend' page. And since neither mentions 'Appearance' the admin form title is slightly confusing when those pages tell you to look for themes. Changing the title of the 'modules' admin form to 'extensions' or any other word is really too late for most novices. If you want to make drupal more usable, make the 'start' page actually give guidance to new users rather than be what looks like a overwhelming set of links. The 'Understanding Drupal' link is buried under other links and even then you have to burrow down several links before you get to the 'overview' document. Change 'module' to whatever you want, users will have the same difficulty finding the 'new' label.
I admit several frustrations with the 'Drupal way' but this long fizzle about the word module is really an exasperating waste of time. The drupal.org page is where new users start and that is where this discussion should start.

audster’s picture

I don't think we really need to change the name modules either. I think what's lacking is the new user's knowledge of the drupal way - which, by definition, means that they don't know a blasted thing about doing anything with drupal. You don't have to know X, you just have to know where to get info about X.

We live in an age where users at all ends of the spectrum have come to expect intuitive and in some ways "lowest common denominator" information be delivered to them - because that's what's been given to them thousands of times, again and again in print, media and applications. (I'm sure everyone here can think of more than 3 applications that were better, but got beat out by "easier to use, but not as great" later-to-market products...)

I agree with dcrock, too often the info you need is buried and unapparent or hidden amongst myriad search results - part of the problem in getting help by searching for it, is to know first what the heck you are searching for...

The screens proposed above go a very long way to providing the educational boost which, I believe, is at the root of this issue. You could call modules "doddles" and have fewer issues for new users provided that they have been educated about what "doddles" are and where to get them and how to find them etc etc etc.

Meno: How will you look for it, Socrates, when you don’t have the slightest idea what it is? How can you go around looking for something when you don’t know what you are looking for? Even if it’s right in front of your nose, how will you know that’s the thing you didn’t know?

Socrates: Just look how it flops about, this fishy argument you have landed! I can see where this line will end! You are arguing that a man cannot search either for what he knows or for what he does not know. He cannot search for what he knows since he knows it; there isn’t any need to look for what’s not lost. Nor can he search for what he does not know; for then he does not know what to look for.

webchick’s picture

"part of the problem in getting help by searching for it, is to know first what the heck you are searching for..."

Exactly. And no amount of Drupal.org textual/design improvements, post-install wizards, etc. is going to help the person who's handed a Drupal website that's already been installed and set up for them. Those are all good things to do to help orient new, technically-sophisticated site builders. But they don't solve the root problem of "I have a Drupal website, now what?"

However, using a word that provides a clue as to what lies under "Doddles" on the actual menu, as we have with themes (Appearance), is a proven way to resolve this. Because when we asked people to change their site's colour, they all found the right spot immediately.

Less discussion, more patches plz. :)

audster’s picture

@webchick - sorry if I'm seeming to go on and on, I was parented by systems analysts and therefore inundated with think a lot first, discuss much, then build - I guess that's just my perspective, sorry if it's a bit tedious (it is) it's just the way I think about problem solving (I'd probably re-think sunsets if they were open to design changes! :)

Well I don't think that the underlying problem is as simple as simply changing "Theme" to "Appearance", because the things that modules do aren't as simply described and I think what we may all be discovering in this discussion (<-- there it is again..) is that like any disaster (no this is not a disaster, just bear with me) it's rarely just one thing going wrong that causes the plane to go down - instead it's usually a series of events that leads to the disaster:

plane looses engine - wings ice - reverse tail rudder ensues = plane crashes
but
plane looses engine = land safely at airport, get help.

Perhaps this issue needs more than just one angle of attack/solution
Perhaps there needs to be changes on the install landing screen, at drupal.org and maybe even an addition somewhere to a brief tour for those taking over existing installs and new to drupal (I'm thinking something like a link under the admin menu "overview of how drupal works")

I say this because as I read this very long thread, many valid ideas and thoughts being presented are touching on these various angles. Perhaps we've all identified that the problem isn't as simple as changing the word modules?

fizk’s picture

There are two approaches to solve this:
1. HARD FIX: To conduct a terminology review and understand what users actually call "Modules" as ... what syncs with them?
2. EASY FIX: Comparatively easier fix is to provide tooltip instructions on hover to "Modules" like "Extend your Drupal functionality" followed by a clear description of a module is on the modules page.

I believe the "easy fix" is also the best fix. There's been a lot of good points made why approach #1 is no good. I'll just add my thoughts:

Approach #1 would have us look for names that are trendy. 10 years from now perhaps the trendy word is not "extensions", "addons", or "plugins", but "doodles". Will we have this discussion again at that point?

Also, there's a wealth of discussion on Drupal.org that makes absolutely no reference to whatever new name approach #1 would have us use.

With the approach of #1, here's an annoying reoccurring discussion I see happening with new comers to Drupal in forum and IRC discussions:

<newbie> Hi, I'd like some help with extensions please
...
<zoidberg> You need to install the ABC module
<newbie> What the heck is a module?
<zoidberg> For the millionth time...a module IS an extension
<newbie> Then just call it an extension...?
audster’s picture

agreed

Bojhan’s picture

Status: Active » Closed (duplicate)

Lets discuss this in http://drupal.org/node/1164760 . Sorry for closing a standing issue, but it seems the momentum is there.

somar-assaad’s picture

Version: 8.x-dev » 7.23
Assigned: Unassigned » somar-assaad

when i tried to install open atrium i have this message that tell me "drupal already installed"
i make the existing database empty,and create new database .
after that i edit the settings.php file and add the new database.
i should to upgrade an existing installation proceed to the update script ,i have this error message

PDOException: SQLSTATE[42S02]: Base table or view not found: 1146 Table 'open.system' doesn't exist: SELECT name, schema_version FROM {system} WHERE type = :type; Array ( [:type] => module ) in drupal_get_installed_schema_version() (line 155 of /var/www/html/openatrium-7.x-2.0-beta3/includes/install.inc).

i need help.

regards

klonos’s picture

Version: 7.23 » 8.x-dev
Assigned: somar-assaad » Unassigned

Hey Somar welcome to Drupal!

Please don't change old issues when you need help with something and especially do not change the "Assigned" field (it is meant to denote the person working on solving the issue - not the one having the problem). Please open a new issue and assign it the "support request" Category. Thanx.

klonos’s picture

Grr img tag