#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)
Change History (41)
#2
@
11 years ago
- Milestone changed from Awaiting Review to 3.8
- Type changed from enhancement to task (blessed)
#8
@
11 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.
@
11 years ago
Removing some unused styles from a previous design that used radio inputs and a select.
@
11 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.
#10
@
11 years ago
In 25821.6.patch:
- Refreshed the CSS so it applies clean again.
- Reworked some of the JS changes.
#14
@
11 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
@
11 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.
#16
@
11 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.
#18
@
11 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.
#21
follow-up:
↓ 22
@
11 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
@
11 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
@
11 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
@
11 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.
#26
@
11 years ago
25821.9.diff adds a check to see if the sidebar is within the viewport before scrolling the window.
#27
@
11 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. :)
#29
@
11 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).
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.