PLIP: Stacked container block settings so subschema blocks (slider, accordian etc) are easier/powerful by being containers

[djay]

PLIP (Plone Improvement Proposal) - Stacked Container Block settings

Responsible Persons

Proposer: Dylan Jay

Seconder: Jeff Bledsoe

Abstract

Currently subschemas is the only way for a block that is composed of one of sub items to have a UI that is easy to use by having all the settings for the main block and the sub items in one side panel. Examples are slider or accordion or form-block.
This proposal is to change the UI for containers so in many cases it would work just as well and look similar to the subschema based UIs but by being less customised code esp in inline preview, it would be be less work for block addon developers, result in a more consistent and functional UI. It also helps solve several other problems with the UI.
iThis will be done by stacking vertically the settings of parent blocks and providing navigation up and down and to manage subblocks, All within one tab of the sidebar.

Motivation

For certain Blocks that involve adding and removing sub components (e.g slider or accordian)

• The current UI doesn't make it easy to have more than 2 levels on containment which leads to artificial restrictions. Like not being able to have images or videos mixed with text in a grid column.
• it is more work that it needs to be to use subschemas because this is done custom for each case. There is no inline built in way to select the subitems, add, remove.
• the result is often inconsistencies in the UI with different ways to do the same thing for different blocks.
• making most complex blocks containers would make it much easier to extend. For example allow a slider of images instead of the inbuilt slide item component.
• Making a headless volto site is easier if you only have to implement containment rather than make special cases for complex blocks

Instead, with the right container UI, many blocks can achieve a similar but more consistent settings UI with less code.

The following are composable blocks that could be made into containers reasonably easily.

• slider (contains slide (but could also be a teaser with a different presentation)
• accordion block (contains accordion header which contain any blocks)
• tab block (containers tab which contains any blocks)
• form-block (could contain fields and could be extended to include any blocks)
• gridblock (contains any block, or could be set to be restricted to text or image)
• columns block (contains columns which contain any blocks (or just single text in some cases?)
• table (contains rows which contain cells which contain single text or any blocks)

There are two parts to this

• the ability to select blocks inside other containers in the preview area and act on them using the toolbar and add new blocks inline. This would need to be done in a consistent way which allows for custom buttons for some settings.
  • mainly covered by the quanta toolbar and where the add after button gets placed. I can create a columns block without having to hack the container primitive UI (quanta toolbar with nested block support) #4931
• changes to settings panel that make it easy to edit both the parents and children in an intuitive way. Ideally in a way that would not be too much of a change for how these existing blocks work, works well on mobile and with WCAG.
  • This is whats covered in this PLIP.

Assumptions

Proposal & Implementation

Blocks Stack sidebar

Using slider as an example, this is a rough mockup of how this could work with the least changes in pastanaga.

And when you close the child (slide/item)

This is how it currently works. As you can see it's not that much of a jump.

• Stack block settings for each parent container from the outermost and ending with the currently selected block.
  • Seperate them by a Block name heading.
    • i.e. the side bar now has three levels of headings. Block, Setting group, Field.
  • Each Block heading as a context menu to add after, delete, copy etc.
  • Note that for many blocks this won't result in more space than they already use, and probably less.
    • e.g. slider block currently renders all children headings + settings of the current slide. This will change to rendering just the current slide without all the sibling names (see below)
• clicking a block heading would select that parent closing the children under it.
  • scrolling up would allow you to edit settings without unselecting a child
  • you can also click "back" on a block heading which closes it and selects the parent.
• Selecting a block would render whole stack but scroll down to the bottom
  • So the currently selected block settings is fully in view
• Use sticky scroll
  • if parents settings can't fit then they are scrolled out of view except the block heading.
  • see vscode sticky scroll
  • so hierarchy is always visible as a kind of breadcrumb to make it easier to navigate.
• Container block settings always has a sub-blocks widget in it's settings
  • Uses a submenu type widget so you can "open" a subblock, but it also allows adding after and reordering.
  • isn't added by using a subschema.
  • bottom settings group for that block. (or could be the top?)
  • Similar to Order tab but It will only show the contents at that single level.
  • it would be hidden (or collapsed) for parents to save space. This would force you to close the child to add a new sibling.
  • In the case where all subblocks have been deleted a default block will be created as the first so it's never empty. If there is more than one sub block type allowed then a choose placeholder will be created.
  • Note this isn't that much different to the current UI for sliders, accordions, form-block etc except you can only expand one child at a time and the delete has moved into the child settings.
• change the known composable blocks to be containers.
  -Support storing Blocks in lists?
  - Lists are used for in some block schemas.
  - Perhaps containers could support lists storage for backwards compatibility and block ids added on the fly?
• (optional) Include the Page as the top level container and remove the tabs
  • saves some space. Could still include a button for order view?
  • Should be pretty intuitive. you keep scrolling up for more and more higher level settings. Click the word page to act on the page as a whole.
  • Including the page as the top helps fix settings button in the toolbar as it can now be a button for all settings. This would also allow us to remove the tabs and save space.
  • removing tabs gets us one step close to quanta also.
  • The order could perhaps be moved into the page settings. or be an alternative view of sub items opener widget

These examples are with full quanta styling and removing the tabs and having the Page is the top level container

• A single slide is selected (note how we have also gained the ability to "add after" and delete etc inplace)
  • 
• We close the slide and the whole slider is selected
  • 
• This mockup shows how tables would work. it is a table that allows many paragraphs per cell which isn't how the default table works but you get the idea.
  • 

Deliverables

• PoC UI using gridblock or columns block
  • stack multiple block settings in one sidebar
  • click on heading to select a parent (or close a child). and click on preview.
  • render a open widget for subblocks
  • sticky scroll for the block headings
  • remove extra preview buttons that aren't needed.
  • put add after in the right place
• menu to add, open subblocks
• Show parents blocks settings and merge tabs
• Sticky scroll
• Context menu to cut,copy delete etc.
• Convert other blocks

Risks

• UX that becomes harder
  • currently clicking on a slider always selects the whole slider. Now it will likely select a child. So enter or add now adds a new slide, not a new block after the slider which might be confusing. You now have "close" the child to select the whole slider and add a new block after.
    • conversely this now means you can add a slide inline which you couldn't do before
    • you already had this issue with accordions and tabs anyway.
  • Grid blocks
    • 
    • This is an example of a block that would change the most. It was 2 add buttons (inside and after), a settings button (which is the only way to get to the block settings) and it has an inconsistenacy that slate blocks inside work differently that slate blocks outside. You can't mix images and text inside a grid currently.
      • So while it's a risk that the changing the UI could lead to resistance, mostly its for the better
  • Table block
    • This will need some tweaks. Adding a cell after the current one should let you edit the next cell or add a new column? You will need shortcuts inside the settings and quanta toolbar to make adding a row or column easier than navigating to the parent block and adding there.
• if we remove the tabs, do any plugins use custom tabs? if so where would that go?
• backwards compatibility
  • shadows on these blocks would break
  • schemas of those blocks might need to change
• while this would still work without the quanta toolbar, it would work better with it, and fixing the inline add button and selection marker as these give additional context on what block the user is editing.

Participants

Context

The inspiration is the simplicity of the design for tables in Quanta.

• Here there is a setting for of "current cell" that change based on selection.
  • 
• We are extending this idea further with the stack of blocks.

Future extensions

With a standard UI we could potentially get rid of a standalone listing block. Instead a source could be added to any container to automate it's contents with the fields from the listing source being mapped into the subblocks. similar to - #4478

Other solutions considered

Order tab and one block shown at a time

The incumbent solution would involve using the order tab and perhaps adding in add/remove functions and indenting to show containment.

Pros

• easier to move a block between containers
  • in the stacked approach you could still support DND to a parent by dragging into the parents settings. And you could support DND from a parent into a direct child. But you couldn't support DND into a deep child. But you can always use cut and paste instead.

Cons

• harder to get to settings of parents. you can only show one block settings at a time. more clicks due to this
• currently no breadcrumbs or navigation aid when in a deep container to understand the container relationship.

[djay]

@plone/volto-team this is ready for review