[UX] Improve the UI and UX for managing modules

[klonos]

This issue here is a culmination of thoughts and ideas that have been spinning at the back of my head for years. I have tried to break them up into smaller bits and file separate issues for them, but each one of them presents its own challenge (see #541 and #2532 for instance). Anyway, the whole discussion in #6309 and a series of comments by @stpaultim and @bugfolder specifically triggered the creation of this issue here:

In general, I think we have worked very had to limit help text in the UI, because help text can be a crutch to mask poor UI. It's our preference to make the feature more intuitive to use, rather than simply providing text to help people better understand a bad UI. ...

(And if one thinks that this page is "poor UI" that the help text is masking, I would suggest that would be better addressed by filing a seperate issue with a proposal for the new and improved UI.)

I don't think that the UI in /admin/modules and its sub-pages and sub-sections is necessarily "poor", the UX has room for streamlining and improvement though. So I started working on a possible proposal for consideration on my local to see how things would work and if worth pursuing (still not ready for an PR though). I got slightly demotivated/sidetracked when I got myself into relevant rabbit holes again, revolving around the navigation (primary tabs, breadcrumbs and page titles etc. - see #1509, #1508, #1456 and other relevant/linked issues).

Anyway the gist of my proposal is this:

1. Rename the List modules tab to Enable modules and do not allow anything other than that action to be performed there. Once a module has been enabled, we hide the checkbox - that's it! I am NOT proposing to do what they have done in D8+ where you cannot disable modules any more - read next point...
2. Rename the Uninstall modules tab to Disable modules (or come up with something even more generic that encompasses both actions), and allow both disabling and uninstalling to happen there, as variations of the same cleanup task (depending on the level of cleanup desired). I was thinking that:
   • The uninstall action could be an additional checkbox Also remove configuration and any associated data in the confirmation dialog when disabling modules (with appropriate warnings etc.)
   • Make it so that it is possible to directly fully uninstall modules, skipping the disabling step (we take care of any required intermediate steps in the background - no need to be exposing internal processes to the end user, nor forcing them to follow a two-step process).
   • No need to "lock" checkboxes and requiring some modules to be uninstalled before allowing others to be uninstalled - we should be doing that in the background as well, fully transparently to the person initiating the action. We just figure out the necessary order to disable/uninstall things instead of asking people to manually do it.
   • An alternative to offering the uninstall action as a checkbox would be to offer both options as a radio set with two options. The label would be something like Select method to disable the modules listed above:
     • Keep their configuration and data (allows them to be restored)
     • Fully uninstall them (permanently removes configuration and any associated data)

The benefits of the above:

• There would now be 3 very distinct primary tabs under admin/modules, providing 3 actions that are clearly indicated by their labels, leaving very little to no room for confusion/disambiguation/misinterpretation:
  Enable modules | Install new modules | Disable modules
• No need to include help text in the admin/modules/uninstall tab to explain that disabling modules is required before they can be uninstalled.
• Perhaps even no help text needed to explain that uninstalling modules will fully remove their data and configuration - we show that as an option (with a warning) when confirming the action.

Hard to visualize the above? Stay tuned for screenshots/mockups, or even a PR sandbox to play with...

[kiamlaluno]

I would rather leave the List modules page. It should not be different from pages like /admin/structure/types/list, /admin/structure/block/list, or /admin/structure/layouts/list. The latter is probably the closer to /admin/modules/list, since it has a Install new layout templates tab.

Eventually, Disable modules, Enable modules, Install modules, and Uninstall modules could be actions to show on the List modules page.

[klonos]

@kiamlaluno thanks for the feedback. Most of the things you are proposing have already been discussed previously, and there are a few problems/caveats: We could add individual actions for enabling/disabling/installing/uninstalling modules in the "List modules" page, but that would mean losing the bulk operation of enabling + disabling multiple modules at the same time via the submit button at the bottom of the page. We would need to click multiple action/operation buttons, when needing to enable/disable multiple modules, which is bad UX. So that means that we would need to also add bulk operations to the form if we were to retain the current functionality. That would be fine otherwise, but the checkboxes in that form are currently used to indicate the enabled/disabled status of each module, so they can't be used for bulk operations. We would need to either add another column of checkboxes (which would be confusing), or a separate column to indicate the module status (enabled/disabled/uninstalled). We could explore that option, but I believe that it would lead to other problems and a more complicated UI/UX than the one I am proposing here. So perhaps create a separate issue to explore that idea?

I understand the concern about the potential inconsistency with the other "List xyz" pages (I was actually part of the effort to bring consistency to that - see #525), however we are dealing with a much bigger issue with regards to UX here, which I believe is worth the compromize. Besides, we are already making exceptions to these rules around consistency in the various "List xyz" pages as needed. For instance, the "List layouts" page (admin/structure/layouts/list) that you yourself mentioned is NOT something that manages the layout template type, which is what is similar to modules and themes - that happens in the "Layout templates" tab (admin/structure/layouts/settings) instead. So there's already inconsistency there (because we are dealing with a different type of thing). Another important difference with modules vs. layout templates is that layout templates only have an enabled state and a disabled state - you cannot uninstall them. Same goes with themes: you cannot uninstall them - you can only enable/disable them. Same reasons with admin/structure/block/list: you cannot install/uninstall/disable them - you can only delete them. So I am all for consistency where possible, but a) not when we need to sacrifice UX improvements over it, and b) we should not be comparing apples to oranges.

[kiamlaluno]

I was not suggesting to add actions to each listed module, but action buttons that appear on the top of the listing page. Disable modules, Enable modules, Install modules, and Uninstall modules would still be bulk operations.

Renaming the List modules tab to Enable modules would be a bigger inconsistency. Users would expect the Enable modules tab to enable modules, as the tab name says; they would expect it to list all the existing modules.

[klonos]

I was not suggesting to add actions to each listed module, but action buttons that appear on the top of the listing page.

Are you suggesting secondary tabs then? (similar to those in admin/content/comment):

Users would expect the Enable modules tab to enable modules, as the tab name says; they would expect it to list all the existing modules.

I'm confused 🤔 ...don't you need to go to a list of available modules in order to select which ones to enable? Why would users not expect a list under "Enable modules"? Same with "Install new modules", I would expect a list to browse and select from. Same with "Disable modules", I'd also expect a list to select from. In other words:

• Enable modules: would provide a list of all modules already available on the site (codebase) to select from - already enabled modules would simply not have a checkbox to allow them to be selected.
• Install new modules: would provide a list of contrib modules available to download (install) - any already downloaded modules are already indicated:
  
• Disable modules: would provide a list of both currently enabled and disabled (previously enabled) modules.

So all of these tabs would be listing modules - just different purpose, so it would be filtered to only show modules relevant to the task that can be performed in each tab. Can you please elaborate so that I can understand your argument?

[kiamlaluno]

I am referring to the MENU_LOCAL_ACTION routes, which are rendered in the page as the Add menu link in the following screenshot.

To me, Enable modules is the page to enable modules, which could also list only the not enabled modules, not the page that lists all the installed/installable modules, which could list all the available modules, even the ones still to install.
The page that gives a list of item has a name that starts with List: List themes, List categories, List content types, List custom blocks, List layouts, List menus, List vocabularies, List views, List image styles, List URL aliases, etc.