-
Notifications
You must be signed in to change notification settings - Fork 38
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
Comments
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:
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:
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. |
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:
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.One of the main issues the way that I see it is that we are using the same term "custom blocks" for:
Things to consider, but that do not necessarily need to happen:
Here's a few places in the UI that we could be doing a better job:
A basic block for adding custom text.
, but images can also be added in the "Block content" CKEditor field. We should change that toA basic block for adding custom text (can be made reusable).
(or something better than that?)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.The text was updated successfully, but these errors were encountered: