Experiment: Try block inspector controls toggle in block toolbar #65118
Conversation
| import { ToolbarGroup } from '@wordpress/components'; | ||
| import { ToolbarGroup, ToolbarButton } from '@wordpress/components'; | ||
| import { settings as settingsIcon } from '@wordpress/icons'; | ||
| import { store as interfaceStore } from '@wordpress/interface'; |
There was a problem hiding this comment.
I know we can't do this as block-editor cannot depend on interface.
|
Size Change: +936 B (+0.05%) Total Size: 1.78 MB
ℹ️ View Unchanged
|
|
Editors had this functionality via block Options. It was removed in #46709. PS. Block Toolbar has limited space, so I would avoid adding any global controls there if possible. cc @jasmussen |
|
I remember that option. I never found it to be much help to be honest. Hiding it in that menu is probably worse than what we have today, which is likely why it was removed. This PR does something different.
Acknowledged. I also considered this. However, I'm becoming increasingly concerned with users find it very difficult to locate the "full controls" for the block. With the best will in the world you cannot put all controls in the block toolbar. That "one control" the user is looking for will always be the one we didn't surface there. Therefore IMHO we need inspector controls to be easier to find. Currently they are anything but... For example, working with a family member I watched them click on
...before they finally worked out that the icon that looks sort of like a sidebar actually triggers the block's full controls. This PR is an experiment for how it would feel to reintroduce such an affordance. I'm certainly I'd love to see some alternative proposals for solving this all to common UX problem. |
|
Thanks for the excellent example, @getdave! I think it's hard to say if a new icon would help in that situation. The dropdown menu item certainly didn't 😅 It would be nice to hear if the design team has any suggestions. @WordPress/gutenberg-design |
That'd be great. This PR hopes to spark a conversation because - anecdotally - this feels like a real editor painpoint. However, it'd be good to get more perspectives. |
|
Thanks for opening this, it's always fun to try experimental ideas 'in the flesh'. It might be tricky to work out the a11y story; when navigating by keyboard the toggle doesn't seem very helpful? In that respect it might make more sense if the settings panel opened as a dialog within the context of the toolbar: 
But given that settings panels can be quite long, with intricate behaviors, and may have functional overlap with tools already present in the toolbar, I'm not sure how practical this would be. I appreciate there are some blocks where the UX leans heavily on the settings panel, and that it's not initially super discoverable. But on balance it feels like an intuitive and familiar pattern once learned to me. Curious what others think about this one. |
|
Thanks James. I appreciate the feedback and your alternative suggestions.
I agree that once a UI pattern is learnt then it becomes relatively familiar. My concern is that in this case the initial learning experience is not at all intuitive. I think that an icon tucked away in the top right corner of the editor UI is not clear enough. This is further compounded by the fact that often users are looking for more advanced "Styling" controls and the Blocking Settings toggle is placed adjacent to another icon called "Styles". All too often this leads them down a rabbit hole until they discover that I really think that, even if we tick off 50% of use cases in the block toolbar, we still need to be challenging ourselves to make the discoverability of the block inspector controls sidebar easier. |
|
It would be great to see some sort of iteration like this land.
Indeed, if you close the sidebar it's quite a journey to start editing block settings again. Some other / previous / possibly related discussions: |
|
I think part of the trouble before was that with the inspector panel open the "hide more settings" felt always a bit off and weird. Perhaps the balance is to have this option in the ellipsis menu (I don't think it warrants placement in the main toolset) only when the sidebar is closed, and remove it when it's open. |
|
Personally I think putting it under the ellipses provides no benefit. It’s still hidden and still requires 3 clicks to get to settings:
Accessing block styles currently requires potentially 3 clicks:
A block settings and block styles top level toolbar item reduces all scenarios to 2 clicks. |
I'd echo this. The past behavior was curious because it was mostly a toggle button duplicated in the top toolbar. If we can restore it to the ellipsis with the goal of opening and focusing the inspector, rather than toggling, this seems good behavior. It's mainly confusing when it closes the inspector when it's open. |
|
I appreciate all the feedback here. I recognise the concerns regarding toolbar space. Unfortunately however, my primary concern remains. The block sidebar (inspector) controls are a key part of the block UI and they are not easily discoverable. With respect, I'm not convinced that adding the option to the ellipsis menu will have an impact on this because that menu itself is not obvious to all users and has a lot of options within it. It's too easy to miss the toggle. As a side quest, I'm going to try and explore a few ideas for solving this. Perhaps they can start as experiments and open them up to feedback? Things I've been considering:
Are there other options we could consider? If so please do let me know. |
|
The problem with putting it in the block toolbar is that it doesn't scale. Even now we're shipping this: |
| disableComplementaryArea( | ||
| 'core', | ||
| 'edit-post/block' | ||
| ); | ||
| } else { | ||
| enableComplementaryArea( | ||
| 'core', | ||
| 'edit-post/block' | ||
| ); |
There was a problem hiding this comment.
Noting that this clearly doesn't belong in the block editor package. However, obviously this PR is a proof of concept only. Ultimately something like this would be in editor or something.
getdave
changed the title
getdave
changed the title
The block toolbar doesn't scale, that is a problem. @jasmussen I don't think that means a toolbar item that exposes the other 75% of block settings/styles shouldn't exist.
@getdave I think this might be jarring since it will cause the page to shift and make your current inline selection (bolding text, etc) visually change position. Always worth an exploration though! |
| return ( | ||
| <> | ||
| <BlockEdit key="edit" { ...props } /> | ||
| { props.isSelected && <BlockSidebarToggle /> } | ||
| </> | ||
| ); |
There was a problem hiding this comment.
If this ever went to production we'd always need to be careful about hooking into block edit because it can cause performance degradation if not done carefully with the right conditions. In this case the toolbar item will only render for the currently selected block. We may need other conditions.
|
@getdave the block inspector is constructed as a secondary interface. We already had settings as a floating button in the past. I'd really suggest doing that first pass of at least exposing advanced settings from the ellipsis menu and then continuing to look for alternatives. The current state is not just that it's a bit hidden, it's not present at all on the block. |
|
I wonder if there might be scope for this as part of a "Edit" (Simple) mode? As there are fewer block toolbar items in that mode, we could "teach" users where the block settings are and then when they are in "Design" mode (Advanced) they could be better prepared to find the full block settings. |
What?
Tries adding a toggle in the block toolbar to allow quick access to full block settings in the block insepctor controls.
Why?
Users find it very hard to discover the full block controls in the inspector controls. We should make this a lot easier.
This is just one option.
How?
Hack in (for now) a button to toggle the block inspector controls.
Testing Instructions
Testing Instructions for Keyboard
Screenshots or screencast
Screen.Capture.on.2024-09-06.at.11-09-04.1.mp4