Open closed widget areas when dragging onto them

[mitchoyoshitaka]

Right now if you start dragging a widget in the widget admin and drag it over a closed widget area, you have to let go once, open up the widget area, then drag again. Make it so closed widget areas open up when you drag things onto them, perhaps after a slight (500ms?) delay.

[edward mindreantre]

I've had a look at the code and sorta got it working. There are two problems:

1. When dragging the closed widget holders don't open reliably. You have to drag the draggable item over the widget window title a whole bunch of times before it actually opens.

2. When hover-opened the widget holder won't accept draggables. I'm guessing that the closed widget holder isn't available when the sorting process begins and therefore isn't included in the list of places where stuff can be dropped.

If those two problems can be solved then this patch should work. Haven't built in any delay, though.

[polevaultweb]

Added patch to open a closed widget on hover

[polevaultweb]

This issue is still present and the patch still works. Could I get someones eyes on this for a test/feedback please?

[chriscct7]

Sure, give me a few minutes :)

[chriscct7]

Works like a charm. Nice work @polevaultweb

[johnbillion]

I think this needs a short timeout. If you've got a bunch of closed widgets areas, they all open as you drag a widget over them.

[chriscct7]

What we need to do here is use on hover with the widget for at least 100 milliseconds open, and then if they hover over and then leave the area of the now open widget holder then close it again.

[chriscct7]

Adds hover delay

[chriscct7]

Added delay. 100 ms worked the best in terms of experience.

[polevaultweb]

Makes the hover delay related to the sortable events, not just mousehover

[polevaultweb]

@chriscct7 your previous patch meant that if you just hovered the mouse over a closed widget it would open. This patch now makes a closed widget area open if you drag a widget on to it after a 300ms delay (bit nicer at that length), the timeout gets cleared on the sortable.out event, so the area will not be opened if the widget is dragged away from the area within the timeout period.

Thanks for the feedback @johnbillion and help @chriscct7.

[chriscct7]

Ah indeed that is nicer

[polevaultweb]

@johnbillion I know you are super busy, but if you have chance to check out the latest patch for this with the timeout that would be great!

[chriscct7]

Replying to polevaultweb:

@johnbillion I know you are super busy, but if you have chance to check out the latest patch for this with the timeout that would be great!

I'll go see if I can find a committer so we can get this in. Its a really nice enhancement.

[obenland]

Patch doesn't apply cleanly anymore.

In testing I noticed that the sidebars that are being hovered over don't close themselves when I leave them (without dropping the widget), but rather stay open. Is that a Sortable thing or is that something we could change?

[polevaultweb]

Clean path

[polevaultweb]

@obenland Thanks for testing. I have just applied a clean patch.

The functionality you describe is a little tricky and currently WIP on an improved patch.

[obenland]

Replying to polevaultweb:

The functionality you describe is a little tricky and currently WIP on an improved patch.

Let's improve that then. It is currently possible to drag widgets onto closed sidebars, so I'd rather do it right than swap one mediocre ux for another.

[chriscct7]

@polevaultweb any update on that patch?

[polevaultweb]

Close previously closed sidebar when widget dragged out of sidebar

[polevaultweb]

@obenland new patch submitted, with the UX you requested

[obenland]

Nice work @polevaultweb!

Can we add something that keeps the sidebar open when a widget gets removed again, since a sidebar has to be open to begin with for that. Having it close is somewhat jarring.

The patch could probably benefit from a bit more testing too.

[polevaultweb]

Ensure a previously closed sidebar stays open after a dropped widget is subsequently removed

[polevaultweb]

@obenland thanks for the push here - patch added

[polevaultweb]

Use droppable tolerance of intersect to fix blank sidebar jumpiness

[polevaultweb]

Code comment tweaks

[ocean90]

I made too screencast, one without and one with the patch applied: ​https://cloudup.com/c2hTTi2vig3
There is some odd flickering when the widget is dragging for the first time over the opened sidebar.

[obenland]

Changed tolerance to pointer to fix placeholder flickering

[obenland]

@ocean90: I updated the patch to fix the flicker, good eye!
How does the code look to you?

[ocean90]

13524.3.diff​ works much smoother.
Sometimes the min-height doesn't get removed, but it's not quite easy to trigger this. It happens mostly when all sidebars are collapsed and you drag a widget multiple times over the sidebars. Otherwise it looks good.

[obenland]

Replying to ocean90:

Sometimes the min-height doesn't get removed, but it's not quite easy to trigger this. It happens mostly when all sidebars are collapsed and you drag a widget multiple times over the sidebars.

This could be intentional to avoid jumping when dragging a widget from an open sidebar to a closed sidebar below.

[obenland]

In 33014:

Open closed widget areas when dragging onto them.

Allows dropping Widgets into the correct spot of a given sidebar, no matter
whether that sidebar is open or closed. Removes a step from the setup process
for closed sidebars.

Props polevaultweb.
Fixes #13524.

[azaozz]

This fails for themes with several sidebars when you try to drag a widget from one (open) sidebar or from "Inactive widgets" to a closed sidebar.

Also, if I remember right, couple of years ago we specifically avoided adding "spring-jump" opening of the sidebars while the user is dragging. The argument against was that it makes dragging harder.

I'm 50/50 on whether it is a good thing or not, but if we want it, it will have to be fixed to work when dragging between sidebars.

[obenland]

Can you be more specific on what fails and what is not working?

[ocean90]

#20988 was marked as a duplicate.

[obenland]

Let's explore if hoverintent can improve the experience further.
@polevaultweb, would you be interested at taking a stab at this?

[azaozz]

Replying to obenland:

Can you be more specific on what fails and what is not working?

It doesn't keep the target sidebar open when dragging a widget from another sidebar or from Inactive Widgets. Steps to reproduce:

• Activate Twenty Fourteen.
• Go to the Widgets screen (it loads with the first sidebar open, the other two -- closed).
• Drag a widget from the first to the second sidebar. The second sidebar opens, but when you attempt to position the widget, it closes again, so it's not possible to place it in there.

[polevaultweb]

Ok so a new patch added -

The change of the tolerance to 'pointer' here - https://core.trac.wordpress.org/attachment/ticket/13524/13524.3.diff meant that the close of the sidebar after a widget was dragged out didn't happen. The tolerance has been reverted, and a true fix for the placeholder flicker reported here https://core.trac.wordpress.org/ticket/13524#comment:29

The patch also fixes the issue raised here https://core.trac.wordpress.org/ticket/13524#comment:36

[polevaultweb]

@ocean90 does the latest patch fix the flicker for you?

@azaozz does the latest patch fix your scenario?

[obenland]

Patch fixes the scenario azaozz reported. I could also not reproduce the flicker, although I'm not sure how to make it happen in the first place.

[azaozz]

Yep, 13524.4.diff fixes dragging from open to closed sidebar. The only small change there is to do sidebars.sortable( 'refresh' ); instead of $( this ).sortable( 'refresh' ); so when dragging over a closed sidebar to another closed sidebar, the second one is always refreshed too.

[azaozz]

In 33088:

Fix opening closed widget areas when dragging a widget over them.
Props polevaultweb. Fixes #13524.

[ocean90]

Follow-up: #33015