ToolsPanel: switch to plus icon when no controls present in panel body #34107
Conversation
ramonjd
added
[Type] Enhancement
|
Size Change: +93 B (0%) Total Size: 1.07 MB
ℹ️ View Unchanged
|
There was a problem hiding this comment.
It's a small change this one, but such a nice improvement @ramonjd! Looks great:
Looks like the linting CI step is failing because of prettier complaining about line length, but other than that, LGTM!
packages/components/src/tools-panel/tools-panel-header/component.js
Outdated
Show resolved
Hide resolved
Thanks for testing @andrewserong My local linter has stopped pulling me up on this for some reason pre-commit 💀
My only idea so far on how to get around this was to check the immediate children of So, in the tools-panel/hook, something like: // Checks for the existence of children that are not ToolPanelItems.
const [ hasOtherChildren, setHasOtherChildren ] = useState( false );
useEffect( () => {
const otherChildren = Children.toArray( props.children ).filter(
( { type } ) => type?.displayName !== 'ToolsPanelItem'
);
setHasOtherChildren( otherChildren.length > 0 );
}, [ props.children ] );which we'd add to context and access in the tools header to make our decision. Needs some more testing, so not sure whether it should be part of this PR or not. |
Good question! The fallback behaviour of displaying the three dots if there are non panel item children might not be too bad... unless it gets tripped up once the SlotFill is added, in which case it might be that the plus icon never gets shown (if the Slot gets counted) 🤔 I think because the fallback behaviour is to show the three dots (like we do currently), I'd personally lean toward going with this and tweaking in follow-ups as we encounter issues. But happy to go either way — apologies for the early/eager review if you want to take a bit longer to explore your options! 😀 |
Not at all! Very glad for the feedback. 🙏 |
There was a problem hiding this comment.
Thanks for putting this together @ramonjd.
These sorts of improvements definitely help polish the component ✨
All in all, this tested well for me.
✅ Displays plus icon when its initial state is empty
✅ Dots icon displays when its initial state contains visible controls
✅ Icon correctly updates when controls are toggled on/off
The new plus icon looks good. At first, I wasn't sure how it might play when all the controls in the ToolsPanel have been toggled off and the user wants to "reset all". In this situation, the "reset all" option would only make a difference if it meant restoring the display of default controls. In that instance, those controls are "added" back into the panel, so the plus icon still makes some sense.
My only idea so far on how to get around this was to check the immediate children of for components that are not of type ToolsPanelItem (and therefore not registered to appear in the header toolbar).
This approach while helpful could also be a bit brittle. The ToolsPanelItem sub-component and the ToolsPanel's menu were built in such a way that a ToolsPanelItem could be wrapped or grouped in another component. This might make the check for "not of type ToolsPanelItem a little complicated.
If pursuing this we probably need to ensure we can eliminate false positives from cases such as:
const WrappedItem = ( props ) => {
return (
<div>
<ToolsPanelItem { ...props }>
<div>Just to be difficult.</div>
</ToolsPanelItem>
</div>
);
};
const GroupedItems = () => {
return (
<>
<ToolsPanelItem>
<div>Grouped control</div>
</ToolsPanelItem>
<ToolsPanelItem>
<div>Alt grouped control</div>
</ToolsPanelItem>
</>
);
};
It's hard to see a case where a control would be added to the panel that isn't within the menu. We might add things such as help text or contrast checkers but I'm not sure that would remove the benefit of having the plus icon to encourage the user to explore the more advanced settings available through the menu.
I'll be interested to hear the thoughts of more seasoned UI gurus.
There was a problem hiding this comment.
I've tested this and it works as expected. I think the plus icon only when no items have been selected or are present by default is a good approach.
I think @shaunandrews might want to chime in here since he designed something with the plus menu present all of the time. Personally I'm not sure about this because it means hitting a plus button when removing/unchecking an item -- which seems strange.
There was a problem hiding this comment.
This looks good and tests well for me :)
unless it gets tripped up once the SlotFill is added, in which case it might be that the plus icon never gets shown
Just echoing this -- it looks like this might be the case? If so, I think the plus icon would never get shown for the Dimensions panel once #34063 is merged 🤔 Depending on how likely that is to land soon, maybe that changes the priority of handling the edge case. Particularly if the SlotFill isn't added to all panels, it would be odd for them to behave differently.
Otherwise, falling back to the three dots seems fine to me.
|
I tried a bunch of different icons. It might sound strange, but I almost think we could keep the chevron icon:
But I think it might be really confusing to use the same icon as the accordion, but open a menu instead. Though, to be fair, we use the chevron icon in many places to indicate a menu. -- I did suggest to @apeatling that we might consider using the same icon regardless of the presence of tools. I did try having the icon change once a tool was added, but I found myself looking at a strange pattern of icons (vertical dots, , cross, horizontal dots, plus, arrow) down the right side of my browser, which felt visually unpleasant.
-- When there are no tools present, I think the menu should omit the "Reset all" option:
|
|
Thanks for the feedback everyone!
Thanks for pointing this out. I haven't tested it on top of #34063 (if that's the direction we're taking with slots). I'll check it out and see if we can handle it. My opinion is that this UI change is a nice to have, so I don't there's harm holding off until the ground is stable.
Thanks for confirming. I admit, it was a fairly shallow assessment. Looking at the ToolsPanels tests reveals more to me how it's intended to work. I agree that we should be trying to help the user as much as we can to uncover hidden controls. The plus symbol to me is probably the least intrusive and least elaborate way to achieve this. Given the small footprint of this PR, I'd be fine with merging it and then monitoring the discussion surrounding slotfills. I'll get around to testing this on top of that branch at least soon.
I agree with this observation. I think icon changes might make more sense, or rather, testing icon changes makes more sense, after we migrate more of the block supports over to the ToolsPanel. It's probably just me , but the ⚙️ symbol speaks more to me than a vertical ellipsis, but my primate brain will try to click on anything so the outcome is the same. I suppose users won't spend too much time worrying about the content of the icon before their synapses conspire to compel the finger/hand to click on it. |
ramonjd
force-pushed
the
add/tools-panel-plus-icon
branch
from
d1b14ec to
4ff352e
Compare
|
Holding off until the changes in ToolsPanel: Refine component behaviour #34530 are finalized |
|
The PRs previously blocking this have been merged:
This will need a rebase. While it's being updated, would it be a good idea to add a new example to the component's storybook entry demoing the panel in an initially empty state? |
ramonjd
force-pushed
the
add/tools-panel-plus-icon
branch
from
4ff352e to
ce321f2
Compare
Done! Thank you! I've also tweaked the logic to only take into account optional menuItems, since I couldn't think of a better way to apply the original intent behind this PR to the new UX. I had plans to create tests for the ToolsPanel hook, but ran out of time today.
Definitely, thanks for the idea. I did notice that the default story already displayed the plus icon, since the min-height isn't shown by default (and therefore optional)
So I made them all display by default, and created a story specifically to showcase the plus icon. The default now looks like this: And the new story:
What do you think? I'm happy to revert it since the default story demonstrated the plus icon anyway. |
There was a problem hiding this comment.
I had plans to create tests for the ToolsPanel hook, but ran out of time today.
This would be great. I was also thinking about having unit tests that interact with the ToolsPanel component, showing/hiding optional items and checking that the expected icon is being shown.
About the Storybook examples — what if we kept the "Minimum height" panel in the "Default" story as optional, but we made it visible (if that's even possible)? This should still hide the plus icon on the first initial render, but it will make for a more complete example (since this is the default one). Hopefully I'm making sense 😅
Also, another thing that I find useful when browsing Storybook examples is if the text in the examples describes what is being showcased. For example, the label props for each ToolsPanel and ToolsPanelItem component could read something like this:
Just a thought, though :)
|
Thanks for reviewing @ciampo !
This was a late night copy 🍝 . Thanks for catching that one!
True, I looked briefly at the DOM nodes generated and I couldn't find a neat react testing library hook (role, text etc) to check the icon toggling states unless I update the Therefore I thought I'd start with the hooks before making a mess of the component tests. I'm not an expert in React Testing Library so if there are any tricks folks would like to share, I'm ready to learn! Now I think about it, might not be a bad idea to adjust the label, at least to make it more descriptive. Currently the
So maybe something like I'm very certain others can come up with better labels than that! I'm just proposing the toggling of labels. 😆 |
I get it! This is a good idea, thanks. I suppose it might require sending a flag to the ToolsHeader (maybe). I'm not sure yet, but I'll check it out. Update: I'm not sure about this. The DropDownMenu has no prop to toggle initial visibility (as far as I can see), and I can't find anything useful in the StoryBook API either, though I only looked for a minute or two so it might not count for much :) |
ramonjd
force-pushed
the
add/tools-panel-plus-icon
branch
from
2b28194 to
2984e40
Compare
|
@aaronrobertshaw I think this one is ready for a final review. Personally I don't think it's so invasive a change, and it's one we can easily roll back. Nevertheless, I understand that there we are still working out the ToolsPanel UX and this could introduce an undesirable variable. cc @mtias @shaunandrews for any final thoughts and preferences. |
There was a problem hiding this comment.
Thanks for keeping this one up-to-date @ramonjd 👍
The new ToolsPanel menu icon works as advertised for me.
✅ Tested via storybook, block editor and global styles
✅ ToolsPanel unit tests and type checking are all passing
I have a few minor comments or tweaks I think might be good to address.
Then I think this is good to merge as you suggested. I don't believe it will interfere with anything around updating the ToolsPanel UX.
Thanks also for your patience on this one, I appreciate it's been delayed a few times because of other ongoing work to the `ToolsPanel. 🙇
…con to a plus symbol. This is to indicate to the user that they can add controls to the panel.
… plus icon in the ToolsPanel header. Updated stories.
…tional items are available at all *and* if so, are they hidden
… button to describe the element and its intended effects. Added component tests.
Updating tests
…roperty to the ToolsPanelContext type Modified default value of areAllOptionalControlsHidden and updated comments
Co-authored-by: Aaron Robertshaw <60436221+aaronrobertshaw@users.noreply.github.com>
…anel header icon toggle in isolation from the other tests.
Co-authored-by: Aaron Robertshaw <60436221+aaronrobertshaw@users.noreply.github.com>
…r the state var `areAllOptionalControlsHidden`
ramonjd
force-pushed
the
add/tools-panel-plus-icon
branch
from
bc25e76 to
75e37a3
Compare
|
Thanks again for giving it the expert eye @aaronrobertshaw I've implemented the comment changes – much clearer thank you – and have addressed the rebase anomalies 😇
I think I just need an official tick or a dismissal of your last change request (I can't do it at my end) to be able to merge. Cheers! |
|
I've given this a fresh test. Everything looks good to me 👍 I'll leave the honours to you |
Depends on: #34530
Today we're swapping the ellipsis icon with a plus symbol when there are no selected controls within a ToolsPanel.
The original suggestion. Thank you!
The motivation is to provide a hint to users that they can add optional controls to the panel.
"Optional" controls – introduced in #34530 – are those not displayed by default, and whose visibility may be toggled.
Some known edge cases/considerations:
Several ToolsPanels will therefore look something like this:
Testing
aria-labelfor both button states. They should reflect the label prop passed down to the dropdown component.Run
npm run test-unit packages/components/src/tools-panel/test/index.jsfor glory!Screenshots
double-plus.mp4
New view in storybook:
What this PR does
Types of changes
UI: Adding an icon to the ToolsPanel header.
Checklist:
*.native.jsfiles for terms that need renaming or removal).