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.

Comments

Issue tags:+Usability
StatusFileSize
new47.51 KB
new55.62 KB

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

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.

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

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.

...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.

(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.

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

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.

Status:Active» Postponed

Making it clear this is postponed on the disable issue.

Status:Postponed» Active

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.

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?

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.

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

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.

@longwave AJAX! :)

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. :)

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.

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.

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

StatusFileSize
new847.5 KB

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

"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.

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)

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.

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!

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!

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!"

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

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