-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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 inspector: Add pointer to indicate the change. #47410
Comments
Thank you for adding this signpost for users, it's going to be appreciated. Users may not immediately figure out where the referenced Settings tab is. Could we add an additional line like:
Or whatever term is standard to account for touch devices as well. |
Yep, good note. I think it might still make sense, because if you're looking for something specific, you might first be looking through all those controls and scroll, then when you get to the bottom you see the message. Maybe fine? |
@jasmussen This looks quite a lot like a notice and serves a similar purpose: Maybe that component can be used for this? It could have a different 'status'. |
It does feel like the same notice, yes, but perhaps not entirely. Notices when used above the editor canvas in the editor are visually somewhat out of date and could look similar to this or snackbars, and I think there's an open question on whether we need them at all. Probably? But if we do need them, it does put some limitations on what we can do with the design, unless we have a variant that looks entirely different. Mostly, we should avoid an orange notice in the inspector. Not sure whether that's best done as a notice variant or otherwise. But to be fair, it really would be nice to update the appearance of notices — for contrast warnings etc. There's no reason they couldn't look like this. |
@jasmussen With the switch to having "Settings" as the default tab #47575 (for blocks that have settings) do you still think this is necessary — but swapped context-wise to render on the Settings tab, pointing out the appearance tab? Note: This pointer should only render if the tabs are available, as with #47463 done - we don't always have them. |
The text would have to change, because you might then be wondering, "where did my font size go"? I don't think this is an urgent thing, and if we find it to not be necessary, all the better 👍 👍 |
Probably one consideration for refactoring notices is whether the gray background color has enough contrast for a wide array of use cases. That may be the reason the other notices have a stronger contrast. Especially given that plugins would be using that component in a wp-admin type UI, which has a very similar shade of gray as its background. I see there are a couple of other 'pointer' issues (#47583, #47656), so it'll be interesting to see how the design for those works, and whether there's consistency. |
Having had a singular inspector for a while, the split into settings and styles is likely going to take a little bit of re-learning. We can mitigate that with a pointer:
This would be a dismissible first-run message shown at the bottom of the default Styles tab.
Note: It's important this pointer is built as a reusable component to potentially be leveraged elsewhere for similar informative purposes. As such it would be a generic interface not tied specifically to the split inspector, even if that would be where we use it first.
The text was updated successfully, but these errors were encountered: