Cursor doesn't change to indicate block can be dragged #24506
Comments
|
The accessibility team specifically requested that the up/down mover buttons not use a drag cursor, because all buttons should use the same cursor. See #23759. A proper solution, then, would be to add a visible, dedicated drag handle, similar to what WP 5.4 had. The biggest problem here, of course, is how much longer that would make the default block toolbar. And so there's the core design problem that needs to be resolved. |
ZebulanStanphill
added
[Focus] Accessibility (a11y)
|
+1 to some kind of dedicated handle. This is not obvious at all and I thought the feature had been removed. |
|
Additionally, at this time this feature HAS functionally been removed for users who prefer the Top Toolbar option, as the (very un-intuitive) method described to drag and drop in 5.5 cannot be accessed unless users are set to the inline block toolbar. |
|
Considering this issue as initially framed, the cursor state is awkward due to conflating different types of transform—moving a block on a linear path vs. freeform positioning—into one UI device. I'm also in favour of a visible, dedicated handle. Not everyone takes a template-/pattern-first approach to composing page content, and this makes it important to have a highly discoverable way to drag content in and out of container blocks. I'd love to have a way to shift menu context between block content tools (bold, italics, etc.) and block transform tools (freeform dragging, moving blocks up and down). |
|
To provide some perspective from the field literally every single support request I've received from clients in relation to this has been 'why has drag and drop been removed' - hell even I had to check the release notes again to find it. The visual UI updates are jarring enough for our clients and arbitrary, in my opinion, significant regressive steps in terms of what is already in many area a poor UX really do not help. It feels like there is little or no testing within user groups when literally watching over the shoulder of a single novice user grasping around and clearly floundering is enough to show how desperately Gutenberg needs consistency and clear direction. It's truly depressing to see the work and inevitable rework around these poorly conceived changes in what at it's core could be an excellent tool for users. |
ZebulanStanphill
added
the
[Type] Regression
ZebulanStanphill
added
the
[Feature] Drag and Drop
|
I've used Gutenberg since 2018 and someone had to tell me that you could drag a block by clicking and holding on the arrows. I'm not sure in what universe this seemed like good UX. What was wrong with the drag handle we had? |
|
Responding to #24506 (comment); what the Accessibility Team specifically requested was that the editor not combine the usage of single controls serving multiple purposes. A drag surface can use the drag cursor, but the up/down move buttons should use a standard button cursor. The problem is with trying to make a single control serve more than one dedicated purpose. We're entirely in favor of having a drag cursor; it just shouldn't be on a button. |
|
Agree with the above. The removal of the drag handle is a really poor decision. It's ridiculous that the Block Toolbar no longer gives any indication about where you need to click to drag the block, or if it's still even possible to drag the block! Your constant removal and hiding of controls, and elements such as block borders, is making the editor UI go from bad to worse with each new release. |
github-actions
bot
added
the
[Status] In Progress
|
Just a quick sketch and idea: What about hiding the up/down and left/right buttons until hover or focus? Would that a problem with a11y? Maybe some aria label while focusing the move area like "arrow up to move up, arrow down to move down" or similiar could help?
|
|
@mariohamann Controls shown on hover would definitely be problematic for accessibility. Also, the focus behavior in your mockups would be... weird. The tab order should match visual order as much as possible, and in your mockups, the thing focused to show the mover buttons would end up being focused before the up/left button, which from a visual perspective should come first. It's worth noting that I've opened #24805 to discuss solutions to the core design issues with the block toolbar that have led to problems like this. Solving the core issue will fix this one as well. In the meantime, there's an attempt to solve this specific problem in #24852, at the cost of increasing the default toolbar size. Since so many users seem to think drag-and-drop has been removed, this may be a better design for now. Ultimately, though, we'll end up having to solve the other issues like the movers appearing like a single button since they're stacked, and the block transform/style-switcher serving double duty as the current-block indicator... and the longer the block toolbar gets, the harder it is to fit more stuff in and fix the other remaining problems. |
|
@ZebulanStanphill Aren't there already a lot of things that are only shown on hover, though? Why is making up/down arrows show only on hover worse for a11y than not showing a move/drag icon at all? (Mind you, I would prefer having both if it can be done, but I acknowledge the toolbar length issue.) I like @mariohamann's sketch. The four-arrows icon suggests to me that this is what you click if you want to move something. Showing that there are different options for how to move it seems like a reasonable kind of secondary-menu thing. I find the up-down arrows MORE ambiguous as icons, because they could imply different things, e.g. navigating between blocks instead of relocating the block. |
|
I have to ask again, why is it that the default solution is always to hide icons, and only show them on hover?? The ability to move blocks around your page is one of the most used features in the Block Editor, or any sort of editor like this. Why are all the "solutions" here, hiding these buttons by default. Just show the Block moving arrows and the Block Drag Handle all the time. Stop making it harder for users to edit their page by hiding important and often used functionality! |
|
@mariohamann Thank you for taking the time to work on this. I just want to say that all ideas are welcome, you may get some strongly worded feedback like in this comment thread at times, but that's not representative of how the entire community provides feedback. As @ZebulanStanphill mentions, keyboard navigation is important. A user should be able to use left and right arrow keys to navigate through toolbar items sequentially, which may be tricky with your design as the buttons only appear once focused/hovered. There's some more information on the pattern here if you're interested on reading up on it, hopefully that'll help: The 'Select Parent' button that pops up similarly to your design still kind of fits into this as it becomes the first toolbar item and pressing the right arrow key still takes a user through toolbar items sequentially. |
|
I think the description of my idea was a little bit too rough - sorry for that (I currently don't have my PC nearby... :)). So I did another - very low fidelity - sketch:
Description:
What do you think? |
|
Solutions that use the toolbar for placing a drag handle are not sufficient since the Top Toolbar option loses that ability. |
|
@mtias Still, there is a drag handle in the toolbar already, and we ought to at least make it visible until we can find a better way to expose it (e.g. a new editor mode/tool or adding drag-and-drop to the Select/Navigation mode/tool.) As for the parent-block selector being hidden by default, that's a design mistake that needs to be changed, not something that should be copied to other parts of the UI. See #23766. I've tried fixing this in #23800, but I can't progress on that PR because of the other issues with the block toolbar, namely:
So to fix the parent-block selector, you first have to change the block switcher to use a dedicated "transform/switch" icon. But when you do that, you lose the block icon indicator, so you'll have to split that out into its own thing. But if you do that, you end up increasing the toolbar size, and if you then put the parent-block selector button into the toolbar, you increase its size even more. And meanwhile, we're also running into issues where the block movers look like a single button because they take up the same space that a single button would take up, and we need to make the drag handle visible, and fixing those issues will end up almost tripling the space that the mover controls take up. So if you put all this together, you end up increasing the block toolbar size by 3 buttons, or 4 buttons for nested blocks. So this all ties back to the too-many-controls issues discussed in #24805. Again, I'd like to reiterate that hiding controls behind hover interactions is not, and should never be the solution. An earlier version of the G2 block toolbar hid the movers behind a hover interaction, and that was changed to make them more visible and improve accessibility. Let's try not to go backwards again. Moving/sliding stuff around on hover is almost always bad for accessibility, and frankly, it's usually just bad for usability in general. #24852 is the best immediate solution currently available to the invisible-drag-handle problem. If you want to see improvement right now, go over there and help get that PR merged. Anything further is going to require bigger changes as discussed in #24805, or else something like modifying the editor tools/modes. |
|
A lot of these last minute tweaks have indeed made some things worse. The separation of the movers from the block type is spurious, since we have controls without a separator coexisting (inline controls like bold and italics). The issue there was one of proximity causing it to seem like a single unit, but it could have been improved.
Semantically grouping these meta-block tools is important. The toolbar with so many separations starts to lose internal coherence. There have also been some thoughts about moving some of the meta controls to the end of the toolbar, which could be worth considering. In any case, I think we need to solve the drag in selection mode and how to transition. Dragging the block itself (like an image) is always going to win in intuitiveness.
Pardon me, but I don't agree it's a design mistake. It can be improved upon but I definitely don't think always showing it would be great.
Why so?
"Hover interactions" is a bit dismissive of an entire group of design considerations that should not be cast away with a blunt guideline. The toolbar itself is a focus interaction in that it shows based on what blocks is selected. We don't show a toolbar for every block on the page all the time in a permanent way. It's entirely reasonable other specific interactions could work with similar patterns if modeled properly and with the required attention. |
Because the parent-block selector button uses the parent block's icon to represent that clicking the button selects that block. But if you put it next to the switcher, then you have two buttons using block icons, which is confusing. Then again, perhaps the parent-block selector should have a dedicated "parent block" icon, though I'm not sure what that would look like. Also, the switcher shouldn't be using the block icon as its icon because buttons should convey their action in their icons/labels, not their state. A button to transform a block should use an icon that conveys that action, not the icon of the block itself. We already have this problem with the visibility and publish date controls in the document settings. (See #470.) It would be best to try and fix this problem in other parts of the UI as well. As far as I can tell, the only reason why the switcher uses the block icon is to save space by serving a double function as both a transform button and an indicator of the current block. From an accessibility perspective, the two should be separate things: an indicator of the current block (presumably with a tooltip containing the block name) and a transform control that uses a transform icon. As for the whole toolbar grouping thing, I would not be opposed to showing the mover controls in the same group as the transform tool. But unless you style them like every other button (e.g. no stacked buttons, not tiny buttons, just full-size buttons like the ones in the inline formatting toolbar group), you wind up running into confusion where the different buttons look like they might be a single button/select-dropdown. It's also important to note that since there's multiple movement controls (up, down, drag), it would make sense As for the order of the controls, I think it's reasonable to move the mover controls before the transform control. The reason why that hasn't already happened, if I recall correctly, is that we wanted to keep the block icon as the first thing in the toolbar. And that brings us back to the issue of the block icon and transform button being the same object when they should be separate entities. If we simplify things and get rid of all the special-case styling and merged controls, we end up with only one remaining problem: too many things in the toolbar. And at that point, you have to wonder why we're showing so many controls all at the same time. Why are we showing inline formatting controls at the same time as block movement controls? Perhaps it's a sign that we need to start showing controls more contextually somehow. (Hence #24805.) To throw around a new idea I just had: maybe take advantage of the existing editor tools/modes concept, and make the block movers only available in a dedicated "Movement" tool that allows you to drag blocks from anywhere, but also use up/down, move-to-top, move-to-bottom, and other advanced movement controls in the block toolbar, with no other controls being shown. (Maybe the up/down controls could still be shown in standard "Edit" mode or whatever we call it, I'm not sure about the specifics of how this would all work.) I'm not convinced that adding drag-and-drop to the Select/Navigation tool makes sense, since that tool was specifically designed for navigating from block to block, and adding more controls might harm its accessibility and muddy the purpose of the mode... telling people to use a mode called "Select" or "Navigation" to drag-and-drop sounds super weird and confusing. Maybe it's fine to have that as a minor enhancement, but it should definitely not be "the" way to use drag-and-drop, unless we decide to redefine what that mode is and what it's called. I know adding more editor modes is dangerous since it can easily introduce more complexity. But seeing that the block toolbar is already jam-packed with tons of controls to the point where we don't want to add any more, maybe taking advantage of editor modes is the only way to reduce complexity. (If we did go this route, we should probably make the editor mode more prominent in the toolbar... probably with visible text labels, rather than the icon-only look.) Anyway, to reel things back in a bit, @jasmussen noted in #24852 that he's working on a different approach to the drag-and-drop issue, so hopefully a good solution will come out of that. Either way, it's good to see action being taken on this issue, because it's a really big problem, and I really hope we can address it before the release of 5.6. |
Ah, I see what you mean.
This doesn't make a lot of sense in this case. Many of the toolbar items are buttons containing a stateful representation (current alignment, current color, etc) and they are still able to trigger an action (a dropdown, or a toggle) to change it.
I don't think this is necessarily the case. It's fairly common in writing tools for a select-like button behaviour to be present both showing the current type of a text (i.e. heading 2) and as a way to modify said type. That's how the block type was modelled, just abstracted as a general block tool. It used to be presented as a grid to mimic the main inserter but was changed to be a list to more clearly refer to traditional transforms. |
Just because that's how everything is, doesn't mean that's how it should be. It's also worth noting that in the case of things like text/block alignment, all the state icons also happen to work pretty well as general action icons. (E.g. a "align text left" icon also works fine as an "align text" icon.) In the case of the block switcher, something like a Paragraph icon doesn't even come close to representing the concept of "transform". It's also important to remember that for ideal accessibility, a Relying on icons to function as labels is already supposed to be a last resort when it comes to accessibility. It's even worse when the icons aren't even labeling the control in the first place. And in the case of the block switcher, that's precisely what's happening, in my opinion. On another note, I've been thinking about the tools/modes solution some more, and the idea of moving the movement controls to Select mode has grown on me. I think it could work, assuming we rename the mode to something that fits its new, wider range of purpose better. (The "Select" name definitely wouldn't work anymore.) Otherwise, I think a separate "Move" mode/tool may be necessary. |
Is this necessarily an issue? #23892 (comment) makes the claim "Top Toolbar was a mode specifically designed for people focused on writing", and elsewhere in that issue there's reference to the inline and top toolbars as "block-level" and "text-level". I admit I don't appreciate the concept of "focus" here, but it doesn't feel unreasonable to argue a drag handle might be out of place in the text-level context (presuming the claim above is true). |
@mtias I provided an idea some days ago introducing some kind of "layout" mode (instead of "select" mode) which makes it possible to move blocks even without the need of a dedicated "mover" button and therefore being usable with and without toolbar. I would be happy if you could provide some thoughts: #24751 :) |
Is it really necessary with an additional mode one has to select? In apps like Figma and others, the selection tool also allows moving elements. |
|
@chthonic-ds in the sense we should also allow those users the ability to drag blocks. It's ok if there are some differences (like a drag handle in the case the toolbar is detached) but we should still try to not skip the functionality entirely for top toolbar. |
And how should it be? Not being facetious, but we are getting into not very productive territory quickly. The entire toolbar works using tooltips instead of labels. Treating the block type differently is what would create an inconsistency. @mariohamann indeed, that's what "select" was meant to handle! It started as a way to handle clickthrough issues for nested contexts. It then also absorbed the idea of using it as a way to quickly travers the tree of blocks one at a time. It makes sense for it to handle moving as well. The transition between states is something that's an ongoing exploration. Right now it supports escape / enter, for example, but it's also been suggested to use a modifier key at any point to engage with it. That also seems promising, though it would need to ensure not running into common modifier key use at the operating system + browser level, which restricts the options. Transitioning in and out has to be smooth, otherwise modes become an extra hurdle. |
|
You should all check this issue #24898, it contains multiple interesting design proposals. |
For me, yes. I initially came to this ticket because I was baffled about where the drag functionality had gone — I have double vision issues and initially found all the block settings hovering/overlapping above the block to be hard to focus on. So I had turned on the Top Toolbar some time ago, and for me (and other users who had done the same) the functionality to move things in & out of columns/containers had simply disappeared with 5.5. I agree that it's weird to put some drag-like handle in a top toolbar. My primary confusion arose when the baseline functionality it offers seemed to have been taken away from me entirely. So to me, the issues around top toolbar include:
(Is "Move to" supposed to be the way? I just spent a good 5 minutes trying to use "Move to" and my keyboard or my mouse to move a core paragraph into a core column and never succeeded, I have no idea how I'm supposed to do it or if it even can.) I'm not sure what @ZebulanStanphill and/or @jasmussen may have in the works, but I hope the Top Toolbar folks aren't forgotten. I am much more interested in the ability to move things in and out of levels of the outline/columns/containers than I am about dragging necessarily being the way I do that. |
First of all, the tooltips, textually, are the labels; they match the My point is that the icons for most of the other controls in the block toolbar, although they are technically "state" icons, also happen to function as non-textual labels... mostly matching the text of their control's (It's also worth noting that some controls in the block toolbar use standard action/control-based icons, such as the Bold and Italic controls or the "More options" button. So it's not like all controls in the block toolbar use current-state icons.) The block switcher is the odd one out, because it's icon fails to function as a non-textual label for the control. It can't get away with the same 2-in-1 "cheat" that some other controls use. So here's how I'm suggesting "it should be". I propose that the block switcher/icon be split into two things:
I do realize now it's not an entirely clear-cut situation. You could argue the block switcher is fine since technically it follows the same baseline of using an icon showing the current state. But the point still stands that the purpose of the control is not as clear as most of the other controls. I suppose this speaks to a larger issue with the block toolbar: it just doesn't use icons the way that a11y guidelines recommend. It manages to get away with it for the most part since the icons it does use are usually close enough, but I now realize that a complete solution would involve dramatically altering the block toolbar... perhaps resulting in either:
Anyway, this is getting way off-topic to the current ticket (maybe I'll open a separate issue to discuss this sort of thing), but I hope I made clear the point I was trying to make.
In @mariohamann's issue, he's not suggesting an additional mode. He's suggesting the existing modes be altered and renamed. Speaking of which, the idea of having movement controls moved to Select mode has really grown on me lately. It's interesting to hear that there's already a precedent in existing apps to have a mode that's used for both selecting and moving objects. I think we just need to come up with a new name for the mode that would better fit its purpose. @christinablust Yeah, I'm pretty sure that "Move to" is supposed to be at least a partial solution to moving blocks in-and-out of nested containers. It's not really clear how to use it at first, though. (And perhaps there's room for improvement there.) I think you have to press Enter to make the move happen, if I recall correctly. If you feel there's anything to be improved, please open an issue about it. It's also worth noting that if movement controls were moved (heh) to the Select mode/tool, there would be enough room to show "Move to" in the block toolbar (rather than hidden in an overflow menu), and maybe even dedicated "move up one nesting level" and "move into following block" buttons. |
@ZebulanStanphill The toolbar pattern example itself has a a button for a menu that changes state (font family): And sure it's not an icon, but it also doesn't have a visible label that says "Font". A user has to know that the thing visually shown is the name of a font to understand that it's a font picker they're interacting with. The aria-label for the button in this example changes to represent the currently selected font, e.g. "Font: Sans Serif", this is perhaps something that could be used in the block editor to improve labeling on menu buttons.
What's the recommendation you're hinting at here? Always handy to have links. |
|
I'm sorry. I worded my response there somewhat hastily and probably too authoritatively. I wasn't referring to any official "guidelines", but rather this passage from the 2018 a11y status report, which didn't even say exactly what I (mis)remembered it as saying:
(emphasis mine) @talldan Foolishly, I wasn't aware of that toolbar pattern example. One thing I do notice about it is that it emulates the look of a
To our design's credit, however, we do provide actual labels to controls in the block toolbar in hover/focus tooltips, which the "Font family" control in the pattern example lacks. I must admit I'm not as knowledgeable about a11y as some other people here. Apologies if I've said anything else inaccurate so far. Back to the immediate topic of the missing-drag-handle, I'd recommend checking out #24852. The latest iteration seems to at least be a better compromise than what we have in |
|
@ZebulanStanphill It's definitely not a straightforward thing. I think lots of us try to interpret the guidelines the best we can, but sometimes the guidelines aren't even all that well supported. Regarding the lack of labeling, maybe this is something expanding the option introduced in #24304 could help with, though it might need to be in conjunction with a 'top toolbar' style toolbar, as I can't imagine there being enough space on the above block toolbar for text labels. |
|
@talldan Thank you for resolving this! |
|
Have just updated the Gutenberg plugin to the latest version (8.9.1) and still not seeing a drag handle
macOS Catalina 10.15.6 |
|
@maddisondesigns It'll be in the next version, 9.0. |
|
@talldan Ahh ok. Thanks. You should really change the Changelog link in the plugin details popup then. It points to here. If this is the list of changes for the next version, then the plugin is pointing to the wrong place. The plugin needs to point to the changelog for the current version. How do I find the list of changes in 8.9.1?
|
|
@maddisondesigns Oh right, thanks for pointing that out. It's probably because there don't tend to be changelogs for patch releases. The right link should have been this one: It had just a single backwards compatibility fix - #25046. I'll mention it to see if the release process needs to be changed. It may have just been a manual error. |
|
@talldan Thanks for that 👍 |
|
Double checking, the link from the plugin page is to here: Usually the changelog would appear on this page, but as patch releases tend to be made very quickly to fix a specific issue they're usually not compiled. The |
Description of the issue
In WordPress 5.5 I learned the block drag handle has been integrated into the block toolbar. A click+drag on a block's reordering arrows is the new way to drag a block elsewhere (into a column block, for example).
I see the default and pointer cursor but never the 'grab' or 'grabbing' cursor when dragging a block.
To reproduce
Expected behavior
I expect some indication a block is ready to be dragged or being dragged. Not being aware the drag handles had been integrated into the toolbar meant I initially thought it was no longer possible to drag and drop blocks.
I notice in #23863 (comment) the 'drag' cursor is visible, though the layout and target seem to be an earlier iteration.
Editor version:
Desktop (please complete the following information):
The text was updated successfully, but these errors were encountered: