Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upGitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
Connecting patterns with specific contexts & transforms #27575
Comments
|
Big fan. While reducing the complexity of interfacing with a single block is noble, ongoing, and should continue until it's as easy as can be, there are some blocks that will just be intrinsically harder to configure. Patterns provide a massive shortcut there, and any way we can surface that more will benefit the whole ecosystem. Surfacing related patterns in the placeholder/setup state of a block seems like a no-brainer. Though it's important to keep in mind that what constitutes a setup state is evolving, with a most recent example being the Navigation Block. That's just to say that the way we surface patterns should be able to collapse from a palette of thumbnails into potentially a dropdown menu. A la this — unselected:
Selected:
The mockup looks like the right place to do this (potentially with redundant UI present in the sidebar as well?), so as far as transforming from an already configured block into a related pattern, I suspect the challenge is largely technical. But even if the transformation is destructive, I think it would be worth it because we have visible undo buttons with prime real estate. A comparison to how you can change slide templates in Keynote definitely suggests it's a non issue:
Finally, I would love to see this UI potentially also absorbing this sidebar control:
That interface exists mostly for technical reasons (so the mover control can shift directions depending on vertical or horizontal blocks), but the interface is not very good. If aspects of that transformation could be absorbed into this, the unification of the controls next to regular block transforms would be a big step up. |
Some of the blocks being created for block themes are inherently complex to set up (Query being a prime example). Simplified interfaces are going to be offered through variations (like Posts List for Query) but it still stands to reason that in many cases starting from patterns will be a better user experience overall. Semantic template parts (#27337) are a case that would benefit from a stronger tie with patterns, allowing not just listing them as a design start but also the possibility of swapping them out quickly.
My proposal then is to explore defining an API where a block could be tied to one or more pattern categories, broadly speaking. Blocks connected with patterns could then surface them in the main transforms menu; the sidebar inspector; or other interface elements we build in the future:
Blocks that have placeholder states could surface connected patterns (needs some design explorations) similar to how variations are currently exposed. That might also allow themes to connect their own registered patterns with the block interface — so when a user inserts a group, or a column, they could get fast access to a subset of the patterns a theme registered using those blocks in a contextually rich area.
Defining the API
I believe it to be important to keep this API fairly simple for the benefit of integration and transformations. For example, we could do something like this on the block registration surface:
We should try to avoid too much introspection, though given the relationship is a loose one, we might need to validate the root block type of a pattern before allowing it to show up, etc (i.e. should a "quote" be allowed to be transformed into a "heading" if the heading was registered as a pattern on a "quote" category?). In more complex patterns with nested blocks (where a block might not have a counterpart in the target pattern) we'll need to decide on some behaviours upon transformation.
There's an angle to discuss where any pattern category matching a block name could be implicitly allowed to be listed, though I think this is better modeled as an explicit block opt-in, hence the
patterns: []proposal.This proposal can be visualized as a window into the pattern inserter from a specific block context, taking advantage of transform mechanisms when possible, and more broadly connecting our two main content insertion flows.