Block Settings icon doesn't do anything

[shaunandrews]

I see there's a gear icon available when I focus on a block, but clicking it doesn't seem to actually do anything.

After a little more playing, I discovered that if I close the post settings, then this gear icon opens the settings. But if the sidebar is already visible, it doesn't do anything. I'm not sure what the solution is here, as I thinking closing the sidebar is a bad idea — but as-is, it feels broken.

[jasmussen]

The chief purpose is indeed to open the post settings inspector if closed, and set focus on it so you can tab there (and back) if need be. Would it be sufficient if we "flashed the borders" of the inspector when clicking the cog, if it's already open? CC: @afercia

[afercia]

@jasmussen see also #1182 The idea there was to try some sort of "skip links" to navigate to the sidebar and back. "Flashing" the sidebar borders could maybe help users understand what's going on, but I'm not sure giving the "cog" icon a double functionality (open and move focus to) would be ideal. Mouse users could find this a bit confusing (I've already seen a couple of reports).

The "cog" icon is pretty common today, we've learned it on our phones :) to me, it's just about "open" and "close" some settings. @shaunandrews not sure why closing the sidebar seems a bad idea to you, do you feel it would be unexpected? Please share your thoughts, when you have a chance.

I can think of just two options:

1 Clicking the cog opens and moves focus to the sidebar. How to make this visually clear? Also, moving focus to the sidebar might not always be what users want.

2 Make things more explicit: one control, one action. Maybe consider to add a visually hidden "skip link" that gets revealed on focus. It would be available to keyboard and screen reader users. This way, the "cog" would just open/close the sidebar. Pressing Tab, would reveal the skip link. This would leave the choice to users, but the extra Tab could be hard to discover.

Thoughts?

P.S. The cog aria-label="Show inspector" should be changed to something more understandable for users :)

[jasmussen]

So, given some of the feedback on this, I've had some ideas for how to:

• Fix the confusion where selecting the block immediately replaces the sidebar
• Fix the confusion where the sidebar is open, and "clicking the cog does nothing"
• Keep the benefit of having the sidebar be able to hold advanced actions and live-previewing changes in the body content (as opposed to having it be a floating modal that might cover content)

Here are some early mockups at a "rjigger", partly inspired by discussions with @GaryJones and @mtias.

Basically, we have a single sidebar, called "Settings". By default it shows post settings. Even when you select a block.

There's a tabbar at the top, though, and clicking it switches to showing block settings. The cog would also invoke this tab.

Alternate tabbar design:

The question becomes: what happens when you manually click the block tab, but a block has no settings? The best idea I can think of right now is that a block always has block settings. The least it can have is help text.

[jasmussen]

Oh, and CC: @folletto

[folletto]

Regarding the design:

1. I think that approach is solid... as similar to the one I proposed in Parrot. :D
2. I think the tabs at the top add clarity to the fact the sidebar allows changing both blocks and general settings, as well as it makes it more modular for future use in the future, if needed.
3. Style wise, I'd go for the blue underline option, as it's crisper.

Two considerations:

The question becomes: what happens when you manually click the block tab, but a block has no settings?

If a block has no setting, can't we just hide the cog and the tab? Seems intuitive to me.

Basically, we have a single sidebar, called "Settings". By default it shows post settings. Even when you select a block.

As I'm not sure what the design is trying to fix... I didn't get this impression from this discussion:

Fix the confusion where selecting the block immediately replaces the sidebar

If I select a block, it's important that the sidebar switches to its configuration if it's open. I think it's one of the most important interactions here, and I'd be very concerned in removing it. Maybe I'm over-worrying tho, so we could prototype and see how it works.

I cross-checked Keynote for reference, and they do the same: clicking always activates the block view. Similar to how the top toolbar controls change on Adobe and other softwares.

---

Brainstorming solutions

This is a bit tough as the cog is satisfying two different needs, which if I got correctly are:

• Mouse condition: open the sidebar if it's closed.
• Keyboard condition: jump to sidebar without having to tab all the way back.

Analyzing the two parts:

• If we had mouse-only, the cog wouldn't be needed at all: selecting the block already activates the panel, and if the sidebar is closed, the toggle to open it is just there always visible — and with a clear label, which the cog misses! In this scenario I wouldn't add any control to the block: the block being selected is the automatic and strong toggle.
• If we had keyboard-only, we need a way to open the sidebar without tabbing all the way back. Which means that we need to be "close by" the block, and similarly we need to have it discoverable. In this scenario, it seems to me it could be as @afercia mentioned: if the end of the block is reached, tabbing selects a settings icon+label that appears only on keyboard focus and then further tab goes on delete. It's discoverable.

Which makes me consider that a good approach would be:

1. No cog by default.
2. If get tabbed to, show it and allow it to jump to block settings.
3. If it's not there already, we should also consider a keyboard shortcut that moves focus there regardless of the position in the flow.

[afercia]

Worth noting that, at the moment, when the sidebar is closed, selecting a block doesn't open the sidebar. To me, this seems correct because users may want to keep the sidebar closed and focus on writing.

The sidebar "tabs" are interesting :) although a different concept compared to the current "breadcrumbs".

what happens when you manually click the block tab, but a block has no settings? The best idea I can think of right now is that a block always has block settings. The least it can have is help text.

This would have an impact also on the expected interaction with the tabs:

• if there are always two tabs displayed: they should always be actionable
• if we choose to display just one tab when a block has no settings, then the single tab shouldn't be actionable and be reported just as sort of "title" of the sidebar; in other words, a single "tab" shouldn't be "clickable"

[folletto]

Worth noting that, at the moment, when the sidebar is closed, selecting a block doesn't open the sidebar. To me, this seems correct because users may want to keep the sidebar closed and focus on writing.

Agreed. It's the behaviour I'd expect too.

if we choose to display just one tab when a block has no settings, then the single tab shouldn't be actionable and be reported just as sort of "title" of the sidebar; in other words, a single "tab" shouldn't be "clickable"

If we go in that direction I agree. No visual styling changes from the normal highlighted one too.

[jasmussen]

This discussion sounds good, thanks for chiming in.

Also by the way, and I've said this in the past and will continue to say so, your Parrot concept, Davide, is a direct inspiration for the inspector work that we've done here. Thanks for the inspiration.

If a block has no setting, can't we just hide the cog and the tab? Seems intuitive to me.

What happens if you deselect the block? Does the tab hide also? If yes, and this isn't disruptive/annoying, I'd agree this seems sensible.

[folletto]

❤️

What happens if you deselect the block? Does the tab hide also? If yes, and this isn't disruptive/annoying, I'd agree this seems sensible.

There's a chance it could be annoying, yes, but I'd start building that approach as seems clearer, and we'll work from there. :)

[jasmussen]

So in effort to simplify the visuals and complexity, here's another approach that gets at the same:

Inspector icon TBD, but visually I think this one solves our problems, and I quite like it.

Here's another version:

I don't visually love that quite as much — the silhuette becomes more complex.

Thoughts?

[folletto]

Both seems nice, and feel slightly better than tabs inside the sidebar.

The pill approach however has an extra problem on top of additional visual clutter: it implies there's no "closed state" as pills usually have always at least one option selected. So I'd avoid that.

I'd highlight that even in this scenario I'd expect selecting a block to switch to the Inspector automatically.

[jasmussen]

Solid, solid points. Thank you!

I'd highlight that even in this scenario I'd expect selecting a block to switch to the Inspector automatically.

Can you clarify?

I would expect that if you have the sidebar (in this world, both sidebars) closed, and click the "advanced" cog, you'd get the block settings.

Same if you have the Post Settings sidebar open, but click the cog, you'd get the block settings.

Did you mean anything other than that?

[folletto]

I mean:

• If the sidebar is closed, one has to click on cog (but... what about the discussion above?) or the toolbar icon.
• If the sidebar is open, selecting a block automatically switches to "Inspector" view even if it's on "Settings".

[afercia]

I see two potential issues with the two buttons in the toolbar:

• they're very, very, far from the sidebar in the HTML source: ideally, UI controls that "expand" something should be placed immediately before the expandable "thing". Yes, this is true also for the current "Post settings" button in the toolbar and for the "cog". Possible options I can think off the top of my head:
  • handle focus programmatically
  • better: try to move the sidebar up in the source, before the post content (no visual change)
• the term "Inspector" doesn't help me so much, as a user 🙂 it't too technical, and what's inside the sidebar is... settings: global or per-block, but always settings

Question: what happens to the "Inspector" button when there are no blocks selected? Should it be disabled?

[jasmussen]

Really good discussion here. It's been a great way to explore the problem, and potential solutions.

With the tabs — both in editor bar, and on the sidebar itself — the problem I was trying to solve, was to make more clear the relationship between the content and the sidebar-as-metadata, and also perhaps tune the behavior where the sidebar gets "replaced" when you select a block.

However upon all this discussion, it still feels like what we have in master right now is the "cleanest", even if it isn't fully realized yet. And so before we start introducing complexity, I think we should see if a few changes can make the behavior currently in master be more predictable. So here's what I would propose we do:

• Rename "Post Settings" to "Settings". @GaryJones was right.
• Make sure clicking the cog, when the sidebar is already open, flashes the sidebar and sets focus in there (focus was already the intention, but maybe let's visually make it clearer)
• Tweak the behavior so the inspector only overlays the sidebar when a block has block settings.
• Polish the contents for when the inspector does have content, make sure there's always help text, etc.

The inspector content polish, and the focus behavior are things we know we need regardless, so this will be beneficial work, even if after trying out the above we still decide we need a change.

[jasmussen]

Closing this in favor of #2304 and #1182