WordPress.org

Make WordPress Core

Opened 6 years ago

Closed 8 days ago

#19912 closed feature request (maybelater)

Add Widget Groups and Locations

Reported by: koopersmith Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.3.1
Component: Widgets Keywords: dev-feedback needs-patch ux-feedback
Focuses: ui Cc:

Description

Currently, if a widget cannot be properly matched to a sidebar when switching themes, it is moved to the "Inactive widgets" section (debated for quite a while here: #17979).

With the addition of the planned appearance improvements, it would be nice if we could let the user manipulate widgets as a group. Instead of trying to be too clever, we can let the user review where the widgets are positioned in their theme.

Conceptually, this is very similar to how nav menu locations currently operate. Menu items are grouped in menus (created by the user), which can be assigned to menu locations (created by the theme). Likewise, widgets would be organized into groups (created by the user), and could be assigned to widget locations (created by the theme). Currently, "widget areas" are on double-duty — they act as both "widget groups" and "widget locations".

I think the first step is to add the concept of "widget groups" into the current API and turn the existing "widget areas" into locations mapped to these groups.

If we're looking to compartmentalize the patches, these initial changes could initially be added without modifying the widgets UI. Instead, we could temporarily link a widget group to a widget area behind the scenes. That said, the benefits could only be fully realized with a few tweaks to the widgets UI.

Change History (29)

#2 @scribu
6 years ago

  • Cc scribu added

#3 @sabreuse
6 years ago

  • Cc sabreuse@… added

#4 @rfair404
6 years ago

  • Cc rfair404 added

#5 follow-up: @Nobble
6 years ago

This would be great! Defining locations makes more sense as a theme developer as it could open up easier ways of managing widgets:

  • create different widget groups for a location based on the page (for example a blog post could have a different widgets in the sidebar compared to a regular page).
  • a better visual ui for widgets. Right now the widget admin screen lists areas vertically and if a theme has a lot of areas it becomes hard to manage. It's also less intuitive than seeing the page visually represented in sections that reflect the actual page layout. If locations can be defined the visual ui for widget management could be improved at some point to.

#6 in reply to: ↑ 5 @azaozz
6 years ago

There are some very big differences between the menus and widgets config screens. The biggest one is that menus are configured one by one and widgets are configured all at the same time. Another big difference (UI vise) is that menus can be added from only 3 places that take up a small portion of the screen, however there are usually 30-40 "available widgets" that take up most of the screen.

The general UX concept is quite different too: menus are treated as the separate entities versus sidebars are treated as containers where the entities (widgets) are "stored". Imagine the menus screen having 4-5 menus displayed at the same time and being able to drag and drop submenus between them.

Imho adding even more components to the already busy widgets config screen would make it a lot harder to use. It is a nice idea to keep widgets grouped somehow but the UI/UX challenges in displaying and working with these groups would make that a step backwards. It seems the only way this could be implemented would be to mimic the way menus screen works at the moment, i.e. multi-step. However that would revert the widgets screen workflow to pre-2.7 state (remember how each sidebar had to be selected from a drop-down at the top-right and how many users didn't even know their theme had several sidebars?).

In any case having "widgets groups" in addition to having sidebars (that are also widgets groups) makes sense only when switching themes. Thinking that instead of making the widgets screen and the process of setting widgets more complicated, all of the concerns in this ticket can be resolved by displaying a preview of the front-end while setting the widgets (hopefully in 3.5). Then we can afford to "guess" the position of visible widgets when switching themes and the user will be able to correct the positions of any widgets we didn't guess right.

Replying to Nobble:

  • a better visual ui for widgets. Right now the widget admin screen lists areas vertically and if a theme has a lot of areas it becomes hard to manage. It's also less intuitive than seeing the page visually represented in sections that reflect the actual page layout. If locations can be defined the visual ui for widget management could be improved at some point to.

Currently the widgets config screen is roughly separated into two columns: unused widgets on the left and widgets that are in use on the right. Loosing that logical separation would make the UI a lot messier and harder to use.

#7 @markoheijnen
6 years ago

  • Cc marko@… added

#8 @Nobble
6 years ago

@azaozz replied:
"Currently the widgets config screen is roughly separated into two columns: unused widgets on the left and widgets that are in use on the right. Loosing that logical separation would make the UI a lot messier and harder to use."

I think the issues with more complex sites is that the UI is hard to use and messy already:

  • unused/available widgets take up almost all of the real estate of the screen which makes the workspace very small. If a theme and/or plugins add a lot of widgets to select from, it just gets worse.
  • the vertical listing of expandable widget areas doesn't visually correlate with the layout of a page, the only thing you can rely on is the description.
  • it's hard to move around individual widgets between widget areas with a limited screen height
  • While reverting to a pre 2.7 type of scenario is not the answer, setting up widgets is by default multi-step, since most widgets require some kind of custom configuration (even if it is just setting the title). Right now you have to click to expand a widget area just to see what widgets are in it. Multi-step itself is not the problem, it just needs to be something that is intuitive and easy to use. Clearly the pre 2.7 situation was not, but that doesn't preclude a better solution from being developed.

If locations can be defined for widget areas it can help developers find a better way to manage widgets. Right now many theme companies have created different solutions that use a custom drag and drop widget ui and none of them are really ideal. I have yet to see a solution that is congruent with the rest of the admin ui. This demonstrates it's a challenging component and people are trying to build their own solutions. There's clearly a need and I think groups and locations would be a step forward toward giving developers the tools to create something better.

Right now with most clients, I don't bother trying to teach them how to use the widgets screen because they just get overwhelmed. It's an area most users will only visit a few times vs more common areas like the post edit screen, they easily forget how it all operates.

As a developer I hate the widget screen because it's a pain to work with if you have slightly more complex layouts, want to show certain widgets in certain situations etc. There's no good way to do without leaving users with a confusing widget UI to work with...unless one makes a separate UI which is what many theme companies have done with mixed results.

#9 @nacin
6 years ago

  • Component changed from General to Widgets

Per a discussion during our weekly meeting in IRC yesterday, for 3.4 we're going to avoid the API implications here, as well as the implications of the widgets.php UI. This will instead be handled through the customization/preview screen (#19910, #19909). Essentially, we can allow for allow for groups of widgets (as defined by current locations) to be mapped to new locations.

#10 @navjotjsingh
6 years ago

  • Cc navjotjsingh@… added

#11 @eddiemoya
6 years ago

  • Cc eddie.moya+wptrac@… added

#12 @bobbravo2
6 years ago

  • Cc bobbravo2 added

#13 @koopersmith
6 years ago

  • Milestone changed from 3.4 to Future Release

Punting to future release.

#14 @chriscct7
3 years ago

  • Keywords dev-feedback added

#15 @celloexpressions
3 years ago

  • Keywords needs-patch added

UI-wise, with the Customizer now having menus we've set ourselves up to have excellent feature parity between widgets and menus in the Customizer. Both can use exactly the same UI, with the ability to add custom widget groups, then assigning them in a widget locations section and/or with checkboxes within each widget group control. I would suggest not trying to bring this feature to the widgets admin screen, as the UI there would be super messy, per @azaozz's comments above.

Note that Widget and Menus use the same UI in the Customizer - sections for each group/menu, an add-items flyout panel, a reorder mode toggle, etc.

I think this would be a good ticket to tackle for 4.4 if anyone's interested in working on an implementation. Could also potentially explore moving towards storing Widgets as posts in the process. cc @westonruter.

#16 @michaelarestad
2 years ago

Is this an 80% feature or a power user feature? Is this a feature that improves the user experience? These are pretty important questions to answer before implementing a new way to work with widgets.

TBH, I don't think the current way Menus allows grouping is very user friendly, despite being fairly powerful for the few that need it.

Last edited 2 years ago by michaelarestad (previous) (diff)

#17 @westonruter
2 years ago

@michaelarestad I would say it is an 80% feature because currently widget areas get re-assigned to other areas in unexpected ways when switching between themes. If the widgets were associated with the wrong widget area, or if they were dropped altogether, then they have to be manually dragged one by one to their appropriate widget areas in the new theme.

#18 @azaozz
2 years ago

I still stand by my comment from four years ago: adding "widget groups" will potentially make the UI a lot harder to understand for most users. I'd really like to see step-by-step wireframes that show the workflow with a theme with 6-7 sidebars plus 6-7 "widget groups".

I understand that the customizer is missing the "inactive widgets" area so it is impossible to recover widgets that have lost their places after switching themes, but perhaps we can do a better job of re-mapping the sidebars from the previous theme.

#19 @westonruter
2 years ago

For inactive widgets in the Customizer, see #27404.

#20 follow-up: @celloexpressions
2 years ago

If menus and widgets both used the same convention, it may be easier to understand how they work. Ie, if you need to assign both to areas/locations when switching themes, that may make it easier to understand how that process works. However, it does add complexity to the user experience in cases where automatic assignment can fully work. I wonder if we can make this change but also do a better job of automatically assigning both menus and widgets to areas when switching themes? This is probably easier to understand than the idea of inactive (or trashed) widgets when switching themes.

#21 in reply to: ↑ 20 @michaelarestad
2 years ago

Replying to celloexpressions:

If menus and widgets both used the same convention, it may be easier to understand how they work. Ie, if you need to assign both to areas/locations when switching themes, that may make it easier to understand how that process works.

So this is tricky. In many cases adding consistency can add clarity. In this case, I don't think so because the menus interface is particularly difficult to use and understand. Part of that comes from the amount of flexibility it has including the ability to have menus separate from menu locations.

I am all for figuring out a way to handle migration better, though. Perhaps multiple "inactive widgets" sections with the names of the previous widget section for reference. Accompanied with a "move all widgets to another section" button, it would make theme switching a little nicer.

#22 @westonruter
2 years ago

We had a discussion at the Day of REST conference about the REST API endpoints for menus and widgets (yet to be built), and have identified some opportunities for these two constructs to be more aligned in how they are interacted with. Introducing widget groups to be analogous to nav menus (as sidebars are to nav menu locations) is one way they can be more aligned: https://github.com/WP-API/wp-api-menus-widgets-endpoints/issues/10

#23 follow-up: @westonruter
2 years ago

Implementing widget groups could facilitate the migration (and backwards compatibility) of widgets from being stored in options to a custom post type. Per #35669:

the way that widgets get associated with sidebars should also perhaps be changed to follow the pattern of how nav menu items are associated with a nav menu via a taxonomy term. The implementing of widget groups (#19912) could be the right opportunity to do this, where a widget_grouping taxonomy could be introduced, and when a grouping is assigned to a sidebar, the backwards-compatible widget IDs could be copied into the existing sidebars_widgets option. Otherwise, backwards compatibility might entail adding pre_option_sidebars_widgets filter.

#24 in reply to: ↑ 23 @azaozz
2 years ago

  • Focuses ui added
  • Keywords ux-feedback added

Replying to westonruter:

Implementing widget groups could facilitate the migration (and backwards compatibility) of widgets from being stored in options to a custom post type. Per #35669:

Don't think it makes any difference. Widgets can be stored in many different ways without changing the UI.

Introducing widget groups to be analogous to nav menus (as sidebars are to nav menu locations) is one way they can be more aligned.

Perhaps, but only from a coding point of view :) However the menu settings are probably the worst UX in WordPress, in large part due to the "menu locations". Pretty much all people I've helped to set WordPress never ever get that right. Adding something similar for widgets wouldn't be good.

From comment 21

In many cases adding consistency can add clarity. In this case, I don't think so because the menus interface is particularly difficult to use and understand. Part of that comes from the amount of flexibility it has including the ability to have menus separate from menu locations.

Also, we used to have something similar on the stand-alone widgets screen. When switching from a theme with several sidebars to a theme with just one, it used to create several "Inactive widgets" areas, each corresponding to one old sidebar. I just tried to trigger it and it didn't work, so maybe it's broken or it has been removed. There were quite negative reactions to that as far as I remember, being too confusing.

For this to go ahead I'd very much like to get the designers/UX experts opinions first. IMHO we need to improve the menus settings first, not add similar things to the widgets settings.

#25 @westonruter
2 years ago

Right. The changes to the data model don't necessarily mean the UI needs to be changed. At the very least the code could be simplified to just associate a different widget group with a newly-switched theme's sidebar. Instead of there being multiple “Inactive Widgets” sidebars appearing, the actual widget group name could be used there instead. If there is no UI to actually create widget groups, then these widget groups could just be named according to the sidebars they were originally created for.

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


12 months ago

#27 @celloexpressions
12 months ago

The power and flexibility afforded by the menus and menu locations paradigm is often lost in the potential complexity of the concepts in UI. I'd love to see explorations into ways that menu locations and groups could be handled automatically in most cases and manually adjusted when users need that flexibility. The menus data model is actually quite strong and supports this possibility well.

Perhaps the best approach is to first introduce the technical concept of widget groups with minimal UI (such as the ability to add the whole group to a sidebar if it becomes inactive), then exploring better ways to let users manage specific groups and locations for both menus and widgets.

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


8 days ago

#29 @melchoyce
8 days ago

  • Milestone Future Release deleted
  • Resolution set to maybelater
  • Status changed from new to closed

This is something we're probably going to explore later this year as we extend Gutenberg into customization and site building. I don't see us tackling it any sooner.

Note: See TracTickets for help on using tickets.