[UX] Display all available blocks (with instructions on how to get them)

[klonos]

None of the layouts that we ship with core has node/% as path, thus people trying to add a field as a block won't be able to figure it out unless they have good knowledge of the internals of layout paths/contexts. This is something that has made me scratch my head more than once and it honestly is a shame to have in-built such an amazing feature, but not expose it prominently or at least in a way that's easy to figure out.

Possible solutions:

1. We could ship core with another layout that has its path set to node/% and includes a field block. A good candidate would be a "Post" layout that has its visibility set to only post nodes and the main content is a display without the image field so we can have that as a field block placed in a sidebar region.
2. We could show all blocks in the block selection dialog and have the ones that are not available be in a disabled state (grayed out) with a note in the form of "This block is available only in layouts that have the Node context. For example their path is set to node/%". That should be enough to give people a hint as to why the blocks they are looking for are not available and also as to what they need to do.

---

PR by @docwilmot: backdrop/backdrop#1637
PR by @jenlampton: backdrop/backdrop#1854
PR by @klonos: backdrop/backdrop#3179

[docwilmot]

We could show all blocks in the block selection dialog and have the ones that are not available be in a disabled state (grayed out) with a note

I like that one best. But perhaps we should just do both. Layouts we say are one of our best features, and we should ship with it on full(er) display. Also a layout for user/% with user image block in the sidebar, and/or for /contact.

[klonos]

Also a layout for user/% with user image block in the sidebar, and/or for /contact.

Yes! 👍 for more default layouts with core that users can use as examples or easily tweak (instead of having to create from scratch). I'll file a separate issue for that.

[olafgrabienski]

None of the layouts that we ship with core has node/% as path, thus people trying to add a field as a block won't be able to figure it out unless they have good knowledge of the internals of layout paths/contexts.

Additionally to the suggestions, we could improve the help text at the page where a layout path is defined. It's kind of cryptic and made me scratch my head as well. (Better a separate issue for that?)

[docwilmot]

Worked with blocks again last evening, fixing #1704, and I'd say this issue here is a good one. Its a great, but really hidden feature. Can we have a chime in on the options?

1. ship core with another layout that has its path set to node/% and includes a field block.
2. show all blocks in the block selection dialog and have the ones that are not available be in a disabled state (grayed out)

@everybody

[docwilmot]

Pushed PR trying out 2nd option.

[docwilmot]

[klonos]

Thanx @docwilmot. I took a look at the PR sandbox and I think that this is an improvement that should get in, BUT...

1. This solution will only help people like you and me that are aware of this issue/limitation and also annoyed by it so much so to remember what they need to do next. It tells the user what they cannot do, but doesn't give them options or guidance as to what they need to do next. AFAIK, all other places in the admin UI that have disabled things give you the option to enable them (usually a couple of easy clicks away, through a checkbox or a drop-button).

   A way to work around this would be to create the respective documentation on b.org and link to it from the help text/description of these "disabled" fields.

   Nevertheless, this is better UX than having people wondering where the hell the feature we advertise is, but still, not a good UX as we are leading the user to a dead-end. Ideally, there would be some "add required contexts" button/link there that would "magically" do that for the user.

2. I would still like us to add a new layout in core with node/% as context, because consider the current situation:

   • we advertise the fields-as-blocks feature
   • we ship core with the home, admin and default layouts,
   • none of these layouts have node/% as context, so all nodes fall back to using the default layout
   • so, if one wants to add a field as a block, they have no way to do that out-of-the-box.
   • If they are knowledgeable, they'll figure it out, but still we have them do extra work so they'll think that Backdrop is "hard".
   • If they are new-comers or just less savvy, they are likely to give up trying. If that feature was one of the main reasons why they were sold on Backdrop, they are more likely to give up Backdrop altogether.

   By providing a node layout out of the box, we do some of the hard/tedious work for them -> UX++
   By having a field already placed as a block in that layout (articles with their image field on a sidebar make an excellent option), we give them an example that they can tweak or copy. Teach a man to fish...

3. I would still like us to revert the process of define context -> have features available if we can figure out an intuitive way. People do not understand contexts and in my head this is like for example to first have them manually join database tables before using relationships in views.

[klonos]

I might give the 1st option a go if nobody beats me to it. That way, if we can get both PRs committed, I believe we'll have improved the situation a great deal 😉

[klonos]

...although, I find this a very big usability issue and if we nail it, then I think it shouldn't wait till 1.6.0.

[docwilmot]

A way to work around this would be to create the respective documentation on b.org and link to it from the help text/description of these "disabled" fields.

I think this is the primary option here.

Personally I dont think the situation is as cryptic as you describe here. Its not intuitive, so requires access to an explanation, but the explanation is simple. "You cant put a block that needs a node on a page that doesnt have a node". That is the essence of the context thing. Its quite sensible IMHO.

Ideally, there would be some "add required contexts" button/link there that would "magically" do that for the user.

Of course once we've explained in the docs and linked them, the user will recognize this is impossible. No button/link can add a context to a page. You have to create the page with a context. It has to already have a node or user etc on it.

I would still like us to add a new layout in core with node/% as context

Having said all that though, I still agree we should have many more out-the-box layouts predefined, and I agree it would help to understand contexts a bit.