Drupal Association members fund grants that make connections all over the world.
Post-, the Modules UI looks like this:
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.
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
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:
Updated confirm form from Bojhan:
Option 3: Stop using checkboxes for communicating state; switch to buttons instead
Possible mockup from Bojhan in #54:
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
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.
Discuss, deliberate, make a decision.
User interface changes
Yes; that's rather the point. ;)
Original report by @fubhy
D.o procid experiment
This issue would be a good case study to evaluate procid
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
Onceis 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:
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.
FAILED: [[SimpleTest]]: [PHP 5.5 MySQL] 97,949 pass(es), 135 fail(s), and 4 exception(s). View