[UX] Layouts UI: Reusable visibility condition templates.

[klonos]

There are a couple of other related/similar UX issues that aim to solve different problems with the Layout UI:

1691: allow blocks to be grouped so that they can be:

a) configured en mass from a single dialog (less clicking around, avoid having to repeat the same config steps) b) moved around as a whole (less clicking and moving around) c) collapse them in order to save vertical space (make the UI less complex, require less scrolling to reach the form submit buttons)

1886: figure out a way to reuse blocks that have already been configured in other layouts and be able to keep their configuration in sync.

There's also this related module for Drupal: Block Visibility Groups that...

...allows the site administrator to easily manage complex visibility settings that apply to any block placed in a visibility group. The visibility settings for all blocks in the group can be edited on one administration form.

They use the term "group" that initially made me think that this would be more like #1691, but it's not quite like that... it does NOT allow blocks to be grouped and moved around or collapsed, but it allows visibility conditions to be edited from a single place instead of having to edit each block separately. So basically, it does half the job of point a above (not all settings - just visibility conditions).

It also resembles #1886 in that it allows certain blocks settings (visibility conditions) to be kept in sync and edited form a single place having changes be reflected to all blocks.

So basically, Block Visibility Groups allows to create visibility condition templates that can be assigned to many blocks. When one needs to change the visibility conditions in blocks that are spread across many themes/layouts, they can edit the visibility condition template and the change propagates to all blocks that use it.

I know that the block placement UX in Drupal sucks big time when compared to our awesome blocks and layouts, but this small module does improve things and it looks like we can borrow the idea of visibility condition templates.

Thoughts?

[klonos]

This is how I think that this could work in our current Layout UI...

Move the "Available layout templates" section of the Layout "Settings" tab (/admin/structure/layouts/settings) into a secondary tab. So this:

...changes to this:

...the "Visibility condition templates" secondary tab would look like this:

On the layout edit UI side, in the manage blocks form, the add block dialog would include the custom, preconfigured templates as "Template: [template_name]" selection options:

If selected, these would not provide any options, but rather list the already configured conditions they include:

(although we could add links to add/remove/configure included conditions - would be globally applied on the template)

...the submit button text would change to "Apply visibility template" instead of "Add visibility condition".

Once added, the visibility condition templates would be shown in the list of conditions, with any included conditions listed as sub-items in a gray color (to signify that they cannot be edited directly):

...notice the added action of "Edit template".

[quicksketch]

Thanks @klonos for mocking this all up. Between this and the issue to make blocks (or block groups) reusable at https://github.com/backdrop/backdrop-issues/issues/1691, I think most redundancy would be solved in that issue. I might lean towards this issue being a contrib solution if possible.

Terminology-wise, I encountered difficulty understanding what the screenshots meant, because "template" is already used to indicate "Layout templates". Making "Layout condition templates" be something completely different really sent my head into a tizzy.

[klonos]

Fair enough. As I already mentioned, these feature requests are very similar. In fact this one here might be considered a (UI-wise) implementation variation of the reusable blocks thing (notice how the following two points are pretty much a copy-paste of each other with minor things changed for each case):

1. 1886:

   1. aims to implement block reusability by creating "special" blocks that one can create and manage in a central place, separately from the layout edit UI.
   2. Then these reusable blocks become available through the "Add block" browser in the layout edit UI.
   3. Any change to a reusable block from within the separate management UI, would be reflected to all its instances, in whichever layout/region they happen to be placed in.
2. this issue here:
   1. aims to implement block reusability by creating "special" visibility conditions that one can create and manage in a central place, separately from the layout edit UI.
   2. Then these reusable visibility conditions become available and can be applied to blocks (either new or existing ones) through the "Add visibility condition" dialog in the block edit UI.
   3. Any change to a reusable visibility condition from within the separate management UI would be reflected to all blocks to which it is applied to, in whichever layout/region they happen to be placed in.

No matter which solution we choose to go with (1: reusable blocks or 2: reusable visibility conditions), goal achieved: make changes to a single place and have them be reflected to multiple blocks throughout various layouts/regions.

[klonos]

...the use of the word "template" was an attempt (failed one perhaps) to come up with something better than "reusable", because if you think about it, all blocks are reusable right now ...in the sense that you can place instances of the same block in different layouts/regions. So you are reusing the same menu block, just configuring it differently per layout/region.

What would be a better term that at the same time conveys the meaning: reusable, but with sticky-across-instances, centrally-managed-elsewhere configuration?

• Clone? ...we already use that term in views. Besides once cloned, each cloned view can be edited independently thereafter. So mixed terminology there that might be confusing.
• Group? ...that's what the Drupal contrib module Block Visibility Groups uses.
• Template? ...that's what we use for layout ...well templates.
• Configuration? ...that's what we use for CMI.
• what else??

[LeeteqXV]

I'd say "Block instances" is a suitable term, and you just used it two times yourself in the very search for a term, heh :-) (Ref. its usage in https://github.com/backdrop/backdrop-issues/issues/1886 )

[Al-Rozhkov]

D7 Ctools module uses "Reusable rulesets" term.