Testing out some Interface variations.

[paaljoachim]

I see this issue as testing out some variations to how to handle Enabling and disabling auto updates.

Experimenting with icon + Disable text. Icon with slash through it + Enable text. Default: Auto-updates enabled - Disable Icon + On Icon with slash + Off

Individual themes screen experiment.

EDIT: Removing the disabled icons to themes that are not currently being auto updated.

[ronalfy]

This is just my opinion, so please take this as that @paaljoachim

I like the icon next to the enable/disable mostly for aesthetic purposes. Plus in Ajax, we can do some cool animations to it like spinning it without having to use another loading animation icon. I think it should always be visible for all screens, and perhaps use color to indicate whether it's disabled or enabled. However, take Icon+Enable. If we turn the icon red, it seems to me that you're doing something wrong if you click Enable. Likewise for disable, if the icon is green, it gives the impression that everything is okay and no action needs to be taken. I think the icon color should be neutral for both cases.

As far as off or on, in my experience, it's better to give more explicit notes that a particular asset does not have updates enabled/disabled.

Just my 2 cents. Thanks @paaljoachim for the different approaches.

[pedro-mendonca]

Hi, I would like to add a though on this.

Auto-updates is a feature name that started this feature proposal. Being bond to this feature name, all options are around Auto-updates being enabled or disabled. Still, updates already exist in WP core, but are Manual. This feature proposal adds just the Auto option. But disabling auto-updates... is just the existing Manual update.

So, stepping back a bit, we are dealing here with Updates being Manual or Automatic. Which makes the current filters a bit odd: Auto-updates Enabled (4) | Auto-updates Disabled (26)

Would be simpler as: Automatic updates (4) | Manual updates (26)

Keeping this in mind, I suggest something like this:

An alternative, as It seems to me a bit too much to occupy one extra column, maybe as plugin actions:

Thanks to all the contributers that are making this possible :-)

[ronalfy]

@pedro-mendonca @paaljoachim here's the interface in Easy Updates Manager that has served it for the better part of 3 years. It just has one column to indicate which assets have auto-updates enabled. The disabled portion I think can just be removed.

[pedro-mendonca]

Despite the extra UI toggle elements, it's a good solution to just have it below the plugin actions.

For update method status I guess Manual / Automatic do the trick For actions, maybe it's good to keep Enable/Disable auto-updates

[ronalfy]

Just my opinion again, but most users will barely have the concept of automatic updates, if any, in addition to terminology such as manual, which means no action needs to be taken except on the updates screen.

I think if we can make explicit what's being enabled/disabled, we can leave manual off. We should also consider hiding the disabled tab since it's just opposite of the enabled column with no extra information.

So I believe in this case that the Auto-updates Disabled column should just be removed.

[pedro-mendonca]

I agree on hiding the filter Auto-updates Disabled. About the manual term, I specifically used it in the context of a Updates mode status. As action link, I agree that the best solution is Enable/Disable auto-updates.

[pbiron]

So I believe in this case that the Auto-updates Disabled column should just be removed.

I'd be very much against that...just like I'd be very much against core removing the Inactive view.

If I've got 50 plugins installed and 30 of them have auto-updates enabled, it's not easy see which 20 do not have auto-updates enabled, hence the Auto-updates Disabled view.

[ronalfy]

@pbiron makes sense.

[pbiron]

An alternative, as It seems to me a bit too much to occupy one extra column, maybe as plugin actions:

For myself, having the Enable/Disable as row actions would be preferable. However, concerns were raised about the impact that would have for translations in terms of screen real estate, see comment 36 on Trac ticket #48850.

For those who haven't read that Trac Ticket, it has a lot of the history about the various design considerations that were iterated on before this feature plugin even got started (that's not to say discussion of further iteration is unwelcome!).

[paaljoachim]

Some plugins have a lot of links just under the plugin title. Here is an example. Check out the SEO plugin.

Having a Auto update column on the right side looks good to me.

Separate column

• It stands out as something separate. That makes it easier to notice. It is a new feature and it is helpful to have it stand out.

[abuyoyo]

+1 for having the enable/disable button right next to activate/deactivate/delete. This is the most logical. If the auto-update-enable/disable is to be made available via "Bulk Actions" it should also be individually available in the same box as the other "bulk-able" actions. ie. in row actions.

It should not be in the Description box with the "action links". Those are generally used as informative/external links. Not for interacting directly with the plugin installation.

The separate column is just a bad idea imo. Unless you want to move ALL row actions (including activate/uninstall) to a separate column.

As for some plugins adding row actions - it is up to them to decide if all of the actions belong in row actions or if some need to move to Description column's action links (eg. SEO plugin example above - support link can quite comfortably be moved to Description column.)

Also the real-estate issue is easily solved with css wrapping.