D8UX: Redesign Modules Page

Here's Marks latest mockup. If you want to help out with this issue, please come to #drupal-usability for some fierce discussions.

Before we start to throw out more mockups, let's summarize the known issues with this page first,
then look at what could help solve these problems,
then wireframe,
then spin off seperate tasks that will have actual code patches posted to them.

What follows is a summary of our module page thinking during june ux sprint. One of the main ideas is to make 3 main buckets on this page: new, enabled and disabled. Please read:

__

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

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.

http://sprint.drupalusability.org/content/design-module-page gives us a good summary of 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

We need to show more info per module without cluttering the interface. Finding related tasks per module is something the accordion (yes, accordions, I mixed up my musical instruments there) concept could help improve by showing links to configuration and permission pages in 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
- 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 (and maybe even in the admin header) 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 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?
Looking at an average use case with say, 30 installed contrib modules, there doesn't seem to be a need to make the sorting within each box 'smart' in some way. Sorting alphabetically, although about as helpful as 'random' in most cases, seems to be the most logical option here.

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.

I was thinking of a textfield that allows users to filter modules by name. In combination with AHAH this makes searching for specific modules in large lists a lot faster.

Fixing tags. Also, ninja subscribe. ;)

great summary yoroy - really look forward to getting this one nailed, it has been a challenge!

Also tagging with this. I think that it would be a shame for D7 to ship without this page having been re-worked, since it's one of our biggest usability WTFs currently.

I'd presume ubercart would add itself as a category to filter the list on.

As hinted by Yoroy in the other related issue, posting a mock-up diagram here which in my idea streamlines things more.
Please see the attachment here - the first diagram.

The second diagram is a rough diagram approximating an ideal workflow for modules

In conjunction with MODULES.gif above
a very, very rough skecth to show how this mockup handles when there are more than 50 modules or 500

The lists can have more sharpness in display with slightly more increasing the line-heights.
Can post a better diagram when have more time and if there is any enthusiasm here :)

Without having read in depth about this issue (which is probably an advantage), i like the mockup #2 posted by xano >> Its intuitive it looks drupal like >> i feel at home.

I dont like #10

Just my thoughts about this starting from #2

• A direct link to "Module settings", "Module permissions", "More detailed Description" should be added for every module. It would be even more userfriendly to also indicate if a module has "No module settings" or "No module permissions".
• Modules (like ubercart, views, cck, panels) should be sub-grouped acording to the folder structure in /sites/all/modules to indicate if a submodule is a 3rd party addition or if its belonging to the original group of modules.

Subscribe.

So, I'd like to create a first spin-off issue for grouping the module list into 3 boxes "new, enabled, disabled", since that seems like a usefull thing to have regardless of any extra filters for sorting and regardless of any extra links offered per module.

Do we want to discuss the requirements for that here or in the seperate issue?

Now that the "Configuration and modules" page is in, I've submitted a patch which moves the Modules page to the right place in the IA as a first step. I think it is best to get that in fast and then work on the inside of the page. See #545952: D7UX IA: move modules to config/modules.

Subscribing

Just a note that Gábor's issue in #15 was committed last week sometime, so we are no longer held up on that.

Most of you know I've spent dozens of hours in rethinking the module page earlier. I've been involved with many discussions, made many mockups and even made a contrib module which was intended to make it to core. A few months ago webchick advised me to stop further development until the D7UX team picked up this issue, to prevent me from doing a lot of work which wouldn't make it into core anyway. So I'm really committed to this issue.

As yoroy mentioned there are a few main targets here on which we must focus. The order of importance:

1. Scannability: The list can be long, you should easily check the status of most modules by just a quick glance over the module list.
2. Workflow: All tasks involved with modules (enabling, disabling, uninstalling, setting permissions and configuring a module's settings) should be quickly and easily doable.

As for scannability I am a bit disappointed by Mark's work. I don't agree it improves scannability, mostly due to the grouping. The hierarchy is to deep IMO. You have three parent groups (new, enabled, disabled), the categories as subgroups (which can appear in each parent groups as well), and a module can also be a group. We could easily tackle this by removing the uppermost categorization (new, disabled, enabled) and add a 'sort-by' select list to the filter system. From there you could sort by date added, enabled, disabled, and more. I also dislike the amount of whitespace between the modules and groups. I always have thought of the module page as a tabular data like list. That way you don't have to scroll down too much if you've got a huge amount of modules. iTunes! That could even avoid the pager (which worsens the workflow).

The tools made available in Mark's proposal really improve the workflow exponentially. The filters, bulk actions, floaded harmonica's, search field, on/off switches, and so on are all great features which improve the workflow. Still, the lack of scannability breaks the workflow.

Yoroy, Bojhan and me already have made a lot of mockups. The last mockup was really good, so why not work from there instead of taking again a new approach and restart bikeshedding?

Guys, of course show mockups. Just make sure to be really explicit about what you are proposing. #3 had to be written up, that was all.

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)

Skilip: It's hardly time yet to nitpick white space issues. Better to support your argument with showing the mockups and explain how it helps (better) solve the 3 issues outlined above.

I hereby lift the ban on mockups in this thread!

Okay, here's a new mockup. I've merged Mark's proposal with our last mockup. It's not complete, but a good starting point IMO.

the mockup in #21,:

It took me way too long to find this. Adding D7UX to the title to make it easier.

New mockup. Still not finished but more detailed than the first one. What are we going to do with the dependencies?

Uploaded the wrong image

- The per-module package information is redundant, because modules are displayed grouped by package anyway.
- Dependencies sounds too much like techbabble to me. What about Requires or Depends on?
- Group by is a display setting. It should therefore not be put on the same line as Check all and With selected, because those are actions.

Here's a part of a conversation I had with Roy and Bojhan in irc about this issue.

[22:27] yoroy: skilip: I miss the three boxes for new, enabled, disabled
[22:28] yoroy: skilip: the tab-like design of the permissions and settings links suggest an inline form, not a link to another page
[22:28] skilip: yoroy: Yeah, I do not agree on prefixed grouping. I totally see the use of having the newly added modules on top, but that's obviously a usercase
[22:29] skilip: yoroy: for the permissions: since we now have an overlay, we have loads of more space available the the Garland mockups
[22:31] yoroy: skilip: So you see the use but don't like it?
[22:31] skilip: yoroy: Can we skype for that? It's a lot of typing
[22:33] skilip: Well, I'll start typing anyway.
[22:34] skilip: First reason I don't like the grouping in Mark's proposal is that you'll end up with groups within groups.
[22:34] • skilip hopes he doesn't have to explain that
[22:35] skilip: Secondly you could end up with modules which belong to one category but are divided between 'Recently added', 'Enabled' and 'Disabled'
[22:35] skilip: And lastly, the flexibility.
[22:37] skilip: For newcomers I assume Mark's proposal suits them well, but for advanced users, like Drupal developers (which is 80% of the users who visit the module page), this surely isn't preferable
[22:38] skilip: For developers, the most important thing is to find the right module(s) an do the administrative tasks required.
[22:38] skilip: And that's not only enabling a module during a site setup!!
[22:39] skilip: So we should ask ourselves: what's the 80% in this case
[22:39] skilip: ?
[22:40] yoroy: I don't see how this would make it harder for devs to find a module?
[22:40] skilip: So they newly installed isn't very helpfull when you're half way your development process
[22:41] skilip: The separation of the categorization
[22:42] yoroy: skilip: ok, I think it'd be good if you past these concerns into the issue
[22:42] skilip: yoroy: you need to be honest, Groups within groups which are divided over several places over the page, does not improve scannability
[22:43] skilip: I'll do that
[22:45] yoroy: skilip: I'm asking what your concerns are right? Implying I'm not being honest isn't really nice
[22:45] • yoroy thinks he prefers findability over scannability
[22:45] skilip: yoroy: I didn't imply that
[22:46] skilip: yoroy: what's the difference?
[22:48] skilip: yoroy: ??
[22:50] Bojhan: skilip: So basicly, what is the diffrence here is - that you imply that you prefer seeing everything over drilling down - visually.
[22:50] yoroy: skilip: scanning suggests eyes dashing all over the screen everytime. findability suggests putting stuff in place that lets you skip stuff, know where to go
[22:50] • skilip is thinking about that
[22:52] skilip: yoroy: So that's why the 'Recently added', 'Enabled' and 'Disabled' groups are born?
[22:53] skilip: So that you find the right modules in the place where you expect them?
[22:53] yoroy: skilip: yep
[22:53] skilip: yoroy: Ah
[22:53] yoroy: you drill down a part of the list, not the whole list all the time
[22:53] skilip: still
[22:54] yoroy: because you very likely do know if it's either on or off
[22:54] • skilip feels sorry for being a pain in the ass
[22:54] skilip: As a developer in a company, I often do not know where I could a module expect to be
[22:55] skilip: And when you visit the module page a week later than adding all required modules, you probably don't either
[22:56] skilip: If you're working in a team, anyone could have added modules
[22:56] skilip: So again, what's the 80%?
[22:56] skilip: Developers, or end users?
[22:57] Bojhan: skilip: We dont diffrentiate between the two
[22:57] Bojhan: skilip: its totally not about that either
[22:57] Bojhan: its about finding a good middleground,

In the above mock-up the two most important parts missing, imho, is that the user (admin or whoever in the team) is not being allowed to make a favorite list, so that he or they can have a quick look at what they wanted when they come back in future or what they need actually to. And the link to module plugin browser.

Not exactly eye-candy, and the typography, spacing, icons, alignment etc need re-dos but in principle this is what I suggested. Please have a relook at http://drupal.org/files/issues/admin-modules-50.gif
( the figure assumes in each box the modules are default sorted alphabetically, that way I do not have to learn or guess 'categories')

This is also the standard way standard admin panels (where lots of or minimal modules are there) are handling things.

Slight correction done in the diagram

Hot damn, #31 looks really, really nice. I'm assuming that these will all be alphabetized. :P I'm further assuming that modules that come as part of the same download (such as Ubercart, Views, etc.) will expand out and have checkboxes for the sub-modules contained therein. If this is the case, it needs to be visually represented that some of these sections are expandable. I would also love to see what a mock of an expanded section looks like.

I am not sure I understand skilip's argument. I'm a developer with 4 years of Drupal experience and I never know where to find a frigging module once I add it, unless it's one I enable constantly like Views or CCK. And even then, I normally have to resort to cmd+F, because "Views" might be at the bottom, or second from bottom, or 4th from bottom, etc. depending on what other modules are installed. The current interface is a complete nightmare.

This new interface makes it easy. Is it enabled, disabled, or did I just turn it on? Once I ask myself that question, I can find it in no time flat.

@kaakuu: Your idea of tagging modules as favorite should definitely be taken into consideration. However it requires even more work, while we're currently stripping as much as we can to get the concept into core before code freeze. (think of how the modules should be tagged. This needs AJAX behaviors, database alterationsm, etc.).
Beside that, your mockup brings up a total new concept. The mockup we're currently discussing has already been widely discussed with Bojhan and yoroy, months before this issue has been opened.

@eigentor: I really like the coloring of the different groups. Only remark / concerns on that would be how to handle a situation where the modules are grouped by category. This will display an undefined number of groups. Should we predefine, say 50 colors?
Making the tiles of disabled modules lighter, is an extra indicator which is IMHO unneeded.
I guess a week is enough for marking a module new. Maybe even shorter.

@webchick: My main concern is having the 'new', 'enabled', 'disabled' grouping, without the possibility of grouping in a different way. It assumes you know which modules are new, or enabled. When working in a team, you're not the only one who can add, disable or enable modules.
Another drawback of this grouping is that we'll need subgrouping. The 'new' group can contain modules categorized under 'views', but so can 'enabled' and 'disabled'.

After thinking about the discussion I had with Roy and Bojhan, I now understand why the groups 'new', 'enabled', 'disabled' narrow down module searching. You only need to look where you'd expect the module to be. Since this primarily targets novice users and developers who are working alone, I think this type of grouping should be default. Beside that I'm thinking of putting both the filter and grouping select list under a collapsed fieldset, named 'Advanced'.

Working on a new mockup......

@skilip
Cannot we delay the code freeze so that
# there is a solid API or whatever that makes modules that will be old still work in future just like old Paint still works in win XP, new modules will work better but we don't have to discard the olds after 7
# remove half baked things once and for all like http://drupal.org/node/543914#comment-1903512
# it is a developer's game so far and perhaps commercial D's gain but let us have some new or needed features for those who actually use our sites http://drupal.org/node/544474

Was that out of topic? Perhaps. But this module redesign is being just cosmetic and lagging behind in useful "user" ergonomics, other admin panels like cpanel have moved much forwards.

Much thanks for the feedback.

Subscribe.

Erm. If Drupal ever starts using CPanel as an example of what to strive for in a user interface, I officially resign. :) I cannot possibly think of a more overbearing and convoluted interface where it is quite literally impossible to do *anything* without cmd+F.

One other thing I notice about #31, which I think is just a mockup glitch, is that the checkboxes for disabled modules are themselves disabled. This would mean you could never enable disabled modules, so let's make sure we don't do that. ;)

@skilip, that's a good point about people enabling modules while working in teams. I still think this is preferable because it gives a maximum of 3 places to search for the module, but there will indeed be times where things are unexpectedly in the wrong places if 2-3 people are monkeying with this page at once. However, I think I'm willing to consider that an edge case at this point, since hopefully you and your team-mates are communicating well enough to understand what each other are doing.

:) @webchick - I too :) But I meant pick up the good things. The newest cpanel packs the most recent tasks or modules visited in a handy block automatically thus making frequent tasks available easily. It also groups modules in easily scannable and identifiable blocks that can be dragged and reordered. It 'remembers' those without needing to click save. Were you speaking about this new cpanel?
The new Drupal is/was meant to make things easier, isn't it ? Even with these mockups it will still be cmd+F to find out if I suddenly need my module X from a list of 70 modules. A long rigid list to scan plus vast wide horizontal space.

Anyway, I resign from this thread now. Will contribute something useful elsewhere. Thanks.

New mockups. This includes the expanded states of modules, module info and permissions.

I'm also considering dropping the whole filter form. Just having a 'search when you type' would be useful enough.

Even with these mockups it will still be cmd+F to find out if I suddenly need my module X from a list of 70 modules. A long rigid list to scan plus vast wide horizontal space.

But if the lists are sorted alphabetically, it'll b.e obvious where it is even in a long list.

Ok, here's a new one. Quite near to finished I guess.

• Removed the filter form. It only clutters the UI and isn't expected to be used often.
• Removed the submit button 'Search'. The search field should be a 'search when you type' field. When js is disabled, the submit button will be present again.
• Added a submit button to the 'With selected' select list for safety. You don't want to accidentally uninstall a whole bunch of modules.
• I didn't remove the 'bulk actions'. If I would remove that, the checkboxes wouldn't be needed also. But then we'd have to add other UI elements which enables admins to uninstall modules as well. I was wondering whether it might be possible to use actions for the bulk actions thingy. That way other modules could hook into the bulk actions system.
• Added vertical tabs for the 'Depends on', 'Required by' and 'More modules by this package' information. This avoids cluttering. The 'More modules by this package' section displays all the modules of the package the module belongs to
• When the module has one settings / configuration page available, the 'settings' link will appear. If the module has more than one settings page available, a tab will be added in which a list of all pages is put.

I love it! One question: is the Keyword search going to be used solely to filter modules on this page, or does it search the rest of the admin section as well? If the former, then we need to fill it with "Filter modules" or something like that instead of Keyword search, and if the latter, then that's just no fun at all :).

Looks pretty good skilip!

My comments:

I'm not sure about the background colour for disabled modules. It kind of suggests something went wrong there.

Hmm now that you mention it, I agree gray (for example) would be more suitable.

Xano: good point, maybe just a light gray?

I'm a fairly new Drupalist, so take my comments with a large grain of salt.

This is all very encouraging in terms of where the UI for D7 is headed.

Two thoughts:

1. The Permissions and Settings tabs idea is brilliant! Finding where to set permissions for a new module is always a challenge, and this would even give module developers a place for a small explanation of what the options actually do, in context. Total win.

2. To my eye, a "New" box is not necessary. I don't usually download more than one or two modules at a time. Two boxes, Enabled and Disabled, with a "New" visual flag of some kind on those modules that are new, seems sufficient to me.

Hope this helps.

@jrdixey: Glad to see you joining in the discussion...it's important to get the opinions of people who haven't already stared at the Drupal UI everyday for the last 5 years ;)

Re: the New box, I personally think it's a great idea, not only because you automatically want to enable all newly downloaded modules, but also because I tend to download 10-20 modules at the beginning of a site's development, so it'd be really helpful if they were all together. But I might be the exception and not the norm.

That being said, I would be OK with a "Check all new" checkbox right next to the "Check all" checkbox to accomplish the same task. But that would be a step backwards from the mockups IMHO.

Updated skilip's mockup with gray instead of red.

I like jrdixey's idea. Something like the "new" flag used for nodes, but then for modules? It saves a lot of space (and it's consistent).

Hey guys, Thanks for commenting.

• Change 'Keyword search' to 'Filter modules': I totally agree!
• 'Select all' and 'With selected': I'll change 'Check all' to 'Select all'.
• Change the text in the sliders to 'enabled', 'disabled': I've thought of the localization issue of having 'on' and 'off' in the sliders. It definitely isn't preferable to have long words in the sliders, so I'm actually thinking of on and off signs. (| and O). These can be just images and are known all over the world.
• Change the background color of the disabled box to gray: That's a good idea as well
• Remove the 'New' group and use 'new' flags instead: The 'new' box has already been discussed with our D7UX team. The advantage of having all recently added modules in a separate box is that you know where to expect them. There's no need for scanning the whole page anymore.

So I'm seeing at least 3 spin-off issues here that could get actual code written for it:

- create the 3 boxes new, enabled and disabled
- bring permissions and config inline
- make the filters work

If there's no more architectural feedback here (discussing colors isn't) we could go ahead and start work on the implementation.

Skilip: excellent work so far.

I've just had a look at the module in 'open' state and have put together a little mockup (attached) that I think tidies up the tabs area a little more.

I feel like I need to better understand the use case for the 'Required by' functionality? What are the most likely scenarios of use for this?
Also, would it not be more helpful to have a listing of the modules that the select modules requires? (And the ability to install/enable those required modules?)

I'm going to take a look at some ideas for 'grouped' modules next and interested in your feedback on this.

Leisa's above:

The major problem I see from #57 mockup is that it removes the individual checkboxes from the modules within that package, meaning each of those modules has to be broken out as they currently are in 6.x which gets really messy really fast.

That said, I can see a potential problem when grouping all the modules in one package together: in the #42 mockup, there's a master checkbox on the top left of the package, which I assume just enables the Content module, but since it's over the whole package, it sort of seems like that checkbox enables every module in that package. Anybody else?

Leisa: the Required By is useful (for me at least) for determining which modules are preventing me from disabling a certain module. For example, if I want to disable the Comment module, but the checkbox is disabled, you can look at the Required By section to see that this module is required by the Tracker module, which is also enabled, so I need to disable Tracker before I disable Comment.

My view, coming from Mac OS X, is that if I see the switches, I want to be able to enable or disable a module with the switch. If I have switches telling me that they are enabled, but I can't use them to toggle the status, then it seems pointless having them, especially if we already group modules as to whether they are enabled or disabled.

My photoshop skills are non-existant, but I've tried to to piece together my ideas from the bits used above...

Basically, the idea is to replace the checkboxes with space that can indicate new modules. All modules are then in a single, scannable list, and the enabled/disabled status is reflected in the switches. Also, by bringing the switches into the requires/required box, it allows for enabling pre-requisites while looking at a single module.

Obviously to enable the modules via switches, we probably need to use AJAX to process each individual enable/disable in real time, but it would have the advantage of the support queries of a WSOD when PHP times out because someone has enabled all 50 modules they have just uploaded to start creating the site.

I've had a long discussion with Bojhan (in the Thalys on our way to Paris) about the grouping of modules per category. Here's a mockup which shows the idea.

Created an issue for the slider behavior: #565312: Textfield to slider behavior

I've been working with Drupal for less than a year, but I'm extremely interested usability in general, so here's my input:

Slider toggles
I agree with #61 in that if sliders are to be displayed at all, they should be fully functional. A couple other things to think about:

--I think that the slider as an additional element (as in #62 and a couple of previous mockups) could be very confusing. I understand that the checkboxes now serve a different function (sort of a bulk operations thing, as opposed to the D6 enabled/disabled state), and while I think that could be a good thing, we need to think about how the user will interpret both of those elements. For example, will the user expect an enabled module to have its checkbox checked (as I do because of D6's behavior)? And what does the user expect to happen when he/she toggles the slider? Should he/she have to click "submit" to save their slider changes, as they do with a checkbox?
--If the slider does indeed become a functional toggle element, should the user drag the slider (a la the iPhone) or simply click on the entire "image" to switch states?
--Would the modules page be the only page to use sliders like this? Would other areas of the Drupal admin interface benefit from that kind of UI element as well?

Grouping
This may be a slightly more contentious issue, but I'm not a fan the New / Enabled / Disabled grouping as a default. It feels like many users would have just as much trouble finding a particular module as they do with the D6 layout; as skilip mentioned in #34, it "assumes you know which modules are new, or enabled," which is not always the case. I think that the user should be given a couple different grouping options, including enabled/disabled status.

I'm not sure if this idea has been proposed/suggested/shot down already, but how about using row background colors to indicate each module's status in a (more or less) ungrouped list, sort of like the status report and available updates pages? I realize that there are obstacles to that (e.g. how many different colors/states should there be? should that include colors indicative not only of enabled/disabled, but for up-to-date/in need of security update/etc as well?), but I think it'd be much easier for the user to see what's happening when he/she glances at the list. Any thoughts, or is this just a bad idea all around?

Expandable fieldsets for each module
I'm on the fence about this. On one hand, I love how much potential it has for cleaning up the list, especially with a large number of modules installed. However, I'm also really turned off by the prospect of being required to expand a fieldset before enabling a submodule. It feels like adding unnecessary clicks to me. Another issue: If a user checks the "Check all" box, how will it be indicated that all checkboxes in collapsed fieldsets have been checked as well? Should all collapsed fieldsets automatically expand to show that?

Including permissions
Awesome! I'd love to see this executed, but does that mean we'll lose the standalone permissions page? Or would it be just another method for sorting existing permissions?

Filter by module name
Also awesome, and very important in my mind. I agree that this should be a "search-as-you-type" field.

Add new module
Someone already asked this question in their mockup notes, but what would this link do? Maybe give the user a quick overview of how the module installation process works? I do think it's a good link to have on the page though, especially for new users that may be confused by the process or may expect to have to make Drupal "aware" of a module being added to the modules folder before installing it (I know I did at first).

Sorry for the somewhat disjointed feedback; just trying to be constructive. I hope it helps!

After scanning the thread, I evaluated the last design for my 'daily' use as site builder.

* The "Check all" checkbox for all modules on the page has little or no use in combination with "Enable" or "Disable" action. How often do I disable all modules on a site (at upgrade) or enable all modules (never). However a 'Check all' per section (New, Enabled, Disabled) is very usefull and has a clear purpose.

* The section section title "New" confused me. I guess this is meant to be "Recently added (disabled)".

* The upgrade notification triangle could be repeated/placed on the grouping header when the group is collapsed.

For the rest the design is a big improvement compared to existing.

Regarding #62 I"m not sure how I feel. It seems like the page is getting too busy and scannability is suffering while workflow is not necesarily improving (see #18). I fear the page is becoming more like the mess in #56...

The only upside is that it identifies the core modules. Since upgrading Drupal requires all contrib modules to be disabled, we need some way on the page to identify those. Even better would be a link or button that unchecks the boxes (like http://drupal.org/project/contrib_toggle does). We couldn't really have it recheck boxes after the upgrade unless Drupal somehow saved the state before deactivation.

This might be hashed out elsewhere, but one thing to think about with the sliders is the confusion over whether it's enabled or disabled. In implementing sliders in the past, I've had users ask if it says "on", does that mean it's on, or does that mean if you slide it to the word on, it'll be "on"?

Apple in Mac OS X solved this confusion by putting the labels outside of the slider, so when you push the slider to the word "on", there's no question that the slider is set to the "on" position.

Can someone please post a technical summary of this issue (and maintain that summary by subsequently posting revised summaries)?

That summary should NOT contain questions. If any point is unclear, list all possible ways that have been mentioned in this issue to solve the point, but no questions, nor personal opinions. For examples on how to do this, see http://drupal.org/node/8#comment-287088, http://drupal.org/node/8#comment-628434, http://drupal.org/node/8#comment-1178898, and http://drupal.org/node/8#comment-1184066

I'm referring to summaries of that issue, because this one has the potential to be equally challenging.

Additionally, I'd really like to see a flexibility that allows modules like http://drupal.org/project/module_supports to do their job properly. That said - ideally, we put 90% of that module into core (only informational strings, no hard-wired logic), because I've stopped counting the issues requesting to put some "related" info on a project page or the project's handbooks.

Both scannability and searchability would be best done by an incremental filter. Ie #396478: Searchable modules page ...

@chx Agreed, searching this table is a required interaction. It would immediately increase the find ability of any module better. See #229193: Incremental filter for permissions page for how this was done on permissions page.

@eigentor: Thanks for the summary! Here's the status for what I know:

Everything marked emphasized is still not sure.

1. The scannability of the page must be improved.
   • The grouping has been widely discussed. The 'New' or 'Recently added' group is agreed with everyone. The 'enabled' and 'disabled' can be merged into one group.
   • The floaded state state harmonica's for expanding module's descriptions are excepted as well. These can be used as well for module permissions when the number of user roles don't exceed the number N. When the module has more than one settings/configuration page, a tab can be used as well. Otherwise it'll be a link instead of a tab.
   • The sliders are not really excepted. They are said to be more usable on mobile devices (multitouch screen) than on webpages (mouse interaction). Therefore using checkboxes for both enabling and disabling, and for indication the module statuses are proposed. The big disadvantage of checkboxes are that they aren't expected to behave like they could toggle the module status using AJAX. Therefore a submit action is required when using checkboxes. Any ideas on this?
2. The page must be searchable.
   A search as you type box is widely accepted. I've built this behavior and know someone else did as well (forgot his name), so this shouldn't be hard to get into core. Something like a javascript behavior 'tableFilter'.
3. Findability of related tasks must be improved.
   • For the dependencies: I've proposed to display only required modules inside the module's information tab. If should be possible to enable the required modules just as easy as the other modules. There's no agreement on this.
   • For the permissions: I thought doing this inline was widely supported. Correct me if I'm wrong.
   • Settings/configuration pages: . Display a list of links under a 'floaded state harmonica tab' when more than one config/settings page, only a link when it's only one page. There's no agreement on this.

@tha_sun: could you please explain why module_support could improve the current module page?

@chx: I really hope you're not referring to the vertical tabs. This has been proposed before and has been rejected for several reasons.

Given that this was not a Drupal 7 code slush exception, I'm tempted to move this to Drupal 8. I'm happy to revisit that decision if there is Slush time left after we tackled more of the other exceptions. Until then, this is a low priority issue for me. Of course, it doesn't hurt to keep working on this in parallel, but I wanted to manage people's expectations.

darn it, I was looking forward to this in Drupal 7.

one thing I really hate in Drupal is the excessive use of collapsible fieldsets. what's so wrong with vertical tabs that doesn't get even worse with them?

the modules page is still hard to scan and more often than not you have to select a series of submodules to achieve what you're supposed to with your design. that's a lot of clicks. and it doesn't get any better with these sliders. their purpose is still unclear to me, except for enhancing carpal tunnel syndrome.

OK, I'm not here only for stone throwing, so... my proposal is:

1) a simple "flying" menu with all the module group titles in it (CCK, Views, Media, User Interface, Other etc). this flying menu would work like the excellent Table of Contents, but with the table headers javascript (that's part of drupal core) to stay with the admin while he/she scrolls down.

2) also a sort of a "check all" feature for module groups. with it, you don't have to check CCK, link, text, filefield, imagefield, node reference etc etc etc. one by one.

what do you think?

Moving.

Sorry, not just yet.

Now?

Downgrading all D8 criticals to major per http://drupal.org/node/45111

sub

#937814: [meta] Smarter UI/API separation for modules says hello.

Slider Toggles...

1. Do not actually improve usability
2. Don't make sense when the user is holding a mouse, more appropriate on a touch interface
3. Can't be done on the modules page since the modules page has a crazy dependency tree
4. The modules page submit handler is a performance/memory hog, having to run that everytime the person uses a slider would kill the site
5. We should use jQuery Mobile instead if we're going down that route, as they have it working nicely
6. Can we please stop all the bike shedding and split this up into a number of different actionable items? :-)

I like the idea of favorites.
We could use favorites in other contexts: favorite views, favorite nodes, etc.

As a newbie user of packages like Drupal commons, I know I get submerged by the amount of stuff already in the application, and the items I add on get completely lost in the mass. If there could be a "my favorites" page where I could find links to my modules, nodes, views, blocks, etc, that would be a start to reducing the feeling of being lost in the wilderness.

At the risk of bikeshedding... Would it be possible for the various tabs to be pluggable? For instance, I'd like to write an add-on that allows you to adjust module weights by filtering on a particular hook and drag-and-dropping the list of modules that implement it. It would be nice if I could add that as a tab on the modules page and maybe even re-use some of the search functionality.

Also, per-module configurations could be added as inline per-module tabs in addition to their administrative menu locations.

pillarsdotnet: That's just hook_menu(), no? You can add tabs wherever you'd like.

Also, this is D8UX at this point. :P

I have to agree with #88 - Unless we plan on the modules screen only ever showing up on devices which have touch, we should ditch the sliders. No bike-shed here, just pointing out a big +1. (Also, subscribing)

I don't see any fundamental problems with checkboxes as long as there are "normal" interactions for them like you'd find in just about any web application.

Some requirements I can think off of hand:

• Shift-Click of a checkbox preceded by a single click should select the range. GMail can do this so it's more than possible in a browser by now.
• Select All

I see the 2nd covered but we should have ways to deal with ranges.

Do we have any evidence that people find it difficult to tell if a module is turned on or off with the checkboxes? I know I certainly have never seen that.

The problem with color indicators is you have to also have some "as clear" alternative for those who don't perceive colors that well. For months, I wondered why a colleague of mine couldn't tell when a comment was "private" then I finally asked. He didn't see light colors well (the colors that make up most web apps indicators) - So maybe a larger checkbox is in order. But only slightly. The page is long enough. ;)

@webchick do I ever miss a comment like yours in discussions like this. it's not over till it's tested! ;D

however, UI-wise, both the checkbox and the ON|OFF switch serve the same purpose: to turn things on and off! so there could, I don't know, be a module for changing checkboxes into switches? :P

@eigentor I've once suggested vertical tabs on the modules page, or at least a menu with anchors. I didn't cause much of a commotion, though.

@webkenny totally. the colour blind are people too.

The main advantage of the switch would be allowing modules to be enabled/disable in-line, we might be able to do that with a checkbox if the interaction is clear though.

Having the interactions inline would allow for one at a time (or one + dependencies) at a time enabling / disabling to be enforced, which would avoid situations like trying to enable all modules at once and getting a big wsod when you hit submit (oh the memories).

yes, catch, but when you install a module it creates tables. that would bloat the DB while a user is fidgeting with the modules they want, or even if you happen to switch something on by accident. so you switch it on and off and the tables get created then dropped?

anyhow using both is overkill. I still haven't seen a use case for that.

personally, I think people are waaay too much into their capacitive touch interfaces [tm].

also. it'd be nice if you could check some module and its dependencies get checked automagically. now that would be cool.

I think the use of sliders is really a moot point and something that is really more of a theme level issue anyways. If we can decide on whether or not to enable/disable module on the toggling of a checkbox, then some enterprising JS guru can create a mod/theme that implements toggle slider/buttons that swap out the checkbox. Who know's maybe that functionality could even be built into stark if people like it enough. But the system.module should only implement the ajax and checkboxes and let a theme or contrib module provide that extra cherry on top (IMHO).

I'd also agree with Rob Loach that this should really be broken out into multiple actionable issues.

Sorry to come late to this party, but here are some thoughts, in no particular order...

1) Somewhere in the details provided about each module, we need to list the file name of the module. Or better yet, the file path. At some point during every site's development I go to delete the files for modules which I experimented with, but ultimately didn't use. Unfortunately, in many cases it is not very obvious which files go with which modules. Especially when you have several similar modules that you are testing.

2) I like the idea of color-coded row backgrounds. Namely making the rows for enabled modules green and disabled modules gray. The one thing I'd add to that is a different color for modules that were once installed, but then disabled and not yet uninstalled. These colors should of course be checked by someone who's colorblind, to make sure they're differentiated enough. And I wouldn't rely on color coding alone. Each row should also have some text and/or icons that indicate its status.

3) I agree that the sliders may be unnecessarily problematic and, in combination with the checkboxes, could cause confusion. I've been around for awhile and when I first started looking at the mockups on this issue, I was confused about the disconnect between which modules were checked and which modules had their sliders set to "on". Given this and many other slider issues which have been raised here, my vote is no sliders. Other elements (see 2) could be used to indicate status.

I recognize that removing the sliders and returning to the checkbox as the mechanism for enabling/disabling modules does make the idea of bulk actions difficult to implement. Obviously you can't have one checkbox both signify which modules are enabled and allow you to select modules for bulk actions. I have two possible solutions to this. First, the checkbox could be used solely for selecting modules to be the subject of bulk actions. As long as the current status of those modules is clearly indicted with color-coding/text/icons, it should work just fine. This brings the benefit of bulk actions and is similar to other parts of Drupal, but only one type of action can be done at a time. Another option would be to keep the enable/disable checkboxes similar to how they are now, but add an "Actions" tab when you open a module's details. This would contain additional checkboxes for Update, Uninstall and anything else which might be appropriate. This could be a nice productivity boost—allowing users to string together a whole host of actions in one form submission—but it also could bring problems of its own.

4) Disabling the checkboxes for modules with dependency issues is just annoying. This has been a long standing frustration of mine. I don't want to load a page five times just to disable all the modules I need to disable. If you really want to disable those checkboxes, then there should be a Java Script that enables them dynamically based on the other modules a user selects or unselects in the interface. Of course that seems really complicated to me. A better solution might be keep all checkboxes enabled, but put little warning icons next to them if the module either requires modules that are not yet enabled or is required by modules that have not been disabled. Then, when the form is submitted, Drupal can ask the user if they wish to automatically enable/disable these other modules, assuming they haven't already accounted for that in their other module selections.

5) The new/enabled/disabled organization scheme is great, but to be honest I don't think I'd use it as often as category organization, or even just an alphabetical list. There should be an easy way to switch between these displays and the selection should be remembered between visits to the modules page. At least for the length of the session, if not saved as a user preference.

6) If I've been following this correctly, we're not talking about a "text search box", but rather an as-you-type "title filter field". Much like what the Module Filter module now offers. This seems like an important distinction to me and I want to make sure it stays clear. Also, it's not absolutely necessary, but auto-complete might be nice in this filter field.

7) Right now I appreciate the vertical tabs I get from the Module Filter module which let me quickly isolate one category in the module list. I understand people don't want to use vertical tabs here, which is fine, but there should be a quick and easy way to filter down to one category. A drop-down select list seems the likely candidate. This should work in conjunction with the title filter and should be available in all display modes.

8) As has been pointed out by others, there seems to be a lot of unused space in each row of the table. Why not bring back a little bit more information. Sure, descriptions would be too long, but at the very least we should be able to include the version of each module. You could probably fit the file name as well, with room to spare. Something like:

———————————————————————————————————————————————————————————————————————————————————————————————————
[] !! Content                          cck-8.x-4.2                                         Enabled
———————————————————————————————————————————————————————————————————————————————————————————————————
[]    Imagecache javascript crop       imagecrop-8.x-2.0                     Out-of-date | Enabled
———————————————————————————————————————————————————————————————————————————————————————————————————

This would definitely help scannability. Often I just want to check what version of something I have installed.

9) A reinstall option in the bulk actions drop-down might be nice.

10) The "Permissions" tab in the detail view of each module is a very nice touch, but you should be prepared to deal with sites that have a lot of roles, as well as modules with lots of permissions. I don't think either of those are really edge cases.

11) Looking at the module detail view, as shown in #43, it would be nice if each vertical tab indicated how many items it contained.

12) If we're providing an "Update" action for modules, then there should be a section in the detail view (maybe another vertical tab) which shows all the applicable versions of the module and gives users the option of choosing which one would be installed. Perhaps they want to upgrade to a beta or dev version.

We could use PHP to disable a module's dependents, just as we enable a module's dependencies.

@jstoller I agree with pretty much everything, especially the dropdown in (7).

users select which module group they want to enable modules in, and the group shows up. the rest doesn't matter, so it's taken out of the way. as an added bonus, that gargantuan scroll is minced.

that's pure UI gold. :]

I'm moving this to a feature request, since our new policy adopted in http://drupal.org/node/1201874 puts a cap on all major/critical bugs/tasks. There are many other features just as worthy as this one; we shouldn't prevent them from moving forward just because this is categorized as a task instead of a feature.

Considering the awful performance of this page in usability testing and it's relative importance to using Drupal succesfully this issue is more of a bug than a task even. Downgrading this to a feature request comes across as ignoring that problem imo.

Yeah I'm moving this back to a task for now, there is plenty of bad code around the modules page, #820054: Add support for recommends[] and fix install profile dependency special casing and #943772: field_delete_field() and others fail for inactive fields for example - so this is something that needs refactoring both at the API and UX level, and they will need to be done in concert to at least some extent (the field critical adds a new concept to the Modules UI that it's not really built for, for example).

Ugh, well I look forward to this being fixed in the next 6 months so I can get in my first feature patch in 2012. :P

Having the Batch API on there would be super duper helpful.

In case you missed it, How to fix the modules page, by Earl Miles. He makes a few points:

• Add module "categories"
• Have "package" actually retain to modules
• Filter/sort
• K.I.S.S. - Up front information should be limited
• Status indicators to make enabling multiple modules not as expensive
• File dates in the system table

I personally don't agree with all of Earl Miles suggestions (or for some I simply fail to see how much they'd improve things - if at all), but I surely like to see these implemented:

1. Filtering and sorting (currently I use Module filter to achieve this).
2. Modules' update status indication right there on the modules' page.

Since this is about redesigning the modules' page, I am also cross posting my suggestion in #857090: D8 Modules' page: Add links to module help, project page + merge operations links to one cell.:

3. Move the operations links to a single table cell. Please see how table widths are messed up and inconsistent in narrow themes (like the core bartik) and how much more clean it looks when the extra links are rendered in a single cell.

..oh I forgot to mention:

4. Enabling/disabling without page refresh (à la Views 3).

module page missing some important info / features:
1. When a module is missing, it display shortname (machine/code name). It hard to find out the module if that is a sub module
2. Missing a way to Delete modules from harddisk
3. Missing an automatically way to download missing modules

sub +1

Reading this issue from start one sees a lot of mockups (probably outdated/obsolete now) and there's no way to actually know where we stand right now since this stared back in August 2009 as a D7 issue. We need an up to date summary with currently decided/chosen battle plan or perhaps just ditch this one and start afresh.

...breaking it down to smaller issues would help too.

Cross-referencing #913712: Improve modules page table poor layout.

~

someone able to update Issue Summary ? Thanks.

I'd be willing to spend some time to do that, if only I knew what was finally decided. I mean, from reading the whole issue, I can see various mockups and ideas thrown here and there (most of them badly outdated too), but no fix on a specific target.

As for updated mockups, I guess at least for the search/filtering feature that seems to be widely requested/desired, you can try the combination of Module filter and Instant filter as I've already suggested back in #112 for a live, working demo ;)

I personally prefer the forked project Module filter NG instead of the original Module filter because:
- it implements #1023252: UI should utilize Drupal 7 core more - new 7.x-2.x branch?
- it is actively maintained/updated in tandem with Instant filter (same maintainer).
- it implements my suggestion to merge operations in a single cell for a cleaner table layout.

@klonos Nothing has been decided yet from a UX perspective, other than it being neccairy to have a search function. I'd say thats one of the first things we need to get in and is currently lacking activity over at #396478: Searchable modules page

subscribing

Related: #1291592: D8UX: Batch API for the Modules page

#119: Most contributors can't edit the summary because of the input format used. If someone could swap the input format now that anyone can post images, then we can add a summary. :)

Edit: the issue summary is now Filtered HTML.

Seconding yoroy's comments about sorting. Enabled vs. not, at the very least. After installing a new module it can be a pain to find it, though Mark Boulton's 7.x Seven theme has made it much less stressful on the eyes. A toggle for sorting by install date would be useful for enabled modules (and if applied across the board as opposed to filtering on enabled modules, would inherently implement enabled vs. not... to some degree).

Let me begin by first explaining a little of Module Filter's evolution.

Back in '08 I became overly annoyed with trying to find the module I was looking for and thus spawned Module Filter. At that time Module Filter only offered the ability to filter, no tabs or other UX tweaks. Eventually I dug deeper into improving the modules page (at least improvement in my own eyes) by implementing tabs instead of fieldsets (the tabs look was inspired by Views 2) and the addition of an "All" tab. This required Module Filter to override the theming of the page, partly to get rid of the fieldsets and partly to alphabetize the projects (modules). The "All" tab allowed the end user to filter over everything and to present everything in alphabetical order rather than alphabetical only within the package. Switching to a tab acts like a filter in of itself, filtering modules based on a package. I eventually added things like the +1/-1 count and their associated row colorings, the additional filtering checkboxes (a feature request), the count shown just below the title of the active tab of the number of enabled modules out of the total available modules for that tab, and the ability to keep the save configuration button accessible when scrolling.

Several have asked that Module Filter's tabs would utilize the work done by Vertical Tabs. I recall when I was first implementing the tabs view that Vertical Tabs was being developed. At a point I had pondered requiring Vertical Tabs for the tabs implementation but decided against it for Drupal 6 as I didn't want the module to be dependent on another. As for Drupal 7 I have not been convinced to switch probably solely on the lack of being able to display an "All" listing in alphabetical order without some major JavaScript magic.

Now comes the Drupal 7 2.x branch. Thanks to some spurring from both @klonos and @Kiphaas7 I begun an almost rewrite of the module, cleaning the code, making the tabs look a little more like Drupal 7's integrated vertical tabs, and improved performance. The improvements, though, have not stopped there, and is partly the reason 2.x is still only available as a dev release. The following, and what is more in context to this issue thread, are further additions made to the 2.x branch of Module Filter.

1. Replaced the +1/-1 with a CSV string of each module's name.
2. Removed the Operations column and appended the operation links to the Description area. Formatted the operation links to display inline.
3. You'll notice there is no longer an "All" tab. Now when no tab is selected, the list will show everything just like the "All" tab did. When a tab is selected, click it to deselect it. You might also notice that the "Other" tab is slightly lighter than the rest, this is because my mouse (which was not captured in the screenshot) was hovering over the "Advanced help" project which resides within the "Other" package. This allows the user to browse over the entire list of modules and be able to see what package it belongs to (as long as the tab area is visible).
4. The "Save configuration" button area now by default will stick to the bottom of the window when the tabs list is longer than the visible area of the browser window, and sticks to the top when scrolling past the list of tabs.

5. You can see the "Save configuration" button area stickied to the bottom of the window.
6. Shows what it looks like when a tab is selected.

7. Filter text is entered and the tabs not containing matches are hidden. This can be disabled in settings for Module Filter.
8. A count of matches for each package is displayed in it's tab.
9. Filter operators. Currently the 2.x branch offers three operators: requires, requiredBy, and description. I won't elaborate here as I think it's fairly self-explanatory, though the screenshot reflects the queries processing with AND I intend to make it process with OR. This is because I felt the chances of not finding what you need based on the use of a single query were slim and that by instead using OR allows for users to list modules like ones that require "Views" as well as ones with "Store" in the description.
10. A simple clear link that clears the filter input.

Not shown in any of the screenshots is the use of URL query strings. Basically URL query strings can be used to default the filter input and checkboxes. Currently the implementation is only half-baked, the URL queries can be entered by hand but not yet programmatically. This spawned from the desire to remember what filter criteria was set (including what tab was selected) when the form was submitted and to re-apply them. By using URL query strings the modules page becomes much more friendly via links. For example, module's help text (hook_help or perhaps advanced_help module) could link to the modules page and pre-define relevant criteria.

I hope this helps to prove at least that the core modules page does in fact leave a lot to be desired. I am glad to see it is a priority to Drupal 8. And thank you @eigentor for bringing me in to this thread.

Awesome write-up, thanks! One question that immediately came to mind was regarding your point 3: how to select no tab after you did select one? I'll have to play around with the module a bit.

This also shows that Ubercart is a very bad boy :)

Ahh, yes, excuse my forgetfulness. Selecting the active tab would deselect it. I've edited the post to include this point.

Wow James! Thanx for taking the time to explain all the progress made in the 2.x branch. Perhaps you need to edit those img tags and reduce the screenshots' width so they fit nicely in smaller screens though ;)

I kinda stopped following the progress of Module Filter around September 15th (that is the last 7.x-2.x-dev I have downloaded) because I switched to using Kiphaas7's fork instead: Module filter NG (NG stands for "New Generation"). The main two differences of this fork to your original module that made me decide the switch were that:

a) it takes advantage of Instant filter (that I think should be in core btw). Instant filter implements a generic filter API (re)usable by other pages than just the modules pages like the users, content, admin/config and reports/updates pages. There are feature requests filed in order to also implement it in the permissions & reports/dblog pages - perhaps other pages could benefit too:

#793478: Add instantfilter to permissions configuration form
#1342072: Add Instant filter to the "Recent log messages" (admin/reports/dblog) page

b) it implements #1023252: UI should utilize Drupal 7 core more - new 7.x-2.x branch? and uses core as much as possible (core vertical tabs for example).

c) it implemented feature 2 shown in the 1st screenshot at post #127 (your module -the 1.x branch- didn't do that back then). #857090: D8 Modules' page: Add links to module help, project page + merge operations links to one cell. is the related issue filed against core.

Can you please update on whether you decided to or have already implemented any of a or b above in the 2.x branch??

Mind you, right now I think this discussion is better served with a clear definition of the different *problems* we want to solve on the module page. It's tempting to start discussing this in terms of which parts of which existing contrib module should be moved to core. There's value in that, but we need to be able to discuss this based on user goals first.

This is not to discourage the discussion here, just pointing out what needs to be done to be able to move this forward. At 130 comments in we need to step back, regroup and outline the high-level objectives and create some better-scoped follow-up issues.

Comment #73 has a good start for the summary we need. Anyone up to editing the original post on top and add an updated version of #73 there?

Again, thanks for all the input & do continue :)

Hmm I always disliked the table inside a vertical tab idea. I think it's better to move tables and stuff outside the vertical tabs.
Here is a screenshot to show what I mean. I just cut pasted a few things around.

And now we should do what yoroy says in 131 ;)
After defining our goals I would brake up the patch in several sub tasks.
The filter for example can be added afterwards. (if we choose to use a filter)

Personally I would hate the vertical tabs, because they'd prevent me from searching/scanning on the page for the module I wanted to enable, and I'd have to effing click around looking for it.

Edit: Alright, aspilicious tells me that if you click a tab a second time, it disables it and shows the full list. (?) Doesn't seem intuitive to me, but I guess maybe the mockups don't convey everything.

xjm: in addition to aspilicious' clarification, note that when you first get to the page all the modules are listed by default and you can scan all you want. IMO this makes the less-than-intuitive nature of clicking a tab a second time, much less important since that is the default view a user sees

Click-to-deselect, while a welcome new feature, still seems unnecessarily unintuitive to me. I prefer to see the "All modules" tab come back.

@aspilicious, #132: having the table header as shown in your screenshot/mockup (on top of/outside the tabs) is kinda WTF for me UI-wise (and plain ugly if we count personal opinions here). It seems as if the categories tabs are actually some badly aligned cells or messed up rows. Most users (at least Windows apps/UI accustomed people) would expect different behavior from such a UI design. Tabs are there to group together a set of things. They don't need a header (IMO) and that goes for all vertical tabs used across all Drupal UI too - not only those that contain tables. It's simply a matter of consistency.

I could live with the table headings being on top of the vertical tabs set, but we should definitely not add a "Category" heading for the tabs. On the other hand... if we don't, then why bother moving the table headings outside the tab?

@xjm, #133:

...I would hate the vertical tabs, because they'd prevent me from searching/scanning on the page...

When you say "searching/scanning" here, do you mean "looking"/"scrolling" at the whole of the page and "manually" looking for the desired module? I'm asking simply because the actual "searching" (as in "filtering" - not "looking") I believe is well taken care of by the filter thing: simply start typing a few keystrokes! I'm sure you'll agree that this is way more effective then one trying to "manually" locate things.

Updated issue summary.

Yes, we shouldn't get too exited and kill any kittens at all on our way trying to solve this one. Thomas did a great job updating the issue summary (thanx), lets now define the problems and break this down to smaller issues. Shall we?...

I was thinking to perhaps start by trying to solve the searching/filtering thing, since this would be a major UX improvement. As I previously said back in #130, I strongly believe that we should focus on using some sort of a generic API for form filtering so that we can re-use it in other forms all around the UI as well. The Instant filter contrib project is already doing a great job in doing that. I think that besides the standard filter field it also provides the ability to use sets of checkboxes in order to filter things by certain pre-defined properties.

Then we can move to solving the grouping thing. It is generally agreed that the modules' page tents to get bulkier as more and more modules are added to any installation. The way we have it now is a major UX put-off for any site admin going through that page. This makes common tasks a really tedious job. We seem to agree that taking advantage of the core vertical tabs is the most preferred way to solve this.

These are IMO the two major things that should be broken to two separate issues. Once we get these in (or in parallel - but definitely in separate issues), we can add in all the smart ideas like...

- the easily accessible & always-in-view, sticky "Save configuration button",
- the merging of the actions links, so they don't take that much space for no obvious reason
- all the nice visual "goodies" like the indicator numbers & module names on the tabs etc
- ...

...so? Do we agree on:

a) making this a meta-issue (it kinda already is)
b) filing a new issue about having a generic, reusable form searching/filtering API in core
c) filing a new issue for implementing the searching/filtering API in the /admin/modules page (for other admin pages we create separate issues)
d) filing a new issue for implementing (better) grouping in the /admin/modules page by using core vertical tabs
e) filing separate issues for implementing each smart UI improvement we already came up or might come up with in the future

I do think the addition of Instant Filter, or some variant, into core should be a high priority as it would ease use of several pages and who knows how many contrib modules. That being said, I do think that the filtering should take a back seat. I think we need to settle on where we need to go first. Let a separate issue of adding a core "instant filter" take care of the filtering, possibly then later coming back here to include specific filter rules and such. Especially for graceful JavaScript degradation.

Considering graceful JavaScript degradation, I think we need to use a construct of form inputs for filtering the list. Though when JavaScript is available I think we should lend the filtering to core's instant filter.

I like the idea of three groups (new, enabled, and disabled) but I wonder if it could be problematic at the same time. For example, say I'm looking for the Entity Tokens module and I'm not sure if it is new, enabled, or disabled. To make matters worse I have JavaScript disabled so I have to either use the browsers find feature (which we all know is a nuisance) or I have to look through each of the three groups. I think it would be simpler to just keep everything together, alphabetically, and let the filter do the work. Or perhaps even better, provide a toggle where the modules are all in one group or split into three.

If elected to go with using the three groups, I think tabs should definitely be dropped and rely on the filter for reducing the list(s) to modules in selected categories.

I'm a little wary about the batch processing, but other than that I'm liking where this is going.

Thanks for the summary eigentor!

Sun outlines some todo's in http://drupal.org/node/396478#comment-5093082, including this yet to be opened issue:

Enhancement of themed tables to contain a concept of "rowgroups" (which is yet unknown to me). That's a wide-ranging and pretty fundamental change on its own.

#396478: Searchable modules page and
#229193: Incremental filter for permissions page, too.

Also, less words, more sketches in here :) There's older issues here and discussions on g.d.o/usability with other ideas. Research and collect these ideas and images will also be full of win.

Here are some visuals, as requested.

First, I moved the filtering out of the vertical tabs. These filters will apply no matter which tab the user is on and should persist as the user navigates from tab to tab.

I created two clusters of vertical tabs, to allow for different modes of searching and increase "findability" of modules. The first cluster includes the default "All modules" tab, as well as easy access to viewing just newly installed modules, enabled modules, or disabled modules. Below that are the familiar category tabs.

In order to improve "scannability" I drastically reduced the information provided in each row. I propose that when scanning over the table, the important information is:

• Is this module enabled?
• The name of the module
• The project name and version
• Any reason I should pay attention to that module now (i.e. upgrade needed)

Descriptions and required modules are important, but they contain too much text and inhibit scannability, so I've moved them lower in the hierarchy. Clicking on the module name or disclosure triangle will reveal details about that module (see "Context" in the image below). This includes the module description, any available actions and lists of other required/dependent modules. It also includes a list of available updates to this module. From here, the user can enable/disable any dependent modules, or pick an update to instal.

By default these lists will be in alphabetical order by module name. However, I envision that click-sorting can be used to sort them by project name as well. Also, all the tabs in the top tab cluster have a "Group by category" checkbox. Checking this will still list all the modules, but will group them by category (see image below). I thought about permitting the categories to be collapsed, as they are now, but decided that the category tabs negated that need.

The category tabs work as you would expect. And of course, these tabs don't require the "Group by category" checkbox.

Thoughts?

re #145:

1. AWESOME!
2. What else is in the "module name" dropdown to the left of the filter input?
3. How do we know what is "new"?
4. I would suggest having a second save button just below the panel in case it is still long (perhaps we could use CSS media query to hide/show it only if page is tall enough?
5. STUPENDOUS!!!

I've attached my Balsamiq file, for those who are interested. It distracted me from getting any "real work" done today, so I'm glad to know it's useful. :-)

@bleen18:

1. Thanks!
2. I was thinking "Module name", "Project name", possibly "Description", and perhaps "Anything". I'm open to suggestions though. Plus, there may be technical limitations.
3. Not entirely sure. Perhaps Drupal could note the timestamp when a user loads the modules page and compare that to the time when modules were added/updated? It was a request from earlier in this issue, but I haven't worked out the technical details.
4. It would be better, I think, if the button just followed the screen down as the user scrolled the page. That should be easy enough to do with jQuery.
5. Thanks again!

@eigentor:
I wouldn't get too caught up in thinking of any of the tabs as for beginners or advanced users. I would have appreciated the category tabs, even as a beginner, and I'd appreciate the "New modules" tab now, even being strong in the ways of the Drupal.

Color coding is something I considered and still think would be an excellent idea. I just thought the drawing would be more effective in black & white at this point. I don't think it would be appropriate for tabs though. I'm more interested in using color to code the rows of the list. For instance, we could do something like...

• Light-green = enabled modules
• Bright-green = modules that will be enabled on submission
• Grey = modules that will be disabled on submission
• Yellow = modules that have a recommended update pending
• Red = modules that have a security update pending
• Orange = modules that will be updated on submission

All these details can be worked out later though. For now let's stick to big ideas.

+1 for #144 – Good job jstoller!

I'm a little curious how the "requires" and "required by" checkboxes will be processed. Duplicate checkboxes can be a nuisance to deal with. I know it can be done but perhaps there's an easy solution I'm not familiar with. Or perhaps instead of these being checkboxes, a checkmark image is shown for the ones enabled or being enabled. Maybe the name of the "required by" or "requires" module links to it's module listing somehow. Similar thing for the dependent updates.

To the question bleen18 raised in #145 concerning how do we know what a "new" module is. I'd gander Drupal should glean a timestamp from the .info file for each module of when it was added/updated as jstoller describes in #147 and add this to the {systems} table so other modules can use it if ever there is another need for it. One of the many sub-issues to be created of course. :)

So I did some VERY informal, VERY unscientific usability testing with my VERY non-technical wife and she scored really well with this design! My questions included:

Q. How would you turn on a module?
A. Click the "all modules" tab and then click the checkbox

Q. How would you turn off a module?
A. Click the "all modules" tab and then click the checkbox

Q. What do you think happens if I click the "statistics" tab on the left
A. It shows me a page of modules that show statistics.

Q. How would you find info on the "foobar" module?
A. She asked if there was a "foobar" tab on the left, and I said no, so she said she would type in the search box at the top of the table (note: she did not notice the arrow on the left - I had to show it to her)

Q. (showing the design with module detail) What do each of these options do?
A. The "help, Config, perms" links were obvious. The requires & required by lists were clear, but the meaning of the checkbox wasnt. Available updates made sense too. She assumes if you click the checkbox it will update the module.

Based on this unscientific study I would say that the proposed design is extremely successful. I suspect that even the areas that were not totally clear (like the arrow on the left) would be much more clear once the design is fleshed out.

Cant wait to start working on this ... :)

Thanks for the report, good job getting some unexperienced eyes on this.
How would dependencies be handled in this design?

Perfect!!! Thank you for all your hard work and time spent on this excellent write-up Jeremy. If we all agree that these mockups put together all the fundamental ideas discussed here (and elsewhere), lets then break this down to smaller issues and start implementing one feature at a time. Shall we?? Yes, details (such as coloring and filter list drop-down contents) can be worked on later on with successive issues. Two questions though...

Do we re-invent the wheel with filtering, or simply work to get Instant filter in core as a reusable API and then use that?

Are core vertical tabs able to do all we want? If not, do we file issues against vtabs in core or we do custom-coding?

I'm asking because I think we'll have more chances to get things accepted if we depend on core features. If we don't, then I think that at some point we'll be eventually shown the contrib door (i.e. Module Filter/Module filter NG) ...which btw is fine with me - I already use Admin menu instead of the core toolbar like most people I guess.

...btw, while I was at sf, I noticed this nice feature when filtering bugs. Just posting a screenie here so it doesn't get lost.

@klonos: #143 has links to already existing issues for live filtering on admin pages

re: #152

Do we re-invent the wheel with filtering, or simply work to get Instant filter in core as a reusable API and then use that?

I think we would be much beter off working to get Instant filter in core

Are core vertical tabs able to do all we want? If not, do we file issues against vtabs in core or we do custom-coding?

I *think* they should be fine ... if we find that we need to tweak, I would say we worry about that when we get there in the "Ok we decided on a direction, lets build the v-tabs for module admin page" issue

That all said, it seems to me that we have 2 issues to open here:

• Get "instant filter" into core
• Implement vertical tabs on the module admin page

This is something I have seen on a very big Dutch tech site. All filters are checkboxes on the left, even packages/categories. This would allow users to view modules from different packages at once, but it would make the 'single package view' require two clicks instead of just one.

Actually, I find that a very interesting approach. However I really question the use of enabling one to several categories?

@eigentor, #156: While I understand (some of) your concerns Thomas, -when it comes to vtabs- you do need to keep in mind the following:

- the use of vtabs was "decided" mainly because they are in core and because that's what we used when we needed to address the same issue (group/organize a very long list of things that grows as people install more modules) for the content edit form in D7. In other words the main reasons were keeping UI consistency and reusing existing code that does what we're after (as opposed to figuring out a solution that required custom-coding something from scratch).
- the "decision" might seem as if it was a bit rushed (without any actual UX studies etc), but if you consider the success vtabs had with providing sanity in content edit forms, one foresees how they could help with the modules page too.
- one can actually see all that in action if they install either Module Filter or Module filter NG.
- we might have not actually gone through any extensive UX study specifically for this before implementing it, but we did have a wide acceptance of its use (a lot of contrib modules use them in their UI - views for one) and great feedback regarding its usefulness on content edit forms.

@Xano, #157: very intuitive design indeed Bart. I think this implements some kind of solr search type of filtering, but if you give it some more thought, it's not that different from the instant_filter approach:

- instead of having to click on specific tabs, you now have to click on specific checkboxes
- instead of having to click on a "All modules" tab, you would now have a "select/deselect all" checkbox
- they'd both take about the same vertical and horizontal space
- they'd both show the number of current tab/category results (solr search does that)

...most importantly:

- I *think* that solr search type of filtering can also be reused in other admin forms. So we'll benefit in other ways in the future - same if we used instant_filter.

The only advantage I see when using the solr search filtering is that one will be able to filter/select multiple categories at the same time. Don't know how useful that might prove to be, but it is an extra bonus to the features indeed.

Can we implement selected vs total of results in solr? If not, then count that to the cons. Also on the cons: solr searching requires special setup on the server side, while instant_filter not.

Personally, I don't mind which way we go and where we place the widgets as long as we are able to implement all (or at least the most important of) the features we have talked about in this issue. I'm prepared to get accustomed to whichever design, so long as it makes my life easier and every day drupal administration a less tedious task.

Focusing on the problems we're trying to solve, I think a lot of it boils down to use cases like:

- As a site builder, I recently downloaded a new module, and want to enable its functionality.

- As a site builder, I am trying to troubleshoot a specific module.

- As a site builder, I would like to get an overview of what modules are installed on a new site that I recently inherited.

Under none of those circumstances is the category helpful (in fact, it's damaging to the third use case if I can't see all modules at once without clicking 50 times), so its prominence as a primary navigation tool is a bit puzzling. I would actually love to see us get rid of categories altogether, and have sub modules automatically grouped together and the ability for modules such as Address Field to register themselves as submodules of other projects. Not sure if that's on-topic here or not.

But +1 for a "New modules" or similar. That's almost exclusively what I land on this page to interact with.

Personally I like* categories, because it allows to me to see all modules that can be used with Drupal Commerce at one glance. I *don't* like the rigidity with which it works as it is now. Webchick's solution about registering modules as 'children' of other modules (even though they're in different projects) makes sense to me. This doesn't have to do anything with this page directly, but it does influence how this page can be redesigned and AFAIK the package information isn't used elsewhere.

Regarding package vtabs versus checkboxes: the difference is that vtabs present modules in different fixed subgroups whereas checkboxes communicate that there is big list of modules that can be narrowed down with a lot of flexibility. If we continue with displaying/filtering by package, we have to find out if vtabs aren't too rigid and if checkboxes aren't overly flexible and time-consuming.

The advantage* of checkboxes is that we can put all filters in one column/bar, which puts all tools to edit the modules list in one place, whereas vtabs would split these tools in two (the tabs and the remaining textfield/checkboxes).

To address the issue of "new modules": it would be great if we could somehow link to a list that displays new modules only. Do vtabs provide this option? Checkboxes can be prepopulated via the URL.

Another advantage of using a single column with filtering options is that even if JS is disabled for some reason, we can make the filter column position: fixed; so it will still be easily accessible if the list is horribly long. This will backfire if there are too many categories, unless we make the filters scrollable, but we'd end up with Facebook-like sidebar issues.

*) disclaimer: never have I participated in any UX-related study about this horror of a page

@webchick, #160: I personally find categories very useful Angie, both as a filter for the installed modules page in each drupal installation and here in d.o in the module search page as well. It is the only way AFAIK that we *currently* have to help with somehow grouping modules (and thus reducing the length/havoc of the modules page). It is what makes life-saver contrib modules like Module Filter work.

I do find very interesting the feature you propose of being able to define a project as being a submodule of another project or a core module (is there any issue filed for that btw??), but as a complement to the current categories system - not as a replacement. If introducing this ability proves to make categories fully redundant in the future, then yes lets remove categories - but only then. We can for example group various views complementing projects under views and the same for field-providing modules under CCK/Fields or Commerce/Ubercart as Bart mentioned, but where would you group admin_menu under for example?

A similar idea I had was to add the ability to define custom categories and allow admins to group modules to their liking based on these (using the same drag 'n' drop mechanism we have for the blocks page). The continuously growing size of a site's "Other" generic category lead me to this "breakthrough". If we implemented the feature you propose as well, then combining the two one could also drag modules under other modules besides under custom categories (a-la menus' parents/children)

...I can't see all modules at once without clicking 50 times

As long as there is a "All modules" tab or a "check all" checkbox available, it'd only be a single click ;)

@Xano:

Checkboxes can be prepopulated via the URL

Yep, count that to the pros, but please provide a use case where that feature would be useful because I fail to see how it could be used in the modules page. Do we refer to the modules page from certain other admin sections? If we do, it would be great to be able to link and at the same time limit displayed modules down to the intended ones.

I don't know about if tabs can do this. Do they work with #??

As for having all controls in a single place, yes I like that too. In the mockup in #157 I don't see you include the filter filed though. That would still need to be on top someplace. Right?

Yep, count that to the pros, but please provide a use case where that feature would be useful because I fail to see how it could be used in the modules page. Do we refer to the modules page from certain other admin sections? If we do, it would be great to be able to link and at the same time limit displayed modules down to the intended ones.

I think it will be helpful after installation or for use in documentation to be able to link to certain selection of modules.

As for having all controls in a single place, yes I like that too. In the mockup in #157 I don't see you include the filter filed though. That would still need to be on top someplace. Right?

Yes, the filters on the left of #157 don't show the keyword textfield, which would need to be added. My apologies if this wasn't clear. This was a very quick sketch I did this morning right before I had to leave home.

These are the user stories that have frustrated me over the years:

* As a site builder, I want to quickly find a module by name. Current status (in D7): Completely broken

If I hit Control+F and search for the module by name I get all of the modules that depend on it for search results.
Module Filter provides a great way to handle this. Similarly, I like http://api.jquery.com/ 's solution.

* As a site builder, I want to disable all the modules I'm not really using. Current status in D7: Workable, based on experience.

An experienced site builder / developer can know what modules are actually being used by having viewing all of the nodes, views, and other content and know what's being used on that page. It would be nice for a program to do this.

* As a site builder, I want to disable an entire family of modules without submitting the page multiple times. Current status: use drush

I've worked around this issue by standardizing on drush, but it would be nice to provide a UX that
1. informs the user of the consequences of their choice to disable a module that other modules depend on.
2. informs the user that those dependent modules will also be disabled.
3. provide the user a simple way to change their mind before the disabling happens.

@cosmicdreams Would be a great contrib project, I can see this being possible already but its tricky until proven to be possible.

I really like webchicks focus, I want to avoid turning this into a like or don't like categories discussion though :) They have their use, but are quite limited in terms of find ability.

How would we do, having "new modules" do we time their appearance in the sites/default/module folder?

Yeah, I picture basing that off of their file create time on the file system. I have no idea if that's possible in a cross-OS compatible way. :P But that's how I'd do it.

Hm. We could also add something like a timestamp column to the system table and have the function which finds new projects populate it upon inserting new records to that table.

Concerning how to determine what modules are new, my thought is up at #149.

I do think, until a better alternative becomes apparent, we should stick with the current implementation of categorizing modules.

Some of my typical use cases are...

• As a site builder, I'm looking for a module and I know it has something to do with input filters.
• As a site builder, I'd like to take a quick look at all the Views related modules I have installed.

The "All modules" list is important to have and should be the default view, but it is huge and difficult to deal with. Often I may not know the name of a module, or even exactly what I'm looking for, but I know it has something to do with Fields. Having those category tabs lets me very quickly cut the list to a small number of relevant modules, which I can then easily scan to find what I need. From my perspective, the category tabs provide a huge boost to findability and scannability, by letting me quickly flip between focused chunks of data. I'd much rather click between three different category tabs than scroll down the entire list of modules.

Re #157: I'm not as interested in the checkbox approach. That just seems cumbersome. It negates the best aspects of tabs and doesn't seem to provide much in return.

As I said in #144, I think the filters in the form above the list should persist as the user clicks from tab to tab. Taking that a step further, I think that when the user applies filters, any tabs that don't contain relevant data should be visibly disabled. When I apply a filter, I may still have a sizable list of modules, but if I see that those modules fall into only three different categories, one of which is relevant to what I'm looking for, then I just shortened my search time.

+1 for #144

Would be great if we made the Header sticky and let the module section scrollable. The Header could in addition to the search section introduce the bulk operation buttons, or the save configuration button.

With more and more distributions being developed, more and more beginners will have a modules page that shows more than just core packages.

The reason I feel categories are useless is that—apart from the "sub-module" use case, which is clearly valuable—they are one module maintainer's arbitrary decision as to what noun or set of nouns loosely describes the space their module sits in. And there is no consistency between these arbitrary nouns across modules. It's fairly common on a site with more than a handful of modules for your categories to include things like: "Administration", "User interface", "UI", "Admin improvements", "UI tweaks", and so on. So now I need to click 5 possible places to find that module (and in the end, it's probably in "Other" anyway), instead of just scrolling down one single alphabetical list where I could quickly locate something like "Quicktabs" between "Panels" and "Rules." :(

"Entering text in the search box - I mostly am too lazy, if I coult get to my goal without probably some klicks on the tabs would go first."

I don't understand why if you were looking for Quicktabs, you wouldn't just type "Qu" into a search box, which dymaically filters the list and finds it at once, as opposed to scanning down the list of categories (which might number 30 or more), trying to mentally filter those down to a "short list" of ones which most closesly match the thing you're trying to find, clicking the first one, guessing wrong, clicking the next one, reapeat, until you finally just give up and fall back to using the search box. :P

Unless you are very experienced with building Drupal sites, and you happen to intuitively know the package of the most common modules, this is your current path. Putting them into vertical tabs or checkboxes doesn't change it.

In the past an "integrates with" property for modules/themes was suggested. The UI could show these relationships similarly to dependencies. Would this be an improvement over arbitrary predefined packages?

I had a short discussion with webchick, its an interesting idea to consider alphabetical order for this list without the categories exposed by default.

I think we need to look at this without the "installing something new" usecase, which could be handled by a simple "new" switch". I wonder, if we cant have something like searching on a package?

@Xano You touch an interesting point, for distributions this is also a "showing off" what you got point. Having limited to no unrelated modules here (such as core modules), would be beneficial. However I personally think this is better served by something like a marketplace/project browser.

I really like the recent discussions, loads of good ideas!

...I don't mind "hiding" most of the controls (filter checkboxes, categories tabs) as shown in the mockup in #175, but as long as the last hidden/shown state is remembered for successive visits to the modules page. I understand trying to present a less overwhelming UI to newcomers, but as a non-beginner I hate having to click an extra time for each set of controls/widgets I need to use.

A couple of minor notes:

The existence of both the "Enabled modules" & "Disabled modules" tabs along with the "Enabled" & "Disabled" checkboxes might seem redundant to a new user. Perhaps the tabs should be named "All enabled modules" & "All disabled modules".

The "Enabled" & "Disabled" checkboxes should not be presented when one is viewing the "(All) Enabled modules" & "(All) Disabled modules" tabs. It simply makes no sense.

I am really curious how we're going to make this degrade gracefully. With tabs, we'll have multiple occurrences (new, disabled and the module's category, for instance) of most modules on the same page. Without Javascript, how will we know which occurrence's checkbox takes precedence?

I took the liberty to update the issue summary of #430180: Move module_filter (or its functionality) in core for D8 in Module Filter's issue queue since we seem to agree that it is the most suitable candidate in contrib. Despite the issue's title it doesn't necessarily mean that we'll move it in core as is. We can instead "borrow" code/ideas so we don't reinvent the wheel (I've clarified that there as well). Please check it and update as you see fit. Let's make that issue the first of the ones we intended to break this one here into.

I think that -if everyone agrees- I'll open another issue to move Instant filter in core (as a reusable API so it can be used in other places all over the UI) and a third issue to implement it in the modules page.

@Webchick:
I understand your point about the lack of consistency when it comes to package names and I totally agree. However, I still find the category tabs (as currently offered by the Module filter module) incredibly useful. Your example presumes that I know I'm looking for Quicktabs, but more often than not, I don't. So, lets say there were five potentially relevant tabs for me to look in. That still cuts out at least 70-80% of the modules which now I don't need to concern myself with at all. Most of the tabs will only have a handful of modules in them, which I can quickly scan and the time it takes to click between tabs is easily less then the time I would spend scrolling through the whole list. Even when I do end up in the dreaded "Other" list, it just feels so much more manageable when that's all I'm presented with, rather than it floating in a giant list of hundreds of modules. And the categories, inconsistent as they are, still give me a bit of insight into the nature of the modules I'm looking at, which I find helpful.

Perhaps I'm being overly optimistic, but I also think the consistency of package naming could be improved. There's nothing preventing us from coming up with some basic standards for this and adding it to the documentation for contrib developers. It still won't be perfect, but I'm betting we can get a lot closer. We could come up with a few general categories that most modules would fit in and allow the larger modules that have an ecosystem around them to break out into their own categories. That's really where the category tabs shine. I regularly want to see which Views modules I have, or which field modules I have, or which Core modules are enabled. That's not something I can do with a title search field and it's incredibly frustrating to do when presented with the full modules list, even if it is grouped by category.

I think it is important to keep in mind that different users will have different preferred methods to approach this page. Even the same user will find different approaches more or less useful depending on the task at hand. Therefore, I think it behooves us to support as many different modalities as we can, to the extent that we can do so without completely confusing the user.

With that in mind, the question is not so much would you find the category tabs useful, but rather, does the presence of the category tabs prevent you from using this page in a way that does work for you? If having them is not detrimental to your user experience, then we should seriously consider implementing them, since for at least tens of thousands of people, it will greatly improve their user experience.

My goal in #144 was to visually segregate the category tabs into their own cluster, so they wouldn't interfere with other browsing/searching modes, while still providing an intuitive and easily accessible function to those who want it. @eigentor, my preference would be to keep the categories visible at all times, unless UX testing shows that they are causing a problem. And if we do hide them like you show in #175, then as klonos suggests, the expanded state needs to persist across page visits for the same user. Same with hiding advanced filter fields.

@klonos: I think you may be right about not having enabled/disabled as both a filter and a tab. In my mind, the filter seems the more appropriate. Tabs are better for chunking small amounts of information and both of those lists would be way too long. I also can't really think of a time I would use a tab like that. Instead, I suggest adding an "Unused modules" tab, listing contrib modules where no module in the associated project is enabled and therefore the files can be safely deleted. That is something I would use all the time.

Here's a slightly modified version of my original mockup, showing changes to the filters and the upper tab group.

I like where this is going more and more! I think Jeremy nailed it -yet once more- with the enabled/disabled/both radio button set. This way, the "Enabled modules" & "Disabled modules" tabs are simply the "All modules" tab with the respective filter applied. Simple and brilliant.

As for the collapsed or expanded categories dilemma, well... yes when in the "All modules" tab and without any filters applied, it doesn't seem that bad (nor will it seem when in the "Other" category tab that tents to be equally long or more). When one is in a category/tab with only a handful of modules in it, I admit that it does seem ugly to have such a long list to the left that also causes the window to be scrollable & long. Personally, I would easily "compromise" with such a minor ugliness compared to what we currently have.

PS: (kinda off topic rant): If I seem a bit too "eager" in all my posts related to this initiative here as well as HTML5, Libraries API in core and getting core updated to jQuery 1.7 (or whatever is latest), it is only because I secretly hope and wish that if we implement these four features we'd then perhaps give in and release D8 sooner with only these changes ;)

• Modules page redesign + instant_filter in other admin forms in the UI would "mend" some of the bitterness left by things that didn't make it in D7.
• HTML5 would help us get "momentum" - now.
• Libraries in core would provide some more structure sanity (now that we have /core and all) & easier upgradability.
• An updated version of jQuery would provide the basis for other "goodies" -both in core UI and for site developers- by "proving" that core is not as... what's the word I'm looking for here? Archaic??

@klonos: good energy :) I see you found the filter-related issues, it seems like the best place to start if you want to get some code without limiting the design discussion. Go for it!

Awesome, one quick question, because after reading/skimming through all of these comments I'm still not sure:

Why do we need the "Filter list by module name" drop down?

Seems to me that we can simply encode the search bar to be intelligent enough to search the listed modules by module name, category, dependencies, status all through javascript-empowered client-side code.

like this, but better: http://api.jquery.com/

...no reason to have the checkbox that permanently keeps open things (categories or the "more search options"). If we implement a "remember state of controls" from last visit, then that feature would take care of it ;)

There is way to much going on here. Let's think of the kittens and get some scope in here by splitting this into a number of different issues. From the design eigentor proposed at #184, it looks like this could technically be split into the following topics:

1. #1348692: Vertical Tabs for the Modules page
2. Group modules by Category vs Package
3. Group modules by Enabled/Disabled
4. Group newly installed modules
5. #396478: Searchable modules page
6. #1296876: Make dependency list hidden on modules page until requested
7. Update notification on modules page
8. Toggle the vertical tabs on the modules page
9. Table sorting by name/enabled on the modules page

In the attached image, I've numbered each topic according to its design. We should create an issue for each of the previously mentioned.

Hiding categories would hardly remove clutter, since all it does it make an existing item smaller rather than removing unnecessary items from the interface. I'm not sure about hiding filter options either, since they're one row of elements and they're replace with one row of collapsible fieldset.

Instead of using checkboxes for filtering by package, we can also use radios. With some custom JavaScript, they would give us exactly the same behavior as tabs. They degrade much gracefuller though. We would also have some extra space height-wise, since all filters would be located in the left column.

However, before we continue it may be a good idea to decide whether we want to continue using packages or use a more suitable way of categorizing modules. Webchick and I both suggested an alternative. I don't necessarily think we should change this, but if we do want to change it after all, it's not really efficient to be stuck with a new design that was made to use our old-fashioned packages.

@Rob Loach you are thinking too much about the actual implementation, we are just exploring the design here.

Updated Issue Summary once more. Added Link to Comment #88

I thought a bit about what the simplest useful version of this page could look like for small screens.

@Rob Loach, #186:

It all seems a good starting point to me. Lets elaborate a bit further and break these down to separate issues so we can work on them. The issue you point to for #5 is already ~220 posts long and was initially started back in 2009. I'll go through it and try and get its summary updated. What's everyone's opinion on polishing Instant filter and getting it in D8 core instead?

@Xano, #187:

...since they're one row of elements and they're replace with one row of collapsible fieldset.

Good point Bart!

@Bojhan, #188: ...keep exploring the design and pretty soon we'll be renaming the issue to "D9UX: Redesign Modules Page" :/

@eigentor, #189: Thank you Thomas! Heading there...

I think its good to continue with a more holistic discussion of this issue for now, rather than fragment it too much. It doesn't feel like we've reached enough of a consensus on the approach to start breaking this into tasks yet. Exceptions being that everyone seems to want some sort of instant filtering capability (details TBD) and there's broad support for tracking newly installed modules.

@cosmicdreams: I included the dropdown because I thought there was benefit to letting users explicitly choose between searching on module name, package name, description, or all of the above. I think it would be great if we also implemented filter operators—like greenSkin mentioned in #127—but that's really an advanced user function. The dropdown seems more approachable for beginners.

@Xano: I totally agree that hiding stuff doesn't seem necessary. Trading one row of filter settings for a collapsible fieldset doesn't seem worth it. The filter settings aren't providing so much visual clutter that they need to be hidden and doing so would hurt functionality. Again, if UX testing shows that the presence of these few checkboxes and radio buttons is preventing users from understanding the module filtering, then we can hide them. Otherwise, lets leave them out in the open.

I'm against replacing the category tabs with radios. If the radios act like radios, requiring a separate submit button push, then that completely defeats the utility of the tabs. And if they act like tabs, then they should look like tabs.

I also don't think we should try to stick the filter form in the tab sidebar. For me it works better having it above the tabs. Again, I'm trying to visually segregate functionality to make the page more approachable. The tabs are all about chunking data into smaller collections. The filter form is about further reducing the data within those chunks and it works across all tabs. I'm still standing by the mockup in #180.

As for graceful degradation, it seems to me that the most graceful way to do it is simply to remove much of the JavaScript dependent functionality if JavaScript isn't present. Maybe all the tabs just go away, leaving an alphabetical listing of modules and a simple filter form at the top. Correct me if I'm wrong, but I expect the user base for doing administrative site-building tasks, without JavaScript enabled, must be infinitesimal.

Oh plus the heck 1 for #190 and designing for mobile first. That should help a great deal with the rest of the discussion. And I think/hope that makes it clear that adding another 50+ navigation items there per category/package is not going to be a workable solution and will only completely clutter-ify the page for no real gain.

But in critiquing #190, the basic problem with that is CTools.

While there is a module called CTools, CTools is an entire package (in the true sense of the word) of modules: Bulk Export, Page Manager, Stylizer, and so on. When I downloaded the module from Drupal.org, I downloaded "CTools". I am not going to know where the heck "Bulk Export" came from in my list, and I certainly won't know it's part of the CTools package unless there is visual grouping somewhere.

We could solve this by adding > arrow things next to expandable elements, and make that on/off slider default to enabling all sub-modules for a package. But typically you don't really do that. You don't really enable EVERY module that comes with Ubercart, you pick and choose the ones you want. In fact some packages, like FileField in D6, iirc, come with some sort of "edge case" modules for meta-data gathering that require external libraries and the like. You don't want to not be able to install one module in the package because you can't install all modules in the package.

Make sense?

Then in terms of dependencies, I've made a case that dependency information should be obliterated from this page over at #1296876: Make dependency list hidden on modules page until requested, because they're only relevant at enable and disable time, and at no other time do you actually care about this info. So -1 to including dependency info in the search, unless there's a valid use case for it.

@webchick: 190? Really?? Did you perhaps mean 180?

...So -1 to including dependency info in the search, unless there's a valid use case for it.

I can only think the case where one wants to disable a certain module required by a lot others. They then need to first locate all these and disable them before they are actually allowed to finally disable that initial one. If we figure a way to batch-disable modules and their dependencies (first informing the user like we do when enabling modules with dependencies), then yes there is no other use for it - not AFAICT.

No, #190. Because it filters down the problem to only the real, actual uses of that page.

And yeah, I would love to fix the inability to disable modules at once. http://drupal.org/project/qamodules used to do it in D6. Moving that into core would be lovely.

My .graffle file

@jstoller in #192:

I'm against replacing the category tabs with radios. If the radios act like radios, requiring a separate submit button push, then that completely defeats the utility of the tabs. And if they act like tabs, then they should look like tabs.

In a degraded version (no JS) they would act like classic radio buttons with a submit button. With JS. they would update instantly, just like vertical tabs would. From a technical point, this would make more sense than using vertical tabs where modules need to occur more than once. From a UX perspective I have no evidence what will work best.

Webchick, bojhan & yoroy discussed the packaging and filter behavior a bit more.

Wouldn't it be nice to offer a search through d.o. projects when searching locally yields no results we thought:

Talked about the packaging thing some more. Some modules are hit singles, some modules are whole albums. Should we just show package contents directly in the list or put those on a seperate, deeper page:

Within the main list:

On its own page:

graffle file is a mess, start at the last pages.

#198: I'd rather see the page load with everything, no sub-pages, aka the expanded list. The user would toggle these open, but during filtering they should all open so the user can see what the results of the filter are.

What if we stick with the current implementation of "packages" but throw out "Other". Modules that would normally fall under the "Other" package would only be viewable from the "All" tab. Or in the case of yoroy's wireframes for a mobile view, "Other" modules would mix in with the packages (click to show sub-list) in the main list. Scratch that thought, it would make it that much harder to browse over modules not categorized.

@yoroy Awesome work dude!

I also like the one-page results with fancy in-page filtering via the search box.

How about we provide descriptions onclick of the module title?

Love, love, love the stuff at #198. Simple and clear. It's missing the module descriptions and help/perm/settings links, but maybe those sort of "swoosh" down when you click on one of the items in the list (dependency stuff could show up there too I guess, if we really wanted it).

@webchick @yoroy:

I imagine that we'd have jQuery Mobile at our disposal here. So here are some analogs to what we've been talking about:

Search filtered list with inline categories: http://jquerymobile.com/demos/1.0/docs/lists/lists-search-with-dividers....
Accordion style sets that start collapsed and expand: http://jquerymobile.com/demos/1.0/docs/content/content-collapsible-set.html

These accordions that they demo unfortunately don't have much "swoosh".

Darn. Do they at least have cowbell? :)

@webchick, ha. I suppose a question for a future part of this discussion is: Should we adopt jQuery Mobile into core or implement these ideas some other way? Maybe that's a question for John Albin's Mobile initiative?

Are we talking about implementing something like #190/#198 only when administering an installation from mobile/small-screen devices here, or about implementing it as a global admin UI?

@yoroy in #198:
- The second "no results" mockup makes more sense to me. It visually links the search result to the search input.
- Your idea about nesting modules and using subpages is interesting. Do you suggest we nest modules based on their package or based on the project they belong to? Project information is not shipped with modules. AFAIK the only way Drupal knows about such things is if Update.module contacts drupal.org and retrieves the list of projects.
- Using Update.module's information, if a search keyword matches a module name, can we link to its project on Drupal.org directly? This would add an extra link to the search results, but it would take users directly to the project page of the module they searched for.

Sub Issues in hopefully correct format

I'll have to try some mockups for how the expanded view of for a single module in the list might work.

I sense some disbelief around this simplefied approach to this UI though. Don't be put off by proposals that go counter to what was discussed before. The best way towards a *good* idea is to have *many* ideas. The modules page *will* get a serious overhaul for D8, I'm confident it will. We just need to take our time designing the best possible solution before starting implementation.