Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ToolsPanel: Refining the component's behaviour #34257

Open
aaronrobertshaw opened this issue Aug 24, 2021 · 2 comments
Open

ToolsPanel: Refining the component's behaviour #34257

aaronrobertshaw opened this issue Aug 24, 2021 · 2 comments

Comments

@aaronrobertshaw
Copy link
Contributor

@aaronrobertshaw aaronrobertshaw commented Aug 24, 2021

What problem does this address?

Now that the new ToolsPanel has been merged there’s been a few questions or concerns raised about its UX.

The plan has always been to iterate on its behaviour and polish the panel ahead of 5.9. This issue aims to collect comments or feedback from across several PRs, issues or channels and help focus the discussion around what improvements we wish to make.

Issues raised to date

  1. The panel isn’t collapsible. All controls can be hidden but this means the value is also reset.
  2. The majority of people using the panel for the first time expect the menu to only toggle visibility of controls, not reset them
  3. Combining the concept of default controls along with the “reset all” menu item causes odd or unexpected behaviour. Toggling that control’s menu item results in it being hidden whereas the “reset all” doesn’t.
  4. There is no persistence for panel display between block selections e.g. If you hide padding, deselect the block, then reselect it, the padding control will be back again.

Links to feedback / comments

Related PRs

Current panel demo

ToolsPanelDemo.mp4

Questions

  • Does further adoption of the ToolsPanel for block support panels depend on refinements to be discussed in this issue?
  • Do any current explorations around improving the Post tab of the sidebar or global styles introduce any new requirements?

cc/ @jasmussen @shaunandrews @mtias @paaljoachim @ciampo

I hope you don't mind the pings on this but thought it better to cast the net wide for early thoughts and feedback.

@jasmussen
Copy link
Contributor

@jasmussen jasmussen commented Aug 24, 2021

Good ticket, thank you. Thanks for trying the current behavior.

The checkbox behavior in the ellipsis menu seems to be the primary source of confusion. Let's walk through how it could work instead:

  • If a paragraph block says font-size is visible by default then the user should not be able to make it disappear ever. I.e. a default panel should never disappear on reset so the behaviour of reappearing on reselect is unnecessary.
  • Resetting controls should have no effect on other blocks of the same type.
  • Any control the user enables (like line height) is removed when reset.
  • When an attribute is set on a block (either by user or pattern) it makes the corresponding tool appear for that block only.
  • The only case a user would be able to affect default controls across a block type is through the global styles UI, not the block inspector.
  • “Reset all” always just restores default appearance (so only default tools render)

For global styles and in the future, a user could be able to control default panels via theme.json just like themes can. In one such case, you might want to remove all controls by default on a paragraph. If you did that, the ellipsis would be replaced with a [+] icon to add controls when you need them.

One small thing as well: the ellipsis is vertical in recent global styles mockups, so we should update it here as well.

@ciampo
Copy link
Contributor

@ciampo ciampo commented Aug 24, 2021

Premise: I have only been involved in the review of the ToolsPanel PR (and not in prior conversations).

To me, the main source of confusion is that the same interaction/piece of UI causes 2 separate outcomes: "visually show/hide a control", and "reset the control's value".

A better solution may be to have two clearly separate pieces of UI: one for toggling visibility, and one for resetting values. We should then only worry about making it clear to the user when a hidden control has a non-default (ie. that has not been reset) value.

@ciampo ciampo moved this from Inbox (needs triage) 📬 to Backlog (triaged) 📝 in WordPress Components Aug 25, 2021
@ciampo ciampo moved this from Backlog (triaged) 📝 to Next 📌 (un-owned) in WordPress Components Aug 27, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
WordPress Components
Next 📌 (un-owned)
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants