Redesign UI for better management of block visibility

Not sure if this should go here or in #2278541: Refactor block visibility to use condition plugins, but here are 2 ideas for the "click to negate" option:

(Video)

I guess that's still just one condition, can you give an example of multiple conditions?

I'd like to share my exp with that:
1) Default value - all types unchecked, condition is "Hide when {condition label}:" (suppose select box here better)
2) Remember taxonomy page: 2 steps - select bundle and select terms
3) Entity value condition in ctools is still broken and useless: #1630820: entity_field_value is completely broken & #1955954: entity_field_value.inc is mostly useless

I think the show on/hide on control would make most sense in this context. The clickable toggle link is not a typical Drupal control.

IMO two radio button with the options:

- Show on the following pages:
- Hide on the following pages:

It's definitely understandable, but wish it could be more compact. But the smaller version isn't as easy to understand.

IMHO "Show/Hide for" is the best match.

Alternative suggestion: "Show / Hide in context of".

Here is a prototype I have been working on that shows one approach (using chosen library which I know has a11y issues which we can hopefully fix).

This was built as a usability test scenario and has been tested and iterated on three times to get it to where it is.

The scenario is:

You are a junior content editor at a product site and you have received instructions from your boss to configure a block on your site a certain way. So you have clicked "configure block" from the block layout page and you now see this modal dialog.

The first thing you need to do is to move the block from the header 2 region to the footer region.

Next you want to show the block only on the page "Mypage" in content.

After that you want to make sure it is visible only to anonymous users.

Then you want to show it only for the article content type.

After you are done you look at your notes and realize that your boss said to Hide the block, not show it, under those conditions. Now you need to make that change.

Do all of the steps in the order above.

(I realize writing this that the scenario is not very realistic. :) )

http://invis.io/TMZP9L6Q

@tkoleary, this is great work! I have five points:

1. Initially, I clicked on the first select box that contained 'page' page only to be hit with a stop sign. I think an improvement would be to allow exploration here, I naturally wanted to see what my other options were, as they were hidden.
2. I like the natural language design of the context selection
3. Is there no add another context button? How would this work if you deleted the last context from the list? Would a new blank one appear?
4. I love the idea of using the layout thumbnail as an interactive UI element! It never occurred to me that we could use it like that, good idea.
5. Is it clear the effect that drag and drop would have? Or is this an advanced use case? I would rather we didn't rope a new drag and drop design into this issue.

Thanks Lewis.

Initially, I clicked on the first select box that contained 'page' page only to be hit with a stop sign. I think an improvement would be to allow exploration here, I naturally wanted to see what my other options were, as they were hidden.

True, but I think that's an artifact ofthe prototype. If I made all three options click through then I'd have to maintain triple (60 instead of 20) screens :/. Having said that there may be an argument for defaulting in the three cases that are in core now with an empty fourth for another one.

Is there no add another context button? How would this work if you deleted the last context from the list? Would a new blank one appear?

Yes, another blank appears.

I love the idea of using the layout thumbnail as an interactive UI element! It never occurred to me that we could use it like that, good idea.

Thanks!

Is it clear the effect that drag and drop would have? Or is this an advanced use case? I would rather we didn't rope a new drag and drop design into this issue.

I didn't envision drag-drop here, just click (click the region and the block goes there). But it does need more affordance that that is what happens.

I didn't envision drag-drop here, just click (click the region and the block goes there). But it does need more affordance that that is what happens.

Sorry, I meant the drag and drop affordance to change the order of the conditions. That's what he horizontal lines are right?

Sorry, I meant the drag and drop affordance to change the order of the conditions. That's what he horizontal lines are right?

Right. I think that's a nice-to-have, but we already have table drag in D8 so maybe it's easy to implement in form API if we just make this section a table?

The reason I put it in is because as soon as you intermingle "and" and "or" statements the order matters. That ands and ors are not so important here but in discussions with Tim Plunkett I believe that this interaction pattern would be extended to cover rules, contexts, conditions, arguments in layout, views etc.

Updated the prototype with hover states in the thumbnail and tool tips.

http://invis.io/MQZU6A8F

Here's the scenario again if you didn't see it above:

You are a junior content editor at a product site and you have received instructions from your boss to configure a block on your site a certain way. So you have clicked "configure block" from the block layout page and you now see this modal dialog.

1. Move the block from the header 2 region to the footer region.
2. Show the block only on the page "Mypage" in content.
3. Make sure it is visible only to anonymous users.
4. Show it only for the article content type.
5. After you are done you look at your notes and realize that your boss said to Hide the block, not show it, under those conditions. Make that change.

Do all of the steps in the order above.

Click the "x" if you need to return to the beginning.

@LewisNyman

I mocked up the alternate idea from #14 (there may be an argument for defaulting in the three cases that are in core now with an empty fourth for another one.)

Adding a specific pill will remove the "any" pill.

The and/or (boolean button bar) is an interaction pattern we should also generally have in core. There's a stab at this in module filter module but it's not very well executed.

https://www.drupal.org/project/module_filter

@LewisNyman

On another note. I am looking into ways we can get the a11y work done on chosen library. We use it in lift module so we (Acquia) may be able to do it ourselves, perhaps with some help from @jessebeach

#1271622: Seek a better autocomplete replacement for core (jQuery TokenInput / Select2 / Typeahead.js by Twitter)

Sometimes you need more than a select. For pages for example you probably need some kind of input field so we can allow custom paths to be added.

some_page/*
some_page
other_page

@tkoleary
Do you really think that this "replace with" should be part of core? It feels like a potential mess if you really have to maintain your site because it won't be obvious anymore under which conditions are block might appear. It is not configured anymore in one place but in N, with N the amount of blocks in your system.

@dawehner

it won't be obvious anymore under which conditions are block might appear.

You're right. I didn't think through those implications.

I just found this issue because I made a very simple contrib module that defines a condition that checks token values against literal values or another token value.

https://www.drupal.org/project/token_conditions

You can do stuff like

1. Check the if the author of the current node is the sames as the logged in user
2. Check if a field value on the current node is empty.

It seems like a GUI for block visibility conditions should take into account that

1. Current core conditions work with 1 instance per block but many contrib or future core conditions will probably make sense to add the same condition multiple times with different settings. Like in then 2 examples above for mine.
2. Contrib and future core conditions will probably need significantly different settings forms.

It seems like it would make sense to have some sort of "Add another condition*" dropdown like the in mockup in #18 but then have the new conditions form loaded into it's own fieldset or tab by calling buildConfigurationForm on the class that defines the Condition.

To keep the GUI similar to D7 for users the current core conditions could be loaded by default and then dropdown used to add additional conditions.

*I also like using the word "condition" on the front end instead of context because that is what is in the code.

@tedbow

*I also like using the word "condition" on the front end instead of context because that is what is in the code.

That would be true if the only people who were ever to use this UI in the future were people who also had read the code. Nomenclature decisions should be made on the basis of what will be most universally understood, not on maintaining consistency with namespaces in code.

I'm not certain here which is better, or if there is another, even better option for the UI, or none eg. simply: "Add another". In any event what's in the code should not guide the choice.

Nomenclature decisions should be made on the basis of what will be most universally understood, not on maintaining consistency with namespaces in code.

True but in must likelihood popular contrib modules in Drupal 8 such as Page Manager and Panels are going to use the word "context" on the UI to mean what "context" means in the code in Drupal 8. So having the same word mean different things in different places would be very confusing(as it is in Drupal 7 space).

Also in the future if we actually want to surface the code concept of "context" to the UI what would call it if "context" was already used to for "condition" plugins?

I aso think in plain English it makes more sense. For instance: "In what conditions would you like this block to show?"

But obviously the wording is probably a side issue with the actually GUI.

I do like the GUI that @tim.plunkett is working for Page Manager

@tedbow

I aso think in plain English it makes more sense. For instance: "In what conditions would you like this block to show?"

Good point about context. I think the answer is to simplify to "add another" which avoids the nomenclature problem and instructs by example, eg. the user asks herself "add another what?" and answers her own question "I guess another of the things above which appear to be filters that narrow the [contexts, conditions, circumstances, parameters, etc.] under which this block will show up"

Whatever you do, please don't use the word context to mean condition. :-)

Eclipse

An issue I've noticed when Rules is enabled, since Rules implements a lot of conditions by itself.

For a condition to be useful, it has to have enough content available to meet its requirements (as defined by its annotation). So it makes no sense at all to display a condition like rules_data_condition, which needs to get two pieces of data and an operator from somewhere. Unless we allow people to use tokens or Rules 7.x-2.x style data selectors (and for the standard UI, you really don't want to do that), or rules_data_comparison should never appear in the UI. So blocks (and probably other users of context) needs to filter the conditions it displays according to the context it is able to supply to the plugins.

In addition: the number of vertical tabs that can be displayed appears to be limited. Rules by itself already has more conditions than Blocks can display on that popup. And anything that isn't included in the limited space is unreachable. So the irrelevant conditions are also hiding conditions that are actually useful to blocks.

I think we need two things:
- allow modules to hide their conditions if they don't make sense or if the required condition context can't be configured
- allow to make the block visibility conditions configuration to be more compact, if there are a lot of condition types

also see
https://www.drupal.org/project/block_visibility_groups

So, CTools already has classes to do this work. I'm currently pursuing a ctools equivalent to layer on top of core blocks and swap out the UI for something usable and not-insane. I'd be perfectly happy to discuss what that might look like in core for say 8.2.x+

Eclipse

@eclipsegc

Just saw your comment from a while back. Do you have designs for that?

@tkoleary

The issue for it is here: #2604178: Modify core block UI to seperate blocks into categories with tabs

I've not actually tried to document the visuals on that issue, but the block selection UI is roughly what you see in #2662354: [META] Design new UX for Panels IPE comment 11 images 4-7.

Hope that helps!

Eclipse

@eclipsegc

Yes, it does. I now recall you demoing those. Thx.

A more apt title for what this issue really is. Too many people get confused with how block visibility and conditions actually work (especially in regards to the page title now).

Also, it will be great if we could see the administrative descriptions under (or instead of) the block titles? Say, i have 3 different facets blocks, each with the title "Territories". On the block admin page, all of them appear as "Territories" and one has to either guess or do some trial and error to figure out which one is which one. So, it will be better if we could include an administrative block description on the block admin page instead of just the block title.

Thinking aloud, it could also be good to have a "path" filter for advanced users. If a user enters a certain path in that filter, only the blocks visible on that path should be displayed.

No activity here for two years so thought I should touch this issue to remind us that this is (still) causing a problem when contrib provide @conditions which get unintentionally shown on the block UI page. See #3160347: Option of block page visibility is missing. The options are unusable and their presence causes confusion and wastes support time.

Instead of the full re-design, is there an interim solution that can be committed so that the core block UI only displays conditions that it can actually use?

Added some issues that should be taken into account here.

I think the whole condition logic UI and UX should be rethought, if we want a excellent and flexible solution which allows combining and chain and / or. It would be similar to what Rules condition logic does with an indentable tree.

As this issue is 8 years old, it might need a restart...?

There is one more weird thing about this UI. No way to explicitly enable/disable a condition.

The condition is considered enabled only when its configuration has been changed.
https://git.drupalcode.org/project/drupal/-/blob/10.0.0-rc1/core/lib/Dru...

I could not comprehend the reason behind this. What if a user is satisfied with default configuration?
Furthermore, for condition plugins with zero configuration there is no way to be used for checking block visibility.
The workaround is adding to the plugin some dummy option like "Enable" checkbox.

I think, the block visibility UI should work same way as field UI.

1. A user selects a condition plugin from a dropdown list.
2. Plugin configuration form shows up.

Enabled visibility rules need to listed below with corresponding operation links (edit/delete).