Rename shared blocks to global blocks and increase understanding of the feature

[karmatosed]

Shared blocks is incredibly handy as a feature 'if' you know what they do and mean. The term shared is very open to interpretation and many think 'oh I can share with other people'. The naming of this has gone back and forth a bit. I would like to suggest changing to 'Global Blocks'.

Along with this if we added a 'Tip' to say what these blocks are as you go to use them it would really help. I thought about adding a little text beside the block but a 'Tip' would be a nicer touch I think.

[sarahmonster]

💯 for renaming. "Shared blocks" is really opaque and took me ages to suss out what it meant the first time I came across it.

I'm not sure "global blocks" would be the best term though, especially given that these blocks are actually less global than other blocks (because they're specific to a single WordPress instance.) "Local blocks" would almost be better but global/local is a pretty technical distinction that probably wouldn't resonate for lots of people.

What about calling them "reusable blocks" or "custom blocks" instead?

[karmatosed]

Another area to include a 'Tip' could be:

[karmatosed]

@sarahmonster my concern with custom is customization means something to everyone in WPland. Local is also a weird thing as is that local to just the page? It's a tough one...

[andreilupu]

This subject is like ping-pong 😄

For me, the Global label sounds like a little bit too powerful, exactly like the idea that Shared could lead users to the impression that these blocks will be shared between sites "globally".

Why not calling this block type for precisely what it is: a Saved block or Stored? I feel that this topic is bikeshed because we are trying to give these blocks a mask like we aren't comfortable with the fact that they are simply saved for later use.

[ZebulanStanphill]

Is there any way to get across the idea of "blocks that can be saved into a library and when changed will update all instances of that block" in one word?

The equivalent of Shared Blocks in Divi is called Global Modules (or Rows or Sections). Beaver Builder also calls it Global Modules (or Columns or Rows). Elementor calls it a Global Widget. Oxygen calls it a Reusable Part.

@andreilupu Calling it merely a Saved or Stored block does not express the fact that its settings are changed across all instances of the block when you change just one. Many page builder plugins have the concept of a saved module/widget that is only a template and when inserted, does not remember that it came from a template and is essentially just a regular version of a module/widget with some settings pre-applied.

Divi seems to call this kind of thing a Saved Module, though it usually just refers to it as a Module in the Divi Library. Beaver Builder calls it a Saved Module. Elementor actually does not seem to have template modules, but it does have the ability to save a Section or a whole page, which is calls a Saved Template. Oxygen just uses the same name Reusable Part and lets you insert the Reusable Part as Single (meaning changing that instance will change all instances) or Editable (meaning the part will be inserted with the Reusable Part settings only applied as a template and the inserted part having no connection to the original Reusable Part or any of its instances).

For reference:

• https://www.elegantthemes.com/documentation/divi/library/
• https://kb.wpbeaverbuilder.com/article/90-save-a-row-column-or-module-for-reuse
• https://docs.elementor.com/article/60-library
• https://docs.elementor.com/article/100-global
• https://oxygenbuilder.com/documentation/templating/reusable-parts/

[michelleweber]

Saved Block or Reusable Block both make sense to me. I could get behind Custom Block as well -- I know "customization" is a frequently used and specific WP word, but I don't know that that takes "custom," which a more general term, off of the able here. I like Global, but the other options feel more specific.

Re: tip text, something like this?

"Use a YaddaYadda Block for content you want to add to multiple pages and posts -- create a custom block to save and reuse anywhere on your site."

[ZebulanStanphill]

@michelleweber I agree, “Custom Block” is both unclear as to the fact that it shares settings/content with all other instances, and also conflicts with the common idea of a custom block being merely a standard block that is added by a theme or plugin rather than by WordPress core.

[noisysocks]

There was lots of good discussion about the name in #3810.

[noisysocks]

My original hesitation (#3378 (comment)) with Global Block is that I've personally only ever seen global used in political or technological contexts and so it mightn't be something that users outside of our circle understand.

Overall I don't think the name really matters. It's more important, in my opinion, to make the feature discoverable and to use consistent iconography. For example, we could improve discoverability by having WordPress include a built in shared block. Users would then see this and experiment with it when they open the inserter.

I think one reason that naming this feature is so difficult is that we're constraining ourselves to [adjective] Block. What if there is no adjective to describe this type of block? Can we invent a new word? Could we use a metaphor? For example, you don't create log entries in WordPress—you create posts. You don't, copy to RAM an image from one app and insert from RAM it into another—you cut and paste the image.

[noisysocks]

Name aside, I think adding a tip is a good idea. Since a new user wouldn't have any shared blocks, I think adding a tip like the one pictured in #7887 (comment) makes the most sense.

[michelleweber]

(If I may toss in an outsider's perspective, I actually don't understand why this is a separate block at all. It seems like it should be an "save this block to reuse" option that I can activate in any block rather than a block type of its own.)

[karmatosed]

@michelleweber kind of that's what happens but they need to be stored somewhere in their own category within the library, or at least in an easy to find way. This is really why we're looking to give it a name, the action call is important also as what shows in menu.

[sarahmonster]

"Save this block to reuse" seems like a much more descriptive label than "Create a Global Block" (suggested above) or "Convert to Shared Block" (currently in use). 💯

[mtias]

I agree we don't necessarily have a naming problem but one of communicating a feature, which cannot be done by name alone. I like using a tip to give context the first time you create one.

That said, in hindsight, I think "shared block" was probably a poor choice since the expectation for a user is going to be confusing — "who am I sharing this with?". Specially considering most people will have a single user on the site, shared becomes more of a frown.

I like "global", "reusable", and slightly less "saved". I don't like "custom" because I think it overlaps too much with customization and is a tricky word for translations.

[karmatosed]

This is what saved block would look like:

[noisysocks]

Aiming to get this in for 4.9.8.

[mrleemon]

+1 for Reusable

[ZebulanStanphill]

@noisysocks

I am really not sure about the Saved Blocks name. It does not really convey that updating one instance will update other instances.

And what about when template blocks are added, where updating one does not update other instances, because they are just templates? Those are saved as well, but they would not act the same as the Saved Blocks. I think Reusable Blocks or Global Blocks are both better names than Saved Blocks, in my opinion.

However, if there is going to be an option to insert Saved Blocks as a template used to apply settings initially only, in which case the template and saved/re-usable blocks idea would actually be one and the same, then calling them Saved Blocks is fine. Do you know what I mean? Of course, going down that route makes it more difficult to implement things like Selective Sync from Divi, I would imagine, though you could probably still do something like the class system in Oxygen for only sharing some things between instances of a Saved block but not everything.

See also:

• https://www.elegantthemes.com/documentation/divi/selective-sync/
• https://www.elegantthemes.com/documentation/divi/divi-library/
• https://oxygenbuilder.com/documentation/styling-options/classes/

[noisysocks]

Posting a quick overview on where we're at with this so that I can link in some outsider perspectives.

Here's the relevant UI that we're changing:

More Options 1	Inserter	More Options 2

Right now we're using these labels:

Convert to Shared Block / ♼ Shared / Convert to Regular Block / Delete Shared Block

After some back-and-forth that I had with @karmatosed, we arrived at:

Save Block For Reuse / ♼ Reusable / Convert to Regular Block / Delete Reusable Block

But we're not too certain about this. We especially don't like Convert to Regular Block, but struggled to think of anything better.

[chrisvanpatten]

I definitely don't think it's the best idea for this case (a little too technical), but as a point of inspiration… in Sketch, the equivalent of "Convert to Regular Block" would be the "Detach from Symbol" command. The main takeaway there is the idea that the reusable block continues to exist, you're just saying "in this case, I want to edit it separately."

With that in mind, perhaps something like "Convert to Stand-alone Block," "Unlink from Shared Block," "Edit as a Stand-alone Block," etc.…?

[ZebulanStanphill]

Oh, I was not aware of the Convert to Regular Block option. That makes the Saved blocks pretty much double as templates. It would still be nice to have some way of inserting a Saved block as a standalone block from the inserter, though. Maybe right-clicking the block in the inserter could bring up an option to "insert as standalone"?

But due to the fact that you can unlike a Shared/Saved/whatever block, I guess calling it a Saved block actually works alright, since the library of template blocks and shared-instance blocks is one and the same.

Also, "Unlink from Shared/Saved/whatever Block" is definitely better than "Convert to Regular Block" in my opinion.

[michelleweber]

I like "Convert to single-use block." (I don't think "standalone" is a good options here, because it's not quite clearly enough; technically every block on a page is standing along whether it's reusable or not.)

I also wonder about something like "Remove/delete reusability from this block," to stay consistent with the "reusable" language and communicate that the reusability is what goes away, not the block/content itself.

[chrisvanpatten]

To me, “Single use” suggests that the block can only be used once, which is slightly more confusing.

[kjellr]

This is a tough one.

This doesn't quite make sense, but one idea would be for us to frame "Reusable Blocks" as a container, rather than a state/form of block? So for instance:

Add to Reusable Blocks / ♼ Reusable / Convert to Regular Block / Remove from Reusable Blocks

Other ideas that I'm not 100% sold on:

Add as a Reusable Block / ♼ Reusable / Convert to Standard Block / Delete Reusable Block

Make this a Reusable Block / ♼ Reusable / Convert to Standard Block / Delete Reusable Block

Remember as a Reusable Block / ♼ Reusable / Convert to Regular Block / Forget Reusable Block

[michelleweber]

I continue to find this challenging as well, because it seems like an option that I should be able to toggle on/off in any block ("make this content re-usable") rather than its own type of block (which is I think along the lines of what @kjellr is saying?) -- I tend to think that the difficulty in coming up with language suggests a more fundamental issue with how we think about this block.

(All the words we're trying -- saved, reusable, standalone, etc -- have shortcomings because you can theoretically understand them as applying to any block. From a new user perspective, every block is standalone. Every block is reusable -- can't I use an image block on any page? Every block is saved -- I'll always see "text block" as a block option. With this saved block, we're asking them to distinguish between a specific block and a block type using language that will never be absolutely clear, when what's really at issue is the reusability of the content of a specific block.)

Given that, I continue to think that something like "Remove/delete reusability from this block" or "Don't allow this specific block to be reused" is probably the best (clearest) bet.

[ZebulanStanphill]

Something that bothers me a bit about the current shared/resuable/global/saved blocks system:

It is not obvious that you can convert a shared block to a regular one. I think that in the future, it would be nice to use the shared blocks library as a library of templates as well.

For example, the Cover Image block may become obsolete with the introduction of the proposed Container block. The Container block could do everything the Cover Image block could and more. The Cover Image concept would then work better as merely a template: a Container block with some settings already enabled and a Heading block already nested in the block.

But if it were put into the shared blocks library, then to use it as a template, you would have to remember to convert it to a regular block after inserting. I think ideally you should be able to choose whether to insert a shared block as a standalone/template-only or as a global instance from the inserter. See how Oxygen does this:
https://oxygenbuilder.com/documentation/templating/reusable-parts/

[leahkoerper]

I've been following this conversation with interest and folks are making some really good points. The key piece I keep coming back to is how these blocks can be assumed to work in two very different ways: some see it as a template which is a starting place for individual edits, while others see it as a globally-synced block that can be updated from anywhere and impact all its brethren.

No matter how the special blocks are created or listed or displayed, we need to make it extremely clear how they are intended to work. Perhaps whenever a user adds a Saved/whatever block they are immediately given a chance to choose between keeping it synced vs. using it as a template. There's potential for UI bloat, but it does need to be clarified somehow. It will be a very frustrating user experience if folks add a Saved block thinking it's a template, and then unknowingly makes changes that impact other posts and pages. Gutenberg is all about having awesome control over your content, but this issue has the potential to undermine that control.

[pento]

Fixed in #8123.