WordPress.org

Make WordPress Core

Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#25821 closed task (blessed) (fixed)

Allow user to click-to-add new widgets

Reported by: shaunandrews Owned by: nacin
Milestone: 3.8 Priority: high
Severity: normal Version: 3.8
Component: Widgets Keywords: has-patch needs-testing
Focuses: Cc:

Description

Merge the Widgets Area Chooser plugin (http://make.wordpress.org/core/2013/11/04/widgets-area-chooser-3-8-proposal/), making it possible to click-to-add a new widget. The flow works like this:

1) Click an available widget
2) Choose which sidebar to place the widget
3) Click save

After saving the widget, the sidebar that it was placed into will open, and the new widget will open and highlight.

Attachments (10)

25821.patch (8.7 KB) - added by azaozz 6 years ago.
25821.2.patch (8.7 KB) - added by azaozz 6 years ago.
25821.3.patch (860 bytes) - added by azaozz 6 years ago.
25821.4.patch (799 bytes) - added by shaunandrews 6 years ago.
Removing some unused styles from a previous design that used radio inputs and a select.
25821.5.patch (5.2 KB) - added by shaunandrews 6 years ago.
This patch moves the widget-chooser inside the selected .widget, which helps with context and prevents the weird-ness when widgets wrap below. This also adds the ability to hit the enter key to add a widget to the selected widget area, and use the tab key to choose an area from the list.
25821.6.patch (6.2 KB) - added by azaozz 6 years ago.
25821.7.patch (4.8 KB) - added by azaozz 6 years ago.
25821.8.patch (570 bytes) - added by shaunandrews 6 years ago.
Adding a max-width to sidebar columns
25821.9.diff (1.6 KB) - added by shaunandrews 6 years ago.
25821.10.diff (2.0 KB) - added by shaunandrews 6 years ago.

Download all attachments as: .zip

Change History (41)

#1 @barrykooij
6 years ago

  • Cc wpcore@… added

#2 @azaozz
6 years ago

  • Milestone changed from Awaiting Review to 3.8
  • Type changed from enhancement to task (blessed)

#3 @DrewAPicture
6 years ago

  • Cc xoodrew@… added

@azaozz
6 years ago

#4 @azaozz
6 years ago

In 25821.patch: merge Widgets Area Chooser in core. Currently the styling is off as it matches MP6, but all of the functionality is there. Both the CSS and JS will need a little adjustment after MP6 is merged.

@azaozz
6 years ago

#5 @azaozz
6 years ago

In 25821.2.patch: empty the "add-new" field after moving and saving the widget.

#6 @azaozz
6 years ago

In 26054:

Merge the Widgets Area Chooser feature plugin. First run, see #25821

#7 @azaozz
6 years ago

In 26078:

Widgets screen: adjust the placeholder to match the new widget "handle" height, and the spinner's margins so the sidebar titles don't "jump" when it is shown. See #25821, see #25858.

@azaozz
6 years ago

#8 @azaozz
6 years ago

25821.3.patch adds opening the sidebars when dragging a widget over their title. The sidebars remain open as closing them when dragging the widget out makes all other sidebars that are under to move up. Somewhat disorienting and quite annoying while dragging, the user has to "fish" to reach the desired sidebar.

Alternatively we can accept widgets dropped on a closed sidebar's title, highlighting that title to indicate a widget can be dropped there. Then open both the sidebar and the widget so the user can position the widget, enter settings, etc.

Last edited 6 years ago by azaozz (previous) (diff)

@shaunandrews
6 years ago

Removing some unused styles from a previous design that used radio inputs and a select.

@shaunandrews
6 years ago

This patch moves the widget-chooser inside the selected .widget, which helps with context and prevents the weird-ness when widgets wrap below. This also adds the ability to hit the enter key to add a widget to the selected widget area, and use the tab key to choose an area from the list.

#9 @azaozz
6 years ago

In 26259:

Widgets: remove some unused styles, props shaunandrews, see #25821

@azaozz
6 years ago

#10 @azaozz
6 years ago

In 25821.6.patch:

  • Refreshed the CSS so it applies clean again.
  • Reworked some of the JS changes.

#11 @azaozz
6 years ago

In 26271:

Widgets: move the chooser inside the selected widget so it inherits the width, add some keyboard shortcuts: tab to select, enter to append and escape to cancel. Props shaunandrews, see #25821

#12 @azaozz
6 years ago

In 26281:

Widgets: fix the placeholders dimensions so the sidebars don't jump when dragging a widget, see #25821

#13 @azaozz
6 years ago

In 26306:

Widgets:

  • Prevent dragging of the widget-in-question when the chooser is open.
  • Don't show more than one spinner when saving widgets positions.
  • Disable selecting of text in the widget title. Prevents selecting/highlighting most of the screen when dragging on slower devices.

See #25821.

#14 @nacin
6 years ago

"Prevent dragging of the widget-in-question when the chooser is open" — I could see this as something users may struggle with. There are a few other relatable situations where we don't strictly need to block alternative behavior. One example is when you start a password reset, you are still presented with a login box, just in case you remember your credentials. I could totally see a case where someone clicks to expand then realizes they wish to drag instead. Or, they accidentally click while trying to start a drag. Is this needed or can we allow dragging to occur anytime?

#15 @azaozz
6 years ago

Is this needed or can we allow dragging to occur anytime?

Added it mostly to prevent some id collisions/bugginess with UI Draggable when connected to UI Sortable. The same can probably be achieved by replacing the html id of the chooser with a class (it is attached inside the widget now and then the widget is cloned). Patch should be ready soon.

Last edited 6 years ago by azaozz (previous) (diff)

@azaozz
6 years ago

#16 @azaozz
6 years ago

In 25821.7.patch:

  • Don't deactivate "draggable" on the widget.
  • Change the chooser HTML id to a class to avoid collisions when cloning.
  • Refresh the "sortable" positions when an open widget is dragged. Fixes problems moving the widget up or down in the same sidebar.

#17 @azaozz
6 years ago

In 26366:

Widgets:

  • Don't deactivate "draggable" on the widget when the chooser is open. Makes it possible to still drag the "widget-in-question".
  • Change the chooser's HTML id to a class to avoid collisions when cloning.
  • Refresh the "sortable" positions when an open widget is dragged. Fixes problems moving the widget up or down in the same sidebar.

See #25821

@shaunandrews
6 years ago

Adding a max-width to sidebar columns

#18 @shaunandrews
6 years ago

25821.8.patch adds a max-width: 450px; to the .sidebars-column-1 and .sidebars-column-2 divs, which prevents sidebars (and the widgets they contain) from getting too wide. I've also shrunk the overall size of the div.widget-liquid-right to 58%, giving a little more separation between the available widgets and the theme's sidebars.

#19 @azaozz
6 years ago

In 26432:

Widgets: prevent the sidebars from getting too wide, add a little more space between Available Widgets and the sidebars, props shaunandrews, see #25821.

#20 @nofearinc
6 years ago

  • Keywords has-patch needs-testing added

#21 follow-up: @nacin
6 years ago

  • Priority changed from normal to high

Things seem good here, but the scrolling page is really jarring. It is especially jarring when the sidebar is already visible on the page. I think we should remove it. At best, we should collapse all widget areas except for the one we added things to. But that could throw people off because they might have widget areas open in order to figure out where they should be adding their widget.

Triggering the opening of the widget controls seems fine, but I think we should ditch the animations entirely. Thoughts? Compelling reasons to keep this? If we're going to, I think it needs to be much smarter (as in, the added widget can't be in view at all).

#22 in reply to: ↑ 21 @shaunandrews
6 years ago

Replying to nacin:

Things seem good here, but the scrolling page is really jarring. It is especially jarring when the sidebar is already visible on the page. I think we should remove it. At best, we should collapse all widget areas except for the one we added things to. But that could throw people off because they might have widget areas open in order to figure out where they should be adding their widget.

Triggering the opening of the widget controls seems fine, but I think we should ditch the animations entirely. Thoughts? Compelling reasons to keep this? If we're going to, I think it needs to be much smarter (as in, the added widget can't be in view at all).

The compelling reason to keep the scrolling (in any form) is that you get no other feedback that you've successfully added a widget. If we don't scroll the widget into view, then its way to easy to think nothing happened. The scrolling could be much smoother, but its better than no scrolling.

What do you think about making the list of available and inactive widgets a separately scrollable div, positioned fixed to the viewport. This would mitigate the need to scroll the main viewport as your sidebars would be more likely to be in view.

#24 @nacin
6 years ago

I'm not sure we should do much at this point to change the behavior of the screen. The act of clicking "Add Widget" and having the controls go away should be enough of an indication that something was added. The widget area expands if it was already collapsed, as a bonus, and the widget that got added gets expanded, which is nice. I disagree that no scrolling is worse. It makes the screen really jumpy. Have you tried it on a tablet? It's really weird there too. Maybe it should receive the keyboard focus, but that's about all I'd change in return for dropping scrolling.

#25 @nacin
6 years ago

I could go for smarter scrolling that brings a hidden sidebar into view. But in this case, it should only scroll down to the point where the control is entirely in view (within reason, some open controls may be huge) or scroll up to the point where the top of the control is in view.

That said, it's entirely possible that someone is trying to "build" a sidebar with a bunch of widgets, and so they go tap-tap-tap to add two or more, and then go back and configure them. To be honest, if the sidebar is out of view, then I'm not really sure what the user's objective is. But jumpy scrolling when the sidebar is in view should go, and I'd rather sacrifice it all together than keep the scrolling in as it currently is.

@shaunandrews
6 years ago

#26 @shaunandrews
6 years ago

25821.9.diff adds a check to see if the sidebar is within the viewport before scrolling the window.

#27 @shaunandrews
6 years ago

25821.10.diff​ updates the previous diff removed the checks on the top and bottom of the viewport and sidebar as thats not needed. :)

#28 @nacin
6 years ago

In 26695:

Widgets: Only scroll to the newly clicked-and-added widget if it is out of the viewport.

props shaunandrews.
see #25821.

#29 @nacin
6 years ago

Per IRC discussion, clicked-and-added widgets should be added to the bottom of the sidebar, not the top. Jaquith put it well:

  • New widgets are likely to be less important, otherwise you would have added them sooner.
  • And adding them to the bottom causes less disruption if done accidentally.

Widgets also automatically save and instantly go live, so stashing it at the bottom mitigates major site changes. Otherwise, it'd be like adding menu items at the top, when that really only makes sense if you're adding a "Home" link (and FWIW, this is exactly how nav menus behave).

#30 @nacin
6 years ago

  • Owner set to nacin
  • Resolution set to fixed
  • Status changed from new to closed

In 26696:

Widgets: Add click-to-add widgets to the bottom (not top) of the target sidebar.

fixes #25821.

#31 @azaozz
6 years ago

In 26703:

Widgets: jshint cleanup of widgets.js, see #25821.

Note: See TracTickets for help on using tickets.