Proposal to rename "reusable blocks" to "synced blocks" #34352
Comments
mtias
added
Needs Design Feedback
|
I agree, "synced blocks" is much more descriptive to the end user and makes a clear distinction between this block and all other reusable patterns, templates and re-usable blocks - of which there are many! |
|
Cosign! Its much more self explanatory.
|
|
Agreed - this makes a lot more sense to me! Thanks for kicking this off. |
|
+1 to rename, I'm not absolutely convinced that 'synced' is right but it's better than reusable so 👍🏻 |
|
@mtias I like "Synced Blocks" too. However, if the discussion continues, here are a few more suggestions for the "Reusable Blocks":
If none of those options work, let me know. |
|
The term "synced" is definitely a massive improvement over the current terminology. "Reusable" is a term that could apply to almost every block you can copy-paste, and the older "shared" (remember that?) would have sounded like "sharing to the repository". "Synced" brings to mind cloud storage, which is pretty close to how the feature works. Additionally, it is something that could not be applied to standard blocks or patterns. You wouldn't say a Paragraph block is synced to any others, and in fact, the most obvious difference between reusable blocks and patterns is that the latter is explicitly not synced. |
|
Thinking of other apps |
|
I personally think that the word "synced" is a bit confusing. It makes sense when you know how these blocks work, but I don't think it really improves things for a new user. It's also kind of a tricky word on its own and is not common vernacular. What about a more general term that emphasizes that these blocks are used throughout the user's website. I am thinking something like "Global" blocks? |
I agree. For a non-specialist, this really doesn't have any meaning. I think global is an improvement. How about "site wide"? What do the major page builders call them? Because they have had them for years before Gutenberg. Aren't reusable blocks really a collection of reusable blocks? And is that collection really anything different from a widget area? I think if WordPress 5.x were to drop down from the sky brand new to us today, it would be hard to explain to someone how a widget area filled with blocks was any different from what we now call reusable blocks. Reusable blocks are really a powerful thing, but it feels like they have been poorly managed by core. |
|
|
Global blocks sounds better to me, reminds me about global variables with global scope. Synced blocks imply sincronization even for the first time of being created. Also, the word synced is too long for a lot of languages. |
|
I maintain a reference page to explain the multiple block types. Hopefully this add context for those picking a name that is descriptive not just to authors but also compared to the other block-types. Naming is hard, so it’s great to see the effort here. https://brain.vandragt.com/books/wordpress/page/blocks-in-simple-english I would suggest as the aim is to surface content in multiple places, to use the word Content instead of Blocks as part of the name. Perhaps something like Global Content? |
|
My vote goes to "global". It's intuitive even in non-English world. |
That's an interesting idea. Again I come back to the question of what, on a practical level, is the difference between a group of reusable blocks an a widget area made of blocks? If they are all just groups of blocks with content, how are they essentially different? |
|
+1 to Global Blocks. |
|
I think "Synced Blocks" is fine but something like "Global Blocks" would be fine too. Unless it would be too confusing with "Global Styles", which is already set? Looking at other software, for example Notion, their terminology is "Synced Blocks" too for that type of content. |
|
I agree that the name "reusable block" should be changed... But like all others above, I don't believe that "synced block" would be the best choice. The term "global" is familiar because most other page-builders also use it... but that should not be a real concern IMO. |
|
"Global Blocks" makes the most sense to me. By using "synced blocks" it's inferred they're synced somewhere - is that off-site? Is it a backup mechanism? By using something more descriptive, like "Global Blocks" I think it's more clearly defines what they are. |
|
Quick +1 for the term Global Blocks, for many of the reasons others have previously said. |
I agree that "block" might also be confusing since it can be a collection of blocks as well as a single block. However, every block is/can be "user-created, personalized". So I do not feel that the "Personalized" gets to the root of what this type of content is. So I could see either "Global Blocks" or "Global Content".
I actually think it being familiar is the greatest asset to "global". I am not saying it is the perfect, but it's recognizable and we are already using it in "Global Styles". Furthermore, those that are coming back to core WordPress from page-builders will instantly recognize the functionality and understand it. |
I'm mostly trying to think of what a new user, someone who has never seen WordPress or a builder will think. |
|
Don't beat me but I'm starting to think that "reusable content" is the most accurate descriptor for this concept. The whole idea - from user's perspective - is about the content piece that can be used in multiple places. Not about the block-based construction (where patterns play their role). |
|
What is the process for deciding these issues? Picking up on the points raised so far: So: 'global', 'sitewide' or 'synced' are all an improvement - but I still think synced is the most effective way of dealing with this problem as it helps people to understand how they work and the ramifications. Perhaps the "are you ready to save" interface could be changed to: "are you ready to sync"? Notion explain the concept well. I accept that 'global' is commonly used, but the end user, part time content editor is unlikely to be familiar with 'global styles'. Content v Blocks v Widgets My vote is for 'Synced Content' |
|
I agree with the previous contributors who've stated "global" is a better term than synced. Synced, as noted, makes it seem like you're moving the blocks to and from some other server (ie Cloud syncing). Global is a term that's been used by lots of page builders and other tools, and I think will properly invoke the idea that "this is a block that when I change it here, I change it everywhere." |
|
Interesting discussion here. I really like where this is going. Luis makes the distinction between "blocks" and "patterns". I'd even consider pushing the unification/simplification even further: Everything is a block, and depending on some metadata and context for that block, it can "behave" differently a bit. For instance:
It doesn't mean we'll be surfacing all these possibilities (naming, semantics..) in all parts of the UI, but it means everything is just a "block" with potentially added "metadata". So for sections that are being tried right now, I was proposing just that #40393 (comment) (and this could be a starting point to even more simplification/unification down the road) |
|
The UI for this can theoretically be very simple:
Without wanting to go too far down a rabbit hole, perhaps there is only one container type, and it absorbs the options from all existing containers. Then transforms can be much more dynamic, based on the child blocks rather than a static list. This allows us to not only simplify concepts like reusable blocks and template parts, but also streamline the block library quite significantly. |
|
I'm glad to see more ideas are forming here 🙂 I've been thinking more about this since @mtias proposed the idea of sections: patterns/blocks that can style and control their children using My previous proposal had three different parts:
@mtias's sections proposal made me realize that synchronization is one of the capabilities a group of blocks can have, but not the only one. Monopolizing the term pattern for just one block/pattern capability doesn't make sense to me anymore. Part 1 (using a single name for the groups of blocks a user can import) still makes sense to me to simplify the number of concepts we expose the users to. We can aggregate the different origins and abstract them from the user:
And still, let users decide what they want to see with filters prepopulated depending on the context.
We could hide some of the filters when they make no sense in a context. Part 3 (verbose UI prompts) still makes sense to me to make sure users understand the consequences of their actions until they understand the mental model and learn the UI icons/tips. But part 2 (monopolizing the pattern name for synchronized blocks) was based on the assumption that synchronization was the only/main capability of a group of blocks, and therefore it doesn't make sense to me anymore when analyzed in conjunction with the section's proposal. It has two specific problems:
So the more I think about it, the more I gravitate towards what @youknowriad mentioned here:
I think the best example of this today would be the implementation of the locking mechanism. If blocks can absorb these capabilities, naming can be more explicit, and the need for multiple wrappers disappears. For reference, a list of block capabilities could be:
Maybe it's worth noting here that these capabilities don't belong to the block intent, so the platform should control the UI: icons and colors, toolbar settings… But the work on sections has just started, so it's a bit early to know how it will materialize and if it will go in that direction or not. I'd wait a bit here until we know more about that. |
|
Here’s a design concept based on the discussions here and in other issues. I’ve stripped things back to the bare minimum so that we might consider an iterative implementation. The steps necessary to get here feel fairly manageable, and align with on-going work across other initiatives (template editing). pattern.mp4All global entities are referred to as 'Patterns' in the UI which drastically reduces the cognitive load on the end user. Template Parts, and Reusable Blocks all now appear in the Patterns tab of the Inserter. Pattern properties (such as category or semantic area) allow us to contextually surface them where appropriate. For example a 'Header' pattern would not appear in the post editing context, and perhaps have less prominence in the template editor when another header is already on the canvas. Those same properties facilitate the filtering of views where many patterns are visible. When a pattern is inserted, we determine whether it should be synced or not. Ideally this would be done automatically based on context – A header pattern should be synced (being explored in #42142), an 'About me' pattern should not – but we can use a modal to ask the user as a fallback. On the canvas, a synced pattern is un-editable and behaves as a single, inert object. The toolbar communicates synced status / usage, and has three primary tools:
In the future we can build a centralised pattern management interface within the Site Editor from which you can create, edit, delete, import / export, etc.
Even this fairly simple / iterative concept covers quite a lot, and obviously there are a number of details / interactions we'd need to polish. Nevertheless it seemed like a good opportunity to put some pictures to the words. One piece missing here is pattern overrides, that means locking the blocks / arrangement of the pattern, but allowing content to be overridden locally. This is fairly complex and has several tangential considerations (pushing local edits upstream, resetting local edits, defining which properties can be overridden, etc). Since we don’t have anything like this right now, it seems fair to defer it until later. |
|
Love where this is going @jameskoster; a few notes:
🔥
My hesitation is the with the use case of employing the Blank template for one-off page designs (such as landing pages). By assigning the Blank template, you can pick any header you'd like (or none) if they're added as patterns – not just template parts.
I this is great — I've been thinking along similar lines. We could start with auto-syncing what we'd consider template parts (maybe even just headers and footers) and see if we need to introduce a modal to ask (I don't know that we would though).
I'm not sure we would need a focused in view to edit the synced pattern. Maybe not even replacing (seems like an extra model to understand). I like how Notion handles syncing, where you can edit as per usual, navigate to other instances of the synced element, unsync a singular instance, or unsync all from the original. Maybe a border (using the synced/reusable purple) would help distinguish the pattern as synced:
This could simplify the understanding between syncing/unsyncing, while keeping the experience in line with what we have today, with a good bit more clarity. I think we should clean up/organize the block toolbar options, to bring more clarity to tailored experience such as syncing, but I cover that here: #42203
I don't think so — once unsynced/detached, anything could have changed. |
|
Thanks @richtabor!
Hmm, if the template is blank how does the page content get displayed? The template would have to at least include a Post Content block, no? Wouldn't it be more sensible to have a 'Landing page' template that was comprised of Header / Post Content/ Footer? 🤔 It's a bit subjective, but for me it's important that the template / content boundaries are more clearly defined. There are certainly many options to explore with regards to adding clarity to the editing experience for global elements. I like focus mode for two key reasons though:
|
|
A very good idea @jameskoster ! Thinking out loud... We create a pattern. Define if it should be synced or not. We will need a way to notice which patterns are synced and not in the Pattern inserter. Perhaps an icon beside the Patterns inserter drop down elements giving a signal to where there are synced patterns. Then a synced icon just above right of the pattern to signal that it is synced. There are a lot of possibilities here! |
Yea, I meant the Blank templates like this (https://github.com/WordPress/twentytwentytwo/blob/trunk/templates/blank.html) which only relay the post content — which you could add a header pattern to, to make a custom landing page (or whatever kind of page) for example.
It does, but this also takes the editor out of the page context. I'm not sure if introducing another layer of diving in/out is worth the weight of trying to understand what's happening with the "focused" state.
Definitely tricky. But I'm still not convinced it needs a separate space to bake this in. One thought I've had is perhaps any RichText attributes could be editable. For example, if you've changed text at the source, and not on any synced patterns, then those changes permeate. But if a paragraph of one of the synced patterns was changed, then that paragraph text attribute would be opted out of the sync. If you wanted to opt it back in entirely to the original pattern, there's a control to reset all changes. And maybe there's a control to force push changes from the original synced pattern. 🤔 |
|
I also think that if a user indicates they want to make a pattern a synced pattern (and it shows up in the pattern library) then we could consider not asking them if it is to be synced when added to the page. If we had an icon, or color change for focus, then that would indicate the synced pattern is indeed synced and I can detach/unsync it if I'd prefer otherwise.
|
|
I am seeing more and more modals show up in the Gutenberg UI. I believe we should look at UI methods that better incorporate decisions directly into the toolbar and/or sidebar settings. Instead of adding too much focus on modals. This is though more of a general feedback to the direction of design in the last few months. |
Yeah I still think adding headers (template parts) to content is a bit awkward. It can easily get confusing if you later change the template. If folks want a header for the current page, we should encourage them to add it to the template imo. Probably a discussion for another issue though :D
Or push upstream! Could work :)
Agreed. If you insert a pattern and sync it, subsequent insertions should be synced by default.
It's true, but I think this is partly due to the increased complexity of the software (site editor in particular). From the handbook:
In that sense I think the modal is the correct choice here. |
|
@richtabor I tried a quick prototype for the direct-manipulation-editing of rich text: pattern.overrides.mp4I still think you need the dedicated editing view if you want to do anything beyond this (add / remove blocks, re-order, etc). There's also a question of how to handle non-text content overrides (e.g. images). |
I also think the dedicated view should be the default edit option to make clear that those blocks don't belong to that page/post, but there could also be an explicit "Edit in place" option. |
|
I love the discussion and mock ups above relating to syncing patterns across a site. This is something I feel is really missing from FSE at the moment. There is no entity currently for this and patterns are slightly useless without the option to potentially sync this across a site. Often patterns are repeated across a design on various pages or templates. Aside from the discussion above and in other issues (#41717, #39281) has any work been done on making this a reality? I think the modal option illustrated above is super intuitive and simple for users to understand when choosing to add a pattern to a page or template and it would fill such a gaping hole currently in FSE. I need to use a pattern across multiple pages in FSE and currently any style changes I make to that pattern are not globally synced, in effect making patterns pointless in this instance. I might as well just copy and paste that group of blocks to each page which is time consuming and not ideal if anything changes design wise in the future. Compared to something like a php template or ACF Flexible content field where you could update that centrally in one place and change the style for the entire site, this workflow is horrible currently in comparison. Tracking multiple issues all talking about patterns and potential ideas for them is also pretty confusing and hard to track for someone keen to follow any progress on this. |
|
Work hasn't yet started but you're following the right issue. I do want to mention this sub-issue as part of the patterns as sectioning elements that was recently opened #48458 I know it's a lot to follow but it's a big change with many moving pieces. You've correctly identified the big ones :) |
|
Thanks @annezazu, really appreciate the confirmation and letting me know. Excited to see what can come of all this great discussion around patterns! |
|
With the rename of reusable blocks to synced patterns going into 6.3 I think we can close this. |
and others
Reusable blocks have a long history now. The started as "saved blocks" and went through some renaming iterations until we settled on "reusable blocks". This worked alright at the beginning, but with the introduction of patterns its meaning has started to become more fuzzy and confusing (see related comment). In the end, patterns are also reusable pieces of design.
Given the nature of these blocks is to have content in sync wherever it's displayed — edit once; update everywhere — I propose we change the name in the UI to "Synced Blocks" and adjust the block description a little bit to clarify that.
The text was updated successfully, but these errors were encountered: