Implement the block-by-theme listing page

@xtfer @bojhan

Awesome! Bojhan and I have been discussing some minor changes to that design. He has a copy of the file as well and may have altered it already. I'm going to ping him in IRC and point him here so he can share the latest design.

Awesome @xtfer. Post patches often while you work and so we can iterate quickly on this issue.

Also related #1998698: Allow Dialog Controller to work with form/entity form routes

@xtfer: how is it going?

@xtfer

Bojhan revised the design to apply the seven styles (from the new style guide) and removed the concept of the slide out drawer in favor of using the meta information paradigm already implemented in the content creation page.

I like the fact that this leverages an existing pattern and that it removes the need for new javascript. I am concerned that it may not scale but we can iterate on it as we go to mitigate that if it proves to be a problem, perhaps by introducing internal scroll into the categories if they exceed the length of the form.

@xtfer: are you using a sandbox to work on this? Are you still working on this? It is kind of important we get this done in the upcoming 2 weeks in case there are API changes needed to implement it (also to help validate the existing work from SCOTCH).

Yay, looking forward to it!

Woohoo! Didn't catch that this was spun off. I know we've been looking for more applications of the right sidebar as we introduced it on the create content screen. This looks like a very good candidate!

@xtfer: should we try to convince someone else to work on this?

Note that the whole PluginUI business is currently only used by the block module and never underwent a thorough code review, and it's probably almost certainly unnecessarily abstracted. We might need to mark it deprecated if we can't remove it entirely by code freeze, but ideally we should try to get this done in the next 10 days.

Bumping to critical; this is release-blocking.

@xtfer: you don't need to completely solve anything in the first patch :)

WIP is totally fine @xtfer! Each of us is an expert on some little part of Drupal. Sometimes it takes a village to build something complicated.

I have a bit of late feedback (I missed the shift to the new issue).

I'm not sure if moving the place block functionality from a modal to a sidebar is an improvement for three reasons:

1. This functionality is always on whether you need it or not, it adds visual noise to the page. The beauty of a modal is the functionality only appears when you need it then disappears.
2. The "place block" title no longer makes sense, it's an action, which implies you click on it to do something. This can be easily fixed by making it more descriptive of the content below it. “ Available blocks” doesn't sound right but something similar would work.
3. There's no way this will work well on mobile. I understand we are aiming low here but I'd rather we didn't introduce new interfaces that are not very usable on mobile. A modal solution would be much better.

Also, I just realised that the dashboard module had the UI to solve this exact problem. Maybe we should just use that? :-)

@Lewis The Dashboard UI was horrible, I don't think many people actually used that. The reason we are not using a modal is primarily because its moving the "add" functionality further away.

1. Yes, this is unavoidable and a sad downside of this solution.
2. Agreed, we should re title it.
3. This will actually work on mobile, because when you click a block - you will get a modal to configure it, this includes a region selector. This is also needed for a11y purposes. If the modal is mobile friendly, . the interaction itself will be mobile friendly

The following interaction flows are not yet defined by designs (or I don't know where to find them):

• Menu links (shown in a mockup)
  • Block type
  • Blocks
• Add block type form. Requires specifying
  • Name
  • Description (optional)
  • Fields
• Edit block type form
• List of blocks (missing!)
  • Where is the access point? A menu link? I don't see this in the current design.
  • This is the page that will list blocks and provide operations for each one like edit and delete
• Add block form. Requires specifying:
  • Step 1:
    • Chose Block type (if more than one exists).
  • Step 2, details form:
    • Title
    • Region placement (optional)
      • If Region is specified, then we create a block and an instance of that block at the same time. Both have the same name and description.
    • Fields
    • Visibility (optional, depends on Region)
      • If Region is specified, then visibility rules must be exposed.
    • Revision settings
• Edit block form
• Place a block interaction: Drag/drop? Keyboard UX?
• Place a block details form. Requires specifying:
  • Title
    • Pre-populate with the parent block title
  • Visibility rules
  • Region placement
    • Pre-populated if this form was opened because a user associated a block with a region e.g. by drag/drop

If designs exist for these flows, please link to them in the issue summary.

I just had this thought that a placed block might be analogous to a view mode of an entity.

Added a related issue

added the list of forms

Updating title to reflect the reduced scope of this issue. This will no longer be the "implement the Blocks UI" issue. That goal is too large and amorphous. Instead, we'll track the many sub-issues in #1875252: [META] Make the block plugin UI shippable and break the effort down into manageable chunks.

Heads up that #2029321: Provide list and form controllers for EntityViewMode and EntityFormMode is evolving to having a similar setup: a list of sections, where you can add stuff to each. Difference is you create new ones instead of adding existing ones (view modes in that case over there). Would be good to see if we should try and match these interactions or not. (The 'Add X' button for each section as in https://drupal.org/files/Layout.png would cover both?)

NR for the bot, then we can set it back to NW. :)

De-prioritzing and postponing on #2055853: [meta] Improve the place block UX; Separate interaction from the create block UX; Improve the existing blocks-by-theme layout, which is a much more narrow scope. After #2055853 is complete, we can reevaluate the further improvements we have time to layer in in this issue here.

I actually feel that this is pretty much a duplicate at this point. If we want to add specific additional improvements following #2055853: [meta] Improve the place block UX; Separate interaction from the create block UX; Improve the existing blocks-by-theme layout, let's file them individually and track them in #1875252: [META] Make the block plugin UI shippable.

removed list of forms