Towards a more better managable modules page

The modules page is a typical example of a long list that gets hard to manage pretty quick. The categorization is not ideal, with big modules providing their own category and a quickly growing 'misc' section.

The usability tests have shown that after installation, modules do not provide clear starting points to where you can find their configuration pages. Same goes for the new permissions a module might expose. No clear indication that there are new permissions and no clear pointers to where to find them. summarizes the main issues with this page:

  1. Finding functionality once a module is installed
  2. Finding functionallty a while after the module is installed
  3. Finding functionality (with no knowledge of modules whatsoever)

In general, this gives us two areas of attention:

  • Managing the big list of modules as a whole
  • Finding related tasks per individual module

For the latter, we need to show more info per module without cluttering the interface. Finding related tasks per module is something the accordion concept (yes, accordions, I mixed up my musical instruments there) could help fix this by showing links to configuration and permission pages from within the context of the module itself.

During the UX sprint we discussed ways to make it managing the big list itself easier. The main idea is to provide 3 top level boxes for modules to live in: New, Enabled and Disabled.

Let's take a look at how this would help solve some of the problems:

Box 1: New
This would make it pretty easy to find the module you just installed on the page. You'd find both enabled and disabled modules living in this box. Of course, we'd still have to provide messages on other admin pages so that you know you have to visit the modules page at all.
Box 2: Enabled
It seems sensible that below the list of 'New' modules is the list with 'Enabled' ones, no? These are the ones that provide the parts you built your site with.
Box 3: Disabled
For the modules that are installed and fully configured or have been enabled before, but are (kept) disabled, well, you probably don't want to have them clutter the top part of your screen.

Yes, but…

What about the categories?
It would still be handy to be able to filter on everything 'media' or 'ubercart' yes. Propose to make the categories a filter as a select list on top of the page.
What about modules that consist of multiple modules, like panels, views, ubercart? What if I enable some of them, some not?
Yes, the New/Enabled/Disabled segmentation would seperate these 'sub-modules' from each other. Currently these modules are grouped into their own category. I don't expect the seperation to be a real problem. On first usage (after installation) the module family would be shown in full in the 'New' box. After configuration, the category filter would allow you to see all panels, views, ubercart related modules together again.
This would mix up core and contrib modules!
From the users perspective, does that really matter? Again, the Category filter would come to the rescue in providing a filter to show 'Core modules' only. In itself it is not a very relevant disctinction to make.
How would the modules within each box be sorted?
Sorting alphabetically, although about as helpful as 'random' in most cases, seems to be the most logical option here for the New and Disabled boxes. For the enabled section, which would normally be the longest list, we can re-use the categories from the configuration page (the new name of what currently lives under /admin but reorganized).

Any other edge cases I missed? Any other problems that might arise from this new grouping? Point them out please and talk us through it. If the concept still holds after discussing them, then just this new grouping of modules in New / Enabled / Disabled boxes would be a worthwhile improvement for the modules page.