Problem/Motivation

Post-#1199946: Disabled modules are broken beyond repair so the "disable" functionality needs to be removed, the Modules UI looks like this:

List of modules with checkboxes, some of which are unchecked, and others of which are disabled.

Checkboxes are used in order to enable modules. However, once modules are enabled they can never be disabled, so the checkboxes stay checked and disabled, even for non-required modules and modules without sub-dependencies (unlike what the disabled checkboxes represented in Drupal 7).

The only thing you can do after enabling a module is uninstall it, but that's on a separate tab, which is not immediately obvious. The discussion here is how to address this disconnect, ideally by combining the two pages.

Proposed resolution

Several proposals have been put forth:

Option 1: Move checkboxes to "bulk operations" style checkboxes, add drop-button for action, add column to indicate on/off status of modules

Mock:
List of modules with checkboxes, on/off status column.

Option 2: Keep checkboxes as they are, make the "off" version perform uninstall

This is the simplest thing that could possibly work. It's tricky however, since "uninstall" is destructive, making it very easy for people to accidentally delete data they didn't mean to by making it "too" easy to perform uninstallation, especially if enabling/uninstalling modules are combined into the same form submission.

yoroy mocked a confirm form to warn people about potential destruction, in response:

You're about to uninstall CTools. These modules rely on CTools and they will also be removed. Are you sure?

Updated confirm form from Bojhan:

Breakdown of what modules are to be turned off, what content/config will be deleted.

Option 3: Stop using checkboxes for communicating state; switch to buttons instead

Possible mockup from Bojhan in #54:

Buttons to the side with a colour indicating module on/off-ness and an install/uninstall action.

The advantage to this approach is that colour cues as well as labels can begin a warning prior to initiating any action. There is also no chance of weird interactions when trying to install and uninstall modules in the same page request. The disadvantage is installing multiple modules in one go is no longer possible (which is convenient esp. for modules like Drupal Commerce, etc. with multiple sub-modules), though presumably toggling would initiate an AJAX request so it wouldn't be quite as tedious (however, bear in mind that each button click is initiating a 30+ second page load by rebuilding all of the various caches).

This one has one other strong advantage which is that it is a very visually stark change from Drupal 7, which is indicative of the stark behavioural change from Drupal 7 as well, which will hopefully cut down on accidental destruction of data from those who do not read warnings carefully enough.

Option 4: Add uninstall button to each enabled module

The 'expanded' row on each module with an 'uninstall' button.

Similar to browser extension UIs, this would place the uninstall button on the same row as the enabled module, within the "expanded" view. This also has the advantages of being highly visible what you're about to do, and an incremental improvement. We would lose the feature of being able to uninstall many modules at once, but this could be a "feature" from a stability POV.

Option 5: Make modules page similar to admin/content

Same style and pattern as with content and module specific actions as dropbuttons. Also including bulk actions and combining this list/layout with confirmation page from Option2.
Modules page styles similar to admin/content list

Remaining tasks

Discuss, deliberate, make a decision.

User interface changes

Yes; that's rather the point. ;)

API changes

Unknown.

Original report by @fubhy

D.o procid experiment

This issue would be a good case study to evaluate procid #2154143: Evaluating Procid, a tool to help the drupal community improve the consensus building process for d.o issues
You do not have to use procid to work on this issue, but if you want to, your feedback would be very helpful.

----

Follow-up / spin-off for #1199946: Disabled modules are broken beyond repair so the "disable" functionality needs to be removed

Once #1199946: Disabled modules are broken beyond repair so the "disable" functionality needs to be removed is in the install/uninstall modules page are going to need some serious overhaul and re-consideration regarding the UX. Let's discuss that here. We might end up with only one page too if we can figure out how to solve this in a way that does not end up with people accidentally uninstalling modules and thereby deleting all their data.

There are currently two WSCCI conversion issues for these two pages:

#1990544: Convert system_modules() to a Controller
#1993202: Convert system_modules_uninstall() to a Controller

Which did get a fair amount of love already. We might want to do a straight conversion first and then fix this issue afterwards after using those two issues basically as first iteration for a clean-up of the existing code.

This issue is critical as it's a required follow-up for the original issue which is also critical.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

yoroy’s picture

Screenshot based on patch in https://drupal.org/node/1199946#comment-7615823 :

Screenshot of greyed out checkboxes on modules page

I tried out the patch that removes disabling/enabling modules. Quickly reviewed it with Fubhy.

Problem:

If we leave things mostly as is, then the checkboxes on the modules page for installed modules are greyed out, because you can't disable anymore, only uninstall.

Uninstall lives on a seperate tab, which is too far away because switching modules on and off is an important site builder tasks, especially in the early stages of site building.

Also, when you uninstall a module it disappears from the modules to uninstall. Which is logical but quite jarring because in the meantime I'd forgotten I was on the uninstall tab. For a moment I thought I had actually deleted the module itself.

Enough reason to design a UI where toggling between un- and installed happens on the main modules page itself.

A first idea:

Mockup, uses checkboxes for selection only, and on/off text labels for installation status

First thing to allow us to get a workable ui for this is to stop using the checkboxes themselves to convey on/off status for the module.

We'd need to introduce specific labels for that. With those in place, we can then use the checkboxes like on the content listing page, to make a selection and then apply an action to it.

This will be confusing if you are used to how the page works now. But it would likely be more consistent with how checkboxes are used on other pages.

tkoleary is exploring more efficient bulk operation ui options in #2022297: [META] Unified toolset for Views in core

Bojhan’s picture

So you can't disable anymore, but you can on/off? I dont really understand, it seems like the checkbox should still work, but simply perform the on/off scenario.

yoroy’s picture

On/off *is* uninstalling, at least that's how I understand it. There's only (un)installing what you can do.

catch’s picture

Right, we could leave the checkbox, make that uninstall, and completely remove the uninstall page. That's got the least impact on the UI, the only issue is that unchecking and hitting submit is going to have more consequences than it used to.

klonos’s picture

...unchecking and hitting submit is going to have more consequences than it used to.

(I'm opposed to the whole idea of removing the disable modules feature, but...) we now have modals available to take care of warning people before they do dangerous stuff.

fubhy’s picture

(I'm opposed to the whole idea of removing the disable modules feature, but...)

It's not an idea, it's a must, and it's decided. I am not targeting this at anyone in specific but every-time someone still questions this decision my blood starts to boil. So let's please just get over with it and move on ;).

we now have modals available to take care of warning people before they do dangerous stuff.

I am not sure if modals are the right thing here. I am actually a little bit concerned about the idea of removing the uninstall modules page as I am worried about people with clumsy hands accidentally un-ticking a checkbox on the overall module list page while acutally just intending to install a set of new modules and then simply hitting confirm on the confirm form, not realizing they also removed a module. By splitting it into two pages that would be much less likely to happen. Not sure about that though and going to trust yoroy's and Bohjan's judgement on this.

However, let's get the WSCCI conversions of the system install/uninstall forms in first, then the disabled modules patch (without refactoring the forms much) and then clean up the install/uninstall form (potentially merging them) as we see fit in this issue.

Bojhan’s picture

I agree with @catch his assessment. We have a separate page for confirmations, which we should use for this.

yoroy’s picture

I discussed this a little bit with bojhan yesterday, and as catch says in #4, we could leave as is, keep checkboxes and make install/uninstall. I would expect a confirmation though, because unchecking will have more impact.

And because if the higher impact of uninstalling I'm a bit worried about installing module a, b & d and uninstalling x and z with a single submit.

The initial proposal is just that, a first sketch to tease out more questions and considerations.

catch’s picture

Status: Active » Postponed

Making it clear this is postponed on the disable issue.

catch’s picture

Status: Postponed » Active
neclimdul’s picture

The current checkboxes fail at conveying state or action weird so I'm going to make this argument again since it goes way back and I actually feel pretty strongly about it. The checkboxes need to be buttons. They both convey the current status and how to change the state much more clearly the checkboxes are ever going to.

I think there's a lot of room for discussion for how that should happen but I'm very convinced for numerous reasons not limited to the removal of disabled issues, this is the correct solution for dealing with these checkboxes.

longwave’s picture

Could we merge the checkbox and the module links into a dropbutton per module, with an Install button for new modules and Configure, Permissions, Uninstall, Help buttons for installed modules?

neclimdul’s picture

I'd say keep it just install/uninstall since it wouldn't be clear that there are unrelated tasks in the dropbutton. Drop button would be a good way to handle uninstall/disable though i think.

yoroy’s picture

Would love to see ideas/sketches around not having checkboxes but buttons instead, makes a lot of sense.

longwave’s picture

The only downside with buttons is that it removes the ability to select and enable many modules simultaneously - but is there much of a use case for this in the UI? Modules with dependencies would still work, and there is always drush for enabling several modules in one go.

Bojhan’s picture

@longwave AJAX! :)

neclimdul’s picture

i think it was more useful when you could go in and disable and enable in one go. the actual downside currently is the delayed caused by rebuilds and cache clears. AJAX could help with some of the perceived delay there. Maybe in the future even provide feedback when we have a sane and trustworthy Batch API. :)

yoroy’s picture

Looking this over with bojhan we stared wondering if there's really a problem here. We could keep the checkboxes *and* remove the need for a seperate 'uninstall' tab and use unchecking the box as the way to uninstall. No need to change things if we can make it work with what's available already.

catch’s picture

I think removing the uninstall tab and making the checkboxes install/uninstall would be fine. That's also something we could change relatively easily then see if more changes need to be made later, but those changes might not need to be critical then or at least would be compared to a better starting point.

Bojhan’s picture

Yes, however we do need to somewhat figure out what we do with dependencies. It'd be nice if all modules can be disabled.

yoroy’s picture

Which is trickier. Uninstalling CTools is likely to remove a whole bunch of data. What about attached sketch?

neclimdul’s picture

"Looking this over with bojhan we stared wondering if there's really a problem here." can you elaborate? I don't understand.

"No need to change things if we can make it work with what's available already." I think I disagree. I don't know the conversation but, fix to a weird state rather then aiming for a better solution seems to be a bad choice. Really, I'm probably just really tired of banging the "buttons do this better" drum for years and hearing "checkboxes are ok, lets just keep doing it." At the _very_ least a button would save finding a checkbox and then moving down to a button and replace it with a single click. Many times its also going to save some page scrolling and confusion.

Even with the warning screen though, prior to unchecking the box and clicking save I would have no idea what was about to happen. This is true of new users and even worse for existing users that will be expecting to disable the modules.

yoroy’s picture

I agree it can get tiring :-)

Making the choice what pattern to use is for now less important than merging the uninstall page back in. More important:
1. Deciding how to handle uninstall of modules that are required by others. People are likely to ignore basic warnings and things are potentially very destructive here so lets find out if we need to special-case this (Are you sure, like really really sure? etc…)
2. Figuring out how to handle the messaging for the potentially more destructive action of uninstalling
3. Decide wether you can install X, Y and Z and uninstall A, B and C in a single go (probably not, but how to handle that)

neclimdul’s picture

Cool. I'm going to beat the button drum just a little bit more because I brought it up in this issue because I think in addition to being better in general, addresses some of those exact concerns and well suited for combining these pages.

1) I think buttons helps this as I think I said. We could provide color queues to make it more clear as well so the warning starts before they click the button.
2) I like your mockup in #21 as a confirmation page. Warning icon, "this could be really bad," and a list. Limited and clear.
3) I would agree not. If you do both, the confirmation messaging gets complicated and how to proceed if you think you might have made a mistake is less clear. I'm not sure how to try to not support both with checkboxes honestly.

StuartJNCC’s picture

I think that the confusion here is that the modules list (Admin -> Extend) shows both installed modules and those that are present in the file system, but not installed.

In my mind this is what is wrong, this main list should show only the currently installed modules. That is what I expect to see and I expect to have to do something extra to install a module.

So, instead of an "Uninstall" tab, there should be an "Install" tab which shows the modules that are present in the file system and available to install. On that page, checkboxes and an "Install" button would work well (you can then happily install multiple modules at once). So, the "+Install a new module" button would take me to the screen where I enter the URL or downloaded file name, do its business (if it worked - it doesn't at the moment! #2042447: Install a module user interface does not install modules (or themes)) and then take me to the Install tab page where it now appears in the list and I can activate it.

The only action on the main list page would then be to unisntall. I am not very bothered about whether that uses buttons or checkboxes, but I do agree that some heavy warnings are needed! If buttons are decided on, then maybe red text and a skull & crossbones icon for the "Uninstall" button!

StuartJNCC’s picture

I think that the confusion here is that the modules list (Admin -> Extend) shows both installed modules and those that are present in the file system, but not installed.

In my mind this is what is wrong, this main list should show only the currently installed modules. That is what I expect to see and I expect to have to do something extra to install a module.

So, instead of an "Uninstall" tab, there should be an "Install" tab which shows the modules that are present in the file system and available to install. On that page, checkboxes and an "Install" button would work well (you can then happily install multiple modules at once). So, the "+Install a new module" button would take me to the screen where I enter the URL or downloaded file name, do its business (if it worked - it doesn't at the moment! #2042447: Install a module user interface does not install modules (or themes)) and then take me to the Install tab page where it now appears in the list and I can activate it.

The only action on the main list page would then be to unisntall. I am not very bothered about whether that uses buttons or checkboxes, but I do agree that some heavy warnings are needed! If buttons are decided on, then maybe red text and a skull & crossbones icon for the "Uninstall" button!

dsnopek’s picture

Can I make a random suggestion?

The "+ Install new module" link should really say "+ Download new module". I've seen clients thinking they are installing a module when just downloading it to the filesystem. Then I say "Now you have to go install it" and they say, "But I already did that!"

vijaycs85’s picture

Just a thought, as a site builder/end user point of you, http://cdn.themelab.com/wp-content/uploads/wordpress-plugins-page.png looks making lots of sense. One thing that we won't get by this approach is enabling multiple modules. IMHO, Which is something not necessary for non-technical people to avoid confusing (not sure which module braking stuff). This way, we push developers to use drush to install/uninstall module.

Minor UI change is activate/deactivate => Install/Uninstall and edit => configuration or settings.

The proposed solution is:

1. Remove all core required modules from the list (we can make it available for developers from a contrib module like devel or a config variable 'mode')
2. Provide a list of module/plugin with link to the project page and link to install and uninstall

lostkangaroo’s picture

#2091363: Update hook_help for System module is blocked until this process can be resolved

YesCT’s picture

mbrett5062’s picture

FileSize
132.35 KB
57.98 KB
93.75 KB
133.88 KB

I have been experimenting with another CMS recently (Processwire), and I like their "Modules" page, it is clear and obvious what is installed, what is not, and also allows to delete the module/files from that page.
Everything is on one page.

When a module is installed it is shown in bold and clear text.
An uninstalled module is shown struck through and in faded text, with an "Install" button and a "Delete" button.
Hitting "Delete" will remove the file/files from your machine, and requires confirmation. "Install, obviously installs the module.

If a module depends on another, then in the uninstalled state, there is no "Install" button, just a simple text label that states "Requires - AnotherModule", which must be installed before the "Install" button for this module will appear.

Some of their modules come as a package of dependencies, and if you select to install they will both be installed, i.e. fieldtype and inputfield. This is indicated by "Also Installs - AnotherModule"

There is no uninstall on this page. To uninstall a module, you must select the module name and you are taken to a separate screen with information about the module and an uninstall area. Selecting uninstall will remove the module from the database and it's data, then it will be struck through and feint on the module page with an "Install and Delete" button added.

Also, the modules page does not show immediately new modules added to the file system, but instead provides a button to "Check for New Modules".

Please note also, the 3 tabs, "Site" "Core" "New" and within the these tabs the page is split into categories.
Plus they have a built in "filter" for module categories.

I am including some screen shots, maybe something like this would be useful.

catch’s picture

Component: base system » system.module
seanr’s picture

I like the idea of keeping the checkboxes and just making the action install/uninstall rather than the old enable/disable. If you checked any that were installed, you'd get a confirmation page like the following:

Are you sure you want to uninstall these modules?
The following modules will be completely uninstalled from your site, and all data from these modules will be lost!

Module 1
Module 2
...

Additionally, these modules will be installed:

Module 7
Module 8

[button with arrow, first selected:]
Uninstall and Install
Uninstall Only
Install Only

[regular button:]
Cancel

If only installs are being performed, you could just skip past the confirmation step (except for the usual dependency confirmation). That keeps the UI relatively similar to what we already have and avoids the one-at-a-time issue presented by the screenshots in 31 (though the other ideas there certainly have merit).

jhodgdon’s picture

There is also another issue about UI issues on the Modules page: #2056089: UI problems on the Modules/Extend page. This issue has no viable/recent summary so I do not know if they are duplicates or not...

jhodgdon’s picture

webchick’s picture

I worry that checkboxes are the wrong UI pattern here, because checkboxes imply toggling opposites, but Uninstalling is NOT the opposite of Enabling. It's an irreversibly destructive action. We can try and put whatever modal warning fanciness we can to cover our asses here, but I don't know that it's enough. I feel we need a clear visual indicator before people even see the modal, because modals are often automatically dismissed by people. The current "uninstall" tab does that successfully, but it's currently too visually distant from the enabling action.

In the process of updating the issue summary; I have a call now but saving my work so far.

webchick’s picture

Priority: Critical » Major
Issue summary: View changes
Issue tags: -Needs issue summary update

Ok, I finished the issue summary update. Might not have gotten every single nuance of every single argument, but at least the major proposals have been enumerated.

Based on reading this entire issue and updating that summary, however, I don't really see any way that this issue is critical. There are only three problems:

1) Checkboxes, once turned on, can never be turned off again (at least, from the same page).
2) There's no visual distinction between required modules/modules with dependents and regular ol' module that can be uninstalled with fewer consequences. (a regression from Drupal 7, but not a critical one)
3) Uninstalling is disconnected from the act of enabling (this could be a feature or a bug, depending on your POV... having to hunt for uninstallation options a bit does prevent people from accidentally destroying data, at least.)

...none of which we would block the release of Drupal 8 on, as far as I can see. All functionality works, it's just not optimally presented.

So reducing priority, this should give us ample space to discuss which of the options is the best fit (or something else).

FWIW, my personal opinion (not "core maintainer decree"):

  • My concern with option 2, even though it's by far the easiest and least disruptive, is that it makes it way too easy to accidentally destroy data, no matter how big and bold we make that warning modal, especially if various modules can be both enabled and uninstalled in the same request. I kind of think this is a no-go, because it could introduce an arguably critical UX problem as a result.
  • In a perfect world, I actually favour option 3 and using buttons, if we could figure the AJAX out to cut down on the annoyance of enabling/uninstalling multiple modules at once (https://www.drupal.org/project/module_filter may be able to serve as a guide here... I worry that the performance of CMI in D8 might make this prohibitive, though). The main reasons are the ability to warn people before they initiate an action that what they're about to do is destructive, and the fact that the behaviour of this page changed drastically from D7, so changing the visuals drastically would help communicate this.
  • However, given where we are in the cycle, Option 1 is probably the most interesting. It shares the advantage of warning people ahead of time of what they're about to do, but it's also a fairly non-invasive change, and has the added bonus of making this page more aligned with other pages that use checkboxes. Both of the current forms already handle the condition of enabling/uninstalling multiple modules at once, and a drop-button would ensure only *either* enabling or uninstalling was taking place during a form submission, not both.
webchick’s picture

Oh, and since it was brought up, I don't think #2056089: UI problems on the Modules/Extend page overlaps at all (seems to be mainly focused on accessibility of the form), but it's fine to keep it as a related issue since it's touching the same page.

catch’s picture

Agreed with major, this is something we can completely replace in a minor release if we want to.

My concern with option 2, even though it's by far the easiest and least disruptive, is that it makes it way too easy to accidentally destroy data, no matter how big and bold we make that warning modal, especially if various modules can be both enabled and uninstalled in the same request. I kind of think this is a no-go, because it could introduce an arguably critical UX problem as a result.

This is slightly mitigated by uninstall validators, which will prevent uninstalling modules that provide entity types or bundles if there's content in them that would be destroyed. However we mainly have that pattern because there's no scalable way to clean up data on module uninstall, so not sure the validators can be 100% relied on as a permanent thing.

yoroy’s picture

I had a look at how different browsers handle their extensions.


Chrome: checkbox to enable/disable, trash icon to uninstall


Firefox: separate buttons for disable and uninstall (remove)


Safari: checkbox to enable/disable, uninstall button

If I understand correctly, our checkbox is irreversible. It will ony be unchecked if it's not been enabled before. After that, you can only uninstall. Maybe something like this?

catch’s picture

Something like that seems pretty consistent with other interfaces.

Android also has uninstall as a separate action (and no disable).

nod_’s picture

Should we just remove the checkbox if it's checked? I always try to click on it despite knowing I can't disable it.

catch’s picture

For me at least I'd wonder whether it was removed intentionally or disappeared due to a rendering issue/bug.

yoroy’s picture

I considered that for a bit, but thought that might be more weird than an uneditable one.
It's still something to consider based on a prototype patch :-)

yoroy’s picture

FileSize
80.9 KB

Easy to show what it would look like, but hard to tell how that would feel:

webchick’s picture

Issue summary: View changes

Oooh, #42 looks really nice. I started doing that same research but wasn't able to arrive at that conclusion. :) We would lose the feature of being able to uninstall many modules at once, but this could be a "feature" from a stability POV.

Added to the issue summary as option 4.

webchick’s picture

Yeah, I actually think disabled checkboxes are fine. I'd have more questions about where the checkbox went than why it's disabled (could look like a weird rendering bug), and if I dig into why checkboxes are disabled, it'll entice me to expand the row to find out why, which is the only way to find the uninstall button, at least in that mock.

davidhernandez’s picture

I would love to have "enable" "disable" buttons like module filter. It makes the UI so much easier, especially with the color coding.

#4 is a reasonable compromise. I agree with the comments that it looks a little confusing removing the checkbox. Not the removal itself, but because the descriptions are all collapsed by default, (as you see with Toolbar in yoroy's screenshot,) so there is no context to why it's removed.

jhodgdon’s picture

Re #59, it's not "enable", "disable", but "enable", "uninstall", just to be clear.

I personally like Option 4 or Option 3 (in that order).

Option 3 would, in my opinion, only be OK if when you slid the button from one side to the other, the enable/uninstall action happened immediately, because I think that is what you expect if you operate a slider. But having the words on the buttons just be "on" and "off" is I think a bit mild, considering that "off" really means "DESTROY SOME DATA". To me, having a button you click that says "uninstall" is a better signal.

I don't like option 1 or 2, because personally I hate UI where a checkbox actually does an action. To me a checkbox is "select an option" and I expect to then hit a submit button of some kind in order to save the setting.

Given that, Option 4 seems better to me. Having checkboxes to enable modules and a button to uninstall reinforces the concept of them being different and seems the right ui.

Bojhan’s picture

I don't really understand. What options are we supporting with a button/checkbox whatever? Its not a singular install/uninstall?

FYI, disabled checkboxes are truly horrible for usability. People always click them and are confused why it doesn't work.

jhodgdon’s picture

What would happen if we completely reorganized the page: Have one section for "Installed modules" and one section for "Available modules"? The Installed modules section could have no checkboxes, and "Uninstall" buttons. The Available section could have checkboxes and an "Install" button.

Or these could be two separate tabs.

It seems like separating the two sections completely might get around all of the difficulties. The downside is that you'd lose the grouping that currently exists between related modules that are and are not currently installed, but it might be worth it.

Another possibility would be to visually grey-out the modules that are currently not installed. I imagine if the whole entry was greyed out, at least people who can see that would have a clue that they are different from the ones that are currently installed.

Bojhan’s picture

A few more ideas.

From my understanding, we don't actually need the concept of enabling and disabling anymore. So its really only about installing and uninstalling. The checkboxes approach doesn't really work because you cant "disable" something anymore as it requires uninstalling.

The big challenge being that we can't really provide "quick" interactions as some requests take a while. And while we can provide an uninstall option, the destructiveness of it is often missed by users.

What if we do pursue a solution that allows people to "toggle" but with a better uninstall page?

Crazy idea, because it takes a while - we can perhaps let the "green" part of the button animate in and out a few times until the process is done? Then again I might be thinking too 2014 here :) Personally I am not a big fan of using the word "uninstall" on the green button - but not sure how else to do this (the switch is a truly awful interaction in the browser).

Like we do now, we should trigger the confirm page when it has a significant effect. The fact that people brush over this and just quickly continue is from my point of view an artefact of poor design. Within Drupal we rarely do any information design, we keep it very "bland" and only offer tables or fieldsets. This way you can't bulk uninstall modules, other than through dependancies.

While the design below isn't done, its a different way of engaging people with the uninstall action. With a more clear visual explanation of what will happen.

I do want to point out that taking the "shortcut" to solving this problem is what got us here in the first place, we should probably be quite wary of approaches that don't actually fix the problem in a significant way.

davidhernandez’s picture

Ooooooo, I like that second picture. Actually letting me easily see what content will be deleted. How novel. :D

webchick’s picture

Issue summary: View changes

Updating issue summary with those. I agree the confirm form looks bad-ass. :)

We were discussing the button approach in IRC and a couple of concerns:

- The table rows on the modules table are much closer to together in Drupal 8, and this makes the Install/uninstall options very close together, making an accidental click much more likely. (though this is mitigated with the confirm form)
- Each button click here initiates a really expensive rebuild process (takes 20+ seconds on my local with zero contrib modules). And yet, it's extremely common to install multiple modules at once (30+ on a new site install, 5+ on most "big" modules). So even AJAX won't mitigate the performance impacts entirely, since now you only click a button once and it installs/uninstalls in bulk.

webchick’s picture

Bojhan and I went around a few more times in IRC once we had kind of figured buttons wasn't going to work. (Maybe they could still work somehow, but not without a good answer on the performance issues around rebuilding each click, given enabling multiple modules in one go on this page is at least an 80% case.)

I then asked what about yoroy's original idea in Option 1 to just make a bulk edit form here. He said that it would be weird to be able to check some things and perform an action that may or may not have any effect (for example, if you check 5 modules and say "install" but 5 of them are installed already, the form doesn't do anything). Though it's worth pointing out this is the case with all other bulk admin forms in Drupal as well (there's nothing that stops you from checking users who already have the "administrator" role and re-applying the administrator role to them).

Bojhan reiterated the UX problems with disabled checkboxes, esp. empty disabled checkboxes if we keep the ability to bulk-install/uninstall things and don't allow people to attempt to install things that are already installed. We then went back to yoroy's "omit enabled modules' checkboxes" mock in #47. The main problem with that (apart from it's weird that checkboxes come and go) is it's not immediately obvious from viewing https://www.drupal.org/files/issues/uninstall2.jpg that Toolbar module is is installed and Tour module is not. So we're missing an "on/off" indicator here of some kind.

One thing we discussed (though I can't really picture how this would look) is the following:

- checkbox for "uninstalled module, can be installed" (all dependencies met)
- green checkmark icon or whatever (with alt text for accessibility) for "installed module"
- red X icon or whatever (with alt text for accessibility) for "uninstalled module, can't be installed" (dependencies unmet)

By putting uninstall as a button on the far right, you still have to hunt for it a bit (it's under the collapsed section of each table row) but that's probably actually a good thing because we lost the guard rails we had in D7 where the only modules that could be uninstalled were those that were disabled first.

I think that was everything.

vijaycs85’s picture

FileSize
119.1 KB

#57: something like this?

btw, the red one applicable for "installed, can't be uninstalled" (because other installed module(s) dependency) case as well.

vijaycs85’s picture

FileSize
134.81 KB

Or something like this:

checkbox - ready to install
green tick - installed
yellow warning - installed, can't be uninstalled because required by other modules.
red error - can't be installed because missing dependency modules.

jhodgdon’s picture

So... What are our objectives/requirements here? What I'm seeing in this discussion:

a) Being able to check several modules and install them together is a Good Thing. It takes a while to install a module and it's easier to do a bunch at once. So I don't think we want to lose that functionality that we've had since at least D6. [Not sure if this is also necessary for Uninstall, maybe or maybe not?]

b) Checking a box and immediately having it do something is Not A Good Thing. It is not what people expect to happen with a checkbox. If there's a checkbox there should be a Submit button.

c) Separating Uninstall from Install because it's destructive (you don't want to click it by mistake) and because it's different, is a Good Thing. We want to make it kind of difficult or at least more obvious that install is a Big Deal. [It should probably be a red link/button like Delete is if you're on the Edit screen for a node??)

d) Disabled checkboxes are not great UI. People don't understand them.

e) A column where there are some checkboxes and some blank spaces is not great UI. People will wonder if it's just a browser glitch.

f) Having checkboxes that might or might not work would be weird, such as being able to check several boxes and choose a bulk operation like Install, where some of the modules are not actually installable due to missing requirements or are already installed.

Given all of that, I think:
- Option 1 violates (f)
- Option 2 violates (c) and (f)
- Option 3 violates (a) and (c)
- Option 4 violates maybe (a) for uninstall, and probably either (d) or (e) or (f), depending on how "this isn't available for install" is handled in the UI.
- Comment #54 violates (a)
- I don't think #59 violates anything.

Maybe my read on the requirements and assessment has problems but ... it's a start to thinking about it systematically?

Wim Leers’s picture

What about having /admin/modules list all installed modules, without an ability to modify them. Then, have a "Add module" action button (just like we have an "Add field" button) that triggers a modal that allows you to add a module. And either a separate tab/page to uninstall modules, or dropbuttons with a sole "uninstall" operation in the list of all installed modules.

In other words: make this work like almost every other "listing of things" in Drupal 8.

I think this can meet requirements a/b/c/d/e/f as described in #60.

webchick’s picture

Yeah, that's basically option 1. The only thing it violates is f):

"f) Having checkboxes that might or might not work would be weird, such as being able to check several boxes and choose a bulk operation like Install, where some of the modules are not actually installable due to missing requirements or are already installed."

However, my stance is that's not really a huge deal, since the same risk applies to all other bulk operations forms in Drupal. Bojhan brought it up, however.

jhodgdon’s picture

I was going to say "What's wrong with #59, let's just do that!", but then I realized that it violates principle (d) from #60: I think the green "installed" checkboxes are not really operational checkboxes.

So to make it be OK I think we would need to instead of having a green ticked checkbox, use a different icon to indicate "this module is currently installed".

Regarding #61, if I understand it correctly, you would only list on the Modules page the modules that are currently installed. But I think it's *very* useful to have the list of "installed" and "available" (the ones you have the files for but aren't turned on) on the same page, as they are on the current Modules page and have been for many versions of Drupal. It gives you a good idea of which modules you picked and chose and which ones you for some reason didn't have installed, keeping related modules together. That to me is preferable to having to open an "add new" dialog. For instance, if I go to the Views section I could see that I have Views installed plus 3 add-on contrib modules, but I don't have the other add-on contrib module or Views UI installed at the moment. If the Modules page only lists the ones I have available then I have to go out to the file system to see what else is there, which is not at all straightforward in many cases (I might have to look in a lot of places and subdirectories etc.). I would hate to lose that... so maybe I should add it to my list of design principles from #60? I'm not sure if anyone else agrees with them anyway though so I haven't added them to the summary. But if they're added to the summary, let's add:

g) The D7, 6, etc. Modules page gave you the ability to see all of the modules whose files you have available within your Drupal root, by category, whether installed or not. This seems like a Good Feature, because making this list by looking through the file system manually would be tedious to say the least. The drawback to the D7 and previous design is that it isn't clear at a glance what the status is of each module (installed, can be installed, blocked for install by missing requirements, can be uninstalled, blocked for uninstall by required modules).

And by the way... This was kind of implied by I think the screen shots in #54 (or at least I think/hope it was): Could we have an uninstall button on *all* installed modules (except for the very few that Drupal requires to stay on)? So for instance I would like to be able to click Uninstall on Rules, and it should tell me that if it will also uninstall Rules UI, Rules Add-On Foo, Rules Add-On Bar, and all the Commerce modules. And if I decide that is OK it would go through all of them in the right order. But I shouldn't have to waste my time manually having to click through all the "Oh no there is ANOTHER one that I have to uninstall first" if I really want to get rid of all Rules-related modules. As an example. The install works that way -- if I want to install Foo it will ask me to verify that it is going to install 3 required modules as well. Why not uninstall? Ubuntu does this and we clearly have the information needed to do this in the right order and maintain integrity.

Wim Leers’s picture

But I think it's *very* useful to have the list of "installed" and "available" […]

That's fair. I personally find it a painful experience, because I can't easily see what I'm looking for, because on actual sites, there's both many modules installed, and many modules available, and hence… it's a bad UX both in the case of finding which modules I have available to install, and which modules I already have installed. But that's just my 2 cents.

For instance, if I go to the Views section […]

If we'd not see a full list, but only one section at a time — think Vertical Tabs — then my concern from above would mostly go away.

jhodgdon’s picture

Agreed on the vertical tabs or something similar being easier to deal with. That is what at least one or two D7 contrib modules that offer mods to the admin/modules page do, and most D7 site builders use one of these, along with something like Admin Menu, to manage this problem.

And just as a note, yes many sites do indeed have a huge list of modules in their file system. But they usually would also have a huge list of just installed modules; adding the few that aren't installed does not appreciably change the size of the list on most sites I've built and/or worked on. Maybe 20% more at the most (ballpark).

Nchase’s picture

I really hate the new d8 modules list. It is simply unusable. I takes me one click more to find the necessary information I need: the module version and the links to configure & permissions and to enable / disable modules.

This module list is superflous.

Why do developers tweak parts of Drupal which were really good the way they were? The only improvement at the modules list is the contrib module https://www.drupal.org/project/module_filter

Dom.’s picture

What is the beta evaluation on this ? Would it be eventually added to 8.0 is finished on time ?

MalHT’s picture

FileSize
19.06 KB

How about something like this? The current state of the module can be communicated in a better way than the current checkboxes, perhaps with text or with icons (as in #58).

The actual selection of 'install' or 'uninstall' actions is done with links or buttons that instantly mark that module clearly in the UI as 'to be installed' or 'to be uninstalled' - this way multiple selections can be made before clicking Save, and the user can see at a glance what they have changed from the page's initial state. The user does not have to make a selection and apply only one action to that selection as would be the case with a bulk operation.

A 'cancel' link or button is provided to unmark a changed module. This hopefully does away with the checkboxes making install/uninstall look like equivalent actions without making the user hunt around for an uninstall button located somewhere else.

Links idea for module list

vijaycs85’s picture

+1 to #68. We can just move the checkbox to the way right and just hide it behind the link. check/uncheck the checkbox in the background when we click the link. This way, it's simple solution and great accessibility improvement. Thanks @MalHT.

rootwork’s picture

I like this too! +1 to #68.

webchick’s picture

Issue tags: +Needs usability review

#68 does seem interesting. This would allow us to remove the checkbox pattern in a way that doesn't incur 30+ second page loads for every thing clicked, and only incur the 30+ second page load at the end when the set of things to add/remove is defined.

Tagging for the UX team.

rpayanm’s picture

In concert with #68:
Color of "Installed" and "Not istalled" are the same, may be some blue would be nice for "Installed".

jhodgdon’s picture

#68 is interesting, but I am not in favor of having the links marked as "Install" and "Uninstall", unless they are performing these actions immediately.

Also I don't think we really want to go back to 7.x behavior where you can mark a bunch of stuff for install/uninstall at the same time. It was confusing for people, and what if for instance you marked Views for uninstall and Views UI for install at the same time, which would take precedence, since Views UI depends on Views?

webchick’s picture

Well, the dependencies system automatically figures that out for you, even in D7. Views gets installed first, since it's a dependency.

webchick’s picture

Oh, derp I should read more closely. :)

Probably we'd do a round of uninstall before install. Maybe only allow one or the other in a pass, to keep it simpler.

But if we keep the ability to do both and uninstall runs first, in that specific instance, Views would first be uninstalled, and when Views UI was marked for install it would warn the user that it needs to install dependent module Views in order to proceed, and the user would click "OK" same as they do now when they check Views UI without checking Views.

If install ran first, they'd get an error that Views couldn't be uninstalled because there are installed modules requiring it, and they'd have to manually go back and mark Views UI for uninstall as well. Same as now.

So in other words, "no big deal" as far as I can tell?

jhodgdon’s picture

OK. I personally think that the current separation between the install and uninstall pages makes this clearer than the mixture that we had in 7. We must have changed for a reason, which hopefully was based on Usability and not Developer Convenience? The current Uninstall page clearly shows you a list of which modules are able to be uninstalled, which is a destructive operation that should not be taken lightly. The Install page gives you a list of modules that you can install, which is non-destructive. I guess I don't really get, if we made this switch already in 8, why we are now considering reversing it, but I wasn't in on the original decision to split them.

jhodgdon’s picture

I also generally think that links should *do something immediately*. Having a link that really is acting like a checkbox, so that the UI is "Click this link and some others, then when you're done, click Submit at the bottom to finalize it" is not good UI.

David_Rothstein’s picture

FileSize
71.42 KB

@jhodgdon (#76): The separation between the install and uninstall pages isn't new in Drupal 8 - haven't they been separate pages since, like, forever? :)

I agree, though, since uninstall is a destructive operation we should be really wary of combining these pages, especially in any way that looks remotely like a toggle.

The biggest thing needed in this issue is to get rid of the always-disabled checkboxes. They are so bad for usability that I almost filed a bug report about them the other day myself; I'm very familiar with the history of why they're there, but the visual hint they give is so strong that I temporarily forgot and figured there was some bug in core that was treating optional modules as required modules (and thereby preventing all of them from being turned off). Since Drupal 8 is apparently going to release with no capability to turn modules off, the UI has to reflect that.

How about we try to deal with that first, then think about merging the pages later.

The green checkbox part of #58 looks like the best solution for that so far, but since that's also ambiguous per the comments above, I was wondering what would happen if we just put the word "installed" in there somewhere? Here's what I came up with as a first pass:

David_Rothstein’s picture

FileSize
73.64 KB

Cropped image, for people too lazy to zoom or view the full-size version above:

Module page with 'installed' next to the module name, and no checkboxes for enabled modules

webchick’s picture

Oooh, that works!

jhodgdon’s picture

David: You're right... of course in 7 you could *disable* and enable modules on the same page. 8 loses the disable functionality.

And by the way... Try installing Forum and then go to the Uninstall page. You will not see Forum there. You have to go back to the main Modules/Extend page to find out why. So that Uninstall page is not listing all the modules.

David_Rothstein’s picture

Ugh, for future reference the message is "Required by: Drupal (To uninstall Forum first delete all Forums terms.)" - and yes, that message is on the main Modules page which doesn't make sense currently since you can't uninstall from there.

webchick’s picture

We could probably spin-off a sub-issue to make that better, but that's not a new problem... the uninstall page even in D7 only showed options for modules without dependent modules enabled.

jhodgdon’s picture

Yeah, I just think it's weird that *some* modules that you can't disable are shown on the Uninstall page, but not all of them. I really have no idea how this choice is made of which to show and which not to show.

TR’s picture

alexpott’s picture

So the forum module is now always listed on the uninstall page. Things got a lot better now that we don't use hook_system_info_alter() to make modules uninstallable - firstly that was super expensive on cache clears and secondly it lead to that problem (#2392293: Refactor hook_system_info_alter implementations to use ModuleUninstallValidatorInterface)

I think there is have another solution that not mentioned in the summary. We could split out the list of modules that can be installed to one page. The list of modules that are installed to another and leave the uninstall page as it is. Also we should improve the uninstall page so the modules that can not be uninstalled are listed in a separate area and do not have a checkbox. The thing I like about this solution is that when you get to the Extend page you will be presented only with a list of things you can add to you site - the things it can do already are listed elsewhere - which I think will be less overwhelming and easier to use as each page in admin/modules corresponding to a separate task ... installing something new, listing installed modules, listing required updates and uninstalling.

alexpott’s picture

Status: Active » Needs review
FileSize
45.51 KB

The code is a bit ugly but should be good for testing the idea I outlined in #86.

Status: Needs review » Needs work

The last submitted patch, 87: 2035079.87.patch, failed testing.

alexpott’s picture

Status: Needs work » Needs review
FileSize
5.33 KB
47.97 KB

Minor fix ups.

Status: Needs review » Needs work

The last submitted patch, 89: 2035079.89.patch, failed testing.

jhodgdon’s picture

I tried this patch out on simplytest.me and I like it!

When you click on Extend, you get a list of modules that can be installed, on the "Install" tab. That makes sense -- if I click on something saying "Extend", I would expect to be extending my functionality.

Then the other tabs are "Currently installed" (which has no actions, good!), "Update", and "Uninstall". And the Uninstall page clearly tells me why modules cannot be installed. (I even installed Forum and went to Uninstall, and it told me what I'd need to do.) So this is all good. A couple of tests to clean up but I think it is much better than what we have now...

The only drawback is... On the current Modules page in D7, you get a list with all related modules together -- both the ones you have already installed and the other ones that came with the contrib package. This is lost in the new page system. So for instance if I download CTools an Panels in D7, I can see all of those various page manager and panels modules together (or at most in two spots on the same page). Now I would need to switch back and forth between the Install and Currently Installed tabs in order to find this grouping. That could make things difficult in the Contrib universe... I don't think it matters as much for Core, but definitely for Contrib it is an advantage to be able to see the whole group together and know at a glance that you forgot to install one of the related modules.

Thoughts?

loopduplicate’s picture

Oh darn. The patch no longer works on Simplytest.

davidhernandez’s picture

Issue tags: +Needs reroll
vijaycs85’s picture

Status: Needs work » Needs review
Issue tags: -Needs reroll
FileSize
45.8 KB
361 KB

rerolling... Seeing empty message box on 'installed' page. Other than that everything looks fine as mentioned in #91

rootwork’s picture

Re: #91

The only drawback is... On the current Modules page in D7, you get a list with all related modules together -- both the ones you have already installed and the other ones that came with the contrib package. This is lost in the new page system. So for instance if I download CTools an Panels in D7, I can see all of those various page manager and panels modules together (or at most in two spots on the same page). Now I would need to switch back and forth between the Install and Currently Installed tabs in order to find this grouping.

I do think that's an unfortunate development. While I tend to use drush to download and install everything now (which tells you what submodules are present), early on there were some contrib submodules that I never would have discovered had they not been grouped with the main module.

A secondary and more minor issue is that contrib maintainers don't always name their submodules clearly; i.e. they may be counting on that grouping to make clear that a given submodule is part of the main module. (It's true that submodules would also be listed as being dependent on the main module, but if they're also dependent on 6 other modules that information might get lost in the noise.) I suppose contrib maintainers could just be pushed into naming everything better, though.

The main concern is one of discoverability for newer Drupal users, and it does seem like that would be negatively affected by this. I'm not sure if that's a good enough reason, given the positives that this patch would bring, but we should probably be aware there will be more confusion in this area as a result.

jhodgdon’s picture

Note that in #91 I said "fine with caveats". I really don't think we want to lose the ability to see all the grouped modules together for contrib.

Status: Needs review » Needs work

The last submitted patch, 94: 2035079.94.patch, failed testing.

vijaycs85’s picture

Status: Needs work » Needs review
FileSize
45.95 KB
671 bytes

Missed test file renaming...

Status: Needs review » Needs work

The last submitted patch, 98: 2035079-98.patch, failed testing.

Bojhan’s picture

This needs screenshots.

cilefen’s picture

jcnventura’s picture

Version: 8.0.x-dev » 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

dmsmidt’s picture

Issue tags: +sprint, +ux
vulcanr’s picture

I have something to add. I saw the screenshot from #42 which shows to disable and uninstall Firebug for Safari, and yes it could work, but, if we think about it for 2 seconds, uninstalling an enabled module could break your site, maybe by mistake or (because the user doesn't know), I think that the possibility to uninstall it is great, but I think that the option to Uninstall the module should be applicable only for disabled modules.

alexpott’s picture

@vulcanr the problem here is that the whilst the words disable and uninstall from the Firebug example are the same - the actions are not. In the firebug example, disable means don't run the code and uninstall means remove the code completely. In Drupal 8 we've removed the disable step because from the UI you never able to remove the code. In Drupal 7 disable modules still were able to affect the upgrade path - so disabled didn't actually mean don't run the code in all situations.

vulcanr’s picture

@alexpott yeah, makes sense. Didn't think about it, just was following a "user path". +1

Bojhan’s picture

Version: 8.2.x-dev » 8.3.x-dev
Category: Task » Bug report

I would consider this a bug, as it completely hampers understanding of the page.

geerlingguy’s picture

Agreed on the bug report; I've built 4 largeish D8 sites now, and I'm still wasting time trying to figure out why I can't uncheck a module and/or click an uninstall button on the Extend page. It's a definite #UXWTF.

mallezie’s picture

Agreed on the bug report; I've built 4 largeish D8 sites now, and I'm still wasting time trying to figure out why I can't uncheck a module and/or click an uninstall button on the Extend page. It's a definite #UXWTF.

I thought i was the only one suffering from that ;-)

geerlingguy’s picture

Issue tags: +DrupalWTF

Does this issue still 'Needs screenshots'?

yoroy’s picture

Issue tags: -Needs screenshots

nah.

dmsmidt’s picture

I've discussed this issue earlier in the UX slack, but I'll leave my thoughts here aswell.
All current design options have something to say for them. The ultimate solution is imho not yet available.

Goals
Some things I would consider important:

  1. Visually apparent which modules are installed and working v.s. which modules are available and not currently working
  2. Easily undertake actions per module
  3. Allow bulk operations for multiple modules
  4. Don't confuse users with terminology (add, extend, install, enable, uninstall, disable, remove)
  5. Warn of potential data loss

Mix solution
So a possible mix of the shown options would be:
Add visually pleasing buttons per row on the right side for individual module actions. They can also communicate state.
Then put/keep the checkboxes on the left (but don't check the installed modules). Let them be used as we use them for bulk operations. Finally at the bottom and top we then need a 'perform action' select list and button.
This is also more in line with how the rest of the Drupal UI is designed.
In any case we can combine it with the confirm page after taking an action.

Terminology
Furthermore, as can be observed over and over again, is that our terminology used for module/extension management is not clear and consistent.
I find the 'Update' and 'Uninstall' tabs misleading. Because you can't update directly via the UI. A simple change would be to name it 'Available updates'. 'Uninstall' for me implies that also all module files will be deleted.
Currently we have an 'Install new module' button on the top of the page. I would reword that to 'Add new module'. Because at the bottom of the page we also have a button 'Install'. This can be confusing.
I guess this has already been discussed a lot, but I'm unaware what has been the thought process.

Technically possible actions for the user
A bit off-topic, but maybe we should (again) think about which module actions we show and support. I think it would be great if the interface can change depending on the disk writability of folders. In case they are writable we allow and show options for downloading + installing, uninstalling and updating though the UI. And if we can't write to disk we don't show the options which need this. In both cases we should tell about what it means for security and 'ease-of-use'.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

martinhansen’s picture

So, I've started using d8 after many many years of using d7, and encountered this issue the same as everyone has. I found this issue thread (and the seemingly related 2915646 one). However the last comment here is from almost 2 years ago now.

So in the meantime before this is addressed in core, here's a new d8 module you can try out: module_checkbox_clean

It doesn't really make any major changes, but it does at least help out a bit with the UI on the /admin/modules page.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

benjifisher’s picture

We started discussing this issue at #3307567: Drupal Usability Meeting 2022-09-09. We plan to return to this issue at an upcoming meeting. For the record, the attendees at today's usability meeting were @AaronMcHale, @DyanneNova, @rkoller, @shaal, @vitorbs, @worldlinemine, and me.

Personally, I think that a good place to start is to decide what actions can be performed on this page.

One annoyance when uninstalling modules from the UI (currently done on a separate tab) is that the user has to figure out the dependencies and uninstall in multiple steps. That is, you cannot uninstall a module if it is required for any other modules. When installing a module from the UI or with Drush, or when uninstalling a module with Drush, the system takes care of the dependencies, and there is a confirmation step when appropriate. I think it would be a big win if we could do the same thing when uninstalling modules from the UI.

One point that came up during the usability meeting is that there are different problems when uninstalling modules in bulk or one at a time:

  • If you try to uninstall too many modules at once, you sometimes run into a timeout error.
  • If you have to uninstall a lot of modules at once, then it is painful to do them one at a time.

I do not recommend it, but some sites routinely install and uninstall hundreds (!) of modules. (This came up at the usability meeting.) So I think we should provide both options. For comparison, consider the Content page (/admin/content). From the drop button in the last column, a user can delete nodes one at a time. Using the bulk operations, a user can delete several nodes at once.

One more point: it might help control scope if we add a related issue to redesign the confirmation form for disabling modules.

quietone’s picture

This issue was a Bug Smash daily triage target, adding tag. ambermatz dropped a message in #ux which resulted in the comment above explaining that that this issue is scheduled for further review. @benjifisher and ux folks, thanks for looking into this long standing issue!

The group, ambermatz, smustgrave, catch and myself think this is a task not a bug. I am changing the category. catch also wondered "whether project browser is going to end up looking at this UX at some point".

I'm adding a related issues I found when searching for duplicates.

benjifisher’s picture

@quietone:

catch also wondered "whether project browser is going to end up looking at this UX at some point".

I already added this issue as a related issue to #3300397: Consider unifying all the extend tabs into a single tab.

AaronMcHale’s picture

I think #2949629: Split the modules page into Installed, Available, and Uninstall would be a very good first step towards making the UI more usable, it would definitely reduce the number of checkboxes that the user cannot do anything about.

While I think there are some great ideas in this issue, it risks becoming too big and never actually getting done, whereas it's usually easier to get smaller incremental improvement type issues done.

My guess is the issue I linked here will also be consistent with what Project Browser will end up doing (that's just purely speculation on my part though). I do believe that Project Browser does have its sights set on taking over the modules UI, but in any case we'll still need an underlying Core UI, because Project Browser is itself a module which may or may not be installed.

simohell’s picture

Usability review

We discussed this issue at #3310096: Drupal Usability Meeting 2022-09-23. That issue will have a link to a recording of the meeting.

I presented a review of different options using general usability heuristics by Nielsen. The conclusion was that it is probably good to move to make modules page user interface more like admin/content. Option 2 is somewhat different issue from listing page and should be pursued maybe in a seperate issue. Adding more tabs is not a good idea and Project browser taking over is not preferable to complex sites maintained by agencies who do not incluce Project browser in their processes.

For the record, the attendees at today's usability meeting were @AaronMcHale, @Balu Ertl, @benjifisher, @dancbatista, @rkoller, @shaal, @simohell, and @worldlinemine.

simohell’s picture

To limit different styles of coposing and filtering lista I propose using the style from admin/content list.
Here filtering is done using exposed filters and filtered lists are not split across different tabs. I feel this is in line with general usability heurestics and fe. principles of simulation design usability approach. This type of listing uses existing patterns, increases the amount of information provided and improves user control over. To keep up to date these images use the current Claro theme.

Changes to the existing modules page:

  1. add new filters
  2. add dropdown to select bulk actions
  3. use checkboxes to select items for bulk actions
  4. provide module name as a link to project page
  5. use dropbutton default for uninstall/install
  6. move module specific help/permissions/configure links into the dropbutton
  7. display information about module status in seperate columns

(Add module -button in image is an idea that is not currently supported as it would download the module into filesystem. I left it in the screenshot as it would fit there when using patterns from admin/content)

Mockup from modules listing in style of content listing

Mockup with module links as a dropbutton

Here uninstalling modules either using the button or bulk action would result in a confirmation page describes as Option 2. Selecting an action like "install" to already installed modules would just be effectively ignored for those lines. Just like trying to publish already published nodes.

Bulk actions would include

  • Install module
  • Uninstall module

Updating modules etc. could be useful, but they can be considered later.

simohell’s picture

Issue summary: View changes

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

AaronMcHale’s picture

Partial usability review

We discussed this today at #3373236: Drupal Usability Meeting 2023-07-14, it was also previously discussed at #3307567: Drupal Usability Meeting 2022-09-09 and #3310096: Drupal Usability Meeting 2022-09-23.

Those issues will have links to the recordings, the participants in the discussion were: myself, @benjifisher, @rkoller, @simohell and @worldlinemine.

One of the challenges in making recommendations on this issue is that the scope is quite open ended. That's not a bad thing necessarily, but we were not able to complete the discussion at today's meeting (or even at the previous meetings for that matter).

During the meeting we felt it would be more useful to identify specific well-scoped and incremental improvements that could be actioned. We identified three such improvements, and have created child issues for those:

  1. #3374766: Allow uninstalling modules and the modules which are dependent in the same action
  2. #3374768: Use a bulleted list on the install module confirm form, for parity with the uninstall module confirm form
  3. #3374769: On the module list, use a drop/split button for module links

We are planning to continue the discussion (hopefully at next week's meeting), which is why this comment is not a complete review.

AaronMcHale’s picture

Title: Figure out what to do with the install/uninstall modules page » [PP-3] Figure out what to do with the install/uninstall modules page
Status: Needs work » Postponed

Follow-up usability review

We briefly discussed this issue (again) at #3374668: Drupal Usability Meeting 2023-07-21.

That issue will have a link to the meeting recording. For the record the attendees were: myself, @benjifisher and @rkoller.

We have decided to mark this issue as postponed on the three issues that we opened last week. Given that this issue does not have a clear solution, we feel that once those three child issues are done, we can revisit this issue and the solution or any further work needed may be clearer. We hope that this will help to give some direction and steer on how to progress here.

We were also mindful that with initiatives like Project Browser and Automatic Updates, those may provide better interfaces and make further improvements to the UX in the install/uninstall area. There is also a wider effort going on to take a more holistic view on reorganising the admin interface, and that may have implications for the ultimate solution here.