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

Split block tools between "settings" and "appearance" #40204

Closed
mtias opened this issue Apr 9, 2022 · 22 comments · Fixed by #45005
Closed

Split block tools between "settings" and "appearance" #40204

mtias opened this issue Apr 9, 2022 · 22 comments · Fixed by #45005
Assignees
Labels
[Feature] Block API API that allows to express the block paradigm. [Feature] Blocks Overall functionality of blocks [Feature] Design Tools Tools that impact the appearance of blocks both to expand the number of tools and improve the experi Needs User Documentation Needs new user documentation

Comments

@mtias
Copy link
Member

mtias commented Apr 9, 2022

We've discussed this as far back as 5.0, but it was not yet the right time to explore. Now that we have tools more clearly delineated, it's a good time to start looking at how we can split the block inspector between settings and appearance — appearance would generally be all the common block tools registered through supports, and setting would generally be block specific tools. The earliest mockups we had used a tabbed interface for this. There are some other considerations to discuss, including attribute types and UI slots for registering controls. We should assume by default <InspectorControls> are of role "settings".

Mockup:

Tabbed inspector

See also: #42257, which could benefit from this.

@mtias mtias added [Feature] Block API API that allows to express the block paradigm. [Feature] Blocks Overall functionality of blocks Needs Design Needs design efforts. [Feature] Design Tools Tools that impact the appearance of blocks both to expand the number of tools and improve the experi labels Apr 9, 2022
@jasmussen

This comment was marked as outdated.

@jameskoster
Copy link
Contributor

This looks like a great starting point to me, but there's something about the nested tabs that feel a bit awkward. Maybe it's just because the settings/appearance tabs seem 'heavier' than the post/block ones, and that's throwing the hierarchy off a bit?

Some more 'out there' ideas that are probably terrible, but I share just in case they inspire anything better:

Settings only

Could we say the inspector only handles settings, and put access to the appearance panels in the toolbar?

Screenshot 2022-04-13 at 11 05 13

This would reduce reliance on the Inspector which could be good, but the appearance panels would need to be movable which complicates things.

Drilldowns

Remove the post/block tabs and utilise the drilldown pattern from global styles.

inspector

We might do the same thing in the block inspector – emphasise appearance options and put settings in a drilldown.

Figma prototype here.

Split document / block settings into different UI regions

In the site editor, template details are accessed in the top bar, we might do the same thing in the post editor freeing up the Inspector to concentrate solely on blocks.

Screenshot 2022-04-13 at 11 32 31

@ZebulanStanphill
Copy link
Member

In my opinion, it has always felt inconsistent and confusing that all plugin sidebars are separate in the top toolbar, but the document settings and block inspector share a sidebar. So I'm all for splitting the document and block sidebars, though I'm not sure where to place the former.

Perhaps just have two buttons instead of the current single cog next to the Publish button? Or maybe the middle of the top toolbar is the place to put it after all (as seen in the prior comment's mockup); my main concern with that design is how it is not clear that the post title in the toolbar is the point to access the settings. I know there's been some accessibility concerns about various buttons lacking descriptive labels.

Back to the main point of this issue, I totally agree that we should split design options from more block-specific settings. Divi Builder does this, and it really helps with organizing the very large number of options in its modules.

@jameskoster
Copy link
Contributor

Or maybe the middle of the top toolbar is the place to put it after all

On balance I think this could be the way to go. There's a lot of context in #27093, but in short:

  • Displaying the title on the canvas can be confusing (it cannot be styled, doesn't always appear in the same location – or at all – on the frontend).
  • We already do something similar for templates in the site editor / template editor.
  • It's fairly common to see the filename top-center in edit apps, e.g. TextEdit:

Screenshot 2022-05-10 at 10 36 27

Plus it means we can eliminate the awkward nested tab situation that could arise when we close this issue.

Also related: #39082

@shaunandrews
Copy link
Contributor

Rather than having multiple, nested tabs, or a complex drill-down, perhaps a segmented control would work better:

image

@jameskoster
Copy link
Contributor

Yup that could work too. The only slight drawback is that we use the SegmentedControl elsewhere as a selection tool:

Screenshot 2022-05-10 at 15 24 34

@SaxonF
Copy link
Contributor

SaxonF commented May 11, 2022

Tabs feel like the right pattern here but agree nesting looks weird. What about converting post/block tabs into breadcrumbs to better show the parent->child relationship, with "post" being the top level "block".

Could also play with typography treatment and input stroke colour to try and reduce competing elements.

image

Dark mode
image

@jameskoster
Copy link
Contributor

At a glance the breadcrumb pattern looks great, but I worry about the scalability. In the template editing context you'll mostly be seeing Template / ... / Selected block which reduces the value quite a bit.

I do appreciate how much lighter the interface appears when you reduce the stroke on active tabs, and use icons instead of full labels.

@SaxonF
Copy link
Contributor

SaxonF commented May 11, 2022

I don't like this as I don't think its visible enough but worth dropping here in case it inspires other approaches

image

@jasmussen
Copy link
Contributor

For folks subscribed to this ticket, I added a mockup to the main issue with a baseline tab interface that we can build. Whether that needs to evolve into a segmented control or otherwise, this can be explored separately.

@mtias mtias mentioned this issue Oct 7, 2022
57 tasks
@aaronrobertshaw
Copy link
Contributor

Thanks for adding the mockup.

I'd like to take this one on, as it touches on some areas I've had a little experience in Gutenberg. Namely, block supports and our InspectorControls slots. Happy to collab with others as well 🙂

@aaronrobertshaw aaronrobertshaw self-assigned this Oct 11, 2022
@mtias
Copy link
Member Author

mtias commented Oct 11, 2022

I think this might take a few iterations to get right, so we should consider enabling it as a feature flag until we square all the dependencies (UI, block API, extensibility, etc).

@mtias
Copy link
Member Author

mtias commented Oct 12, 2022

@jameskoster @SaxonF can we try a design that includes the three tabs (list, settings, styles) but uses the icons?

@jameskoster
Copy link
Contributor

Purely using our existing components:

Screenshot 2022-10-12 at 14 24 09

There's some tension between the block icon and the tabs, which would be solved by simply removing it.

Screenshot 2022-10-12 at 14 28 16

The icon to use for settings is also a bit contentious. The one above is used for "custom" elsewhere so doesn't feel like a perfect fit. The cog feels more natural, but obviously we use that to toggle the Inspector itself so it might be a bit awkward.

@mtias
Copy link
Member Author

mtias commented Oct 12, 2022

I think we should try using the panel icon instead of the top level cog, and use the cog for the settings tab.

image

@jameskoster
Copy link
Contributor

Yup, that could work.

Screenshot 2022-10-12 at 17 25 28

@jasmussen
Copy link
Contributor

Perhaps nitpick territory — should the sidebar icon be flipped horizontally?

@jameskoster
Copy link
Contributor

Yup, we should probably have both versions of the icon so the button can flip based on locale (rtl/ltr).

There may be other applications where we need the inverse as well such as #28745.

@aaronrobertshaw
Copy link
Contributor

Can someone point me in the direction of the panel icon via a figma link or supply the SVG etc so I might add it to the icons package?

@jasmussen
Copy link
Contributor

Sure, here's drawer-right:

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" style="enable-background:new 0 0 24 24" xml:space="preserve"><path d="M18 4H6c-1.1 0-2 .9-2 2v12c0 1.1.9 2 2 2h12c1.1 0 2-.9 2-2V6c0-1.1-.9-2-2-2zm-4 14.5H6c-.3 0-.5-.2-.5-.5V6c0-.3.2-.5.5-.5h8v13zm4.5-.5c0 .3-.2.5-.5.5h-2.5v-13H18c.3 0 .5.2.5.5v12z" style="fill-rule:evenodd;clip-rule:evenodd;fill:#1e1e1e"/></svg>

drawer-left:

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24" style="enable-background:new 0 0 24 24" xml:space="preserve"><path d="M18 4H6c-1.1 0-2 .9-2 2v12c0 1.1.9 2 2 2h12c1.1 0 2-.9 2-2V6c0-1.1-.9-2-2-2zM8.5 18.5H6c-.3 0-.5-.2-.5-.5V6c0-.3.2-.5.5-.5h2.5v13zm10-.5c0 .3-.2.5-.5.5h-8v-13h8c.3 0 .5.2.5.5v12z" style="fill-rule:evenodd;clip-rule:evenodd;fill:#1e1e1e"/></svg>

Screenshot 2022-10-14 at 09 56 25

@jameskoster
Copy link
Contributor

Remember to remove the fill:#1e1e1e part 😁

@aaronrobertshaw
Copy link
Contributor

Proof of concept PR is up in #45005.

@priethor priethor removed the Needs Dev Ready for, and needs developer efforts label Nov 2, 2022
@bph bph added the Needs User Documentation Needs new user documentation label Dec 15, 2022
@priethor priethor removed the [Status] In Progress Tracking issues with work in progress label May 22, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Block API API that allows to express the block paradigm. [Feature] Blocks Overall functionality of blocks [Feature] Design Tools Tools that impact the appearance of blocks both to expand the number of tools and improve the experi Needs User Documentation Needs new user documentation
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

9 participants