-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Block Settings icon doesn't do anything #1608
Comments
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 |
@jasmussen see also #1182 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 2 Thoughts? P.S. |
So, given some of the feedback on this, I've had some ideas for how to:
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. |
Oh, and CC: @folletto |
Regarding the design:
Two considerations:
If a block has no setting, can't we just hide the cog and the tab? Seems intuitive to me.
As I'm not sure what the design is trying to fix... I didn't get this impression from this discussion:
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. 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 solutionsThis is a bit tough as the cog is satisfying two different needs, which if I got correctly are:
Analyzing the two parts:
Which makes me consider that a good approach would be:
|
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".
This would have an impact also on the expected interaction with the tabs:
|
Agreed.
If we go in that direction I agree. |
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.
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. :) |
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? |
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. |
Solid, solid points. Thank you!
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? |
I mean:
|
I see two potential issues with the two buttons in the toolbar:
Question: what happens to the "Inspector" button when there are no blocks selected? Should it be disabled? |
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:
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. |
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.
The text was updated successfully, but these errors were encountered: