The modules page in Drupal has always been one of a handfull of pages that I consider flat out embarassing for us.

In the old days, i.e, back in Drupal 4.6 when I started, it was nothing more than a collection of modules, ordered alphabetically, with checkboxes. Drupal was small enough that this wasn't really that much of a problem. And then modules like ecommerce and CCK came along with these large collections of modules and nobody could find anything.

For Drupal 5, a few of us tried to do a revamp of the modules page. I tried to eliminate the checkboxes, but I failed. However, many of the other improvements I pushed did get in, though it required someone else to rewrite them (thanks neclimdul!) and eventually they turned out mostly as I had envisioned them. We got the 'package' keyword in, which allowed us to group modules. We moved the checkbox from one side to the other. We got module dependencies in place. Yes that's right, previously modules didn't have dependencies. Before there were .info files, modules had no information at all. You couldn't even tell if a module was for your current Drupal version or not, meaning it was really easy to hose your site completely by trying to turn on the wrong module version.

Still, there are a lot of problems with the page:

  1. The checkboxes mean that to activate one or a small number of modules, you first have to find your module (difficult enough because of information overload), then scroll all the way to the bottom, hit a button, then come back to someplace totally different. There is no response at all to the action, either, beyond a message telling you modules have been enabled.
  2. Contrary to what I believed, people misuse the package keyword. Some because they don't understand, and others because they believe the definition we created was simply wrong. Despite very clear explanations of what the package keyword should be, years later several modules abuse this. Thus the packages are a soup and unreliable, rather than a nice grouping the way they were meant to be. They are a total failure.
  3. The sheer volume of modules means that we are simply throwing too much information at the user. We throw the module name, description, version and links all at the same time. The page is incredibly hard to scan, and the only reason it's usable, at all is that the browser provides a search command. So if you know what you're looking for, you can find it.

There are several things that, IMO, need to be changed about this page. I'm going to write these out and hope that one of our UX people will cogitate about these ideas and maybe do some drawings, and we can post this to drupal.org and get something going. This is actually being posted on my blog more to draw some attention to it, because drupal.org has so much data it's easy to lose. And once this disappears into history, it will not be seen a lot. But I can push the conversation forward again. The current issue for this is on drupal.org: http://drupal.org/node/538904. Meaningful suggestions and, hopefully, drawings and/or mockups and/or additional reasonings should be added there.

Here are my recommendations.

  • In addition to the 'package' keyword, modules need to gain a 'categories' keyword. Categories should be specifically limited to a set of categories provided by drupal.org and should be something that can be updated in the drupal.org XML file. (This means that, like update status, groups that maintain their own modules could also maintain their own category set. Very few people use this today but I know it does happen). The modules page should then include a filter widget with the available categories to easily filter or sort by modules with the given category. Sites that have udpate_status turned off will need to have a backup strategy for figuring out viable categories.
  • The 'package' keyword should become limited to project names. If a module has a package that does not match a project, then its package would be reverted to the generic 'Other'. The full list of possible projects can be retrieved easily via update status module. Sites that do not have update_status active would need a backup strategy for determining package validity, or maybe just not check.
  • The modules page should have a set of filter/sort widgets. There are at least 4 different persepctives that we want to see modules in, and we should be able to easily switch between these views, plus allow searching:
    Enabled modules
    We need to be able to see what's on, right now, and learn exactly where to go to deal with these. This should be the only view in which the 'help' and 'administer' links should be visible.
    Project view
    Similar to what we have today with packages, this view would list modules grouped together by the project they belong to or are attached to. For example, small modules that add things to Views or Commerce or similar could simply attach themselves to the Views project if they want through use of the package keyword.
    Keyword view
    This would be the basic search mode. You select keywords and/or enter search terms, and it tells you what modules you have, enabled/disabled status, etc.
  • Dependency view
    This view would allow us to see modules grouped by what they depend upon. For modules with multiple dependencies, they could be listed multiple times. For example, that views_content module that depends on both Views and CTools would be listed in both sections in this view.
  • The information per module, up front should be very limited. We should list the module name, enabled/disabled status, and a visual indicator of how it's grouped. Some other mechanism should allow us to fetch more data, and the view we are using itself might include more data. Also, we should consider providing update_status information right on this page. If a module is out of date, say so right here.
  • The checkboxes should be done away with. Instead, we should use a status indicator and a button. AJAX should be in use to change module state. AJAX response mechanisms can provide more data, questions about enabling dependencies, and possibly optional forms and tell users what the next step for dealing with that module is. Enabling multiple modules should not be as painful as people think because of the AJAX interaction -- you won't leave the spot you were at when you enable a module. Likewise, the 'uninstall' page should be eliminated and indicators on the module itself should show that the module still has data and that 'uninstall' can be used to eliminate it.
  • The ability to re-sort should be just as easy as though we were using tablesorts, though I don't think table headers with sort widgets is necessarily the right way to do it. Said sorting should be handled entirely by the client so that it is fast. We should be able to re-sort the entire module list alphabetically, last updated date, so we can easily tell what modules are newest.
  • We should keep file dates in the system table. This way we can tell if a module is 'new' (never before seen) or 'updated' (has changed since we last saw it), much like we do with nodes. This data should be a little fuzzy so that just glancing at the module page doesn't discard new/updated information. This fuzz can simply be an offset from the current time. For example, when a new module is added to the system table, it should include a range of dates that the module will be considered new. When the system table sees that a filedate has changed, it should include a range of dates that the module will be considered updated.

Comments

Either the modules page or the available updates page needs to indicate where the module is located in the file system.

I often use the Acquia distribution of Drupal which includes a number of modules such as Views. However, when I'm looking at the update status, this fact is not immediately clear. I prefer not to override included modules unless there is a real security reason to do so. However, I'm left looking around the file system to see which are included and which are in sites/all/modules.

OH! YES! I meant to put that into the text. It's been an issue for me as well. There are many places a module can be now, its location is a critical piece of information that has actually been LOST since Drupal 5.

It would be very useful to know if a module is installed globally at sites/all/modules or in a site-specific folder. Example benefit: a multi-site administrator notices that they keep enabling a particular module which is in a site-folder, and realize it would be worth moving this to the global folder.

It could also be useful for tracking down modules that are installed in inappropriate locations, such as contrib modules placed in the core /modules folder by a previous administrator.

This info might also be useful on the update status page, e.g. there is an update for all sites, and an update just for this site.

Some of this might also be useful on the themes page too, although that already got a new arrangement in D7.

There is no mention of the other usability issue that has been recently found in the last round of usability testing Report from the University of Minnesota Drupal Usability Testing where users were looking to brows D.O. module under this section as well.

IMO this should be bundled with that 'requirement'.. It becomes a little larger in scope where people can browse D.O. modules in their sites, their modules installed, their modules available under the modules directories and then install/update. Some nice ideas in that issue http://drupal.org/node/538904 but I think a step back and this ecosystem needs to be looked at as a whole.

It's worth thinking about, but being able to browse the entirety of available modules at the same time as your active modules might be very difficult to pull off because we're talking a LOT of data. However, adding it as an additional 'view' may be feasible.

Yeah, just another tab say "installed" and "on Drupal.org" . I just think there is a lot of duplication around the structuring of the modules they should be the same, that way when user understands one screen they understand the other. Im sure D.O. could cron run a list of modules into some xml format (hey maybe rest) that can then be sucked down by everyone and used in the "on Drupal.org" view that can also be cached and refreshed on a cron run not real time but should scale well.

Duno just some thoughts.

One of the biggest YES of your recommendations is the AJAX point, (being extra careful about CSRF) Now: 1st enable the module, wait 4 seconds to load page and you found yourself at top of page. No! Scroll down to find it again the "Settings" link. This way also the module could implement hook_enable() to display a useful info message and links just-in-place. Finally recommend the must-have module "module_filter" real-time search until this pain goes away in D8 ?

http://drupal.org/project/module_filter

So if I develop a bunch of custom modules for a website, I would need to have a website.module just to be able to group them together under "website" on the module page?

Not all projects are named after modules. Views is, but the CCK project has never had a cck.module. I think this is just a case of adding an entry to the .info file that is normally only added by the packaging script.

Very much related this useful thread [meta] Smarter UI/API separation for modules http://drupal.org/node/937814

Including jroos comment, to having the location in the file system available in an update.

That would include the module's machine name, which i think should bepretty visible, but should at the very least be part of the search.

As someone who has had to maintain a couple dozen sites running with over 100 modules, I've felt THE PAIN of the module page acutely. AJAX enable/disable/additional info would be wonderful, especially with dependency handling. Scrolling the current page list over and over to enable/disable a set of interdependent module is horrible.

Some of the core modules(node,fields) are essential for drupal. There is no need for them to be in the list as the user cannot disable them anyway. They should be removed from the list.

Couldn't agree more - but +1 on the first comment that module locations should be in there. The AJAX stuff would be phenomenal!

Hey Merlin I also think that module maintainers should be able to add some type of icon to their modules. This will help show exactly what is installed and what is not. I seems like it would be easy to do by just adding a one liner to the .info file then just loading the icons up in the list is the other side. I know this is a bit out there but it might be worth a shot to improve the overall system.

I know this is slightly off-topic, but I would really like a module that would add a "proposed modules" feature to the module page. It would propose the most popular modules for new installations and then - based on the modules used, and matched against other sites - those modules are most often used in combination with already installed ones.

Some great ideas. I've also felt that the Modules page could be vastly improved, including (a) Better use of screen real estate (b) Merging with the Module Update page (c) Link to module Advanced help (d) Option to hide dependencies, etc.(e) Links to each category at the top of the page (f) Merged with "Used modules" module (so I can get a snapshot profile. (g) Option to display as pretty icons.

Anything that makes it easier to keep track of your modules and using Drupal overall is a good thing. I like Stefan's idea, it would certainly help novice users like myself.

How about using the context system of block arrangement ... i.e. blocks are organised in to a hierarchy by the creator type?

strike please ... completely wrong topic (caffeine-induced semi-coma)

I started writing a module that would shorten the modules admin page, but it started to become time-consuming and I moved on to other things. I arrived at some simple improvements:

  • A checkbox to toggle hiding the dependencies. You don't always need to see them, and they take up an inordinate amount of space. I got this working without much trouble. It uses javascript to do the hiding and ajax to save the setting.
  • An enable/disable button per module. This turned out to be the tricky part, because of dependencies.

As Merlin wrote, the package method of grouping is not working. I think you would run into problems with any method that depends on the module developers to self-categorize. I like methods like separating enabled vs disabled, updates-pending vs no-updates-pending, grouping by dependency (this would achieve a similar effect to packages, without depending on the module developers to cooperate), and simple sorts like alphabetical or chronological. I.e., methods that are not voluntary on the part of the module developers.

It would also be nice if the module page would integrate with drupal.org and offer to automatically chase down dependencies and automatically download the most recent version of a module. Some things are already implemented in drush.

This general class of problem is not unique to Drupal. Red Hat and Debian Linux both have mature package-management systems. There could be inspiration there.

Add new comment