Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[UX] Come up with better terms for "custom blocks" and "reusable blocks" #5922

Open
klonos opened this issue Jan 11, 2023 · 2 comments
Open

Comments

@klonos
Copy link
Member

klonos commented Jan 11, 2023

This is one of these things that may be obvious to many "chronic" Backdrop users, but not so much for people new to Backdrop. Also, there's a huge difference with what "custom blocks" are in Drupal and how they work, since these are fieldable/revisonable entities with "block types" that can have custom fields too. The Backdrop version of "custom blocks" is a much simplified variant though, with only a single body field available.

In Backdrop, there's also 2 flavours of custom blocks:

  • Reusable: these can either be created in the custom blocks management page under admin/structure/block, or directly via the "Add block" dialog in the block management UI of any layout (and then select the "make reusable" option). You can add a reusable block to any number of regions in multiple layouts, and updating the content of any one "instance" of a reusable block will reflect the changes to all other instances across all layouts/regions across the entire site.
  • Non-reusable: these can only be added via the "Add block" dialog. They cannot be added to any other region/layout - only to the place where they have been created. They can be moved within various regions of the same layout, but not across layouts.

One of the main issues the way that I see it is that we are using the same term "custom blocks" for:

  • two different things, with the only distinction between them from a UI standpoint being the "make reusable" checkbox (which is hidden away and only discoverable after several clicks)
  • the same thing that in Drupal means something else and works differently.

Things to consider, but that do not necessarily need to happen:

  • If we renamed these things to "reusable blocks" vs. "content blocks" (or something like that), then there would be clear distinction between these 2 flavours of Backdrop blocks, and also relatively obvious by their names as to what their purpose/function is
  • If we moved away from the term "custom blocks" for these things, then there would be less confusion and no false expectations for those coming from Drupal-land with regards to the purpose and features compared to the custom blocks provided by Drupal.

Here's a few places in the UI that we could be doing a better job:

  • The "Custom blocks" menu under "Structure" could become "Reusable blocks" (or "Reusable content blocks"?). See [UX] Custom blocks listing: Add the word "reusable" to the page title and the "+ Add ..." link #6531 for that.
  • The "Custom block" option in the "Add block" dialog could become "Create new content block", and existing custom/reusable blocks could be prefixed with "Reusable block: "
  • The description for custom block in the "Add block" dialog is A basic block for adding custom text., but images can also be added in the "Block content" CKEditor field. We should change that to A basic block for adding custom text (can be made reusable). (or something better than that?)
  • Perhaps we should be explicitly providing two options in the "Add block" dialog: a "Create new content block" and a "Create new reusable content block" (the non-reusable form would still provide the checkbox to convert the block to being reusable).
  • Perhaps consider also pulling all non-reusable blocks and listing them under admin/structure/block, either in a separate table, or in the same table and add a "Type" column, which distinguishes between reusable/non-reusable. In this scenario, we most likely wouldn't need to rename the "Custom blocks" menu item.
  • other things ???
@stpaultim
Copy link
Member

I just had a discussion with @klonos about issues around reusable custom blocks and non-reusable custom blocks. I like the fact that the PR for this issue is helping resolve this issue, but I expect we will need to do more.
#4108

@klonos klonos changed the title [UX] Do a better job at clarifying what reusable vs. non-reusable custom blocks are and how they work [UX] Come up with better terms for "custom blocks" and "reusable blocks" May 12, 2024
@klonos
Copy link
Member Author

klonos commented May 12, 2024

Thank you for @-mentioning me here @stpaultim 🙏🏼 ...I was about to file a duplicate of this issue here. This is what I have written:

This is relevant to issues like #4108 and #6531, and theres a thread in Zulip: https://backdrop.zulipchat.com/#narrow/stream/218635-Backdrop/topic/Reusable.20blocks.20UI.2FUX

Here are my thoughts on the matter:

  • If we were introducing this feature now, I would certainly find Reusable custom blocks over the current Custom blocks way more fitting. So 👍🏼 from me on the change proposed in [UX] Custom blocks listing: Add the word "reusable" to the page title and the "+ Add ..." link #6531.
  • Since the feature has been around for a long time, people are used to the position of the current "Custom blocks" menu item in the "Structure" top-level menu in the admin bar. Adding the word "reusable" as the first word causes the menu to be repositioned, and I expect people to find it rather disruptive/annoying. I then thought that perhaps Custom reusable blocks would be a good compromize, since it introduces the word "reusable" while at the same time retaining "custom" as the first word. That would in turn leave the order of the menu item in the admin bar unaffected.
  • Reusable custom blocks is much better than Custom reusable blocks though (more technically accurate).
  • For comparison, in Drupal they have the notion of "block types" (fieldable blocks basically), and the default block type that they provide OOTB is called "Basic block". That block type provides only a title and a body field, which arguably makes it more or less equivalent to our custom blocks. To add to the confusion and the differences in approaches/UI/workflow, when adding such a block via the "place block" modal, the action to add such a block is called "+ Add content block".
    • If only the one "Basic block" type exists on the site, this action takes you directly to the form that allows you to add this type of block (provide a title and some body text -> save -> done)
    • If more than one block types exist, then you are asked to select which type of content block you want to add.
  • During a Jitsi call @stpaultim and I had, we discussed why these aren't called "Content blocks" instead. As I explained, I vaguely recall the discussions about this matter many years ago, but I believe that the main argument was that technically all blocks produce some form of content when rendered, so it wouldn't make sense to call these blocks specifically "content blocks". "Custom content blocks" as a term has the same issues.
  • Relevant to the previous point: not sure why we are calling these "custom" blocks in the first place. Technically, all blocks can be custom/customized.
  • In addition to the previous point: not sure why we are calling them "reusable" either. They may be "reusable" in the sense that we mean "reusable" in Backdrop, but for non-Backdrop users (as well as non-Drupal users for that matter) these are not explicitly reusable, because technically all blocks are reusable.

In general, I've been trying to get some clarity on what we are actually trying to convey with these terms. Here's a series of thoughts I had:

  • "custom blocks" are "content blocks" (they are not the only content blocks though)
  • We already have "Existing content" blocks, which basically display node content. I personally find this term very fitting, and cannot figure out any case where it would be ambiguous.
  • If there is the notion of "existing content" blocks, then what could "custom blocks" or "content blocks" be called to differentiate them appropriately, intuitively, and non-ambiguously?
  • What is the differentiating factor that makes "reusable custom blocks" distinct from the non-reusable ones? (which one can argue that they can actually also be "reused" based on the definition of this verb)
  • Are reusable blocks being "reused" across layouts, or they being "shared" (well, technically their content is being shared across layouts - not the blocks themselves). So could perhaps "Shared content blocks" be a better term?
  • Would either "cloned content" or "mirrored content" be any better as a term?
  • Is there any other term that might be better? Please consider the following when making suggestions:
    • The goal is NOT to find synonyms of the words we are already using.
    • We're looking for words that when used would immediately, intuitively, and without much documentation/explanation or help text convey the meaning and purpose.
    • We need something that ideally in 3 words or less says:
      1. "The content of this block will always be the same across all layouts".
      2. "Change the content in one place, it changes everywhere".

PS: Silly idea but throwing it out there: in Greece, we use the French term "aller-retour" (means "come and go" or something like that) to describe the setup of electrical switches/wiring that allows the same light to be controlled from multiple points/rooms, which is called multiway switching in English I believe. Wondering if there is any real-life use case or concept that is similar to this, and that people are commonly familiar with, which immediately just makes sense.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants