A themeable and scalable primitive system

[SaxonF]

What problem does this address?

As the editor expands in what it is capable of, so too will the complexity and density of its controls. The current UI language is quite heavy which can be distracting when faced with a dense panel of settings. There is also the ever present discussion of dark mode which is on its way to becoming expected in today's software.

What is your proposed solution

Its worthwhile discussing whether there are some iterations we can make to our wp/components primitive system so that they are more suitable for dense interfaces, as well as working our towards supporting themes.

The concepts below make use of the Radix Color System which includes hand picked light and dark themes. Others have approached light and dark mode in a more programmatic way which is also worth exploring.

Early concepts which soften stroke colour, adjust spacing and typography (using Inter).

Uppercase inspector section headings like we use in global styles

Some earlier explorations around dark mode

A more expressive example

[pablohoneyhoney]

I'm not entirely sure how the above progresses what's currently up, to be honest. There are a lot of mixed details in the UI, and challenges with a11y. The breadcrumb isn't an ideal application in such a constraint space, and the compressed elements is overwhelmingly tight and make many UIs clash.

Aligning the uppercases could be a specific task to look at.

And the dark mode could be interesting too, if the community is open to it. But it has other set of challenges, like how it affects moving pieces like admin darker elements, nav sidebar, or exploded view, as you note above (it'd be better to explore it with what's in production, it's confusing to see it with foreign elements).

[SaxonF]

@pablohoneyhoney This is just the start of the conversation so of course we can iterate and explore other options. Maybe a better starting point is looking at how our editor compares against other site builders and design tools, some of which are WordPress builders.

My concern right now is that the current interface starts to break a little when we get into more granular editing capabilities such layout, typography details etc. Spacing and the weight of elements such as inputs/controls (strong stroke) are two examples that imo draw a lot of attention away from the canvas and make it hard to focus. I think there are some relatively small refinements we can make to improve that. Colours are driven by Radix so should all be accessible, both in light and dark.

Of course, this all subjective as design is :)

[SaxonF]

like how it affects moving pieces like admin darker elements, nav sidebar, or exploded view, as you note above (it'd be better to explore it with what's in production, it's confusing to see it with foreign elements).

On this point, I'm not a fan of the darker canvas elements we've introduced like the exploded view partly because they require us to use both light and dark variations of our components within the same environment. I think we can learn from how Figma handles dark mode and how it affects the default colour of the canvas.

[SaxonF]

Another little iteration.

• Capitalised headings used for sections rather than every input
• Less borders to soften interface (inputs, secondary button, menu items)
• More use of muted/secondary text colour
• 36px input height vs 40px
• [0,3,5] border radius scale

condense.mp4

[jasmussen]

Thanks for the energy. There are a few things to like here, notably the thought put into dark mode, and some of the thought put into label/allcaps systematization.

I think the layout panel revamp is worth extracting as a separate focused exploration.

I will admit that I'm not convinced about the larger changes put into the basic metrics. It's not actually clear to me that this different visual solves problems with the existing target outlined at #46734, so before we change course midstream, it seems worth really understanding what problems these solve. Some of the decisions, specifically, contradict previous decisions to focus on 32 and 40 px controls.