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