[UX] Make all visibility conditions available at all times (and automatically set appropriate paths, contexts and context relationships).

[klonos]

This might initially seem unrelated to the issue title, but please bare with me...

There is this slight WTF (or feature, depending on how one looks at this) with visibility conditions not being available unless the right context is selected. This has made me scratch my head quite a few times before a final aha! moment. Examples include the node/% context that provides the "Node type" and "node_nid" conditions and the taxonomy/% and taxonomy/term/% contexts that provide "Vocabulary" and "taxonomy_term_tid" conditions.

Now, say that for example I want a specific design to be applied in specific terms/vocabularies and in specific nodes or node types. The way to achieve this currently is to create two different layouts, one with a taxonomy context and one with a node context in order to be able to specify those conditions separately. In such situations, we are not offering the option to have a single layout that one can use in both contexts. So the site admin/builder needs to apply the same changes to two (or more) layouts. Tedious UX there.

Add the WTF I mentioned at the start to this and you have really confusing things going on UX-wise.

My question is this: would it make sense to implement any of the below things...

a) Allow multiple contexts to be added to a single layout ...so that multiple visibility conditions become available. This way, we save people from having to create and maintain multiple layouts with the exact design.

b) Allow people to select visibility conditions and have the context be filled in automatically (or present a drop-down with options if there is more than one available). Visibility conditions are easy to grasp contrary to the context thing which is pretty vague to a newcomer. We currently have it so that people need to select the right context in order to allow certain visibility conditions. I feel that it should be the other way around.

c) Perhaps we should replace the "Path" text field in the layout create/edit form with a drop-down. The options would be the most commonly used ones (node/%, taxonomy/%, taxonomy/term/% etc) and there would either be a "Advanced" or "Manual" or "Other" checkbox (or drop-down option) to allow advanced users to manually enter a path.

Thoughts?

[docwilmot]

Or have all contexts available on the default layout.

[klonos]

...I have thought of that (or something like that) actually. You see, if one leaves the "Path" field empty, then the form throws a validation error upon submit because that field is required. I thought that perhaps we could have it so that the "Path" field is optional and that if there was nothing specified, then it defaulted to "all contexts". Did not know if that was sensible though so I never proposed that.

My main point is that the goal for specifying a path/context is to be able to define proper visibility conditions (whether these are on a block level or layout-wide). We have quite a few options for visibility, but we seem to have implemented a hard to understand concept (context) as a means of limiting these options. So, in practice, we provide an option that people do not understand 100% ("Path" field and the "context" that comes with it) and then based on the decision that they make for that initial option, we provide them with additional options (visibility conditions). The problem here is that the second set of options is what people know and are after when they start this task. So when they reach that step and see that some options that they expected are not available, it takes them some time to realize that this is due to not having made a "proper" decision on the previous step. Sometimes, they don't even realize it at all and they might think that this is either a bug or a missing feature.

So, imagine this dialog between a site builder and Backdrop:

SB: I want my site to have a different design when condition x is in effect.
BD: Yes, you can do that by creating a layout and defining a visibility condition for it.
SB: Great! Sounds easy. Lets go ahead and do that.
BD: Lets start by creating a new layout. Please let me know what you want to call it?
SB: Lets call it "Sports Articles Layout".
BD: OK, and what design do you want this layout to have?
SB: 2 columns.
BD: Next I need to know the path(s) this design will be applied to.
SB: ??? ...[looks at the default and default admin layouts for any hints - nothing! ...these layouts don't have any path or visibility conditions defined] ...??? ...Lets try the % wildcard.
BD: No-no. Can't use % as the first part of a path.
SB: ...[reads a few documentation pages] ...Alright(?)... lets use node/% then (not sure?).
BD: OK. Any visibility conditions?
SB: Well, of course. That's the reason I am creating this layout for. I want one condition for the node type to be Article...
BD: Sure...
SB: ...and another for when the article has a "sports" tag.
BD: Sorry, I don't have such a condition available.
SB: But I read that you do have that feature.
BD: Sorry, don't know what you're talking about.
SB: WTF?!? ...[goes to read more documentation and ask in the issue queue] ...OK, you know how I told you to use node/% ...well forget about that. Lets use taxonomy/% instead.
BD: Sure, but now you cannot use the condition for the node type to be article. Sorry.
SB: This is too hard... I GIVE UP!! _Backdrop sucks_

How about if we changed that to this instead:

SB: I want my site to have a different design when condition x is in effect.
BD: Yes, you can do that by creating a layout and defining a visibility condition for it.
SB: Great! Sounds easy. Lets go ahead and do that.
BD: Lets start by creating a new layout. Please let me know what you want to call it?
SB: Lets call it "Sports Articles Layout".
BD: OK, and what design do you want this layout to have?
SB: 2 columns.
BD: OK. Any visibility conditions?
SB: Well, of course. That's the reason I am creating this layout for. I want one condition for the node type to be Article...
BD: Sure...
SB: ...and another for when the article has a "sports" tag
BD: Sure...
SB: ...and another for ...
BD: Sure...
...
...
BD: ...in order to apply all these visibility conditions that you have just defined, I need to set the path/context to xyz.
SB: Whatever makes this work. I don't care. _Backdrop rocks!!_

[ghost]

Not precisely related to issue title, but if you just want "Sports Articles Layout", PR #1333 does the job...

http://1333.backdrop.backdrop.qa.backdropcms.org/admin/structure/layouts

[klonos]

Thanx @gifad for the very prompt reply. No, I am not specifically looking for that. The use case was just an example I made up in order to make my point - not an actual, real-life use case.

I did take a brief look at the PR sandbox and it does work, but what is the approach you have taken there? From a first, non-coder look it seems like the code handles only that specific use case with vocabulary terms being made available in the node context. My proposal here is to make this more generic so that users do not hit WTFs with the UI and the workflow when trying to add visibility conditions.

[ghost]

what is the approach you have taken there?

well, you wrote :

This is too hard... I GIVE UP!! _Backdrop sucks_

as this is more and more my opinion about the layout thing, and the weather was unpracticable this afternoon, I seized a favorable opportunity to change my mind, and tried and make something useful with it, and assert

Whatever makes this work. I don't care. _Backdrop rocks!!_

now, if this is not a real-life use case, and backdrop is just useful to add visibility conditions, I give up!! etc...

[klonos]

@gifad 😄

[quicksketch]

Thanks @klonos for opening this issue. It's a good topic and contexts are definitely problematic from a UX stand-point.

a) Allow multiple contexts to be added to a single layout ...so that multiple visibility conditions become available. This way, we save people from having to create and maintain multiple layouts with the exact design.

I don't think we have an issue for this yet actually. We do need the ability to add multiple contexts via relationships (i.e. get me the author of the current node) or possibly even arbitrary contexts (i.e. get me "Node 1" and let me use any data from it). However from what you've described, that's not quite what you're asking for here based on this part:

Now, say that for example I want a specific design to be applied in specific terms/vocabularies and in specific nodes or node types. The way to achieve this currently is to create two different layouts, one with a taxonomy context and one with a node context in order to be able to specify those conditions separately.

This is describing the editing of multiple layout paths at the same time. I see what you're meaning that it's cumbersome to position/configure a Footer or Breadcrumb block multiple times. However I can't think of a good UI for dealing with something like this. If you configured multiple paths at the same time, you'd want to go back and be able to edit the "collection" of paths again. But it's entirely possible you'd want to separate collection and edit the paths as separate layouts if they became too different, and you might want to join together multiple similar layouts into the same collection so you could edit them altogether.

b) Allow people to select visibility conditions and have the context be filled in automatically (or present a drop-down with options if there is more than one available).

This could be challenging from a UI standpoint. We'd definitely need relationships first in order to do this. If you're on node/%, there is no author context available for example. If you wanted to do something like show a block only if the author had a particular "User: Role", you'd need to be able to add relationships on-the-fly instead of assuming that the current, always-available context of the Logged-in user is what is needed. Right now we show a drop-down when multiple contexts are available:

But what you'd need to be able to do is define a chain of relationships (or pull from an arbitrary static ID) to get to the user you wanted. So from a node you might need to follow the author. Something like this:

But you wouldn't stop at that, you would need to be able to click the "+" to dig deeper, loading the user and then getting any relationships from that as well.

This idea here is basically that instead of defining relationships "up front", you'd do it as part of the process of adding a condition/block. I can see where you're coming from, but I'm not sure this would be friendly to more experience side-builders. You frequently want the same context over and over again. If you're positioning blocks from a user (referenced by a node) you wouldn't want to reselect the same chain of relationships every time you added a block or configured a condition. So we'd probably still want some way to save existing contexts that had already been added once.

Ah, this issue has got my head spinning. We definitely have at least two things going on here:

• Relationships.
• Editing multiple paths at the same time.

They are separate problems so it would be best to split this discussion rather than trying to solve them both at once.

[quicksketch]

Let's close this issue to have one that is more focused. I made an issue for adding relationships at #2134.

[quicksketch]

We also have an issue for having layouts work on more than one path at a time at #1528.

[klonos]

Relationships and multiple paths will be great and we do have issues for both these features, but what I'd ideally still want is to reverse the process of how proper paths (and context relationships) need to be defined before the various visibility conditions are made available. I would like to:

1. Have all possible visibility conditions available (both for blocks and layouts) - not only those that are tied to the path users (are forced to) chose. The UI that you have drafted with the drop-downs where the user has the option to "dig"deeper à la https://www.drupal.org/project/dhtml_menu looks nice.
2. Hide the path selection and context part of the UI under a "Advanced context settings" fieldset. Simple users do not understand (or need) this. It scares them away from one of our most-advertised features, so lets put it out of their way please (but still have it easily available for advanced users).

In general, instead of this:

select context (and context relationships) -> see what visibility conditions are made available

...I'd like us to have it so that:

select visibility conditions (and be able to "dig deeper") -> backdrop automagically sets the required contexts for you (and you do not need to even know that this happens - things Just Work™)

[jenlampton]

Have all possible visibility conditions available (both for blocks and layouts)

I think I could be okay with this if we could have a way to make the ones that won't work disabled. That way users could see that they exist, but wouldn't be able to shoot themselves in the foot by using them. It would clutter an increasingly foreboding UI with a bunch of useless options, but maybe that's still an improvement.

Here's an idea: What if, we didn't put them in the select list (which will be bad UX for power users, needing to skip all the non-options in order to get to the real options) we added another link similar to the token browser, that would display all the available options - and their related contexts - in a modal window? That could help inform the user what they need to do in order to reveal the "missing" options by adding the required contexts.

Hide the path selection [...] part of the UI under a "Advanced context settings" fieldset.

When you are creating a new page the first (and only) thing you need to define is a path. That's going to be a huge UX fail if people skip the advanced section (as they should) and then are immediately smacked in the face with a validation error when they hit save.

Hide the [...] context part of the UI under a "Advanced context settings" fieldset.

I like this idea. It would also create a place for us to add relationships, which would also be confusing to the new user. I would recommend that we also add a setting to expand this section by default for the more advanced user. (Just like we do with views). That will keep our pros happy.

backdrop automagically sets the required contexts for you (and you do not need to even know that this happens - things Just Work™)

This isn't possible. The site-builder needs to be able to tell Backdrop which thing provides the context.

For example: On a node I want to show the author's bio in the sidebar. I have defined a layout at node/% and need to load the author's profile block. In this example, I need a User context for that profile block. If a site-builder drops in a profile block and Backdrop automagically assigns a context, then anytime anyone looks at this node, they are going to see their own profile in the sidebar.

Why? Because that is the only User context that is available on that page... unless the site-builder adds a second context of node-author. Once that context is available, then the site-builder will also have to choose which of the two available contexts to use when displaying the profile block.

Now, let's complicate matters by adding a user-refernce field to the node. Say it's a book or something) and we have a field for "Influences" that references other users. Say it's a multi-value field! Now there could be any number of User contexts available on the page, and there's no way Backdrop could automatically assume the correct one.

There are just way too many site-building possibilities for Backdrop to make assumptions about context without input from the site-builder. In the places where context can be assumed (the path) Backdrop already does it.

[jenlampton]

With 15 days left before feature freeze and no PR here yet I'm not sure this is likely for 1.6. Pushing to 1.7.

[jenlampton]

Since this issue has already missed a core milestone and is not likely to be ready in 1 day (it's a big undertaking) I'm going to remove the core milestone. Let's add it back when this issue becomes a priority (and has a PR).