Make WordPress Core

Opened 10 years ago

Last modified 5 years ago

#27404 assigned feature request

Widget Customizer: Allow adding inactive widgets to widget areas

Reported by: westonruter's profile westonruter Owned by: melchoyce's profile melchoyce
Milestone: Future Release Priority: normal
Severity: normal Version: 3.9
Component: Widgets Keywords: has-screenshots needs-patch has-ui-feedback
Focuses: ui, javascript Cc:

Description (last modified by westonruter)

Currently a user may add new widget instances to widget areas in the customizer, and they may remove these widgets to send them to the inactive widgets area (aka widget trash). However, there is currently no way to restore these inactive widgets to widget areas without leaving the customizer and going to the widgets admin page.

The widget addition panel should be extended to also list out inactive widgets.

Originally reported at https://github.com/x-team/wp-widget-customizer/issues/46

Related: #39693

Attachments (17)

27404-2-17-16-1.patch (292.7 KB) - added by todd-inmotion 8 years ago.
27404 Patch - not final, progress example, UI not frozen
27404-3-24-16.patch (33.1 KB) - added by rramo012 8 years ago.
27404 Patch
27404-5-2-16.patch (31.9 KB) - added by rramo012 8 years ago.
27404-6-8-16.patch (34.2 KB) - added by rramo012 8 years ago.
27404-1-30-17.patch (34.2 KB) - added by rramo012 7 years ago.
Refresh
focus-2-7-17.PNG (249.4 KB) - added by rramo012 7 years ago.
collapse-2-7-17.PNG (228.6 KB) - added by rramo012 7 years ago.
mobile-2-7-17.PNG (13.9 KB) - added by rramo012 7 years ago.
sidebar-2-7-17.PNG (337.5 KB) - added by rramo012 7 years ago.
sidebar-move-2-7-17.PNG (349.6 KB) - added by rramo012 7 years ago.
customizer-widget-presets-i2.png (245.8 KB) - added by folletto 7 years ago.
Customizer widgets "Presets" area i2
widgets-admin-screen-available-widgets-followed-by-inactive-widgets.png (217.3 KB) - added by westonruter 7 years ago.
customizer-widget-presets-i3_inactive-at-top.png (1.3 MB) - added by melchoyce 7 years ago.
customizer-widget-presets-i3_widgets-in-accordion.png (1.7 MB) - added by melchoyce 7 years ago.
delete-and-deactivate.png (33.1 KB) - added by westonruter 7 years ago.
customizer-widget-presets-i3_combined.png (1.0 MB) - added by melchoyce 7 years ago.
customizer-widget-presets-i3_topv2.png (1.0 MB) - added by melchoyce 7 years ago.

Change History (108)

#1 @westonruter
10 years ago

  • Milestone changed from Awaiting Review to Future Release

#2 @mrjarbenne
9 years ago

Now that users have the ability to change their theme within the customizer (a feature that didn't exist when this ticket was created), I feel the importance of this ticket increases, particularly when the user has a number of customized widgets beyond the standard fare (text widgets with embed codes are a good example).

Without the ability to re-activate inactive widgets, the promise of being able to completely stage your site before taking it live disappears, because the new theme needs to be activated, in order to then navigate to Appearance/Widgets to pull in the previously active widgets.

This ticket may see more attention if it were categorized in the "customize" component, rather than "widgets".

#3 @westonruter
9 years ago

  • Keywords needs-patch added
  • Priority changed from low to normal

See also #19912, as implementing widget groups would be better than using creating orphaned widget areas.

#4 follow-up: @Joel MMCC
8 years ago

How about this method instead or in addition: you know the “Remove” link that appears at the bottom of a widget in the Customizer (next to the redundant “Close” link)? Right now, as @westonruter said, it just moves the widget to the Widget Trash, known to users as “Inactive Widgets” but which is for all intents and purposes a Widget Zone (is that the proper term?) that isn’t displayed on the site.

How about replacing that link with (or adding) a “Move Widget to…” drop-down menu that shows all of the other Widget Zones including the “Inactive Widgets” Trash Zone (at the bottom of the list)? Then with a single mouse move, any Widget can be quickly and easily moved from its current zone to the bottom of any other zone, or made Inactive. The drop-down could either not show the current Widget Zone at all, or show it but disable it (gray it out and make it non-selectable).

With this in mind, the “Inactive Widgets” could simply appear as just another Widget Zone at the bottom of the list of Widget Zones that users first see after going to the Widgets Customizer. No need to add an Inactive Widget. Just go there to see all of your Inactive Widgets, click the one you want, then move it to the Zone you want. Then move back to that Zone and re-order its widgets as desired.

I fully agree with @mrjarbenne that the importance of this has greatly increased now that we can preview Themes other than the currently Active Theme in the Customizer.

Last edited 8 years ago by Joel MMCC (previous) (diff)

#5 @westonruter
8 years ago

Let's try to get on this for 4.5.

#6 in reply to: ↑ 4 @westonruter
8 years ago

Replying to Joel MMCC:

I fully agree with @mrjarbenne that the importance of this has greatly increased now that we can preview Themes other than the currently Active Theme in the Customizer.

The better solution here is to implement #19912 (Add Widget Groups and Locations). This would allow sidebars to be managed in the same way that nav menus are managed: just as you can change which menu is assigned to a given location, so too you should be able to change which group of widgets are associated with a given sidebar (widget area).

#7 @Joel MMCC
8 years ago

The better solution here is to implement #19912 (Add Widget Groups and Locations). This would allow sidebars to be managed in the same way that nav menus are managed: just as you can change which menu is assigned to a given location, so too you should be able to change which group of widgets are associated with a given sidebar (widget area).

I agree with this in principle (and read it when you said the same basic thing before). The difference is that that’s more of a long-term, 5.x solution, since as far as I know it would require a database schema change to implement the concept of “widget groups” as distinct from “widget zones.”

What I was proposing was more of a stop-gap until then, something that could be implemented in 4.5, that would require only a UI change without any change at all to the database schema. And even it would have some use once the widget groups are implemented in, say, 5.0, as the drop-down could be used to quickly move a whole group of widgets from one zone to another from within the Customizer in Live Preview mode on an inactive theme.

As my boss often says, “don’t let the perfect be the enemy of the good.”

Another aspect would be to perhaps change how widgets are handled when the theme is changed and the new theme lacks the same widget zones as the prior theme. At present, it seems that WordPress assigns widgets to what it thinks is the closest matching zone in the new theme, which could cause some horizontal-aspect widget designed for a Header or Above/Below Content zone to wind up in a sidebar. Instead, if there is no closely matching zone name whose nature is obvious, widgets (and groups once those exist) should be assigned to Inactive Widgets (widget trash). Perhaps the schema for widget zones should include a field for the aspect of the zone (landscape, portrait, square, unspecified [default]) and its minimum width to help WordPress determine whether it can safely move widgets into a zone.

Version 0, edited 8 years ago by Joel MMCC (next)

#8 @westonruter
8 years ago

  • Milestone changed from Future Release to 4.5

#9 follow-up: @todd-inmotion
8 years ago

Hi All,

We are doing something very similar for our implementation of WordPress. If nobody has claimed this, we can probably take this ticket and be aligned with the April 4.5 Release. Anyone working on this already?

This is the first time we as a company (InMotion Hosting) would be doing core tickets but we have done lots of work on WordPress and in the Customizer for our BoldGrid suite of plugins and themes. Happy to provide example work if that helps.

Let me know and I will have the developer responsible for this find you on #core-customize to understand how you want us to go forward.

Our internal ticket is described below, but it is open to modification based on feedback to fit core:

In the Customizer, add a new panel to the WordPress widget areas section tentatively named "Inactive Widgets". The inactive widgets should contain all configured widgets that are not currently assigned to areas.

Additionally, while viewing active widgets the options for a widget will be the following: Deactivate | Move and Close (Right justified).

While viewing inactive widgets the options for a widget will be the following: Delete | Move and Close (Right Justified).

Deactivate will remove the a widget from an area. Delete will permanently remove a widget configuration from the database.
Move will inherit the functionality of Reorder > Move.

#10 in reply to: ↑ 9 ; follow-up: @westonruter
8 years ago

Replying to todd-inmotion:

We are doing something very similar for our implementation of WordPress. If nobody has claimed this, we can probably take this ticket and be aligned with the April 4.5 Release. Anyone working on this already?

No work has commenced, no. You are free to pick it up!

Instead of a separate panel/section, I was thinking it might make more sense for the inactive widgets to be made available via the panel that slides out for the user to pick from among the available widgets to add.

#11 in reply to: ↑ 10 ; follow-up: @todd-inmotion
8 years ago

Replying to westonruter:

No work has commenced, no. You are free to pick it up!

Great!

Instead of a separate panel/section, I was thinking it might make more sense for the inactive widgets to be made available via the panel that slides out for the user to pick from among the available widgets to add.

That is preferable UI wise I think too. Then a user just has to go to Add a Widget from the Widget Area regardless of adding a "New Widget" or adding an "Inactive Widget" to the widget area.

UI wise, we chatted here and we are thinking about listing the Inactive Widget directly underneath its base "New Widget" but indented. If the user has filled in the Title of the Inactive Widget, we will replace the normal description with the title they have used. If they do not have a title (very common), we will have a default of some sort.

Two issues we will think more on:

*How to truly delete the Inactive Widget - our other method allows access to the Widget Config to delete it. We would need to add Delete of some sort to the Inactive Widget in the Add Widget list.
*If user has many Inactive Widgets the list will get long - do we try to create some accordion drop down under the New Widget? This could be a non-intuitive change since the current click action is to add the widget to the zone. My thought is we do not take this on - essentially, if we have an easily delete method that will let people clean it up their individual list gets to long for them.

Thoughts?

#12 in reply to: ↑ 11 ; follow-up: @westonruter
8 years ago

  • Keywords ux-feedback added

Replying to todd-inmotion:

UI wise, we chatted here and we are thinking about listing the Inactive Widget directly underneath its base "New Widget" but indented.

I like that.

If the user has filled in the Title of the Inactive Widget, we will replace the normal description with the title they have used. If they do not have a title (very common), we will have a default of some sort.

Not totally sure I understand. Are you referring to how inactive widgets are listed on the widgets admin page?

*How to truly delete the Inactive Widget - our other method allows access to the Widget Config to delete it. We would need to add Delete of some sort to the Inactive Widget in the Add Widget list.

I suggest eliminating the “Close” link that appears next to “Remove” since it is redundant (if useful or accessibility, it can be marked with the appropriate class to make it invisible?). So instead of “Remove | Close” the links for a previously saved widget could be “Remove | Delete”, where “Remove” moves it to the inactive widgets (or this could be “Deactivate” instead). If a widget was just added and is not saved, it would just have the “Delete” link.

*If user has many Inactive Widgets the list will get long - do we try to create some accordion drop down under the New Widget? This could be a non-intuitive change since the current click action is to add the widget to the zone.

Maybe there could be an arrow button that appears next to each available widget that has inactive widgets available. When clicking this arrow, a list of inactive widgets could appear below. Clicking the arrow again could collapse the list of inactive widgets

#13 follow-up: @celloexpressions
8 years ago

I wonder if we should reconsider the term inactive"?

"Remove" make sense from a widget area, whereas "deactivate" doesn't really. But to make that term match the name of the section that the removed widget goes to, maybe we should say "orphaned" or "unplaced" or even just "removed" widgets?

In terms of grouping all of the inactive widgets together vs. putting them under the corresponding new widgets, we should probably user test this as it could potentially get very confusing if we're not careful.

#14 in reply to: ↑ 12 @todd-inmotion
8 years ago

Replying to westonruter:

Replying to todd-inmotion:

If the user has filled in the Title of the Inactive Widget, we will replace the normal description with the title they have used. If they do not have a title (very common), we will have a default of some sort.

Not totally sure I understand. Are you referring to how inactive widgets are listed on the widgets admin page?

I am referring to how the Inactive Widget will look in the Add a Widget slide out menu when nested under the New Menu. For example, the Categories Widget has the text underneath "A list or dropdown of categories". For Inactive but configured, we will need a way to identify it - so maybe replace "A list or dropdown of categories" with "Title: Filled in previously by user". But this can wait till we do the wireframe, not really sure how that will look yet.

*How to truly delete the Inactive Widget - our other method allows access to the Widget Config to delete it. We would need to add Delete of some sort to the Inactive Widget in the Add Widget list.

I suggest eliminating the “Close” link that appears next to “Remove” since it is redundant (if useful or accessibility, it can be marked with the appropriate class to make it invisible?). So instead of “Remove | Close” the links for a previously saved widget could be “Remove | Delete”, where “Remove” moves it to the inactive widgets (or this could be “Deactivate” instead). If a widget was just added and is not saved, it would just have the “Delete” link.

Summary of "How to Truly Delete a Widget" based from thread.
To provide an easy way to delete from both an Active Widget and from the new Inactive Widget placement inside of the "Add a Widget" slide out menu.

For all Active Widgets the action links could become one of the following options:
Remove | Move | Delete
Deactivate | Move | Delete
Move | Delete
Remove | Move

Note that Close does not exist anymore for all options. It is redundant.

Remove/Deactivate places the configured widget into the Add a Widget slide out menu
Move give navigation to move the widget to a new widget area. If menu doesn't have "Remove/Deactivate", then an option will exist to "Save and Remove" with a message it is going to Add a Widget. If menu doesn't have "Delete" then put that under "Move".
Delete actually removes the configuration.

I like "Move | Delete" - your thoughts?

Once the user has placed the Inactive Widget in the Add a Widget slide out menu, we need a way for them to delete this. We will add a Delete link specific to the Inactive Widget, TBD how it looks though.

Maybe there could be an arrow button that appears next to each available widget that has inactive widgets available. When clicking this arrow, a list of inactive widgets could appear below. Clicking the arrow again could collapse the list of inactive widgets

Sounds good, we can do that.

At this point, I will have some mockup/wireframes made, that will make it easier to decide.

#15 in reply to: ↑ 13 @todd-inmotion
8 years ago

Replying to celloexpressions:

I wonder if we should reconsider the term inactive"?

"Remove" make sense from a widget area, whereas "deactivate" doesn't really. But to make that term match the name of the section that the removed widget goes to, maybe we should say "orphaned" or "unplaced" or even just "removed" widgets?

That has been a challenge for us for a while, "inactive but configured" is what we say internally, but yeh, probably move to something that more intuitive would be great. See my "Move | Delete" option for above, how about that?

In terms of grouping all of the inactive widgets together vs. putting them under the corresponding new widgets, we should probably user test this as it could potentially get very confusing if we're not careful.

We do have a Customer Experience group that does usability testing for us. We do it with 5 testers per test. It isn't perfect, but it does catch any really serious issues. I don't know if it would tell us which one is really "better" but it would tell us if either method is preventing people from saving then recovering configured widgets and if we created a barrier/problem.

#16 follow-up: @Joel MMCC
8 years ago

I think we should reconsider whether the Customizer should even have the ability to outright delete a Widget (or anything else for that matter, with the possible exception of simple Menu items [and that only because there’s currently no equivalent to a Menu Trash / Inactive Menu Items]) at all.

The Customizer’s purpose, as I see it, is to affect the appearance of the site without altering its content. Allowing it to delete things trespasses on content (or at least structure) management territory instead of appearance / theming territory.

We wouldn’t want the ability to delete Pages or Posts or Media Items or Users from within the Customizer, would we? WP goes out of its way to make at least Pages and Posts somewhat difficult to completely delete permanently. You first have to move it to the Trash, then delete it from the Trash, and there’s a confirmation prompt.

Now, granted, most Widgets are pretty simple. Type in a Title, set some simple parameters such as numeric entries, checkboxes, radio buttons, etc. (usually only a very few for any given Widget), but then there’s the Text Widget which can have custom text or HTML or even script. Imagine how frustrating it could be to delete an important one of those by accident while merely trying to tweak the appearance of the site.

The Inactive Widgets area exists for just this purpose: to allow a Widget to be removed from view without deleting it. I think that fully deleting a Widget should only be doable from the legacy Appearance ⇒ Widgets area, not from within Customizer.

#17 in reply to: ↑ 16 @westonruter
8 years ago

Replying to Joel MMCC:

The Customizer’s purpose, as I see it, is to affect the appearance of the site without altering its content. Allowing it to delete things trespasses on content (or at least structure) management territory instead of appearance / theming territory.

The Customizer's purpose is to live preview any change to a site, I maintain. This could be appearance or content. Widgets and nav menus are both content. #34923 is about a first step to create pages in the Customizer.

We wouldn’t want the ability to delete Pages or Posts or Media Items or Users from within the Customizer, would we? WP goes out of its way to make at least Pages and Posts somewhat difficult to completely delete permanently. You first have to move it to the Trash, then delete it from the Trash, and there’s a confirmation prompt.

Yeah, that makes sense. A trashing safeguard when deleting things in the Customizer makes sense. This is what we have in place right now, where “Remove” is acting like trashing. So perhaps this should stay as is, but then there could be a “Delete Inactive Widgets” button that appears when listing out the inactive widgets, or a red X that appears with each inactive widget listed, or something to that effect.

#18 @todd-inmotion
8 years ago

Yes on using a more proper Trash flow, my mistake on listing the Delete as a direct action option! Joel, thanks for the polite reminder to an obvious miss.

Philosophically, I think we have to provide the same functionality in the Customizer Widget management as in the legacy Widget management.

How about
Move | Trash (or Remove)

Move is a mirror of what happens with Move today but we would add something like "Save to Add a Widget"
http://toddrobinson.us/wp-content/uploads/2016/01/customizer-move-menu.jpg

Trash would have a similar menu but options would be "Save to Add a Widget" and "Delete Permanently"

An action to "Delete Permanently" inactive configured widgets from the Add a Widget menu will be handled as well.

How about that?

#19 @westonruter
8 years ago

“Save for later” seems like it could be a nice way to phrase “Move to inactive sidebar”

#20 @todd-inmotion
8 years ago

We have enough at this point to get going, so we will put together a few wireframes. I will post those back here for comment by next week.

The developers that are going to work this are following the coding style in the pertinent files, but is there any specific documentation/guide we should be looking at for this section of the code base?

#21 follow-ups: @todd-inmotion
8 years ago

Hopefully we have captured what is needed in the below shots.

The options for all widgets will be changed to Move | Remove
http://toddrobinson.us/wp-content/uploads/2016/02/move-remove-on-widget-control.png

Clicking Move will open the reorder menu which will have a new option that is always visible, named “Save for Later”

http://toddrobinson.us/wp-content/uploads/2016/02/save-for-later.png

Clicking Remove will do the same thing as "Save for Later"

Additions to the “Add a Widget” panel

When a widget type has widgets configured but unassigned to a widget area, those widgets will be displayed with a drop down arrow to the right of the widget type under "Add a Widget":

http://toddrobinson.us/wp-content/uploads/2016/02/add-a-widget-with-menu-expanded.png

Clicking on a widget type will automatically add an unconfigured widget to the widget area as it does today. Clicking on the arrow will drop down and display unassigned configured widgets.

Upon hovering over an unassigned configured widget, a link to either add the widget or delete the widget will appear.

Delete will permanently remove your widget. Add, will move the widget to your current widget area.

Heres a view of of the add a widget collapsed. Notice the drop down arrows.

http://toddrobinson.us/wp-content/uploads/2016/02/add-a-widget-with-accordion-collapsed.png

Thoughts/feedback? Hopefully if we can get any tweaks or changes to this in the next week and then we can get moving on it.

#22 in reply to: ↑ 21 ; follow-up: @Kelderic
8 years ago

Replying to todd-inmotion:

Clicking Remove will do the same thing as "Save for Later"

Two things here. It feels a bit repetitive to me, because we have two ways of doing the same thing, which are named differently.

Second, I think we are mixing actions with choices.

Move (action) -> place (choice)
Remove (action)
Move (action) -> save for later (action)

I don't think we really need to have Save for Later under Move. If anything, maybe place it as a sub choice for Remove, along with an additional option of Delete Permanently.

Move (action) -> place (choice)
Remove (action) -> Save for Later or Delete Permanently (choices)


That would function as a confirmation of deletion, which was requested earlier, and at the same time give people a quick way to do either.

#23 in reply to: ↑ 22 @todd-inmotion
8 years ago

Replying to Kelderic:

I don't think we really need to have Save for Later under Move. If anything, maybe place it as a sub choice for Remove, along with an additional option of Delete Permanently.

Move (action) -> place (choice)
Remove (action) -> Save for Later or Delete Permanently (choices)

Sounds good to me. I'll wait a few days for other comments, but will head that way if no disagreement.

#24 in reply to: ↑ 21 @westonruter
8 years ago

Replying to todd-inmotion:

Additions to the “Add a Widget” panel

I like the mock of the changes to the panel.

#25 follow-up: @michaelarestad
8 years ago

I would steer away from the dropdown mockup. They seem too hidden there and a tad complex. Why not just have an inactive widgets section someone could move widgets to and from? (yes, I know "inactive" isn't entirely accurate, but it works well in this situation)

There are already methods in place to move widgets from section to section (though a tad hidden). We would just have to work on exposing those in a friendlier fashion.

Another idea similar to @todd-inmotion's:

  • User clicks +Add a widget
  • inactive widgets show up first in the list with the option to delete them right there (to get them out of the way if they accumulate). They could also show up last.

#26 in reply to: ↑ 25 @melchoyce
8 years ago

Replying to michaelarestad:

I would steer away from the dropdown mockup. They seem too hidden there and a tad complex. Why not just have an inactive widgets section someone could move widgets to and from? (yes, I know "inactive" isn't entirely accurate, but it works well in this situation)

There are already methods in place to move widgets from section to section (though a tad hidden). We would just have to work on exposing those in a friendlier fashion.

Another idea similar to @todd-inmotion's:

  • User clicks +Add a widget
  • inactive widgets show up first in the list with the option to delete them right there (to get them out of the way if they accumulate). They could also show up last.

+1

This ticket was mentioned in Slack in #core by chriscct7. View the logs.


8 years ago

#28 @chriscct7
8 years ago

  • Milestone changed from 4.5 to Future Release
  • Status changed from new to assigned

#29 in reply to: ↑ 27 @todd-inmotion
8 years ago

Replying to slackbot:

This ticket was mentioned in Slack in #core by chriscct7. View the logs.

Hey guys, sorry, we do have a patch prepared, but we were waiting for feedback on the UI so we can adjust code accordingly.

We will put the current patch up tomorrow, but with the caveat that is just the "in progress" code. Works, but is aiming at the UI in the examples above.

@westonruter - is that what you would need to see to feel comfortable keeping this in 4.5?

@chriscct7 - if we are missing some steps or timelines, please advise, getting used to the process here.

Last edited 8 years ago by todd-inmotion (previous) (diff)

#30 follow-up: @westonruter
8 years ago

@todd-inmotion it's too close to beta1 (next week) to be included in 4.5, I believe.

#31 in reply to: ↑ 30 @todd-inmotion
8 years ago

Replying to westonruter:

@todd-inmotion it's too close to beta1 (next week) to be included in 4.5, I believe.

Ah, shoot, ok. Well, we will put the patch up anyway, if you can give feedback on it that will help make sure we are conforming to standards, etc.

Timing, I get it, I can see there will be some more discussion on the UI itself regardless of code.

@todd-inmotion
8 years ago

27404 Patch - not final, progress example, UI not frozen

#32 follow-up: @todd-inmotion
8 years ago

@westonruter - Just wanted to be sure you saw the patch. Let me know if you need anything else or if you want a login to one of our WP installs to see it in place.

#33 in reply to: ↑ 32 ; follow-up: @westonruter
8 years ago

Replying to todd-inmotion:

@westonruter - Just wanted to be sure you saw the patch. Let me know if you need anything else or if you want a login to one of our WP installs to see it in place.

FYI: the minified files should not be modified. These will be automatically generated during the build step. In other words, write the patch against the _develop_ (src) repo at develop.svn.wordpress.org as opposed to the _build_ at core.svn.wordpress.org; see https://make.wordpress.org/core/2013/08/06/a-new-frontier-for-core-development/ for more info.

In terms of Customizer architecture, I wonder if instead of introducing a new setting widgets_deleted, whether it would be better to instead just rely on the existing widget_{id_base}[{number}] settings, but to treat any that have values of false as an indication that they should be deleted. This is in fact how nav menu items deletions are handled. For reference, see:

PHP: https://core.trac.wordpress.org/browser/tags/4.4.2/src/wp-includes/customize/class-wp-customize-nav-menu-item-setting.php?marks=682,689-703#L675
JS: https://core.trac.wordpress.org/browser/tags/4.4.2/src/wp-admin/js/customize-nav-menus.js?marks=1194-1228#L1194

#34 in reply to: ↑ 33 @rramo012
8 years ago

Thanks for reviewing our submission. I'm the InMotion Hosting dev handling this ticket.

Replying to westonruter:

FYI: the minified files should not be modified.

We submitted the build results of the develop.svn.wordpress.org repo. We'll create a patch with only the modified files.

In terms of Customizer architecture, I wonder if instead of introducing a new setting widgets_deleted, whether it would be better to instead just rely on the existing widget_{id_base}[{number}] settings.

That was my initial approach. The reasoning behind going with a new customizer setting was that setting the widget instance to false was causing failures in sanitation (WP_Customize_Widgets->sanitize_widget_instance()). I didn't want to unintentionally make the existing sanitation for widget instances vulnerable. Instead I treated it similarly to a sidebars and used its sanitation. Additionally I feel the intention is more clear when a widget is added to a deletion array.

Last edited 8 years ago by rramo012 (previous) (diff)

#35 @westonruter
8 years ago

I think it would be better to make sanitize_widget_instance() aware of widget settings being received as false to indicate deletion rather than to create a new setting like widgets_deleted.

#36 @rramo012
8 years ago

Sounds good, I'll make those changes and post another patch soon.

@rramo012
8 years ago

27404 Patch

#37 @westonruter
8 years ago

  • Milestone changed from Future Release to 4.6

#38 @rramo012
8 years ago

  • Keywords has-patch added; needs-patch removed

Updated the patch to reflect the latest revision.

Last edited 8 years ago by rramo012 (previous) (diff)

This ticket was mentioned in Slack in #core by chriscct7. View the logs.


8 years ago

#40 @ocean90
8 years ago

  • Keywords needs-refresh added

@westonruter, @celloexpressions What's the status of this ticket?

The latest patch needs a refresh because it doesn't apply cleanly anymore. The ticket is labeled with "ux-feedback" which I agree with. Can we get at least one or two user tests here?

#41 @chriscct7
8 years ago

  • Owner set to westonruter

#42 @rramo012
8 years ago

  • Keywords needs-refresh removed

@westonruter Fixed patch to reflect the latest revision

#43 @ocean90
8 years ago

  • Milestone changed from 4.6 to Future Release

Punting due to lack of activity/feedback.

#44 @lukecavanagh
8 years ago

In real-world use are more users still using Appearance > Widgets > Inactive Widgets over the Customizer?

This ticket was mentioned in Slack in #core-customize by westonruter. View the logs.


7 years ago

#46 @westonruter
7 years ago

  • Milestone changed from Future Release to 4.8
  • Owner westonruter deleted

Re-assigning to 4.8 to be worked on in conjunction with #39693.

Last edited 7 years ago by westonruter (previous) (diff)

#47 @westonruter
7 years ago

  • Description modified (diff)

#48 @westonruter
7 years ago

  • Keywords needs-refresh added
  • Owner set to westonruter
  • Status changed from assigned to accepted

Probably needs refresh. I'll take a look.

@rramo012
7 years ago

Refresh

#49 @westonruter
7 years ago

  • Keywords needs-refresh removed

#50 @celloexpressions
7 years ago

  • Keywords needs-screenshots added

Can we get screenshots of the latest patch for the design team to review? Would be good to take a look through those and discuss in the next design meeting cc @karmatosed.

Quickly re-reading the ticket, I like the direction this is heading in and think this would be a good quick win, that could potentially even be 4.7.x material depending on the defined scope of those continued point releases. This has long been a functionality gap between the admin and customizer and it would be great to finally close it.

@rramo012
7 years ago

#51 @rramo012
7 years ago

  • Keywords has-screenshots added; needs-screenshots removed

#52 @westonruter
7 years ago

I'm going to suggest that widgets most commonly get moved to inactive widget area as the result of a theme switch (#39693). It would be very useful if widgets that were made inactive as part of a theme switch could be grouped in a way to easily batch-add them to a sidebar in the new theme. By grouping them I don't mean widget persistent groups (#19912), but rather transient groupings that essentially are pulling the grouping of widgets from another theme's widget-sidebar assignments. Being able to easily and intuitively re-assign widgets from the previous theme's sidebars to the new theme's sidebars, maintaining their ordering, would be a huge.

If the old theme has 3 sidebars whereas the new theme as 2 sidebars, note that this could mean that 2 groupings of inactive widgets could be added to one sidebar on the new theme. Two additional questions then come to mind: should the best-guess re-assignment of widgets from the old sidebar's theme to a sidebar in the new theme be eliminated unless the sidebar IDs are exact matches (e.g. sidebar-1)? If not, then it is likely that a re-assignment of widgets in the new theme will be wrong and need to be re-assigned. In that case, there should have to be a way to bulk move all widgets from one sidebar to another.

It may be that this theme-switch grouping is out of scope for this ticket and should instead be addressed as part of #39693.

/cc @melchoyce

#53 @mrjarbenne
7 years ago

I would worry that for each time that the inactive widget group can be quickly re-located to the new sidebar location, there are probably an equal number of times when the grouping that worked on one theme needs to be redistributed in a different fashion in a different theme. For example, a stack of four widgets may look great in the sidebar of theme A, but on theme B, where there is no sidebar, and 3 footer spaces, that single stack will need to be re-distributed.

I like the way in which the patch organizes those pre-configured widgets under the type of widget they are, which is an improvement over the "inactive widget" bucket that currently exists under Appearance/Widgets.

#54 @celloexpressions
7 years ago

What happened to 26? Those seem like better approaches if the widgets are going to be individual (showing them as separate instances or in a separate section, rather than a dropdown).

If we do any grouping, I would definitely push for actual widget groups, whether there's a comprehensive UI for it or entire groups can be moved/merged into a current theme's sidebar at once. Any other grouping approach could add complexity without improving usability and flexibility in the way that menus-style grouping can.

@folletto
7 years ago

Customizer widgets "Presets" area i2

#55 follow-up: @folletto
7 years ago

Sorry, I posted the mock on #39693, I wasn't aware of a more specific issue here.

The mockup above does a simple implementation of the suggestion above:

It would be very useful if widgets that were made inactive as part of a theme switch could be grouped in a way to easily batch-add them to a sidebar in the new theme.

From the other ticket: the goal here is exclusively to provide access to widgets that were dropped during a theme switch (or any other reason) with the additional restriction of having minimal impact.
Features of the "Presets" i2 concept:

  1. Inactive widgets have a special separated area in the "Add a widget" panel.
  2. They are searchable as the other widgets, content included if possible
  3. They can be removed, and the removal has an extra trick here: one can position the mouse in the top-right X and keep clicking, removing all the inactive widgets easily in sequence (we probably need a form of undo for the ideal experience).
  4. The second line of the widget instead of showing the details shows when they were removed, thus giving a simple indication of how old a widget is.
  5. I avoided subtitle labels for the sections, but we can introduce them if we want. The current state might still work well enough.

That's all. It's an approach "low key" enough to be effective, but at the same time very visible as it's inside the main "Add" flow: a user that "lost" a widget will get there, even just because they have to re-add them.

Given the idea of groups as well, the mockup above is able to scale later to be grouped as needed, and folded, and so on.

#56 @melchoyce
7 years ago

I think we should build @folletto's solution and try it out.

#57 @westonruter
7 years ago

In #39910 it is proposed that available widgets should be able to be dragged over into the sidebar instead of always only appending the widget to the end of the sidebar. If this is 👍🏻 then it would make a lot of sense for restoring inactive widgets to a sidebar: they should also be draggable.

If so, should that be part of implementing @folletto's design? I suppose it wouldn't have much real design impacts other than being able to drag an inactive widget in addition to being able to click on one.

#58 in reply to: ↑ 55 @westonruter
7 years ago

Replying to folletto:

The second line of the widget instead of showing the details shows when they were removed, thus giving a simple indication of how old a widget is.

The “used until” is not really something we'd have data for. When a widget is moved to the Inactive Sidebar there is no good way to store the date for when it was removed (this would change with #35669). In the case of previewing a theme switch, it may be possible to obtain the name of the sidebar that the widget was previously assigned to and that may be useful to display in this space.

Another question: Maybe I use widgets more than most, but I often find I have at least dozen inactive widgets on sites. If these always appear above the list of available widgets to add from scratch, would it not be somewhat overbearing to see them all listed out? Should they perhaps be collapsed into an expandable section, that once expands reveals all of the inactive widgets? When collapsed it could indicate a count of the number of inactive widgets you have. I suppose this is similar to what @rramo012 developed, but all of the inactive widgets would be grouped together instead of appearing under their respective widget types.

#59 @karmatosed
7 years ago

@folletto I'm wondering if the inactive widgets could somehow be styled to indicate that. It may be something that needs testing to see. Visually the only hitch I am getting is 'why are these split out'. Maybe that's ok as the user doesn't need to know the reason just that they are different?

#60 @celloexpressions
7 years ago

The visual separation makes sense but should probably go further to feel more intentional - these are actual widgets with data, not available widget types that can be instantiated. Maybe even matching the style of widgets in a sidebar, as the admin screen does?

I've always envisioned an inactive widgets section at the bottom of the available items panel that accordion-expands; that may not easily integrate with the search, though. There is a nice simplicity about including them with new widgets.

I'd also keep #39910 separate from this - no need to tie that into this even though it's related.

#61 follow-up: @folletto
7 years ago

The “used until” is not really something we'd have data for.

Ach. Ok until we have the data, we can show a different message then: "Previously used $type widget" (i.e. "Previously used Text widget") maybe?

The visual separation makes sense but should probably go further to feel more intentional - these are actual widgets with data, not available widget types that can be instantiated.

I agree here. I wanted to attempt a first "minimal" try just using the separator and the second descriptive one explaining what that is.
I think that we can test that... and if it works, we have a good simple win. If it's not it's fairly easy to add headers or similar solutions from that design. :)

#62 in reply to: ↑ 61 @melchoyce
7 years ago

Replying to folletto:

I think that we can test that... and if it works, we have a good simple win. If it's not it's fairly easy to add headers or similar solutions from that design. :)

Agreed. I think we should try this out. If it's bad, we'll make some adjustments, or scrap it and rethink.

#63 @westonruter
7 years ago

@melchoyce How should we handle the case where there are many widgets (dozens) in the inactive widgets area. Taking the widgets admin screen as an example, the list of available widgets to add appears below the list of available widgets: widgets-admin-screen-available-widgets-followed-by-inactive-widgets.png

Given that, should the list of inactive widgets not also appear below the list of available widgets to add? We talked about there being a collapsable accordion, but this seems it would only be necessary if the inactive widgets are shown at the top. If they are shown at the bottom, then we could just list them all out separately like on the widgets admin screen, and it would be seem to make more sense when typing in the search box when filtering down the list of widgets. If I type "Text" it could show the available Text widget to add at the top, followed by all inactive Text widgets below and also any inactive widgets that have “Text” in their title.

Also, as of #19159, there is “Clear Inactive Widgets” button added specifically for the use case of there being a lot of widgets in the inactive widgets area. Should there similarly be a clear-all button in the context of the customizer for parity with the admin screen?

#64 @westonruter
7 years ago

  • Owner changed from westonruter to melchoyce
  • Status changed from accepted to assigned

#65 follow-up: @melchoyce
7 years ago

Riffing off of @folletto's last mockup, I've tried out two different approaches:

customizer-widget-presets-i3_inactive-at-top.png wraps the inactive widgets in an accordion at the top of the screen. I think this is a little more discoverable than putting them at the bottom. If you only have a couple inactive widgets (say, less than five), the accordion can be open by default. If you have more than five, we can collapse it by default. Search looks through both inactive and regular widgets.

customizer-widget-presets-i3_widgets-in-accordion.png wraps both the inactive widgets, and the regular widgets in an accordion. This puts the search specifically into the widget accordion. If you have a bunch of inactive widgets (say, more than ten), we could consider adding a search box specifically for that accordion as well.

This version also explores what it could look like if we wanted to allow people to move currently active widgets into inactive. To manually move them into inactive, we could add it to the bottom of the move-to list in Reorder, maybe italicized or some to separate it from the widget areas.

That said, I'm not sure we should add the extra complication of letter people move from active to inactive.

#67 @westonruter
7 years ago

customizer-widget-presets-i3_inactive-at-top.png wraps the inactive widgets in an accordion at the top of the screen. I think this is a little more discoverable than putting them at the bottom. If you only have a couple inactive widgets (say, less than five), the accordion can be open by default. If you have more than five, we can collapse it by default. Search looks through both inactive and regular widgets.

I think I like this more than the second one. I think there should be only one search box, and that should include both inactive and available widgets.

I do still think that inactive widgets widgets should be positioned below the available widgets, however. I believe the vast majority of the time users are going to be going there to add a new available widget rather than add an inactive widget, so I worry about the inactive widgets being constantly up there in the way (especially if not in an accordion). There is also the parity with the widgets admin screen, where the inactive widgets appear below the available wigets. On the other hand, when previewing a theme switch I think in this case users would likely most often need to be re-positioning the newly-inactive widgets as opposed to adding new widgets, and in that case it would make more sense for inactive wigets to appear at the top for easy visibility and access. But, I'm doubtful that having the inconsistent top/bottom positioning would be a good design choice either,

#68 in reply to: ↑ 65 ; follow-up: @westonruter
7 years ago

Replying to melchoyce:

This version also explores what it could look like if we wanted to allow people to move currently active widgets into inactive. To manually move them into inactive, we could add it to the bottom of the move-to list in Reorder, maybe italicized or some to separate it from the widget areas.

That said, I'm not sure we should add the extra complication of letter people move from active to inactive.

In addition to the ability to drag a widget to Inactive Widgets and also moving via the Reorder UI, another option would be to eliminate the redundant “Close” link in a widget and replace it with a “Deactivate” link. The “Remove” link can be returned to always be “Delete” instead of switching from “Delete” to “Remove” upon initial save, whereby “Remove” currently places it among the inactive widgets in core. As it was reported as a bug multiple times, it clearly isn't as intuitive as initially thought (see #27575, #39426). So it could look like this:


#69 in reply to: ↑ 68 @karmatosed
7 years ago

In addition to the ability to drag a widget to Inactive Widgets and also moving via the Reorder UI, another option would be to eliminate the redundant “Close” link in a widget and replace it with a “Deactivate” link. The “Remove” link can be returned to always be “Delete” instead of switching from “Delete” to “Remove” upon initial save, whereby “Remove” currently places it among the inactive widgets in core. As it was reported as a bug multiple times, it clearly isn't as intuitive as initially thought (see #27575, #39426). So it could look like this:

I have my concerns with the language 'deactivate' for all types of users. This may just be a case of iterating meaning though.

customizer-widget-presets-i3_widgets-in-accordion.png gets my vote although I am also not sure about letting people move from active to inactive. I also think we need to observe users on this.

#70 follow-up: @celloexpressions
7 years ago

For me, this is starting to drift to where the benefits of the current menus model suggest that we should really create widget groups in a way that aligns with menu locations and uses a proper post object structure for data storage. In that model, groups of widgets can be active or inactive depending on what area(s) they're shown in, and deleting them actually removes them instead of having a random pile of "inactive" widgets floating around.

I'm interested to see how the accordion approach tests, though. That would be my second choice on approach to try here. I will point out that the delete icon styling should match the menu item bulk-delete mode (larger, centered, and red).

#71 follow-up: @melchoyce
7 years ago

I've made some adjustments in customizer-widget-presets-i3_combined.png based on feedback:

  1. Went with the accordion version as a base.
  2. Moved the search back to the top of the accordions, rather than inside.
  3. Moved inactive widgets to the bottom of the list.
  4. Removed the ability to move an active widget into the inactive accordion. Let's explore this in the future, but leave it out of this version for simplicity's sake.

I'm a little worried about the discoverability of having inactive widgets at the bottom of the list. Most people won't have a monitor tall enough to display all of the widgets, so inactive will be totally hidden for them. They likely won't know the inactive widgets are there, which is frustrating if you switch a theme, your widgets are gone, and then they're not in plain site when you go to your widgets panel. I think we should put the accordion at the top, and close it automatically if you have more than five inactive widgets.

#72 in reply to: ↑ 70 ; follow-up: @melchoyce
7 years ago

Replying to celloexpressions:

I will point out that the delete icon styling should match the menu item bulk-delete mode (larger, centered, and red).

Where in the Customizer can I find this?

#73 follow-up: @folletto
7 years ago

i3

Looks good. I think these changes makes it very solid. Search is really good too! :)
I agree on all the decision taken, and the doubt raised.

Three minor ideas to evaluate:

  1. Can we keep the same styling for the Inactive Widgets (title + line)? In a sense these widgets "hold" more content than the default ones, so I feel it makes sense to use at least the same height, and we can make use of the second line either by Showing the excerpt, some details, the widget type (moved from the title line), or else.
  2. Keep the "×" to delete inactive widgets on search too maybe?
  3. I keep wondering if "Inactive" is the right word. I know it's an habit by now, and as such we could just keep it. But "Inactive" isn't hinting to the fact they were my old widgets already, so maybe we could go for something alternative that communicates them better, like "Pre-filled Widgets"?

To be clear, these are minor things for evaluation: I think i3 is totally shippable without these three.

I'm a little worried about the discoverability
I think we should put the accordion at the top, and close it automatically if you have more than five inactive widgets.

Yep: moving "inactive" at the bottom has that major issue. I'll decompose further:

  1. We could use tabs/pills at the top instead of an accordion to switch between the two columns. That could be very effective, the only challenge there is to find the right wording
  2. If we keep the accordion, 100% should be at the top, and I agree to fold it when there are more than 5. As an addition: we should show on the closed accordion a counter that shows how many items are inside.

I hope it helps. :)

#74 in reply to: ↑ 73 @melchoyce
7 years ago

Replying to folletto:

  1. Can we keep the same styling for the Inactive Widgets (title + line)? In a sense these widgets "hold" more content than the default ones, so I feel it makes sense to use at least the same height, and we can make use of the second line either by Showing the excerpt, some details, the widget type (moved from the title line), or else.

We can explore this, for sure. Can you elaborate more on why you think they should be taller?

  1. Keep the "×" to delete inactive widgets on search too maybe?

👍

  1. I keep wondering if "Inactive" is the right word. I know it's an habit by now, and as such we could just keep it. But "Inactive" isn't hinting to the fact they were my old widgets already, so maybe we could go for something alternative that communicates them better, like "Pre-filled Widgets"?

I agree "Inactive" isn't the right word. "Pre-filled," to me sounds like someone else has filled them for me, rather than widgets I was previously using. We can definitely explore this further, maybe as a cross-customizer-wpadmin ticket after getting this into trunk, but before shipping in a release. @michelleweber might have some ideas around copy.

  1. We could use tabs/pills at the top instead of an accordion to switch between the two columns. That could be very effective, the only challenge there is to find the right wording

I like this idea, but I don't want to introduce new design patterns to the Customizer at this time, so I think I'll stick with an accordion.

  1. If we keep the accordion, 100% should be at the top, and I agree to fold it when there are more than 5. As an addition: we should show on the closed accordion a counter that shows how many items are inside.

Good idea, I'll add a counter to inactive widgets.

I hope it helps. :)

Thanks!

#75 @folletto
7 years ago

Can you elaborate more on why you think they should be taller?

I think I can't see any reason to show up differently if they are the same widgets.

I've a secondary reason but it's a bit convoluted, and might be just my mental model: an "Inactive" widget it like a normal one that has something more (content). So at the very least should show more details, not less. :)

Regarding everything else, acknowledged and looks good. :)

#76 in reply to: ↑ 71 ; follow-up: @westonruter
7 years ago

Replying to melchoyce:

I'm a little worried about the discoverability of having inactive widgets at the bottom of the list. Most people won't have a monitor tall enough to display all of the widgets, so inactive will be totally hidden for them. They likely won't know the inactive widgets are there, which is frustrating if you switch a theme, your widgets are gone, and then they're not in plain site when you go to your widgets panel. I think we should put the accordion at the top, and close it automatically if you have more than five inactive widgets.

What about making it so that the available widgets list container has a max-height of 100% minus the height of the Inactive Widgets accordion label? The list of available widgets can then scroll with the Inactive Widgets accordion label always visible below the scrolling list? This is somewhat similar to how the accordions in the available nav menu items panel are done, except there each post type has a fixed height and isn't stretched to full the available vertical space.

#77 in reply to: ↑ 76 @melchoyce
7 years ago

Replying to westonruter:

What about making it so that the available widgets list container has a max-height of 100% minus the height of the Inactive Widgets accordion label? The list of available widgets can then scroll with the Inactive Widgets accordion label always visible below the scrolling list? This is somewhat similar to how the accordions in the available nav menu items panel are done, except there each post type has a fixed height and isn't stretched to full the available vertical space.

Rather than hacking on heights, I'd rather just show the accordion at the top. Seems simpler, cleaner, and less prone to breaking on smaller screens.

I'll post an updated mockup soon.

#78 @melchoyce
7 years ago

customizer-widget-presets-i3_topv2.png is an updated revision that puts the inactive widgets back at the top, and adds "x" buttons to inactive widgets in search.

I opted to not make any changes to the inactive widget cards themselves for now. They can grow in height depending on the length of the widget title, but I don't think we should otherwise artificially constrain or inflate the size of the cards. They're currently similar in size to the active widget cards and show about the same amount of information (more, since they also include an icon! Maybe we should do this for all active widgets, too). Since every widget is different, we should consider exploring unique card designs in a future iteration that showcase more information.

This ticket was mentioned in Slack in #core by jeffpaul. View the logs.


7 years ago

#80 @jbpaul17
7 years ago

  • Milestone changed from 4.8 to 4.8.1

Punting to 4.8.1 per bug scrub earlier this week.

#81 in reply to: ↑ 72 @celloexpressions
7 years ago

  • Keywords needs-patch added; ux-feedback has-patch removed

I'd suggest re-using the hacks in the available menu items panel to do accordions there. Each accordion has its own scrolling region when expanded, and the heights are set so that all of the accordion section headings are always visible. There's additional logic there to break out to a secondary scroll region if there are too many menu item type headings (since custom post types and taxonomies can also show up there).

It sounds like this design is mostly worked out here, but we need a new patch.

Replying to melchoyce:

Replying to celloexpressions:

I will point out that the delete icon styling should match the menu item bulk-delete mode (larger, centered, and red).

Where in the Customizer can I find this?

If there are items in a menu and you click on the add items button, the bulk delete mode is also exposed for items in the menu, with a red X on the right of each item. I wouldn't go any smaller than that for touch accessibility, but that can always be redesigned along with something else happening here as long as it's kept consistent.

This ticket was mentioned in Slack in #core-customize by westonruter. View the logs.


7 years ago

#83 @westonruter
7 years ago

  • Milestone changed from 4.8.1 to 4.9

This ticket was mentioned in Slack in #core by jeffpaul. View the logs.


7 years ago

#85 @melchoyce
7 years ago

  • Keywords ui-feedback added

This ticket was mentioned in Slack in #core by jeffpaul. View the logs.


7 years ago

This ticket was mentioned in Slack in #design by karmatosed. View the logs.


7 years ago

#88 @westonruter
6 years ago

  • Milestone changed from 4.9 to Future Release

This ticket was mentioned in Slack in #design by melchoyce. View the logs.


6 years ago

This ticket was mentioned in Slack in #design by karmatosed. View the logs.


5 years ago

#91 @melchoyce
5 years ago

  • Keywords has-ui-feedback added; ui-feedback removed
Note: See TracTickets for help on using tickets.