Opened 8 years ago
Last modified 4 years ago
#39910 new enhancement
Customizer: Add ability to drag & drop widgets and menu items
Reported by: | lukecavanagh | Owned by: | |
---|---|---|---|
Milestone: | Future Release | Priority: | normal |
Severity: | normal | Version: | |
Component: | Customize | Keywords: | needs-patch |
Focuses: | ui, accessibility | Cc: |
Description
Currently when you add a new widget in the Customizer, the available widgets will show, but you can not drag and drop any of the those widgets, rather you have to select the widget then, that widget will be added in. Drag and drop does work on widgets that already exist or where just added.
Attachments (2)
Change History (27)
#1
@
8 years ago
@lukecavanagh in other words, you're proposing that you should be able to drag an available widget from the panel over to the sidebar and have it created in the spot that you drop it? This would address the complaint about widgets always being added to the end of the list.
This should also be considered for restoring inactive widgets in #27404.
#2
@
8 years ago
- Type changed from defect (bug) to enhancement
I'm personally not a fan of drag and drop, but I know that it works well for some people. The visual styling of the current available widgets doesn't really suggest draggability, so that may need to be adjusted if this change is made. Or, it could be a hidden enhancement, with click-to-add remaining the primary interaction.
#3
follow-up:
↓ 4
@
8 years ago
I'm not sure dragging and dropping widgets makes sense until you can also do it with menus. In saying that, I think having it work for both in the future would make sense.
I'm also not sure if it would work within the existing UI, that's what makes me wonder if we simply add drag and drop how discoverable it would be for 'non-us' users.
Wouldn't focusing on improving and innovating the UI be a better approach?
#4
in reply to:
↑ 3
@
8 years ago
Replying to karmatosed:
I'm not sure dragging and dropping widgets makes sense until you can also do it with menus. In saying that, I think having it work for both in the future would make sense.
Agreed. If drag and drop works for widgets then it should also work for nav menu items.
I'm also not sure if it would work within the existing UI, that's what makes me wonder if we simply add drag and drop how discoverable it would be for 'non-us' users.
It would probably benefit from having the cursor:move
or some grabber appear on the item which can be drag-and-dropped.
Wouldn't focusing on improving and innovating the UI be a better approach?
Isn't that what this is? Or do you mean perhaps a new UI for the Add button? Eventually I could see it take the same form as the block insertion UI being worked on for the editor, and that there could be a + icon or something that is in between each widget or nav menu item in some what, and when clicking on it, the user could then be prompted with a subset of the available blocks that can be placed there: namely the available widgets, inactive widgets, or available nav menu item types, depending on the context.
This ticket was mentioned in Slack in #core-editor by westonruter. View the logs.
8 years ago
#6
@
8 years ago
Eventually I could see it take the same form as the block insertion UI being worked on for the editor, and that there could be a + icon or something [...]
This is an excellent intuition, but can be reframed to be both a proper translation of the editor UI, as well as express its full power. It's a bit OT for this ticket, but let me elaborate and we can progress the discussion at some point later.
The idea that the editor is current pursuing can be synthesized as the "Universal Insert", a specific area in an application that is the one and only one area in the UI that allows for items to be inserted. This can be found in many modern applications in the form of toolbars or sidebars. These types of UI are incredible effective if they follow specifically two principles:
- They are unique on the screen
- They provide all the possible items that can be added
In the current editor exploration, you see it's following these two rules to the letter. It might change in the future, but that's why it's so appealing right now.
Thus, a proper "conversion" of the same concept to the editor is a single UI on the screen that is able to add... anything that can be added. This means that clicking there makes the user then able to add both menu items and widgets... and in the future anything that can be added.
Back to the ticket...
Excellent suggestion and very rich discussion. I'll add a few of considerations for the discussion:
- Drag'n'drop should be a way to augment existing features, not replace them as it's an advanced feature. As such, doesn't inherently have to be highly discoverable because the discoverability is already satisfied by the alternative (non-drag'n'drop) way to do things. Which means that changing the cursor might be the only thing we need to do.
- I agree any enhancement here should happen for every analogous UI, such as menus. Both will benefit by the ability of drag'n'dropping elements directly in the right position.
#7
@
8 years ago
@westonruter
Yep correct, seems like drag and drop should be an option for widgets and menus. I personally do like drag and drop.
#8
@
8 years ago
I am constantly trying to drag and drop menu items. Instead, I end up adding a couple duplicate menu items by accident. It's pretty irritating. Menu items in the Customizer look like they should be draggable. Widgets, less so — but I see an argument for making both draggable.
One thing we could do to improve drag-and-drop discoverability is change the widget design to use "card" styles. They'll look more draggable. Uploading a mockup to show what I mean.
#10
@
8 years ago
@melchoyce
The card style mockup, does make it clearer to end-users that widgets could be added by drag-and-drop.
#11
@
8 years ago
- Summary changed from Customizer: Add widgets drag and drop ability to Customizer: Add ability to drag & drop widgets and menu items
#12
@
8 years ago
- Focuses accessibility added
Just adding the accessibility tag so we don't neglect that area when tinkering with this.
This ticket was mentioned in Slack in #core by swissspidy. View the logs.
8 years ago
#14
@
8 years ago
- Milestone changed from 4.7.4 to 4.8
- Version 4.7.2 deleted
Punting for now. Feel free to re-add to milestone when this is really ready for 4.7.4.
#15
@
8 years ago
Widgets as cards look nicer and would suggest they're draggable. Would be nice to explore something similar for the menu items too, though there are some more space constraints there. If they're going to be draggable, maybe the same functionality should be communicated with a similar design.
One thing to consider is that when clicking on a widget, the widget gets added and the widget panel auto-closes. This is annoying when adding multiple widgets, since you have to re-open the panel each time. Same with the introduction of drag-n-drop, the panel should probably not close automatically.
This ticket was mentioned in Slack in #accessibility by afercia. View the logs.
8 years ago
This ticket was mentioned in Slack in #core by jeffpaul. View the logs.
8 years ago
This ticket was mentioned in Slack in #design by melchoyce. View the logs.
7 years ago
This ticket was mentioned in Slack in #accessibility by afercia. View the logs.
7 years ago
#23
@
7 years ago
I'm moving this out of 4.9 because widgets and menus are going to be changing heavily with work in Gutenberg, and there will likely be components that we can re-use from Gutenberg in the Customizer.
This ticket was mentioned in Slack in #accessibility by afercia. View the logs.
7 years ago
#25
@
4 years ago
- Keywords needs-patch added
Is drag and drop still a need with the block inserter replacing the widget inserter in 5.8? There is some discussion specific to the block (editor) inserter above. It could still be applied to menus unless/until menus are also replaced with a block version.
Customizer Add Widget