Style Book: Iterate on presentation and design. #53431
Comments
jameskoster
added
[Type] Enhancement
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
jasmussen
added
Needs Design Feedback
|
Thanks to beautiful work by @beafialho, I've updated this issue with designs attached. There's a lot to dive into, you can explore the linked Figma, but for now the main focus has been on updating the book itself, what's inside the frame. Especially on that, please share your thoughts. CC: @WordPress/gutenberg-design |
jasmussen
added
Needs Dev
|
I've been looking into these designs and I have a few questions and thoughts:
How are we going to define which blocks comprise this list?
How and where are we going to define this hierarchy? Blocks in the styles book are currently rendered in the order in which they are registered, if I'm not mistaken.
This might be an answer to the first question; we could add a subcategory which the Landing Page compiles blocks from. The
Demo content is mostly the placeholders for each block, currently. I think we could be taking further advantage of the |
|
Thank you for looking, @vcanales!
We'd manually curate this list according to the suggestions in the mockups.
How are we curating these? Essentially we only need a few of the blocks to be "prioritized" in a particular order, and after those, anything else can show up.
The landing page should specifically have a goal of giving you a sense of the site design. To that end, this can be thought of more like a highly curated and stylized "style card", like this:
It wouldn't need to be updated that often, in part because we don't often add new blocks, in part also because it is intentially a subset. If you want to see all the blocks, you have to dive into the tabs.
This is likely fine to separate out exactly as you suggest, and not make part of this particular task. We definitely need to enrich the demo content across the board, update the current preview images, etc. |
As discussed in the ongoing [GitHub issue #53431](#53431), the current implementation of block categories in WordPress allows for a flat structure where blocks are grouped into high-level categories such as "text," "media," "design," etc. However, as the ecosystem of blocks grows, this flat structure becomes increasingly difficult to manage and navigate, especially when dealing with more complex themes and plugins. Subcategories offer a solution by allowing blocks to be further organized within parent categories, adding valuable granularity. In this proposal, I’m suggesting an addition to the `block.json` schema that enables the use of subcategories and constrains their assignment to specific parent categories. This approach ensures a well-documented and structured categorization system, preventing misuse and maintaining consistency across blocks. \### Proposed Schema 1. **Explicit Subcategory Definitions**: Define which subcategories belong to which parent categories. This ensures that only relevant subcategories are available within a given parent category, enhancing the organization and discoverability of blocks. 2. **Schema Validation Enhancements**: Modify the JSON schema to allow references between categories and their allowed subcategories. For instance, a subcategory could reference its parent category, ensuring that only blocks that belong to a valid parent-child relationship can be categorized accordingly. 3. **Granularity in Block Organization**: By enforcing these relationships, extenders will be able to categorize blocks more precisely, making the block inserter more helpful and user-friendly. This would be particularly beneficial in large projects with numerous blocks, where the ability to filter and search based on subcategories could enhance their discoverability. \### Benefits - **Improved User Experience**: Users can more easily find and insert blocks into their content, as blocks will be categorized in a way that makes logical sense. - **Developer Control**: Developers gain more control over how their blocks are presented to users, allowing for a more curated and intentional block browsing experience. - **Consistency Across Themes and Plugins**: By standardizing how categories and subcategories are defined and used, there will be greater consistency across themes and plugins, leading to a more predictable user experience.
As discussed in the ongoing [GitHub issue #53431](#53431), the current implementation of block categories in WordPress allows for a flat structure where blocks are grouped into high-level categories such as "text," "media," "design," etc. However, as the ecosystem of blocks grows, this flat structure becomes increasingly difficult to manage and navigate, especially when dealing with more complex themes and plugins. Subcategories offer a solution by allowing blocks to be further organized within parent categories, adding valuable granularity. In this proposal, I’m suggesting an addition to the `block.json` schema that enables the use of subcategories and constrains their assignment to specific parent categories. This approach ensures a well-documented and structured categorization system, preventing misuse and maintaining consistency across blocks. \### Proposed Schema 1. **Explicit Subcategory Definitions**: Define which subcategories belong to which parent categories. This ensures that only relevant subcategories are available within a given parent category, enhancing the organization and discoverability of blocks. 2. **Schema Validation Enhancements**: Modify the JSON schema to allow references between categories and their allowed subcategories. For instance, a subcategory could reference its parent category, ensuring that only blocks that belong to a valid parent-child relationship can be categorized accordingly. 3. **Granularity in Block Organization**: By enforcing these relationships, extenders will be able to categorize blocks more precisely, making the block inserter more helpful and user-friendly. This would be particularly beneficial in large projects with numerous blocks, where the ability to filter and search based on subcategories could enhance their discoverability. \### Benefits - **Improved User Experience**: Users can more easily find and insert blocks into their content, as blocks will be categorized in a way that makes logical sense. - **Developer Control**: Developers gain more control over how their blocks are presented to users, allowing for a more curated and intentional block browsing experience. - **Consistency Across Themes and Plugins**: By standardizing how categories and subcategories are defined and used, there will be greater consistency across themes and plugins, leading to a more predictable user experience.
|
@jasmussen @beafialho this is looking wonderful. I agree we should focus an iteration on the contents and landing screen, and then revise navigation and frame, which is in need of a deeper look now that the design of the site editor has continued to evolve. |
I've started looking at reorganizing the style book categories. I'm thinking a first pass will be to refactor the way the style book displays categories and blocks, to make it flexible and easy to update, and then refine in follow ups. Most of the following points are for later, but I'm just jotting down some notes/questions: Layout category/Landing tagI gather initially, there'd be a static list of blocks or even a pattern or two to display here. It's mentioned that these will be blocks that show off the theme style. Down the line, should the theme be able to include their own? Blocks that contain other blocks / PatternsSome blocks normally live in other blocks, some are:
Not sure how it would affect navigation yet, but maybe these blocks could be displayed in mini patterns. Examples already exist for some, but others have none. Perhaps there are some custom Core patterns we could create/borrow to highlight blocks that go together, e.g., a comments pattern, to avoid displaying individual blocks just as comments next link. Custom blocks/categoriesWhat about custom categories and blocks from plugins and themes? We should append the categories to the tab list? Where there are too many categories for a single row of tabs, off-canvas category tabs could be converted into a drop down, or scroll arrows. This could be dynamic, e.g., checking for element visibility or something. By the way, what is the |
Worth here connecting dots with mockups shown here that expand on what gets shown for navigation items. Notably, it explodes the navigation item into one unit for each state, hover, focus, current, etc. That's not to necessarily to block this work, just important to keep in mind. There are some mockups that potentially affect this work too, in this Figma.
@beafialho in case you have a moment. Ramon is referring to this one. |
Nice! Thanks for cross-linking that work. I can work with reasonably little detail initially - I think it's a good opportunity to set the style book up for flexibility. By that I mean, create a component that can consume some sort of map or config, which folks can tweak to determine categories/blocks etc. And then concentrate more on the content. That's the theory anyway 😄 |
@ramonjd I'm currently seeing "Custom Link" under the Design tab:
|
Are you thinking of including this config in the block.json definition? A not-so-flexible approach I thought of was adding a |
It's the navigation link block, isn't it? |
@vcanales Thanks for the suggestion. I had the same thought, but wasn't sure if it warranted updating the block.json schema (and every block.json file) just yet when things could be hard-coded for the first iteration. I hadn't seen your PR yet however, and I think it's a good idea to allow deeper categorization in general, for example, to make things more discoverable and sortable. I haven't looked closely yet, but do you think some of the existing Core filters and other functionality would also need to be aware of sub-categories?
Oh yeah, thanks for pointing that out 🤦🏻 Custom link doesn't really mean much out of context, at least to me. |
We could get away with adding them incrementally; I think a potential subcategory attribute should remain optional.
Yes, in my proposal for the schema, subcategories would be children of an existing category, so we'd have to add this awareness.
Agreed. I don't think the block's title describes it in a way that makes it easy to find. |
Designs in this issue are created by @beafialho. Figma.
Sections
The main goal of this refresh is to better organize the blocks that make up your site into a representation of the book of style for your site. Organize into what could have been a design manual. This work includes:
This video shows a scrolled prototype of how these could work:
style_book_tabs.mp4
The landing page would be useful for the current iteration of the Site View, which does not feature tabs at all.
This landing page would also serve as a quick glancable "poster view" for the site style guide. Here is how that could look, as applied across three different themes:
Finally it would serve to have deep-links to the other tabs, e.g. clicking "Headings" would take you to the Text tab:
To afford this structure, the new categories, Color and Theme would benefit orientation. Here is a suggestion how we could reorganize existing blocks, as well as include all the site-specific blocks in those taxonomies.
Selecting blocks / sections
Here are two different suggestions for when we click each block: one similar to the current state and one that takes advantage of the labels.
Headings:
style_book_hover_2.mp4
Existing:
style_book_hover.mp4
In both cases,
currentColorwould be leveraged for the selection style.Tasks
Suggested tasks related to this:
Implement a style book landing page.
Reorganize blocks into the proposed categories.
Apply the new structure and layouts to each of the pages.
Apply the new selection style.
Additional opportunities
There are many improvements that can be made across global styles and the style book, for that reason, this issue has been focused primarily on the content inside the frame. There are a couple of additional opportunities to explore, they are likely best done separately, but mentioned here for completeness.
Invoking and browsing the Style Book
The designs include a clearer separation of content and manipulation, moving the tabs to the top toolbar:
Behavior(s) in site view
Related to invoking and browsing, there are opportunities here to review how that's meant to work in a more holistic sense. There's a larger conversation about this in #53483, where this view shows one path forward.
This recognizes that the on-canvas interactions (such as click the Quote block to style just that) as well as the tabs are not available in the Site View.
On-canvas interactions
Some blocks, like Button, have hover and active states. Other blocks, like Details and Navigation, have expanded states. How those states are visualized is likely also best explored separately.
Revisions
Side by side revisions are tracked separately in #53484, and when these are viewed the same Style Book button should invoke a side by side revisions history.
Please share your thoughts! This issue has been updated April 16th.
Previously:
Considerations:
The text was updated successfully, but these errors were encountered: