D7UX: The Modules page needs to be easier to find
| Project: | Drupal |
| Version: | 7.x-dev |
| Component: | base system |
| Category: | task |
| Priority: | critical |
| Assigned: | Unassigned |
| Status: | needs work |
| Issue tags: | D7 UX freeze, Usability |
Mark and Leisa's design showed "Modules and configuration" yet the implementation shows "Configuration and Modules". I agree with Marks approach over what's been implemented.
The natural order is to enable then configure. Arguments have been made stating "users are looking to configure Drupal out of the box, and therefor users are going to scan for the word Configure". I agree with this, but think its splitting hairs. Given that Drupal ships with only 13 enabled modules, and the average site has 30+ modules - you have to enable first. As such, what about the case where users are scanning for modules?
In all honesty, my bigger concern is less about the title, and more about the order in which the tabs under Configuration and Modules appear. Putting configuration before modules feels wrong. If there were not tabs, and the word "configure" was an action link on the module, it would land at the end - like this:
----------------------------------------------
[x] module name verson configure
----------------------------------------------
We should follow this same paradigm and put configure after modules in both the title and tabs. If people are so in love with the idea of leading with Configuration, I propose we loose the words "& modules" in the menu bar (makeing Configuration stand on its own), and adjust the tab order so that Configuration comes after modules.
| Attachment | Size | Status | Test result | Operations |
|---|---|---|---|---|
| After.jpg | 72.76 KB | Ignored | None | None |
| Before.jpg | 44.77 KB | Ignored | None | None |
| modulesAndConfig.patch | 32.96 KB | Idle | Unable to apply patch modulesAndConfig.patch | View details | Re-test |

#1
Oh, yes please! It's great to hear Acquia's resident UX guru agreeing with everyone in #drupal. :D Explaining over and over to people where to find the modules page now is getting a bit old. ;)
I'm ambivalent about changing the title. I don't think it's the end of the world for the tabs to be reversed from the title of the menu item - only our most pedantic users are going to notice something like this, vs. all of our users who notice they can't find where "Modules" went. ;)
I do think the word "Configuration" needs to be there, though, since people installing Drupal for the first time and clients doing basic administrative tasks won't understand what "Modules" on their own are, I don't think.
Something to check is what happens for people who don't have "administer modules" permission but do have "configure something something" permissions. They should be able to see the link, but it should not take them to a 403 page.
#2
Changing some metadata.
#3
Oh, also I misread this. You were proposing removing "& modules" not "configuration"
I thought this seemed a bit odd too, but Mark and Leisa pointed out that for the people who do know what modules are (which is everyone but the people using Drupal for the first time), "modules" is a word that is heavily scanned for with them.
#4
note that #550718: admin/people needs to have a default tab (was: Tabs on admin pages are not accessible from overviews and menus) might make modules a bit more accessible for those used to older drupal versions.
however, i agree even with that patch, modules is not the easiest to find.
If we turn more and more in tabs, (and move out the action links,) we get used to those tabs, and the problem might be not that big.
#5
I'm less sure about removing the word "modules". I just proposed it to nip concerns about users trying to hang their hat on the word Configure. I'm about to do a bunch of Garden's testing. I might learn more about this.
#6
Switching the order of the tabs means an extra click every time you want to do anything from the configuration page - which with the design of the IA is a lot of stuff.
The modules tab getting lost is an issue with seven as a theme or with it being a tab, putting configuration in that same position, will cause all the same problems, except the number of pages being 'hidden' will increase from one to over 40 or more.
If we don't like modules hidden off as a tab (and I don't particularly - I have to think twice before clicking on structure or configuration, then when you get to the page, you have to refocus to the tab), then let's make it a menu link within admin/config (system?), or put it in structure, or split the tab out to a separate top level menu item, but just reversing the position is going to cause more problems than it solves IMO.
#7
@catch:
when #550718: admin/people needs to have a default tab (was: Tabs on admin pages are not accessible from overviews and menus) get's in, tabs will be visible from the overview pages as they should be.
actually, to properly diagnose this issue, you should be checking with that patch applied.
#8
In the Admin module for D6, Modules is a separate item on the Admin menu. I think it would make more sense for Modules to be a separate item from Configuration in the Toolbar.
#9
@Noyz Your tabs are not working, probally because of an old version + Gardens stuff.
I will respond more to this some later. I am not sure, I am following your logic at all - what user confusion are you solving?
The contrib case, makes sense - but merely from an abstract point of view. Sure you enable it first, before you configure - but is the order of the label truely confusing? Shouldn´t the usage of this toolbar, be above the semantic order? After one installs, his 30+ modules, you would still need configure - and you do this more often and more reoccuringly then modules.
**Noyz: If there were not tabs, and the word "configure" was an action link on the module, it would land at the end - like this** Not sure, does this mean we need to change the design of the module page? Is that what you are implieing?
I truely do not think, we should focus on people complaining about not finding the modules page (especially the people in #drupal). This seems to be very much a negative effect, of the current Seven theme it´s visual design. The overlay should fix this - and seasoned users for now, is the only testing feedback we have on this.
Still not seeing the logic, is this a critical issue? Or is merely an artifact that we try to hang certain symtoms upon? Eitherway, I am not strong minded on this one - but it seems rather wierd, to go for modules first (that will not be the usage pattern, beyond instalation of a module)
#10
It actually took me quite a few times to find the modules page on /admin. You have to scan down the entire "Configuration and modules" block section to get the link to the modules page.
#11
I agree that it's a bit annoying to find now. And it's a lot of people in #drupal who couldn't find it, not just one or two. However I think exactly the same would go for 'configuration' if we swap them, and that'll also make it a longer process to get to a lot of common tasks.
For me the main probiem at the moment is I keep ending up at /admin via breadcrumbs, or habit, or whatever, when I really want to be on admin/config, and they look almost the same, so I get confused and swear a bit. I really hope we don't ship with /admin as it is now along with /config - would rather move /config back into the top level than that.
#12
Modules is only one entry in "Configuration and modules". We either have modules on top and rest of the items configuration, or the entire list of configuration, then modules. And yeah, /admin, is just :(
#13
Since the words "and modules" are already taking up real estate in the menu, it seems natural to give "Modules" its own link. I agree that "Configuration" needs to be present, and if users don't understand what "Modules" are, then they won't have to click on the "Modules" link. Why is it so critical to group configuration and modules together? To me this grouping is just a tease suggesting I'll be able to view my modules with just one click, when really I'll need two.
#14
@sambrin: I completely agree with you. I think that it is a big usability flaw to group the module page with configuration, when configuration is so much more frequently accessed.
#15
Let's title this more appropriately. I'm also updating this to critical. Overlays were supposed to address this, but they only do for the sub-set of the users using the Overlay module (which, until we fix some more bugs, is not too many ;)). I also believe that this breaks UI convention; typically, stuff in tabs is "ignorable" until you actually need it. But the Modules page is the most frequently accessed page while you're building out a site.
Here are some solutions that have been proposed:
* Swap the order of "Configuration" and "Modules" tabs. Not ideal, since you end up under configuration far more often than you do turning on/off modules on your average site.
* Make the current /admin/config be the landing page at /admin instead. Seems reasonable to not have two pages that do this, but I'm not sure how this works for people not using Toolbar module.
* Make "Configuration" and "Modules" two separate links on the toolbar, rather than grouping them together. Is there a reason not to do this? I don't think it would take up any more space on the toolbar (possibly less without the & :P)
#16
The downside of #1 is that the Modules page quickly becomes a beast to load. /admin/config could become the new /admin, but what links would be lost that way? Would there be functions that people could no longer do by typing /admin and then doing Ctrl+F (as I do on D6 when I am configuring a rarely-modified module)?
I think #3 would be the best, and simplest, solution, but I don't want to keep repeating myself :) Thanks, webchick, for making this critical.
#17
So this is a big "scratching an itch" for me... I have always been very confused by the "Configuration and modules" menu that just show a page that shows two more tabs saying... "Configuration" and "Modules"... *ugh*!
So here's a patch that splits them in two. It looks very complicated and long, but it's basically:
find . -name '*.module' -o -name '*.inc' | xargs sed -i 's#admin/config/modules#admin/modules#g'... and a bit of tuning in the system_menu() hook. This splits the configuration page and the module page in first class menu items.
Also, we move away from admin/config/modules (aka admin/build/modules in d6) to admin/modules (yay! plain and simple, shorter to write!) and admin/config/config to admin/config (clean-o!).
I'm unsure as to how to figure out the order in the menu, it looks pretty magic to me at this point (unless I just need to add weight to sort them properly), but I'll let the 'order' bikeshed out of this patch, which I think should make changing the order easier anyways.
#18
The last submitted patch failed testing.
#19
I am oke with doing #3, back in the days we had to arguments :
1. Overlay, should provide more prominence - and it did, but the argument is to be made that its prominence is somewhat demoted over site administrative duties (which really makes less sense, if you think about clicking configuration and modules(which does not apply) all the time)
2. There would be more interconnectivity with the modules and configuration page, but that didn't happen for various reasons.
#20
Two top level items is good. Earlier in this issue I was concerned about burying it elsewhere - like as a link on admin/config or under structure, but just splitting 'config and modules' in two seems best.
#21
webchick requested that failed test be re-tested.
#22
The last submitted patch failed testing.
#23
webchick requested that failed test be re-tested.
#24
Missing some admin/config/modules paths. This should be all of them.
#25
Ok, this will require manual disabling of PIFR since it enables SimpleTest through the UI at the expected admin/config/modules.
See:
http://drupalcode.org/viewvc/drupal/contributions/modules/project_issue_...
#26
The last submitted patch failed testing.
#27
FWIW, I'd like to see two top level items as well. Since they'll still be 'eachothers tabs', it will also still be clear that they are two sides of the same story.
#28
+1 for making the modules button and configuration button in the top bar separate.
I can't tell you how many times I've clicked on the word "Modules" only to end up on the configuration page confused. Eventually I programmed my brain to know I have to click the tab... but that's just another / a new DrupalWTF. And D7 is the Drupal to get rid of as many interface WTFs as possible. So yeah for this issue! Make it make more sense, please.
#29
An alternative in my mind would be to title "Modules & Configuration" to "Settings." It's very common to find one work hooks with several sub options below. Think preferences for any number of desktop applications. Doing so would be less to grok, a more familiar pattern, and would give us more real-estate in the menu bar. At present, 1024 is already a squeeze. If we were to take this approach, I still think we lead with modules for the same reason. You add things, then configure them - not the reverse.
I personally dislike the two being their own links in the header. I'd rather users get into this part of the UI and then grok whether the modules page is what they wanted (which is what they landed on) or whether configuration is what they need. Versus, having the have to grok whether they should go to Modules or Config (soley based on the menu title alone) to extend Drupal.
#30
I like the proposal in #29 and tried it out. You should too. Module pages is a pretty heavy in your face page, but this might just work.
#31
We can't put admin/config as a tab, that just reverses the problem of things being hard to find. Except in this case it's a tonne of stuff you need to access quite regularly on an actual site, whereas modules gets less and less common as time goes on.
Also, if we rename the menu item to settings, then we should rename the paths to settings too, which doesn't fill me with joy.
#32
The last submitted patch failed testing.
#33
Judging from all the issues that there are in 6.x on how Modules page takes forever to load, I think making it the default is a very bad choice. Also, I agree with catch that the configuration continues to be a regular need to access, whereas modules becomes infrequent. The Admin module for 6.x has the two as separate menu options - I think that has been tested "in the wild" for months now and works quite well.
#34
I'm for two separate top level items. Whilst most modules do need configuration, I don't think it is fair to assume that if you want to configure something that you have any care or even understanding about what modules are. In my experience, the modules page is accessed infrequently, and those that access it know all about modules. The configuration page on the other hand is accessed 10 times more regularly (at least) and by a much broader audience, many of whom will have little or no understanding of what a module is, let alone wanting to be faced with a great long page full listing them!
So, for me it's 2 top level menu items:
- Modules
- Configuration
Preferably, such that the Modules button does not show unless you have the Administer Modules permission - likewise for Administer Configuration (assuming my assumption of what those two permissions do is correct).