WordPress.org

Make WordPress Core

Opened 2 years ago

Last modified 2 years ago

#19912 new feature request

Add Widget Groups and Locations

Reported by: koopersmith Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version: 3.3.1
Component: Widgets Keywords:
Focuses: 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 (13)

comment:2 scribu2 years ago

  • Cc scribu added

comment:3 sabreuse2 years ago

  • Cc sabreuse@… added

comment:4 rfair4042 years ago

  • Cc rfair404 added

comment:5 follow-up: Nobble2 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.

comment:6 in reply to: ↑ 5 azaozz2 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.

comment:7 markoheijnen2 years ago

  • Cc marko@… added

comment:8 Nobble2 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.

comment:9 nacin2 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.

comment:10 navjotjsingh2 years ago

  • Cc navjotjsingh@… added

comment:11 eddiemoya2 years ago

  • Cc eddie.moya+wptrac@… added

comment:12 bobbravo22 years ago

  • Cc bobbravo2 added

comment:13 koopersmith2 years ago

  • Milestone changed from 3.4 to Future Release

Punting to future release.

Note: See TracTickets for help on using tickets.