This is a terrible, terrible problem.

Across the board, the usability testing participants we tested at UMN did NOT understand that you could extend Drupal. There were a few reasons for this:

1. The word "Modules" means nothing to them. Some thought it means blocks, some thought it meant the site outline (sitemap), some thought it meant a part of the front page.

2. Once they got to that page and kind of got the jist of it, they thought that the options presented there were the extent of Drupal's functionality. The option to add additional modules wasn't discoverable.

3. Once they got to Drupal.org, it was incredibly jarring and people didn't realize they were still within the context of their site. The lack of integration was very challenging for people getting around.

Here were some possible solutions we brainstormed, but this really needs a larger community discussion:

"Develop tabbed interface to module list, to indicate there is more than what is included. Example:
1) Enabled modules
- Configure
- Disable
2) Disabled modules
- Enable (taken immediately to configure)
3) Add module
- Discover/Browse [drupal.org]
- Install to your site"

Related issues

#1167458: New users do not know to click on 'Modules' to extend their site
#1464964: Rename "module" to a more generic term so people new to Drupal understand what it means

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

tronathan’s picture

Additional information about this issue:

- Users Expected “Browse” button to lead to a page of modules to browse. (recommendation: Add in-app browser interface of drupal.org list.)
- New media and social networking features were expected to be part of the default installation.

Damien Tournoud’s picture

I'm not completely convinced this is a core issue. If it is a secret that you can extend Drupal, the whole "Download & Extend" section of Drupal.org really gives it away. Typically people don't get to Drupal via the software first, but via downloading it from Drupal.org. All the rest (except the in-app browser interface that I can definitely support) is the question of "what should be included in the default download". And that's definitely not a core usability issue, but the whole debate about distributions all over again.

Bojhan’s picture

@Damien This is a Drupal core problem.. It is true, that we did not test the scenario where they would go to Drupal.org and possibly encounter the concept (we don't know if they would understand it). However this scenario, of them installing Drupal without going through Drupal.org is still fairly common (think hosting admin, a friend did it for you, etc.)

It should be clear this issue does not discuss, what should or shouldn't be in core. Its about making the Modules label and possibly Modules page be less intimidating and more clear within Drupal core, part of the problem here is when people actually do get on the Modules page its not clear where you can "add" new functionality besides the already existing checkboxes (action link not standing out it seems).

A few quotes:

"A module is something on the home page that I click on"
"Ha ha ha ... I don't know!"
"I don't even know what that means"

webchick’s picture

Damien: Yeah, we considered that this was a factor of the usability testing environment rather than an actual problem. But there actually are many instances (as Bojhan refers to, also think "one-click installs" in hosting control panels, Acquia stack installer, etc.) where the first step to obtaining Drupal is not to get it from Drupal.org.

However, one person did end up on http://drupal.org/download in their struggles to find the webform module, and did what I think is the natural thing to do, which is completely ignore the text of the page and instead click the BIG ASS GREEN BUTTON. In other words, I'm not convinced that even someone starting on Drupal.org will understand that modules exist. :\

dcmistry’s picture

Also, I would like to add that the problem intensifies at every step like a ripple. Putting the user hat: I am unaware something like extend Drupal extends, if it extends no options in the toolbar are clear to me, if I do understand or get assist that "Modules" is the place to be, the "Modules" page is overwhelming with a buried link to "Add new modules" which I do not notice (making me wonder if I am on the right track) and of course if I did understand that as well - there is another can of worms to try to find a module on D.O.

Overall, Damien: I understand your concerns about people MAY know about it. But I think we should look at the BIG PICTURE and solve for the over all experience. There is no adequate information to tell you what is a module, what does it do, how to download, etc.

Last thing, if we solve for this case - we are pretty much improving the experience for everyone: Universal Design approach!

droplet’s picture

interesting, what are the testers background ??? I read some of new usability issues this few day and most of them do not make sense to me.

I know some guys, they are not native English speaker, no coding experience. even that, they never ask what is module, all of them know about it.

webchick’s picture

Good question. We're working on a big write-up that summarizes the results, but the target participants were people with site building experience (some had WordPress, Dreamweaver, Joomla! experience) but not Drupal experience. There was one participant which deviated from that, but the rest were directly in Drupal's target audience.

dcrocks’s picture

Just to add a comment from somewhere on the sidelines, the module pages are very difficult to browse. The descriptive material has very loose standards, there are no ratings, and the tagging system seems sometimes to be ad hoc. A module's description can vary from a few uninformative sentences to a 1000 word essay. Searching by tag is no guarantee that the result set will include ALL and ONLY those modules appropriate to the search. This makes the page difficult to search and requires real effort to find what you want.
If you could separate modules as to whether they were 'APPS' (produce content) or 'mods' (modifications to drupal behavior that other modules or themers can take advantage of) it would be a lot easier. And, if a module produces content a demo page should be required. Did you ask the test group what terminology they expected when you asked them to look at extending drupal?

ps. Themes should be separated to those that are meant to be 'base' themes for theme construction, and those that are meant to be 'templates' for theme customization.

joachim’s picture

As I tried to explain at the other issue this came from, this is to do with the structure of your usability tests, and quite probably with nature of testing itself.

If you give people a box and tell them the test is to make something with the contents, they will consider the contents of the box to be the problem space.

webchick’s picture

joachim: See #4. Additionally, it still doesn't negate the eyetracking evidence that none of them saw the tiny "Install new module" link until specifically directed there by the help desk.

naught101’s picture

related issue: #1167458: New users do not know to click on 'Modules' to extend their site

As I said on http://drupal.org/node/1175694
From wiktionary: Module:
8 definitions, including:
A self-contained component of a system, often interchangeable, which has a well-defined interface to the other components.
and (computing) A section of a program; a subroutine.
Which are both perfect descriptions of drupal modules, but, again, probably only known by programmers.

Personally, I think that "plugin", "addon", and "extension" are all better terms than module, if only because so many other systems use them (ie. every common browser uses one of these).

catch’s picture

Modules are not only known by programmers. There are modular pre-fab houses, modular sofas, all kinds of things are modular.

Extension and add-on applies to Drupal stuff that isn't modules (template engines, cache backends, themes even) - that is not a renaming issue but about adding a meta-word on top of existing terms.

Plugin is a namespace that is already taken by ctools, at least one other module, and potentially core.

There seems to be two possible courses of action here:

1. Add some basic inline help text / better link titles that help people find Drupal.org easier. This should be a relatively small change and arguably what makes this a bug (we used to have help text that sent people to Drupal.org but removed it after the first UMN tests when people went off-script there instead of looking around Drupal in the first minute). There is a fine balance but we may possible have swung too far the other direction. I'm not convinced though - there's a lot you can do in core without installing modules - like create a custom content type with a tonne of fields, default it to unpublished, and add a trigger to redirect to a thank you page after posting - wouldn't that have been an (entirely valid) way to solve the issue in the usability test?

2. Add a module/theme browser to core - that is a 'task' not a bug.

sun’s picture

Category: bug » task

I'm using my ubiquitous superpowers to overrule @webchick and call this a task.

webchick’s picture

Priority: Major » Critical

I guess I'd be ok with that, as long as we do this.

emjayess’s picture

I think it should say,

"MOAR FEECHURS PLZ ICANHAZ"

jherencia’s picture

Subscribing...

bryancasler’s picture

It looks like you want to maximize the users ability to find relevant modules for their website. And then you want to make their installation process as painless and simple as possible. You can meet both of these goals by reducing the number of clicks necessary to find and complete a module installation. I'm for Catch's suggestion (#12:2) of core having a built in module/theme browser, but I think this would only meet our first of two goals. If you have a built module/theme browser AND one click installs, then you'll be unstoppable. As for a verbiage switch, I prefer "extensions".

Go to "extensions" page > Click on "browse extensions" tab > Find an extension you like > Click Install

naught101’s picture

@catch: I know, modular is a somewhat familiar concept to most people, but the definition I quoted is clearly programmer specific (I picked it because it was the closest to what "module" means in drupal).

"Modular" as is applies to couches probably applies just as well, or better, to drupal blocks than to drupal modules, to most people.

I agree with the idea of using "extension" as a phrase covering all modules, themes, etc. then we could move admin/modules and admin/appearance under admin/extend - but that of course makes theming slightly less accesible.

I think the drupal community is just going to have to resign itself to the fact that there's always going to be a need for some jargon, and that there's never going to be a set-up that is the best for everyone. When it really comes down to it, it's just about flattening out the learning curve, so that the initial step is easiest, and that's mostly gonna be done via really good and obvious help text and tutorials and the like.

geevee’s picture

I think we should seriously consider changing the terminology "module" to "extension". Its the most direct way we can tell the user that he can "Extend" drupal.

One can always argue based on dictionary definitions that one of these are better. But what is needed is the right term that our target audience understands. Actually even based on dictionary definitions, extension is a better term and is more popular among folks who are not coders. Drupal should aim to be a tool for even noncoders, to easily build websites.

tamanna-freelancer’s picture

Hi,

I feel if instead of having a link "Install a new module" we have a search module textbox and button on the modules page,that would be easier for first time users to understand.

plach’s picture

My 2cc: as a minimal measure, why not making the package fieldsets collapsed by default? This would make the "Install new module" link more evident.

Edit: I should note my suggestion above is for a D7 minimal fix.

lathan’s picture

I think some of the discussions on Merlin's page here are also relevant here http://www.angrydonuts.com/on-how-to-fix-the-modules-page

bryancasler’s picture

Looks like someone is doing a GSOC to create a project browser. Worth considering.
http://groups.drupal.org/node/145159
http://www.screencast-o-matic.com/watch/cX16jGqeg

aspilicious’s picture

Sub. I like #23.

catch’s picture

In terms of the module/theme browser, that work could continue on #395478: Plugin Manager in Core: Part 3 (integration with installation system), or that issue should be marked duplicate of this one.

bryancasler’s picture

bmx269’s picture

Webchick, this is something I brought up when you were at ImageX Media for lunch. When we discussed it on our own after you left, we felt that the addition of an rss feed to the module listing (on drupal.org) would help. We could then write a module to pull that info and hook into the module download option of core. After testing of proof of concept, that could be built on to include a rating system that was stored off d.o and combine it for even more greatness. What do you think?

-Trent

franz’s picture

bmx269, do you mean a 5000 item RSS with descriptions, links and tags?

bmx269’s picture

All I am looking for is a feed. From there it can be pulled and sorted, filtered etc. All the data needed, from file location to usage counts are available. With that info, we could pull what we need from the feed, and create the interface to connect to the "Install Module" function already present in D7.

bkoether’s picture

@franz: I don't think a monster RSS feed would make sense for something like bmx269 has in mind. You probably would need to create some kind of buffer to accomplish this.
For example: A cron job that compiles all important module data once a day and saves it into a mongoDB or a similar high performance storage.
Then the "client" module could use this storage to look for module information and results would be delivered via JSON. Just as an idea...

Ben

franz’s picture

Makes sense. Looks like a JS web API would be really cool for that.

catch’s picture

@bmx269, there is active work going on for this at http://drupal.org/project/project_browser - that's probably the best place to try to chip in and help.

yoroy’s picture

*If* project browser lands in core it would give us a great single destination for 'how to extend' tips/links that we could sprinkle over core. Where those links should live is highly debatable but I was looking around and having them on top level admin listings they might work:

Just an idea. What is yours? :)

xmacinfo’s picture

In parallel we need the modules page on d.o. enhanced with ratings. Is there an issue for this on the d.o. issue queue?

Jolidog’s picture

I think the link to d.o from the admin/modules page should not point to http://drupal.org/project/modules but instead to a new landing page with a welcoming text and below the modules section of the http://drupal.org/download page.

Below that we could even add something along the lines of "You might also be interested in this: Themes and translations"

This page could be only directly accessed from within a drupal installation.

Obviously this would be only a part of the solution and I believe it could be ported to drupal 7 also.

giorgio79’s picture

#33 I think this should be much much more prominent, perhaps a separate entry in the top navbar after structure, with a menu entry like "Extend". Given the importance of extensions vis a vis other CMSes, this should be right there in the admin menu.

vegantriathlete’s picture

D6 had the help text appear on the front page when you hadn't created any content, whereas D7 just has the text "No front page content has been added yet." To find the same text that was *right-in-your-face* when you first installed D6, you now need to navigate to the Help menu. You don't know which install profile the user will choose, and thus don't know how likely the user is to even find the Help menu (minimal install = no toolbar, which may mean not finding the Help at all).

I know that as a new user (starting with D6.9), I found it really cool and helpful to see those four steps and their links right on the front page telling me how to get started. How about reinstating that front page? Or, how about creating a "Welcome" message that pops up in an overlay with that same information that continues to appear until either the user checks a box on the overlay saying to dismiss it or the user creates a piece of content on the site?

P.S. I think that the information should still appear on the Help page as well, just so that people can get back to it later on.

xmacinfo’s picture

@vegantriathlete: You put the finger at the heart of the issue.

The welcome text displayed in Drupal 6 was helpful for some and confusing to others, the more so if the user did not choose to publish content to the front page.

We want to help new users discover what they can do once the installation is completed.

You are right, the front page help text should make a comeback. And the idea to show the new user help text in an overlay or attached to a cookie (or variable), so that the user could dismiss it temporarily or permanently, should help even better.

franz’s picture

extending this idea, there could be a nice tutorial presented (or suggested) on the front page right after installation. For most software, there is a video or graphic tutorial that really helps to take the first steps.

vegantriathlete’s picture

I would also add that the "Welcome" message should be truly warm and, well, welcoming. How about something like "Congratulations! You have successfully installed Drupal. Here are some things you can get started with immediately and some others you can do as you gain more experience." (Then list the four steps in the order -- based on current numbering -- 1, 4, 2, 3). That seems much better than "No front page content has been create yet." Can we possibly be any more impersonal than that? Come on, let's be the friendly and outgoing party host, not the socially awkward code monkey. (Personally, I prefer to think of myself as the friendly and outgoing code monkey)

aspilicious’s picture

The text is removed for a reason, based on the results of usability testing. So it is NOT going to come back. So please don't hijack this issue for adding back the text. It won't happen. Seriously.

Main problem with the steps were that once you added something the text is gone and people suspected it to be still there on the frontpage.

franz’s picture

@aspilicious, doesn't have to come back as the same thing. It is the idea of a "how to get started" thing coming up as soon as installation finishes. This also helps to instruct users about key concepts like blocks and modules, which is a current issue.

LoMo’s picture

I agree that "modules" is a confusing term for new users, even though it is more accurate that "extensions" or "plug-ins", etc. The point is that Drupal is "modular" and each chunk of modular code is a "module" -- some of the "modules" are "core" and even "required" and others are core and can be activated if the features they provide are desired... and then there are modules that are downloaded to add other features. THOSE modules could be called extensions, IMHO. The "required" modules shouldn't even be in the "modules page" (there should be no way to turn them on or off if they are "required by Drupal" so what's the point of them cluttering site administrators' overview of active modules?).

Anyway, as much as I've found some of the "renaming" within Drupal a bit ridiculous (e.g. changing "admin/user/*" to "admin/people/*" did NOT improve anything, IMHO, and possibly reduced clarity, especially for the "weekend admins" who were already familiar with the "admin/user" paths and related menus), I'd have to agree that changing the terminology to "extensions" is a reasonable way to improve new users' understanding of the system. OTOH, there is always going to be a bit of a learning curve to putting together a complex site with a framework that a site builder hasn't used before.

Learning some jargon is always going to be a part of the process, so just making documentation more standard and improving the chances new users will find what they need to overcome the learning curve are the real issues, as I see it.

j.somers’s picture

From #12:

Plugin is a namespace that is already taken by ctools, at least one other module, and potentially core.

The fact that ctools or anything else which is not part of Drupal core uses the term plugin is not relevant. They will have to adapt to what Drupal core is doing.

If we look at other open source CMS/CMF systems they always seem to use the term plugin to identify an add-on that extends the functionality of your website. Even something simple as jQuery (which is part of Drupal) uses the term plugin to identify extensions. If Drupal would use the same term I believe it makes it a lot easier for new contributors and contributors who come from other systems to start contributing.

I would also use the term plugin rather than add-on or extension because it's simply more used than anything else.

In all my years developing websites or regular desktop applications I have come across only two projects that use the term module rather than the term plugin to identify things like this as modules: Drupal and Microsoft Prism. (Prism is a framework that provides guidance designed to help you more easily design and build rich, flexible, and easy to maintain Windows Presentation Foundation (WPF) desktop applications and Silverlight Rich Internet Applications (RIAs) and Windows Phone 7 applications.) If you develop an application with Microsoft Prism every core aspect of your application becomes a module. From big concepts as the file import/export tools to something small as the options dialog. But almost always these are things that are part of your application when you ship it. Additional extensions that people can buy separately that enhance the functionality of the application (custom file importers) are defined as plugins.

And maybe something similar can be done for Drupal core. Every things that comes with Drupal core, which is part of the default installation, whether or not you can disable it, can be called a module. Those are the things that define the installed Drupal system.
Every thing that is contributed, that adds to the functionality of the standard Drupal installation can be called a plugin.

edit: For some reason I am seeing myself as one who added a revision to this issue. I have no idea why or what happened, sorry if I broke something.

LoMo’s picture

Something about the whole issue makes no sense to me... The title of this thread is (currently) "[meta] New users universally did NOT understand that you can extend Drupal", but we are told that the users selected for the study were all experienced users of other web-based CMSs, such as Wordpress and Joomla! Given the fact that basically every other CMS has "modules" (or plugins or extensions... or...), why would they NOT assume that Drupal was as extensible as any other CMS they'd experienced?

There are obviously many tens of thousands of site builders who have jumped in and build sites based on Drupal without too much trouble getting their heads around the terminology (I certainly don't remember ever thinking Drupal was not extensible or wondering what a "module" was -- but I spent days figuring out how to make my first semi-complex Views display.)

So personally I think this aspect of the study might say more about how people with no particular goal or purpose -- just participating in a UX study -- are unlikely to have their thinking caps on to solve simple tasks (such as figure out some of the basics of extending core).

Bojhan’s picture

@LoMo Please try to keep this discussion constructive, claiming that participants where stupid does not get us anywhere. Additionally your comments on the term we use for modules, are the ones we always hear when discussing terminology (they should just learn it). We are exploring different directions to solve this problem, if you have an idea please share.

LoMo’s picture

I didn't mean for my comment to be "non-constructive", nor to imply that the people were actually "stupid" (that's really paraphrasing in a way that I wouldn't intend), just that the participants, at least in this regard, probably didn't really model the "real world" where people come to Drupal and figure it out a step at a time. I DO think it doesn't otherwise make much sense that we are to believe the participants in the study had the experience they claimed, but didn't presume that Drupal was extensible. I question whether it's really likely the test group had the experience they are purported to have. Is it possible some of the participants exaggerated their experience with other CMSs?

And I wonder about the test situation affecting the normal "step-by-step" flow of understanding how Drupal works, at least from the POV of someone who intends to start building sites with it. Currently, if you land on drupal.org, you see a big green button for "Get started with Drupal", and assuming you click on that, you get to another page with a set of steps outlined, the first of which is "download drupal" (again with a big green button), the second of which is "Extend Drupal", with a sentence that clarifies that "modules" are what we use to "extend" a site and add extra functionality... then there is the step to "Documentation" and finally, "Support". In the test, maybe they didn't install Drupal or read the "readme", which also clarifies the term "modules", right near the top... but these are steps that a regular new user would likely take if they weren't in a "lab situation" with a "tech support" desk to "call".

I do agree that some things could be more intuitive, and I also have read the report of this study and think that there is a lot of useful information there which the community and core developers should take to heart... but also take with a grain of salt. In the "real world", most people come into the Drupal world a small step at a time and, most likely in the "decision-making process" of picking Drupal as the CMS to use for their intended project, they've learned not only that Drupal is extensible, but maybe also researched distributions and/or particular modules that would be involved in satisfying their requirements. Determining the modules to use to satisfy requirements of a given project isn't always so easy and I think that improving UX in this regard is a fundamental issue.

I do agree that the terminology could be a minor stumbling block; I'd already said that I fully agree that the term "extension" is more clear ("plugin" also works). And I said it might be better to do away with listing "core required" modules on the same page as modules that are "extensions". You can't turn off the "required" core modules, so not much point in cluttering the UI. I do also think that there could be better searchability of available modules and modules for particular purposes. I think that these issues are more important, actually, since renaming terminology that's worked for the Drupal community for 10 years could muddy the waters for newcomers as much as it clarifies things. If we start calling contributed modules "extensions" or "add-ons" or whatever, there will still be millions of references, here and elsewhere, with the word "module" used... but the real issue is sorting out which module does what you need, improving the search function for modules, and improving the integration of searching for new modules and adding them to a user's site. If we are on the topic of confusing terminology, a lot of Drupal jargon is used in ways which are not immediately clear to a newcomer. I think people new to Drupal have an easier time accepting the term "module" than understanding what some other terms mean, e.g.: "node", "vocabulary", "term", "entity", "block", "profile", "view", "display", "feature" ... all of these words have meanings that are quite different outside of Drupal, some of them even in the "programming / IT" context. But changing the terminology used, at this point, would likely cause more confusion than it clears up. What I propose is that we continue to ensure that wherever these terms are used in the documentation (or main pages of this site), that it's clear what we mean. "Extend Drupal: Download hundreds of modules to customize and extend your site" (from http://drupal.org/start) seems pretty clear to me. We need to make sure that other prominent places where Drupal jargon is used, and where people are likely encounter the term for the first time (in "Drupal jargon" context), we do it in a sentence which clarifies the term. Revising the documentation here and there could help. Using the Glossary module to add "title tips" with definitions of Drupal terminology could also help. It's what I do in my blog posts for Cocomore. I can think of other ways to ease the newcomers' necessary learning curve, but I think those ideas are better discussed in another thread.

No disrespect to anyone intended,

Lowell Montgomery

koala_b’s picture

.../...since renaming terminology that's worked for the Drupal community for 10 years could muddy the waters for newcomers as much as it clarifies things. If we start calling contributed modules "extensions" or "add-ons" or whatever, there will still be millions of references, here and elsewhere, with the word "module" used...

LoMo, you've given yourself a part of a solution: to be more precise for your potential readers, you was forced to qualify the word "module" by adding "contributed" (by opposition to 'Core').
Why not advice the Community to avoid to use the word 'module' alone (on a page, in a documentation, ...) and, stead, to always use "Core module" / "Plugin module".
In 10 years, it will be maybe time to say "Core" and "Plugin" alone...

LoMo’s picture

Maybe in 10 years, but as others have pointed out, a number of modules have "plugins", which are different from modules... well, at least a bit different. A lot could change in 10 years (or even five).

Anyway, generally agreed.

For now, I think I think it's most important that all pages likely to catch newcomers include docs which elucidate ambiguous terms, ideally the same for the UI, but that will have to wait for D8, at least for "core". Hopefully, by then, users won't need to do their module search on drupal.org, either, but from within the UI be able to search out, select, and add new modules.

xmacinfo’s picture

"plug-ins" is already used a lot by jQuery developers. A jQuery plug-in can be used modules or themes.

So I would leave the name “module” as is.

franz’s picture

Everybody uses plugins. Nobody would be confused if, given a context, they understand we're talking about Drupal plugins.

LoMo’s picture

I think that it might well be confusing if we had the millions of references to "modules" that we have now (in books, blogs, screencasts, this site, and other sources) ... and then also started calling them plugins, extensions, add-ons, or such. It would be best to keep the terminology as-is and ensure that in places where people are likely to be first encountering the words, they are well explained.

naught101’s picture

FileSize
18.88 KB

giorgio79’s picture

#53 +1 for naught101's proposal

droplet’s picture

You must know it can extend Drupal before use it. I don't think peoples will try Drupal/any software without read any recommend articles or hear from guys.

Issue Summary point #2, #3 are more important. Telling new users how to find / install / configure new module that will be help.

Unfortunately, Drupal is too powerful. It's a lot of API-like modules & dependencies. It's so hard to install a module.

I think we can do something improve on Drupal.org or Drupal core:

- a fixed area on D.org module page like Download section, show what dependencies module needed & directly link to that modules page
- a fixed area & directly link tell users there has a install profile

and try to read this page:
http://wordpress.org/extend/plugins/wp-super-cache/

"Description / Installation / FAQ / Other Notes / Changelog Stats"
It's clearly tell users some important info.

- README.txt should be able & easy to access it online. Some guys install modules remotely and no chance to read it :(
we can do something like Github, show Readme automatically (https://github.com/jquery/jquery)

- List all "Required by XXX" modules.
eg. Drupal Commerce
It's a bit hard to find out related modules. Searching by keyword would get a lot of "Ubercart, e-commece ..etc" unrelated modules.

("People" on the toolbar also confusing me. who care about IA or whatever meanings/reason of it. "Users" is more friendly)

yoroy’s picture

Please refrain from meaningless +1's in a critical issue, it's not constructive and doesn't move things forward.

naught101 thanks for the mockup, could you provide some rationale for this design?

joachim’s picture

I agree with LoMo's point, and I tried to make it further up this thread (or in the other one) too.

Consider a different test: you are given a box of tools and you are asked to fix the bike. How many test subjects would consider that going out of the house and to the hardware store to buy more tools would be *part of the test*?

naught101’s picture

yoroy, see #18 for the rationale.

Paul Simard’s picture

Just a thought. Why is there no Welcome! Tour for site admins accessible from the install page that walks them through the features of Drupal including things like install profiles, feature sets, and expansion opportunities? A quick 5 minute walkthrough as introduction could address these issues. Or if this notion seems a bit much, how about a 5 minute video that does the same thing?

xmacinfo’s picture

@Paul Simard: The Drupal 6 welcome page have been removed because most users did not know how to remove that page once the site was built.

However, we still need a welcome message that should be displayed only once, though.

LoMo’s picture

And of course that welcome message could be linked to an "overview" tutorial video (online, not included in the Drupal download), as suggested by Paul Simard. But then we would also need to translate that to as many languages as possible and make sure it's still easy to find (from the "help" menu), later on. I do agree; a simple screencast showing the steps to locating, installing, activating, and possibly upgrading a module or two -- as well as giving some ideas of the range of common module functionality -- would be very useful, as would a bit about themes.

catch’s picture

When recovery.gov launched on Drupal it had the standard welcome page still at /node. We could look at something like a message with a close button though.

franz’s picture

catch, I believe that with the decoupling of node module, '/node' will be no longer the default homepage, am I wrong?

catch’s picture

@franz: that will be true for the minimal install, not necessarily for install profiles if they want a river of news on the front page (as standard currently has) - so depends on what snowman comes up with a bit.

The other problem with the old default help text is that once you posted something to the front page, it disappeared without explanation, so it was tricky from that angle too.

franz’s picture

So what is suggested as a "message that appears only once" is even worse to the users, as it would bail even before some content was posted.

This could get inserted in the Help region as a something small linking to a page with a short tutorial. This should appear on every page until user disables it, and to do so he can be lead to a settings page where he is properly instructed where to find that help again if he needs.

Just a plain idea. I think we need to start experimenting and if possible, testing some of these solutions the same way it was tested.

catch’s picture

A lot of web applications have messages (often informing you about new stuff) that you can leave open or close - generally linking to help pages etc. They neither disappear by themselves, nor magically based on unrelated interactions - the explicit close (and ability to do so) is important I think.

I'd be fine with trying to adapt the drupal_set_message() system to use this (in the same way we have persistent messages on admin pending action, although those are ugly right now), or using the help block.

yoroy’s picture

I'll have to look if any previous issues exist for showing 'tips' in, about the user interface. I'd be hesitant to mix that in with where warnings and errors are shown (adapt drupal_set_message) but I can see how it is similar in functionality.

franz’s picture

I think the help region is the most suitable, semantically - it is not just a message, it is a help item for the whole system. But finding a nice way of making it persistent and not annoying at the same time is the point.

As examples, I like the "Disable the overlay" link that was intruduced with Overaly accessibilty improvments. Something like that at the top of the string with a different visual appeal (and a nice classical lamp icon =P).

LoMo’s picture

FileSize
71.56 KB

I think users shouldn't have too much trouble finding "help" at the right of the Toolbar menu, which is active, by default, in a standard installation.

And if they click on it, they'll see pretty much the same instructions that they saw on the front page before creating content:

(I'm only trimming off the list of module help links a bit)

Personally, I think that's pretty good for solving the issue. Users just need to take enough time to look at that page as they go through the steps of setting up their site.

What could help is a bit of Javascript that alerts the admin, on visiting the front page, that the helpful text which was previously on the front page can be read by clicking on the "help" menu of the toolbar (or at "/admin/help"). The help menu could be highlighted with the alert text appearing nearby with an arrow pointing up toward the "help" link.

naught101’s picture

#68 franz: problem is that not all themes HAVE a help region (though they probably should).

once around that stumbling block, I think it's a great idea. If it's just a block in the help region, you could just have a "disable this message" link at the bottom that calls for the block to be disabled. That way you could also have it on the front page (which I guess would mean not in the help region?)

franz’s picture

@naught101: I know, but we're talking about first-time installs with core profiles, which would use core theme (Bartik), so I don't think that would be an issue

@LoMo: It's the first time I ever saw that link, and took me about 30 seconds to find it. I first expected to see it on the top right corner, then I expected it to be somehow different from other menu entries. I guess that's the root of the problem in here. If it was clear that the help button is the one thing to click once you finish installation, we'd have a good thread to solve this whole issue (let's not forget it is about extending Drupal).

I still vote for a block in the help region. The link to disable it could very well be the link to move the block to "Disabled", and once user clicks on it he is warned about the link on the top menu (with those neat screenshots).

Paul Simard’s picture

Another thought. The screen at the end of the install, where there are already 2 links. One says,' Take me to my website'. Suggest another link to a Tutorial (satisfying translation issues) that can walk the user through those initial tasks, with the final steps having the user disable the Tutorial, and telling them how to delete the module entirely. The tutorial pages could reside in the module code, as a book, and/or link to Drupal.org directly.

I also like the Help block idea. Let's not forget that we're talking about Drupal noobs, with overall expertise at nearly all levels. Also, users at all levels have expectations about software whether they realize it or not at its install, and we can't guarantee that they are correct, or that they can even find what they need or that they'll even figure out where to look for it. Assumptions like this invariably jump up and bite you down the line. Whatever is decided, we should at least offer a clear path to discovery for new users, bringing them to the first step on the path, and inviting them to continue down the road at their leisure.

[I don't know how I got credited with authorship of a revision. Totally unintended.]

joachim’s picture

I had an idea about a way to point users to drupal.org as a source of further modules to install.

Here's a quick and rubbish mockup. My idea is basically to combine the module admin page search that we'd like to see in core (qv another issue) with sending the user off to drupal.org to swim in the giant Lego box.

module search home and abroad.png

I'm thinking if we give the user a single search box, and make it clear they can search either what they have right now, or drupal.org, then that demonstrates to them what they can do. It would be at the top of the module admin page -- where UX test participants who get as far as clicking on 'modules' get stuck -- and would be a way into finding contrib modules.

Obviously, this would need considerable work from UX people -- not just the search UI but how to present the results clearly. Not to mention a search interface on d.org that can be queried via REST or something.

cweagans’s picture

I did some really informal usability tests with some people that I donated websites to (friends, family, local non-profits, etc.). When they logged in for the very first time, 4 of 5 people clicked "Dashboard" because it seemed important and they thought it would provide an overview of what they could do on the site. Granted, core doesn't really provide much out of the box for Dashboard use, but I understand their thought process.

Given that, I propose that we add a "Welcome" block to the very top of the dashboard in the Standard profile. When users click dashboard, they'll be greeted and given a really high-level overview of Drupal, what they can do with Drupal out of the box, and where they can get more functionality or themes.

aiwata55’s picture

Catch on #12 and naught101 on #18 gave me an idea:

- to call all modules, themes, template engines, libraries and others "extensions."
- to call modules "Functions"
- to call themes "Appearances," "Look & Feel," or "User Interface"
- Put module management page and theme management page under "Extensions" link in the system.

To be honest, modules can have not only additional functionality but also miner appearance changes, so calling modules "Functions" may not be perfectly appropriate.

LoMo’s picture

To be honest, modules can have not only additional functionality but also miner appearance changes, so calling modules "Functions" may not be perfectly appropriate.

That's for sure! We definitely should NOT call modules “functions”… this could be very confusing since functions are also blocks of PHP code which, in part, are a component of modules. ;-) Furthermore, something that adds functionality, in English, is not, itself, usually called a “function”. For example, a tow-hitch adds functionality to a car, but would not be referred to as a “function”; we might call it an “accessory”, which could be a better term to use for any kind of general “add-on”.

We could loosely call all community-contributed code “extensions”, but with millions of references to “modules” and “themes” already in books, blog posts, and all over this site, we might only add to the confusion if we stopped using these terms in internal documentation — again, it's best we just make sure that people are not confused by the terms when they first encounter them, so provide clear explanation of these terms everywhere a new user might run into them, within their new Drupal site, and within the “getting started” documentation here on Drupal.org.

Adam S’s picture

This has nothing to do with Drupal Core.

If people can't figure out that Drupal can be extended, sadly, they are not going to figure out how to use all the modules to extend Drupal so it doesn't matter. The best way to show people what Drupal can do is focus a little on the installation profiles like OpenPublish, OpenPublic, OpenAtrium, NodeStream, Managing News, eRecruiter, ArrayShift and Commerce Kickstart. Also, give the option to install them with demo content.

Selling Drupal core and modules to people who can't see that it can be extended is like a real estate agent walking a client into a Home Depot and saying this is the house they are about to buy. Rather it would be wiser to walk a client into a completed house preferably with show furniture.

You guys are the smartest people on earth. I wish for a moment I could just show you my point of view.

yoroy’s picture

So if we observe smart, web-savvy people who are trying out Drupal for the first time and we see they do not find out about one of the defining traits of the software (extensibility) it is simply their mistake and they should've downloaded something else anyway? How is this not a core issue?

Mile23’s picture

FileSize
987 bytes

Not sure what's so hard about this. :-)

This patch to node puts a second message under the 'There is no front page content on this site' message. The second message only appears if there is no front page content, and if the current user is an administrator. It tells the user that they can extend Drupal with modules and themes, and gives links to the download page, and a module how-to page.

TODO: Update URL for D8 how-to page when it gets written.

Adam S’s picture

Across the board, the usability testing participants we tested at UMN did NOT understand that you could extend Drupal.

I think that the problem with this might be the people who conducted the tests or how the tests were conducted and not Drupal core nor the users being tested.

module -- a separable component, frequently one that is interchangeable with others, for assembly into units of differing size, complexity, or function. (source)

The single best word to describe what a module does in English just happens to be 'module' which is correctly 1 out of the 10 most important words in Drupal. How do I know that it is that important? Because there are ten words in the toolbar. If the user's first language is English and they don't know what a 'module' is then, yes, I would suggest that they start with building Facebook pages before moving up to Drupal.

I don't think this has anything to do with how smart the test subjects are or Drupal core. There is a saying in Cambridge, MA that "Harvard students make fun of MIT students because they don't know how to read and MIT students make fun of Harvard students because they don't know how to add." If, for the the test subjects, 'the word "Modules" means nothing to them,' perhaps they made a HUGE mistake choosing the people for the test. Instead of 'web savvy' people, they could have used English savvy people from the Literature Dept. at UMN who just might have figured that out a bit quicker because there is no single word in English that defines, describes or qualifies what a Drupal module is than the word 'module.'

However, this is probably caused by the problem with the test. I'm going to guess that the people who conducted the test didn't have the test subjects download it from drupal.org and follow the instructions from drupal.org which almost every other first time Drupal user does because it would have jumped out them no matter what their English reading skills are when they landed on the Drupal Start page that Drupal can be extended.

Once they got to Drupal.org, it was incredibly jarring and people didn't realize they were still within the context of their site. The lack of integration was very challenging for people getting around.

Like I mentioned before this isn't a Durpal core problem. It's a drupal.org problem.

Think of Drupal as a development tool like After Effects or Photoshop. I would never recommend to someone who doesn't know Photoshop and wants to quickly touch up a photo to download and install Photoshop. It is not a tool for someone who doesn't want to put the time in to learn. It is a serious professional tool -- so is Drupal.

droplet’s picture

Don't Drupal UMN test captures the screen & mouse tracking ?? We are assume all possible way here is worthless. If they click Eight toolbar links and found Modules page can extent the Drupal, I don't think it is a problem. Issue Summary #2 said they can found it, let move forward to redesign modules page issue.

why not put back INDEX or modules & theme under configuration page. Almost all browsers, OS, mobile are place a button at Options page to redirect user to right place to install new software/apps.

and Why not let user to choose the modules at beginning of installation? We can tell them at that point.

Bojhan’s picture

@Adam S It is a drupal core problem, because even upon landing on the module page people did not know what it was for. Additionally there are a lot of small fixes we can do to make this more usable, par example by optimizing the tooltip. The assumption that almost everyone downloads it from drupal.org, and than installs is quite incorrect - a large number of users install it through their cpanels/direct admin.

@droplet Sorry but most of your comments are unrelated to this issue. We dont let them choose at the beginning, because its nearly impossible for new users to make an educated guess which functionality they need, especially given the fact for the difficult terms we use to describe certain functionality.

Mile23’s picture

"It is a drupal core problem, because even upon landing on the module page people did not know what it was for."

Hence my patch at #79, which explains this to the administrator when there's no front-page content. Another approach might be to put a short-lived nag msg on admin pages. Or perhaps a 'Did you know?' type message, that rotates through a series of important pieces of information like this one. It could be a core module that's installed with the standard profile, which the user could then disable on the modules page. This would teach them what modules do.

cweagans’s picture

@Mile23, we had this sort of behavior on /node in Drupal 6 and removed it because it didn't help. I don't think anyone will be inclined to put it back in. The reason that it was removed is that the text went away as soon as content was promoted to the front page.

Adam S’s picture

Another approach might be to put a short-lived nag msg on admin pages

That's fine. Perhaps, a configuration toggle to turn off the nag messages.

Having polished installation profiles that are easily accessible to new users will sell Drupal more than anything else you can think of. If on the installation page there is a choice for installing OpenPublish, OpenPublic, Managing News and especially Commerce, people will know exactly in about ten minutes why Drupal is the best choice.

What is a basic Drupal installation? A blog? If someone asks me what is the best system for a blog I suggest WordPress or use Blogger. A forum? If someone asks me what is the best system for a forum board, I say vBulletin or phpbb. I'm not going to lie to people. What a beginner sees when they look at Drupal for the first time is nothing. That should change.

Also, if people don't figure out without their hands being held how installing modules work they are not going to figure out how to use Fields, Views, Token, Panels, or most of the modules. The only way that someone will get benefit from Drupal is if they put in the time to go to Nodeone and watch all the videos or read the Lullabot book Using Drupal.

This is why pushing installation profiles on new users is a good idea. They will see what Drupal can do. They will be able to look at example of how it is configured. And, most important they will be motivated by knowing they can accomplish more with Drupal than any other system with a lot of work.

I bet $100 for the Drupal Association that if the users tested were giving an installation profile instead of a blank version of Drupal for the first hour of the two hour session none of the issues listed would have been.

catch’s picture

For the nag message I brought this up at #1164760-66: [meta] New users universally did NOT understand that you can extend Drupal as well, we don't have a pattern for this, but it's a common pattern anyway that it makes sense to support. Worth opening a separate issue for that functionality?

yoroy’s picture

Right, this brings us in 'tips' territory, needing a place *other than status/warning/error messages* to provide guidance. Oh look, I won't-fixed that some time ago. Might well deserve more discussion: #397430: Implement cross-reference links that refer to logically closely related functions.

dcrocks’s picture

Trying to keep to the issue:
1) The usability test indicates there may be a problem, but one test doesn't make this a 'terrible, terrible' problem. Though one usability test can certainly indicate that there is a problem it can't be considered sufficient to define the problem. Why not 'terrible, terrible' , well how many tens of thousands have already extended drupal?
2) This is a UI problem, not a problem with the word or concept 'module'. It may be a UI improvement to make the admin's menu label be 'extend'(or some other word) instead of 'modules' but it should still be clear that 'modules' are the objects by which this is accomplished. As an example, firefox has a 'Add-ons' menu but the objects in that menu are 'extensions', 'appearance' and 'plugins'. In Drupal, modules encompass plugins and extensions while appearance has a separate menu.
3) The usability test indicated 2(at least) problems; function discovery and function usage. How do you discover how to extend drupal, how do you actually go about extending drupal, and then, how do you find extensions beyond the standard set?

I think that is a lot to solve in one issue. I don't think there should be any issues about the word module by itself. It is an ineffective usage of time and a red herring in the issue comments. The didn't know what a module was? So tell them.

I too have wasted more space on this argument about modules but someone needs to cut this off.

Mile23’s picture

I made a Did You Know? module over on #397430: Implement cross-reference links that refer to logically closely related functions.. It's for D7, but obviously easy to port. It presents a random topic, but that could be changed. The rules are: No more than two sentences, always link to a page on drupal.org for more info.

LoMo’s picture

I really liked that idea... shame it wasn't in D7 core and I agree that this would be a useful way to help new users get used to the terminology (and other bumps in the learning curve) as they get comfortable with how Drupal works.

I still have to assume this issue had more to do with the design of the study than with how normal users come to Drupal, though I guess that for those casual users who buy shared hosting before they even know what technology they'll be using, and install with CPanel (or whatever), improving the core to ensure better understanding of how the Drupal community uses certain terms might help ("module" IS pretty ambiguous -- and many might not understand the context that equates to "extension", but might immediately understand another context of the term, even as they are searching for a term in the UI that means "extend" -- that said, I still maintain that Drupal has a steep enough learning curve that coming to grips with the most basic terminology, such as this, is the least of anyone's trouble if they really want to build more than the most basic Drupal site.)

I agree that we might want to highlight what CAN be done with Drupal and bring attention to distributions and/or make "official" distributions which people would download and install (even in cPanel or whatever).

vegantriathlete’s picture

I had suggested a dismissable overlay and @franz had followed up with a suggestion of a tutorial noting that it is a common feature for a software application to present a getting started option when you first install the software. I thought about this more this morning and came up with the idea of an optional module (tour.module ?) that ships with core that would be enabled by default. As long as that module stays enabled a user with the appropriate permissions (IOW a site administrator type) would be redirected to the tour. A question to deal with then, is whether the module would track the preference by user as to whether it should continue to display or if it would just be an enabled / disabled switch.

The tour would take the user through a number of key points in using Drupal, including (but not limited to) installing contributed modules (we might even give suggestions about commonly used contrib modules*) and contributed themes.

I agree with other comments that the critical issue is not what we choose to name "modules" (or anything else for that matter), but how we support new users in understanding Drupal's vocabulary and the things one can do with Drupal.

* For me a key factor in choosing Drupal in the first place was that there was the Blog and Forum modules, a point I wouldn't have known if they weren't a part of core. So, while I agree with the movement to remove those (and other things) from core, I also thinks it's important to educate people about those types of modules in contrib.

franz’s picture

+1 to #91

LoMo’s picture

I like #91, too. Perhaps a "Drupal guide" core module could be enabled by default (but easy to disable during the actual install process without need to go to admin/modules. The Drupal guide module could include sub-modules that can be turned off individually, including pop-up tips for users logged in as admin, tutorials, the suggested tour module, etc.

Mile23’s picture

I think this should be as simple as possible: There should be one module that can send you off to tutorials based on path. Sort of an extended version of hook_help(). A block would appear in the help region saying "How to..." with some links to the various tutorials for that path.

Tutorials would essentially be a simplified version of the old Book content type, allowing you to move through a few steps with Previous and Next links. No more than three steps per tutorial (or so).

The problem isn't that Drupal has no documentation; the problem is that there's no clear guide to what you even need to look up, so these 'tutorials' would really just be brief discussions with links to topical landing pages on drupal.org. They would be aimed at whoever is administering the site.

Drupal already gives you two installation types: Standard and Minimal. There could be a third: Standard (With Tutorial). New users could install the tutorial version and experiment, and either learn how to turn off the tutorial module or reinstall without the tutorial if they didn't need it.

Also, at some point we're just re-writing Advanced Help.

klonos’s picture

+1 for the tour.module too. Great idea!

...only instead of enabling it by default I think it should be optional. There should be some checkbox or link during perhaps the last step of installation. In other words provide a shortcut that enables the tour.module at the "Visit your drupal site" page that shows once drupal is installed successfully.

I think that the "Did you know?/How to..." balloon/help message is the best approach. To make it even less intrusive we could provide a way to hide specific help massages and a link to disable them completely (IOW a link to disable the tour.module).

LoMo’s picture

...only instead of enabling it by default I think it should be optional.

I agree that it should be "optional", but I think that for the sake of new users, the default should be "on". That way there's less for them to figure out... it'd be easy for an experienced user to "uncheck" that option in the installation setup.

klonos’s picture

Yeah, if it is a checkbox it should be checked by default (it's only an extra click for advanced users to disable it). The way it is now though there is a "Visit your new site" link. If it was implemented as a "Take a tour" link (or a button) for consistency, it wouldn't be a matter of choosing which users (advanced or new) we "force" to an extra click but rather a matter of choice:

- advanced users would click the "Visit your new site" link that simply works as in D7
- new users would click the "Take a tour" link that enables the tour.module before taking them to the site's home page or the tour start page.

As for the text in the link/button/checkbox, we could have something plain like "Take a tour" or something more "inviting" like "Find out what you can do with your new Drupal site".

Mile23’s picture

I think ideally it would be an extra install profile, so advanced users could just not install it in the first place.

franz’s picture

Mile23, advanced users have their profile already, so let's spare the creation of another profile and leave this to be enabled in the Default profile. Advanced users that use this profile already have to disable/change the enabled modules.

If #1260214: Choose your Drupal comes out, this new module could be enabled on "Drupal Starter" profile.

yoroy’s picture

Deciding on default state and location of the on/off switch for this is the least of our problems. Dcrocks in #88 points out what we should focus on trying to solve:

function discovery and function usage.
1. How do you discover how to extend drupal
2. how do you actually go about extending drupal, and then,
3. how do you find extensions beyond the standard set?

Adding tips or hints that help you connect the dots here is one option.
But before adding stuff, we should look into what could be removed as well (complexity, amount of main hubs in admin pages), e.g. we should look into re-jiggering the overall IA of admin to more naturally lead to modules and update pages as well.

Mile23’s picture

@franz: 'Choose your Drupal' wouldn't actually help for this issue. You'd end up with new users thinking that only super-advanced Drupalers who know PHP could make different distros, when in fact they can extend their site however they want with relative ease.

rlmumford’s picture

Just to throw in my 2 cents. I think the idea of a 'Starter' install profile is a good one, maybe including a tutorial video on the last page (where it says "View your new site", and more guidance throughout the installation process.

I have a friend who's looking to get into web stuff and Drupal from a place of almost no previous experience. He found the installation form hard to follow, and once the site was installed he was disappointed that their were only two content types and couldn't see the difference between them. I had to really push him to find the Content Type/Fields stuff. A install profile that walked you through this the first time would be really helpful.

I also noticed that he ignored things like the 'Menu Link' and 'Authoring' sections on the node form, as they looked like 'Advanced Settings' and he didn't feel like an 'Advanced User'.

sun’s picture

Category: task » feature
Bojhan’s picture

Category: feature » task
Anonymous’s picture

Just saw this post, and I think there is a lot of things answered by the Project Browser module. Hopefully we can get it into core: #1243332: Deploy Project Browser Server and drupalorg_pbs on d.o

I agree this is a really important thing to address in the coming Drupal 8 as well as Drupal 7 Contrib.

eigentor’s picture

Issue summary: View changes

Added Issue about wording of "module" as related.

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).

webchick’s picture

vegantriathlete’s picture

Angie,
Funny you brought this to the top again (although accidentally). I was just thinking about this issue this morning and had a thought to answer my own question from #91. The overlay module provides an example of how we could treat the tour.module. The module itself can be enabled / disabled (and is enabled by default in the standard install but not the minimal) and when it is enabled, users can decide whether they want to see it by checking or unchecking a box in their profile. If they click the "dismiss" button in the tour, it will "uncheck" the box in their profile for them. {Do you like how I'm talking as though tour.module is a given? I'm not trying to make any assumptions.}

tim.plunkett’s picture

What are the goals of this issue?

Or, rephrased, what is the reason this specific issue is a critical task that counts toward thresholds? Not the idea behind this issue, but the meta itself.

sun’s picture

Priority: Critical » Normal

Yeah. I fully agree that we should do something about this. But I fail to see why this task should block any other changes from landing, which are ready today. Please don't get this wrong - this issue totally is important.

Let's keep on exploring possible solutions, please. It would be great to resolve this for D8!

Bojhan’s picture

Priority: Normal » Critical

This is also why thresholds are such an abysmal failure, sigh. This should not hold up other things if anything demote this to major, but not normal.

If we don't dispute the criticality of this issue, I do not get why it needs to be demoted. We didn't do anything to solve this usability issue, and it is a very big stumbling block in people learning about Drupal. I know we always randomly demote usability issues, because its not important to people - but the fact that we didn't solve shit in D8 doesn't mean, the issues aren't important.

Anonymous’s picture

I believe Joomla has both 'modules', 'plugins' and 'mambots', each doing their own thing, and people are fine with it. Just keep calling it 'modules' for Drupal. Isn't this discussion also about what Drupal is for? If it's for blogging, people should use Wordpress instead. Anybody who's downloaded Drupal themselves, knows it's extendable, right? But if your test panel is the Wordpress crowd, it makes sense that they don't know what to do with Drupal. That's because they should be using Wordpress and Drupal is not competing with Wordpress.

rafamd’s picture

Agree with #106. Changing the wording for "modules" isn't the solution to this problem. We can still rename the label in the menu to "Extend" (in sync with the "Download & *Extend*" section on d.o) or something like that, a-la Appearance -> Themes. This approach would be more future proof for apps, features or whatever else is made available to extend Durpal.

and then yes, explore other things such as project browser ...

main point: leave modules alone :)

webchick’s picture

I'm sick and tired of this issue taking up a slot in the critical tasks queue and preventing other D8 features from being committed.

I think the following things are clear:

- Changing the word "Modules" wholesale isn't going to fly. There's 12 years of legacy knowledge to un-learn (not to mention file extensions on every file, etc.), and there's not a clear terminology winner when we look at other systems that would take its place.
- The word "Modules" is nevertheless extremely difficult/obtuse for normal, non-Drupal people (we have mountains of evidence to support this), so it can't be the only means of identifying this all-important page.
- Therefore, we should change the label in the toolbar to something else, same as we've done with Themes (Appearance).

All of the other top-level items in the toolbar are nouns (Content, Structure, Appearance, People, Modules, Configuration, Reports) so "Extend" will not work as the replacement, because it is a verb. "Features" and "Apps" and "Plug-ins" all have pre-existing Drupal notions, which are different than what Modules means. The word "Extensions" does not have this connotation, it is a noun, and it ties in with Drupal.org's labeling of "Download and extend" as the primary navigation to the place where you download this stuff.

THEREFORE. Can we please get a one-line patch to change the Toolbar label from "Modules" to "Extensions" and thus close this issue? Further enhancements could be done in non-critical tasks that do not block other peoples' features.

webchick’s picture

And if this isn't sufficient to close this issue, then please propose an alternate implementation plan. But we can't keep wandering around for another 100 comments and halting progress on the rest of D8 in the meantime.

tim.plunkett’s picture

Status: Active » Needs review
FileSize
493 bytes

Works for me.

webchick’s picture

Assigned: Unassigned » Bojhan
Status: Needs review » Reviewed & tested by the community

Yay.

Assigning to Bojhan for review.

cweagans’s picture

+1 on this solution and on the patch, FWIW. Easy fix and having different terminology for developers and end-users sort of makes sense.

Status: Reviewed & tested by the community » Needs work

The last submitted patch, drupal-1164760-115.patch, failed testing.

tim.plunkett’s picture

Status: Needs work » Reviewed & tested by the community
FileSize
3.99 KB

It was checking for "Modules" in the upgrade path tests. Back to RTBC.

DamienMcKenna’s picture

Short of calling it "thingies", "whatsits" or "free monkeys", +1 for changing the name, though I think more people would understand the word "plugins" but I understand the concern over namespace confusion. (not meaning to feed the trolls or drag it out any further, but would that really matter?)

David_Rothstein’s picture

Status: Reviewed & tested by the community » Needs review

Sorry, but this change really needs more discussion. Also, changing the toolbar item is being discussed extensively at #1167458: New users do not know to click on 'Modules' to extend their site ("Extensions" was proposed there too at one point) and we shouldn't have two issues trying to do the same thing, should we? (I thought the issue here was supposed to be the meta-issue only, which could be lowered in priority once enough other implementation issues had been completed to make the problem less severe.)

Anyway, the problem I see with "Extensions" is that it directly competes with "Modules" rather than complements it. If I am new to Drupal and see the word "Extensions" so prominently on my site, I am going to assume that "Extensions" are something I can search for (e.g. on drupal.org) and download from there and use... But we use the word "Modules" everywhere else so I'd be pretty confused when I got there and couldn't find any such extensions. Having two words for the same thing actually has the potential to cause more confusion than it solves.

This is not the case for Appearance/Themes; there, the two words complement each other but don't try to define the same thing. Instead, it's pretty widely understood (by native English speakers, at any rate) that "appearance" represents the thing about your site that you are trying to change, not the tool you're using to do it (that is, it's not too likely that a native English speaker who sees "Appearance" in the toolbar is going to think that they can go to drupal.org and search for "appearances" to download...)

I think if we are going to replace Modules in the toolbar we need to seriously look for a word that has a similar relationship. The suggestion from #1167458: New users do not know to click on 'Modules' to extend their site that always made the most sense to me was "Functionality". It's not perfect by any means, but I think it gets the point across, and the analogy between Appeareance/Themes and Functionality/Modules is a strong one.

I'd at least be pretty curious to see how it tested with actual users (especially in comparison to Extensions), which is something that would be really useful here regardless.

David_Rothstein’s picture

Er, also, looking at the patch:

   $items['admin/modules'] = array(
-    'title' => 'Modules',
+    'title' => 'Extensions',
     'description' => 'Extend site functionality.',

The word "modules" should definitely be moved into the description, I would think. We're not trying to hide it from people completely.

This also raises the question of where else the word would need to be changed. For example, themes live at admin/appearance (not admin/themes), so should we really keep admin/modules as the path or change it also?

kattekrab’s picture

Description => 'Extend site functionality with modules available from drupal.org'

Also - functionality is the word that keeps being used to describe what modules do...
So could the label be Functionality or Functions ?

In which case...

Description => 'Add functionality to your site with modules available from drupal.org'

or

Description => 'Add functionality with extra modules available from drupal.org'

stevetweeddale’s picture

Apologies for contributing to the bikesheddy-ness...

But (IMHO) 'Functions' or 'Functionality' seems like an awful name for it! ANY of the menu items could be said to relate to 'functions' or 'functionality' of the site! Extension directly communicates the sense in which you're "Expanding, increasing, adding to" your site, which is what we want.

However, this is just my opinion. When the usability testing was done was any feedback taken on what might better describe the 'Modules' menu item? Feels like that might silence this debate.

kattekrab’s picture

Let's leave it at Modules... but explicitly add something like

"You can add functionality to your site by installing Modules"

somewhere visible, and prominent.

I am not a fan of Extensions either to be honest.

We need to do a better job of describing what modules are, where to get them, how to configure them... etc.

I'd close this as won't fix, and just leave it as Modules.

Let's find other ways to let new users know they can extend Drupal with Modules.

LoMo’s picture

I agree with #126 and also don't think it would be so bad to have noun links and a verb link ("Extend") as an alternate solution. At least, then, we are not calling modules by the name "extensions" and confusing newcomers even more. Click on "Extend" and you are on the "Modules" page, so it should be clear that modules "extend" a Drupal site. A title attribute, e.g. "Modules extend the functionality of your site" on the "Extend" link might help even more to clarify this.

EclipseGc’s picture

Changing our terminology on d.o slightly to reflect the term "Extensions" shouldn't be that difficult. As webchick already mentioned, we currently have a "Download & Extend" in our links. Module and Extensions actually go hand in hand quite nicely "Module Extensions" or "Extension Modules" both make perfect sense. If we're going to be pedantic then d.o currently refers to these and themes in the generic "project" notation for the most part, and while that's totally understandable, the fact remains that our messaging on d.o is mixed and that's less of a problem than the fact that people don't even know they should/could go looking for modules to extend their site.

#114 makes perfect sense to me, so does #123. To be honest, I'm not sure I've ever (even when I was new) seen the text we're discussing in #123, so while I agree with the notion, we should not depend on it. The title needs to be changed, "Extensions" is worlds better than the "People" change.

The debate here seems to have been pretty heavy for a while, I realize I'm just wading into this now, but... If we already have messaging problems on d.o (which we all know we do, and we've put in a lot of work to fix it already and require more still) and the problem is that Drupal itself needs a fix before that even matters, then I ask a simple question: If we were to make this change, how much would it matter in 5 days? Because as best as I can tell, this issue is likely to still be hot in 5 days if we can't settle on a consensus here.

TL:DR: Drupal & Drupal.org are both broke, fix Drupal now, that's easy and will expose the relative brokenness of drupal.org, which we can fix on a different issue.

Eclipse

Bojhan’s picture

Assigned: Bojhan » Unassigned
Status: Needs review » Reviewed & tested by the community

I am support of this change, I think using the word "Extension" allows us to better communicate what that page is about.

Although I understand the fear we might be introducing a competing label, the same fear was for Appearance and it had little to no impact on the ecosystem. I understand David raising concerns, but to be frank - I don't think we will ever find a perfect label - most concuss is around Extension for good reasons. The problem we are trying to solve here is two fold, getting people to the modules page to learn there is a possibility to extend and actually extending Drupal (which is not tackled here).

I understand the resistance to change this, but that is only natural as this is one of the most front facing labels. @David is right in saying, we should find a way to combine this better with d.o but as EclipseGc mentions that might not be such a challenge.

Lets also remember, we are only changing a label and we are not even in feature freeze yet if we find through usability testing or other measures that it is a unfit label - we can still change it.

David_Rothstein’s picture

Status: Reviewed & tested by the community » Needs review

Regardless of anything else, #123 means this is not RTBC (I'm only leaving at needs review rather than needs work because those are smaller issue in the grand scheme of things; the overall idea is what needs review).

The concern isn't limited to drupal.org (that was just an example); it's about the use of competing words to mean the same thing regardless of where they're used. As I mentioned, this is different than the situation with Appearance. The best example I can compare this to is that in Drupal 5 (and perhaps earlier?) "Categories" and "Taxonomy" were both used in various places in the Drupal UI. This was widely considered to be a big mistake and was removed in Drupal 6 so that now we call it "Taxonomy" everywhere (see #192209: Taxonomy module terminology for the history). Can someone explain why this situation will be different?

Lets also remember, we are only changing a label and we are not even in feature freeze yet if we find through usability testing or other measures that it is a unfit label - we can still change it.

For Drupal 8 we are supposed to be testing big changes before they are committed, not after (http://drupal.org/core-gates). This is a small patch, but a big change :) In this case, it's not quite as crucial because we know from previous testing that the current situation is really bad and it is hard to imagine it getting worse. However, introducing two words to mean the same exact thing is the one way I can imagine it potentially getting worse. Although it's very likely that "Extensions" will do well at getting people to this particular page more easily than "Modules", the question is whether it will cause harm/confusion in other ways.

When the usability testing was done was any feedback taken on what might better describe the 'Modules' menu item? Feels like that might silence this debate.

That is a good question. In the 2011 University of Minnesota testing I believe this was discussed a bit with some of the participants at the end but I can't remember if it got as far as asking for specific suggestions - would need to check the videos, I guess. One problem with that is that in describing tasks for the participants to do, the test purposely avoided using the word "modules" and therefore deliberately used some other terms in the instructions ("functionality" was definitely one of them) so if people were asked for suggestions after that they may have been biased a bit by the alternate terms they had been given earlier.

sun’s picture

Just to amend @David_Rothstein, while I don't have a better suggestion, the word "Extensions" technically and also logically means more than just modules; it also means themes and installation profiles. I've been a strong supporter for pushing the extension terminology as a "catch-all" into core, as it simplifies a lot of things. Using the term for a fake-reduced/limited meaning of only modules in the UI potentially leaves us in an even more confusing state, since users might start to talk about extensions but only mean modules in reality. But as mentioned, I don't have a better alternative to offer.

Lastly, may I add that it is highly confusing to have parallel discussion threads here and in #1167458: New users do not know to click on 'Modules' to extend their site on the identical change proposal...?

Bojhan’s picture

@David_Rothstein Oops, sorry regarding status! Yes, lets discuss this some more!

I don't think we can really test this, not because its not possible from a research perspective. But because the gates estimates our resources would have grown, it didn't and we can't waste resources on just a label change and quite frank, what needs to be tested goes beyond that and extends to long-term use age and d.o use age.

My personal feeling is that you are overestimating the impact this will have on the overall experience. I believe it will be similar to Appearance and have little to no impact, then again we should definitely really consider the possible wider impact.

almaceria’s picture

Perhaps, finding a word to be used instead of modules is hard because drupal modules comprises powerful, important and heterogeneous entities: they can be whole solutions, simple tools, or small pieces of code that extends a certain feature. Although the term "Modules" defines accurately what it comprises, it's also a word too abstract to be perfectly-understandable by any sort of users (something that the UI tests have brought up). If Drupal is intended to expand its customer base, it has to deal with new kinds of users that certainly won't have any coding background, and that will find the term "module" bizarre or weird. In this scenario, what have worked during last 10 years may not work for the next 10.

What tasks do we want the users to perform in the modules page? (please, correct me if I'm wrong)

  • To learn / be aware of extensions available in their Drupal installation (a list of enabled/disabled modules)
  • To add or remove functionality into their installation (to enable or disable modules)
  • To know if there are new releases/updates available for their installed extensions
  • To search or browse in a repository so they can add new extensions to their installation (to browse drupal.org modules)

(Since I don't want to divert attention from this thread issue, I would just say that I think the modules page could offer all this functionality if it had a more simple layout: One tab listing the installed modules (each one informing if is enabled/disabled, if there's an update, and a button to uninstall it), and a Second tab for search / browse drupal.org modules section.)

I can see a lot of similarities with what we do in our phones or PCs with app stores.

What if we step forward and call Drupal modules, "Applications"? Well, if you think this term is not accurate for what a Drupal module is, I will totally agree with you. However, I can see some benefits using this term, to be considered:

  • Users will probably think on applications as packages that extend or bring new features / functionalities into a system.
  • Applications are supposed to run over a platform. This highlights the fact that Drupal, more than a CMS, is a platform / framework that can be extended easily when running (enabling) new or different applications.
  • Applications need to be installed to run, and can be uninstalled from your system if you don't want them anymore (it sounds like modules)
  • Users are beginning to get used to browsing on App Stores (Apple, Android, Google,...), looking for new features to be added into their systems.
  • There are complex and simple applications, just like drupal modules.
  • The term "application" can be easily localized into different languages.

Going forward, Drupal.org modules page can be renamed to something like "Application Center" / "Application Catalog", etc. In the same way that "Class", or "Object" remains as programmers jargon, I see "Modules" more like a drupal developer terminology than as a user-friendly word.

I hope I have not add more confusion to the thread. Please, don't be mad at me: just willing to help.

sun’s picture

@almaceria++

Apps "slightly" clashes with Apps, but at least the intention and purpose is essentially the same, and it's almost a given that today's users understand this term almost universally (due to the branding of this term in the mobile sector and web browsers).

xmacinfo’s picture

Status: Needs review » Reviewed & tested by the community

Users are not plugging Drupal, nor appffying Drupal and neither moduling Drupal. But they can extend Drupal.

Please leave this as RTBC and let's use extensions. :-)

klonos’s picture

Status: Reviewed & tested by the community » Needs review

While reading the first half of #133 made a lot of sense to me, on second thoughts...

"Applications" might confuse people to think that they'd use that link/menu item to apply for something (I don't really know since English is not my native language, just saying). Easy fix is to use the shorter alternative "Apps"...

"Apps" makes me think that we are shifting to a Drupal app-store. I'd absolutely hate that! If I wanted that I'd be using Joomla. Talking about Joomla...

If one was to take a quick look at the market share for CMSs during the last past year taking into account only the top three ones, they'd notice that WordPress is definitely the lead and only has minor fluctuations (if you consider that it holds ~54%). So lets take it out of the equation and focus on Drupal and Joomla. They've been steadily going down and we've been steadily going up. So...

Perhaps it'd be relatively safe to conclude that most of our newcomers originate from Joomla. Right? Well, they use the term "Extensions" for their "thingies". Should we just use that in order to make sense for the majority of our newcomers then?

xmacinfo’s picture

Status: Needs review » Reviewed & tested by the community

Looks like klonos cross-posted. :-)

EclipseGc’s picture

Status: Reviewed & tested by the community » Needs work

for reasons stated in #130 this is needs work, can someone reroll?

rlmumford’s picture

It does feel like "Extensions" is the best idea that's been had yet. In reference to @sun in #131 could we have the top level menu item as "Extensions" with "Modules" and "Themes"/"Appearance" as tabs underneath? This would give some context to the word modules, which could aid understanding as well as providing a suitable menu location for the apps and features UI.

IIRC Drupal 8 is trying to cut down the number of items in the toolbar anyway, so this would fit quite nicely into that aim.

EDIT: I've just noticed that @naught101 proposed this in #53. So here's a +1 for his suggestion.

LoMo’s picture

I think we are over-discussing this. My recommendations follow:

Re 123:

  1. Keep the link as "Extensions" (Otherwise change "Extensions" to "Extend" in that link and don't care that the other links are all nouns.)
  2. Keep the path admin/modules
  3. Don't change the word "Modules" to "Extensions" anywhere else
  4. Fix the link description so it includes the word "modules", too.

I think this will be clear enough not to confuse anyone who already uses Drupal, won't break other module's paths to "admin/modules/*", and will help newcomers to Drupal understand that when they click on the menu link for "Extensions" (or "Extend"), that "modules" are the primary mechanism for extending Drupal... then Drupal.org's use of the term module will not confuse them, either. Every book on Drupal, all over this site, and in countless blog posts, we use the term "modules", so we should not try to actually change the term anywhere but in the link name.

Just my 2¢.

catch’s picture

Note there's #1331486: Move module_invoke_*() and friends to an Extensions class open which is going to need to handle themes to some extent as well. Not sure if that's a good or bad thing in relation to the suggestion here.

rafamd’s picture

#122 may pretty much sum it and "Functionality" could be the most acceptable alternative for the label. I'm not 100% convinced myself either, but at least a search on this page reveals we naturally use that word to refer to what we are talking about. Maybe we can also move Appearance to be between People and Functionality, so that Appearance and Functionality are together.

yoroy’s picture

I don't think that changing the label will significantly help fix the actual issue at hand: people not finding out about Drupal extensibility. That's ok, we just shouldn't spend too much time overthinking which label to change to. 'Extensions' is a good candidate. I tend toward 'Extend' because that's what we use on http://drupal.org/start as the trigger word for leading people towards modules on d.o. (but we don't really know how effective that page is in doing so).

Since this is a meta-issue, I'll throw out some other ideas:

Add sample content that gives useful hints on how to go about extending core functionality

At least that would bring this info to the middle 'content' part of the page for a while. People tend to focus on that area of the screen.

Point towards contrib solutions in context of specific functionality

For example, a pointer to Views on the content listing page or near the setting for amount of items shown in listing pages:

Mockup showing a link to Views added to the description for the 'Number of posts on front page' setting

Or mention Display Suite on the 'Manage display' tabs for content types in Field UI:

Mockup that adds a link to Display Suite at the bottom of 'Manage Display' pages

Instead of referring to individual modules is too controversial, link to search results per category in http://drupal.org/project/modules:

 Find modules that extend the Fields(link) and Display(link) options

Rework the administrative information architecture

Minimize the amount of top level links in the toolbar. Put a lot of things under 'Settings' or 'Site', help people narrow things down from there.


Lets start with changing that label. This discussion is as 'meta' as they come though, so maybe best to do the actual patching and committing in #1167458: New users do not know to click on 'Modules' to extend their site afterall? Calling this deep deep issue fixed after a single change in labelling seems silly.

webchick’s picture

Hey, yoroy! Nice to see you! :D

If we want to re-purpose this as a meta / brainstorming issue, then we cannot keep it as a critical task that blocks other D8 patches. Tasks have an end, meta / brainstorming issues do not. I would also suggest that if we want to kick off another brainstorming exercise around this, g.d.o/usability is a much better place than an issue with 140+ comments.

In order to close the "criticalness" of this critical task, and stop blocking other D8 features, the plan proposed by LoMo in #140 makes sense. I can please have patch?

David_Rothstein’s picture

I don't think we can get away with leaving the admin/modules path in place. That would make this menu item inconsistent with all the others.

Also, we'll at least have to change the terminology in some other parts of the codebase, since there are places that refer to "Modules" in the specific context of a menu item and/or page title. Here's one example I found via a quick search:

./core/modules/system/system.module:      return '<p>' . t('The uninstall process removes all data related to a module. To uninstall a module, you must first disable it on the main <a href="@modules">Modules page</a>.', array('@modules' => url('admin/modules'))) . '</p>';

A patch that got started on those changes would definitely be great, though, because regardless of what term we choose in the end it should basically just be a simple find/replace on the patch file to use something else.

As for where that patch should live, can't say I care much as long we have somewhere to keep working on more far-reaching things like @yoroy's idea :) (Which looks very promising, and jives very well with what I remember thinking/seeing people specifically struggle with during usability testing.) This is a meta issue (and seems to have been labeled as such from the beginning), so another option is to keep doing that here but lower the issue priority, then reopen #1167458: New users do not know to click on 'Modules' to extend their site as a critical issue and focus on the patch for that specific problem there. Whatever works...

sun’s picture

Let me respectfully disagree with @David_Rothstein - this would not be the first router path that uses a different label than the internal router path argument. And even more so, as along as the actual page does not allow to manage all extensions but only modules, retaining the router path and only adjusting its label is technically the appropriate thing to do.

I already stated so in many other issues and won't stop to repeat myself: In general, we need to get over the idea and (bad) habit of hard-wiring internal terminology to user-facing terminology. We can freely change the entire UI at any time to improve the user experience and make more sense to humans, but that does not and must not mean that we have to change the internal/technical terminology at the same time. Requiring this (IMHO utterly wrong) hard-wiring for every single UI change to internal/backend stuff is one of the primary barriers and blockers for making the Drupal user experience awesome. The UI and API are detached. There's absolutely no reason for why they have to be consistent. And if it turns out that a particular UI change would also introduce much more sense to the API/backend side of things, then we can happily adjust that later on.

I know it will take time for this to happen, and it might as well deserve its own issue + discussion. But since yet another massive API change is being proposed here on the sole argument of consistency, I couldn't resist, sorry! :-)

yoroy’s picture

Hi webchick :) Yeah, forgot to add that I do know [meta] issues shouldn't be critical.

Whatever works best to: 1. Change the label already 2. Have a place to continue the overall discussion (that might spawn new major or critical tasks). I have some experience that tells me groups.d.o is *not* the right place to do that since it will get repeated here in the queue anyway so might as well keep this one going. So I would suggest re-open #1167458: New users do not know to click on 'Modules' to extend their site for the label change and demote this to major. I'll leave that to someone who can bring the actual patch though.

LoMo’s picture

FileSize
4.2 KB

Re 144: Hi, webchick! It was nice seeing you in Munich. :-)

I agree, keeping this simple and getting this fixed are both important. The only difference between the attached patch and the previous one is:

   $items['admin/modules'] = array(
-    'title' => 'Modules',
-    'description' => 'Extend site functionality.',
+    'title' => 'Extensions',
+    'description' => 'Add and enable modules to extend site functionality.',

i.e., the description is the only line I changed. Otherwise this should be the same as the patch from tim.plunkett (#120)

I agree with sun. There is no reason the visible UI and underlying paths HAVE to be the same and small tweaks to UI definitely should not require other (massive) code changes. I think it will be clear we are only displaying the word "Extensions" to help people find the "Modules" administration page. Nothing else needs to be changed for this (elsewhere in core or contrib) except for the UI-based tests that tim.plunkett already fixed in the original patch.

LoMo’s picture

Status: Needs work » Needs review
webchick’s picture

Status: Needs review » Reviewed & tested by the community

Awesome!

I also agree that human-readable and path URLs can differ. I realize that this creates somewhat of an anomaly as becoming the only one on the Toolbar that doesn't, but OTOH IIRC the choice by Mark and Leisa to use the word "Modules" rather than a more "normal human-friendly" word (like "Appearance" instead of "Themes") is that "Modules" is such an important, central concept in Drupal. So I would stand by the decision to keep this important concept user-facing, both in the description and in the path name. I think it would be a great way to transfer this concept to new users so they understand it innately.

(Btw, I strongly disagree with making this renamed "Extensions" label a catch-all for themes and other ways to extend Drupal. People can find theme-related stuff right now very easily, and I personally feel I'd need extensive usability testing that proves that somehow it would be more findable under a more generic label rather than a specific one, even if that more general one is more technically "neat/organized." But anyway, that's definitely a debate for another issue... a non-critical, non-150+ reply issue ;))

Bojhan’s picture

I was hoping to discuss this with David over IRC some more, but I also think that its best to move this in and discuss further improvements to the flows around this concept.

Let's get this in, and follow up brainstorming about additional ways to make this more clear.

David_Rothstein’s picture

Status: Reviewed & tested by the community » Needs review
FileSize
39.94 KB

I think it will be clear we are only displaying the word "Extensions" to help people find the "Modules" administration page. Nothing else needs to be changed for this...

Maybe, but that's not what the patch does. The patch renames the page title from "Modules" to "Extensions" also (see attached screenshot). There is no longer any such "Modules" page after the patch is applied, so we can't leave help text behind that refers to a page which doesn't exist.

If the patch were changed so that the menu link is the only thing that's renamed and the page title stays the same, then maybe this actually does make more sense (to leave the other references and the URLs intact), though.

David_Rothstein’s picture

I also still don't think we've had much discussion of the two fundamental issues with "Extensions" that have been raised (the issue @sun brought up in #131, plus the one I brought up earlier).

For mine, I'd still be very interested to hear someone explain why they expect having two separate words for the same thing to go better than Drupal's historical experience with "Categories" + "Taxonomy"... (Although, if only the menu link is renamed and not the page title, that would lessen my concern at least a bit.)

LoMo’s picture

Re 152: You are right. It does also set the H1 for the Modules page, which is less than ideal. But since the page has multiple mentions of “modules” in the top matter, and no mention of “extensions” (other than the page and link title), they will soon see that modules are Drupal "extensions".

But this is another reason I'm more drawn to the idea of using "Extend", rather than "Extensions". Yes, it’s anomalous to have a verb link, but maybe this anomaly helps bring attention to the link... it's also more accurate at the top of the "Modules" page. Plus "Extend" is four characters shorter than "Extensions"… What else does it have in its favor?

Extend replaces word “Modules” rather than “Extensions”

Well, if others agree that "Extend" might be better… Here's another patch.

David_Rothstein’s picture

The more I think about it, the more "Extend" makes sense to me. It completely addresses the earlier concerns I had, at any rate.

If we wanted to deal with the it's-the-only-verb problem, there's no reason it has to remain the only verb. (Perhaps we would consider renaming "Configuration" to "Configure"?) And come to think of it, "Structure" is already a verb if you choose to read it that way.. and "Help" also, to some extent :)

We certainly wouldn't be the first software project to mix nouns and verbs in the top menu, either. As I type this, I'm staring at the following list in the top menu of Firefox, for example:

  • File
  • Edit
  • View
  • History
  • Bookmarks
  • Tools
  • Help
kattekrab’s picture

I like extend.

I like the callback to D.O. that implies "Download and extend"

I also don't have a problem with mixing verbs and nouns. If that is a rule somewhere, let me see it.

Otherwise... I think this is a good 'un.

kattekrab’s picture

Status: Needs review » Needs work
+++ b/core/modules/system/system.module
@@ -718,8 +718,8 @@ function system_menu() {
+    'title' => 'Extend',
+    'description' => 'Add and enable modules to extend site functionality.',

+ 'title' => 'Extend',
+ 'description' => 'Add and enable modules to extend site functionality.',

Yep this works for me. Can't speak to the rest of the changes technically - so will leave someone else to RTBC this.

16 days to next Drupal core point release.

jthorson’s picture

Status: Needs work » Needs review
chx’s picture

Status: Needs review » Reviewed & tested by the community

Solving this meta by a 4kb patch with an actual change of 2 LoC is too delicious esp after #155-157 to just let it sit.

webchick’s picture

Okie doke! :) The correlation to Firefox toolbar makes a lot of sense. "Extend" solves everyone's problem, I think!

I'll leave it another 24 hours before committing, but please bear in mind that this issue blocks other features in D8, so unless you have a hugely compelling reason to mark it "needs work" (along with a counter-proposal), I'd much rather handle subsequent tweaks to this in follow-up issues.

webchick’s picture

Status: Reviewed & tested by the community » Fixed

Ok, 22 hours is close enough, I think. ;)

Committed and pushed to 8.x. YAY!!!!

I also added a change notice for this at http://drupal.org/node/1780854 so we can mark this straight to fixed.

Thanks everyone for your speedy work to close out this long-standing critical issue. Let further brainstorming flourish in non-critical sub-issues. :)

LoMo’s picture

After almost 16 months and ten times as many comments, I'm happy to see this one put to rest.

One of the "non-critical sub issues" I'd love to see implemented in D8 is #397430: Implement cross-reference links that refer to logically closely related functions. (mentioned by yoroy, above). Such tips should be non-intrusive, but displayed by default in new installations to help newcomers over the learning curve.

The other thing that would definitely be a big help is integrating the experience of searching/browsing/downloading/installing new modules directly into the Drupal site so that users are not redirected to Drupal.org, but instead browse d.o contents (modules/themes/etc) from within their own Drupal installation. I think this issue might be one of the closest to describing this: #395478: Plugin Manager in Core: Part 3 (integration with installation system)

Bojhan’s picture

Priority: Critical » Normal
Status: Fixed » Active

Should we keep this open, as its meta issue capturing a conceptual problem that is not solved solely by a label change. We need to add more in-context pointers and fix the module installation process.

LoMo’s picture

I'm not going to be presumptuous enough to put the status back to fixed, but while I agree with #164 in the sense that there are UX issues surrounding this which should still be handled, I do think those should be in separate (related) issues.

I think we can assume that new users starting with Drupal will now understand that they can extend the core installation, so I personally feel that this can stay "fixed".

I only added the links in #163 to indicate where "non-critical sub-issues" might already be active.

webchick’s picture

Yeah, I too believe the "letter" of this issue has been fulfilled, so "fixed" is appropriate IMO. The "spirit" of it would be better served by a set of non-wandering and aimless, non-bickering over issue priority, non-160+ reply issues.

kattekrab’s picture

Status: Active » Needs review
Issue tags: +Needs issue summary update

My brain is kinda fried - so what I'm about to say may make no sense, but worse, I'm not able to put this into practice right now.

I agree with Bohjan that the meta issue this little "fix" was exploring is still unresolved.

I think this issue should be marked closed (fixed)... BUT, and it's a big but, good stuff was discussed here, rehashed, rethought...

Someone could write a good issue summary out of it... and include links to the other places where similar gnarly problems are being discussed - and use that to create a new issue.

but... that could just be madness from a sleep deprived mind.

Anyway - I'm tagging Issue Summary Initiative just in case, and marking needs review.

droplet’s picture

Any follow up UX test for the new NAME ??

LoMo’s picture

Re #168, see #132: No budget for a new UX test for this, but hopefully we'll get some feedback from the community... and hopefully the community can provide some testers who are "new to Drupal".

I think we have to assume this is a step in the right direction and that if we make the other proposed changes (e.g. "tips"; in-site module browse/search/download; and core upgrades), this will all improve the intuitiveness and UX for newcomers.

cweagans’s picture

Rob C’s picture

Anyone required some feedback? :)

I only just found this issue, wish i would have found it earlier. I already coded an initial something that i called 'Extend suggestions'. (was on my way to rename it to 'extend info', when i found this issue.)

The idea: A suggestion per form_id or fieldset. Local module to cache suggestions from the d.o. site. On d.o. 2 new content types: 1. the suggestion and 2. the link to the form_id / fieldset. If no suggestion / link exists, nothing is shown. And it's a separate module, so people can uninstall it easy.

The link can have a status, style, message value, key = fieldset / form_id / page / etc, placement (left/top/right/bottom/before/after), repeat (go nuts) and i even started working on a kind of 'display type', so we could use it on even more places / even more dynamic.

More info on what i am working on is available here. (some screenshots demo'ing this a bit) I also created a demo site, that's even able to render a video as a suggestion, but that was just to see how it would look. (but interesting enough to work on). (still need to update the info page, only a couple very rough screenshots exist now, but it's the same idea as i see here.)

I even whiteboarded a bit with 2 friends on this couple days back, and now i find this issue :/ To bad, anyway.

Great work all, this is definitely going in the right direction! (but i'm not sure if listing specific modules is going to work like we all hope, maybe it will if it's not a static value i figured.) (if it's dynamic, we can change it, educating our user base as we go. And this way we can also inform them of awesome new developments and such and promo the latest and greatest in a more prominent way then others. (text string VS image / video) (and also inform them of other important events/developments)

If there's anything i can do, if there's something planned (next to what i read here), i volunteer with at least couple hours a week to work on it. I believe this is possibly 1 of the most (if not the single most) important bridges to cross.

Anonymous’s picture

@Rob - I like it. Reminding users that Drupal can do much more is a good thing, though it might get annoying if the users are more advanced. Perhaps we could have it be part of the standard profile and advanced users can turn it off by disabling the module or flipping a setting?

I think that we need to lower the threshold for both letting users KNOW they can extend Drupal as well as making it EASIER to extend Drupal. So many people who I've spoken to have no idea how to install a module, even with the new install by URL thing in Drupal 7 (which was super handy). That's why I'm pushing for getting Project Browser Server deployed to Drupal.org so that users can browse and install modules right from their admin pages on their site: #1243332: Deploy Project Browser Server and drupalorg_pbs on d.o

yoroy’s picture

@Rob C: yes, a system to provide hints and tips with context-sensitive suggestions for extra modules would be great. #397430: Implement cross-reference links that refer to logically closely related functions. awaits your input :-)

agentrickard’s picture

See #1838514: "Extend" breaks parallel construction for a style issue first noted in #155. I strongly disagree about mixed noun/verb.

agentrickard’s picture

That issue got shot down.

Here's the rule that noun/verb mixing violates. Parallelism

Not using parallelism hinders reading comprehension.

webchick’s picture

Yes, which is why it was suggested to make more of the nouns into verbs (e.g. Configuration -> Configure) so we wouldn't be violating that rule. See #155. Actually, please see the entire issue; it's more than a little frustrating to have people spinning off sub-issues that directly contradict the consensus we worked very hard to reach here.

agentrickard’s picture

Yeah, sorry, I didn't know about this one. We should pick one. Nouns or verbs and not mix.

naught101’s picture

@agentrickard: That's nonsense. Parallelism applies only to a single sentence, and each menu item constitutes its own sentence. Each should be designed for maximum clarity, and "extend" is far clearer than "extensions", and others are more or less impossible to make into a verb (ie. "structure").

dodorama’s picture

@agentrickard: I understand your concerns but it's common place to mix and match verbs and nouns on UI. Just because I can see it now, here's what's on my Safari menu bar:
File, Edit, View, History, Bookmarks, Develop, Window, Help

David_Rothstein’s picture

"Structure" already can be either a noun or a verb (as stated earlier in this issue), and the comparison to web browsers has been discussed also... In short, this has really been discussed to death above so let's not repeat that discussion unless there are new points to make :)

But, we really should get that "Configuration" => "Configure" renaming done. I think changing that to a verb would remove a major cause of why "Extend" looks awkward currently. I created an issue with a patch here: #1839032: Rename the "Configuration" menu item to "Configure"

agentrickard’s picture

I'm going to drop it. I could argue all day about why each of the above points are wrong, but it's apparently pointless.

@naught101 in particular is entirely wrong. Parallelism applies to any scannable list.

Robin Millette’s picture

I was going to make a joke proposing to rewrite core in Loglan since it makes no distinction between nouns and verbs, but now may not be the right time ;-)

David_Rothstein’s picture

Re #168:

Any follow up UX test for the new NAME ??

It actually looks like there was, as a side effect of another test. From http://groups.drupal.org/node/260203 :

  • “Extend” was unclear to intermediate participants in this test: Half of the participants thought that “Extend” wasn’t the correct taxonomy label.
  • "I have an English degree and I think 'Extend' is not a good word for Modules" (P4)

So, not so great on a first glance. (But we do need to keep in mind that these are existing Drupal users who were used to seeing it the old way).

Bojhan on Dharmesh, do you have any more details on what the participants' exact reactions were here? (I personally do think that without #1839032: Rename the "Configuration" menu item to "Configure" we're drawing a lot more attention to this menu item than necessary and that could be part of it, although that's just my opinion. And another thing that comes to mind is that "Extend" is a great label for someone who's planning to turn new modules on, but it might make less sense if you're going to that page with the intention of turning existing modules off... maybe the intermediate users had that in their minds a little bit too?)

Bojhan’s picture

Assigned: Unassigned » Bojhan

I will check with dcmistry.

naught101’s picture

@Rob: one might assume that if someone could figure out how to enable modules, they'd be able to reason that to disable them they must go to the same place..

David_Rothstein’s picture

I'm not Rob, but assuming that was addressed to me, I can almost guarantee you that's not the case. Sure, if they just enabled a module a couple minutes ago, they will know to go back there. But for someone who never has - or, more likely, someone who administers their Drupal site only rarely and hasn't been to the modules page in months and has forgotten what they even are but now needs to turn one off - it's a whole new process of discovery.

I think "Extend" is still likely better than "Modules" for this, though.

dcrocks’s picture

Under 'Extend' on the 'Uninstall' tab, there is a reference to a 'modules page', which takes you back to the 'List' tab. Shouldn't this be modified, and might their not be other such references?

LoMo’s picture

"Extend" is still the "modules" page, we didn't rename "modules" to "extensions" or anything (that would be too confusing giving the history and all the references to modules. The idea is just that for new users, "Extend" is a simple way to find your way to the "Modules". I don't think we should need to change the word from "Modules" to "Extend" in any other places besides the main menu, which is just to give new users a hint for the purpose of modules. When the click "Extend" and find "Modules" (and find references to "modules" in a zillion and one other places), they should be comfortable with links back to the "modules list" page from other parts of the UI.

At least that's my 2¢. And I think that, while there might be an initial confusion on the part of existing users, people will quickly get comfortable with the "Extend" link in the main menu. IMHO, it's less disconcerting than the move from "Users" to "People" (in D6 --> D7 UI changes), which, fwiw, I doubt really helped new users, either….

dcrocks’s picture

I'm not arguing against the change to 'extend'. For new users it will be confusing because they won't have any reference back because the 'list' page, even though it has a couple of links that refer to modules, doesn't say that it is a list of modules. What about changing the reference on the uninstall page to 'modules list page'. Then they will at least have a reference to the 'list' tab. Again, this is for new users and they will soon figure it all out. But I thought this issue was specifically addressing ease of use for new users.

droplet’s picture

You never told users go to Theme page to enable themes. You will tell them enable themes in Appearance page. I think it's same to Extend.

dcrocks’s picture

Yes , Extend leads to modules. But, near the top of the Appearance page you see a label that says 'Enabled Themes'. You don't have anything like that on the Extend page. All I'm saying, what is wrong with a few queues to make it clear to a new user as to where they are. This change wasn't to eliminate the word module, just to make it easier to find. Make it clear. After all, isn't that what this discussion was all about?

YesCT’s picture

I do not know if there has been any other user testing, but of interest issue from one user testing: #1891096: Users don't understand the "Plug" toolbar icon (which points to the modules page)

jrabeemer’s picture

It took a long time, but my Rename Modules module is available for those who want to try different variations.

http://drupal.org/project/rename_modules

dubcanada’s picture

I'm going to revive an old thread. I recently just started playing around with Drupal 8. And "Extend" as a menu item makes no sense. If anything it should be called "Extensions". "Extend" is a verb it means to add onto something, to make something longer. But it makes no sense by itself. Plus you don't "extend" Drupal by clicking on the "Modules" list. All you get is a list of "Modules". It should mirror similar functionality already present to everyone. And that is "Extensions".

I know it may be too late to change it. But it makes no sense at all. And it is very very confusing.

chx’s picture

chx’s picture

Issue summary: View changes

Added an issue to related issues - basically the same discussion as this one.

Nchase’s picture

I'm wondering why the modules list doesn't contain all the info we have in 7. It was really helpful to have the info in one table.

  • module name
  • version
  • description
  • configuration
  • prermission

I'm wondering if this is coming back. Otherwise the extend page is useless.

mgifford’s picture

Issue summary: View changes

What do we need to do to close this issue? The link has been changed to Extend now, so are we good?

thedavidmeister’s picture

Assigned: Bojhan » Unassigned
Status: Needs review » Closed (fixed)

@Nchase and @dubcanada - I think both those concerns should live in followup tasks.

thedavidmeister’s picture