Sidebar Controls & Component System #27331
Comments
mtias
added
[Feature] Design Tools
|
Thank you @mtias , @jameskoster, @jasmussen, and @pablohoneyhoney ! Addressing these issues is at the heart of the "G2 Components" project. It provides the architecture, systems, and code that embody the spirit of streamlining and elevating the UI experience within Gutenberg and WordPress 🙏 . I have a handful of coded prototypes that showcase some of the designs mentioned above. Typography Tools Prototype I have another prototypes that provides a peek the Components / Design Systems aspects of this initiative. Input Prototypes Note: At the bottom (left), there's a handful of controls that allow you to try out various modes and themes - features that are supported from the core Style System. 🧬 Integrating the new Component SystemIntegrating into Gutenberg gracefully with minimal disruption was an absolute requirement from the beginning (along with other "must haves"). Once G2 Components matured, and we felt confident with the architecture and direction, we started planning and preparing for integration. I recognize that there's a lot when it comes to G2 Components. You can find the code in the G2 Components Github repo. Lastly, I've been doing live design/code (almost daily) sessions on Twitch. There, I often walk through parts of the system, explain design decisions, and answer any questions that come in from the chat. ❤️ |
|
In case anybody would like to play with these designs in Figma, I added the components we worked on to the WordPress Design Library as proposals. |
|
Just to clarify, would this let the Drop Cap option still have its own panel / color options, but just have them be consistent with other available options? I think that would be nice and would resolve this request as well as another I spotted while searching for this conversation. |
|
More customization settings for the drop cap would be a separate ticket. I like what Apple Pages is doing with them:
|
|
There's an updated overview issue focused on global styles that expands on this one to further detail: #34574. |
|
This has been largely put into practice through |
The first half of this year brought some needed updates to the design language of blocks, with a strong focus on improving the block footprint, toolbar system, and the inserters. (See #18667, #21080.) Now it’s time to revise the state of block controls primarily used in the sidebar and its underlying component set. This is the next widest topic for the evolving design language.
Kudos to @ItsJonQ @jameskoster @jasmussen @pablohoneyhoney for helping put this overview together.
The sidebar — while secondary in some regards to the block canvas and toolbar — still provides essential tools for interacting with blocks. They also compose the majority of what has been named WordPress Components which also allow building front-end interfaces beyond blocks. As such, the sidebar has grown to accommodate all sorts of controls and design tools...
Most of these elements have grown organically as the block and usability demands increased, going through multiple iterations and isolated refinements. The combination of different component primitives (buttons, selects, sliders, and so on) has also allowed third party blocks to build all sorts of tools. However, it has also resulted in a somewhat disorganized and not always consistent use of patterns which end up hindering usability. (See #26976, #26001.)
Two ongoing core projects (Global Styles and Design Tools) are increasingly demanding more order and design attention to these controls to improve its usability, grouping, hierarchy, and overall design. It’s no longer sufficient to do it piecemeal like with gradient tools (#21269) and cannot be done just in the context of global styles — it is also important to consider these sidebar controls as they scale and adapt cohesively to other realities of the editor.
Block Controls
Looking at the current state of global styles design, it is quite evident that what has emerged so far results in a somewhat convoluted amount of interface disparities and behaviors. Following the footsteps of the block interface, this issue aims to work on its underlying elements and its composition to help the design evolve more coherently. We have enough material now to also focus on the clarity of actions for each typology of control, given more clear hierarchies and expectations, and its impact on a refined set of interface components. (Of note, the different interfaces for resetting controls as a good example of disorganized growth.)
Related: #27295, #16479.
Typography tools, concretely, have been expanding with different blocks requiring a slightly different subset (with or without line height, with or without font weight, etc). These groups of controls need flexibility and clarity. Both themes and blocks need to be able to specify which elements are configurable by the user and the interface needs to be able to accommodate different configurations in a pleasing and consistent manner.
That means there are two complementary goals with this effort: an improved design system and more functional control typologies that neatly organize the complexity of information and actions. We can start with some of the basic and most recurrent panels that can provide a baseline for others.
Typography
The block editor initially supported custom font sizes alone. At the current moment, typography tools include presets, custom sizes, line-height, font-weight, custom units, etc. These tools need to be designed together to provide the right amount of emphasis and order. (See #23767, #26060, #26844, #23908.)
Reusable text styles can be defined in the theme scope (or global styles) and then applied to any block that includes the typography panel. This flexible system will allow users to manage the majority of the typographical rules at a site in the same place, and wholesale changes can be applied with speed and efficiency. Interacting with any block’s typography setting will be more intuitive.
Text styles act as presets for the individual typography controls and so can be as simple or complex as needed. Detaching a text style on a per-block basis for a one-off treatment is as simple as changing a value.
Of note, the ellipsis button reveals a menu of per-control toggles for the typography panel. This affordance allows blocks to show or hide only the most appropriate controls as a default, and for users to exercise more specific typographical designs in just a couple of clicks. This also prevents the interface to grow uncontrollably as the included tools expand.
For example, a Paragraph block may only expose the size control initially, but if a user needs to change the font as well (and this is allowed in the theme.json configuration), that would be possible without overwhelming the majority of users. In reverse it works the same way – removing a control unsets it, and the block will inherit the appropriate value from the theme and global styles.
This should then be both highly configurable and adaptable. To summarize, the following needs emerge:
Colors
Related: #24049, #19785, #8171.
The next panel to focus on are color tools. This is another example of a group of tools that has evolved naturally as the editor began supporting solids and then expanded to include palettes, custom picker, and gradients. It’s widely used by core blocks and third party blocks, which can register color settings for more than one element — with text and background being the most prevalent options. That means we need to accommodate the color tools themselves as well as clearly communicate what they apply to.
Color palettes is another important dimension, which allows themes or site managers to define an explicit color palette and lock down custom colors if desired. One challenge that has emerged is the need to allow theme color to be in addition to rather than in replacement of the default color palette. With global styles also allowing user configurable palettes, it’s important the design accommodates multiple palettes as needed.
The color tools are highly idiosyncratic in their function, which is a good test case for the design language to cover.
Dimensions
The tools to configure the spacing of a block are among some of the most incoherent tools we offer, with controls usually scattered across different panels and standalone tools. (See #23770, #24874, #26368, #22956, #14747.)
The proposed dimensions panel emerges as the consolidation of controls relating to the space a block occupies on the page. This includes but is not exhausted by height, padding, width, possibly alignment, and so on. Much like the typography panel, these controls are not always going to be present for every block, so it’s important individual controls can be toggled on and off as required, and that blocks can expose those that are considered default options based on configuration. The focus in this exercise is to test how the different controls ought to be laid out.
Component System
Related #24341.
These three cases are a catalyst for rehearsing and expanding the emerging WordPress component system and its design. No systems can be done in a vacuum, so it’s important to develop a robust feedback loop between the demands of the application and its design consolidation. There will be a separate issue outlining how we could continue to improve on the tools in a backwards compatible way while introducing higher-level APIs for block authors to rely upon instead of needing to use the primitives themselves. This effort of higher level component APIs has been quite successful with the block toolbar, offering both ease of use, good dev experience, consistent behaviours and a higher accessibility floor.
The design showcased here is a work in progress and very much open to feedback.
The text was updated successfully, but these errors were encountered: