Replace complex blocks settings with a unified container UI

[djay]

Responsible Persons

Proposer: Dylan Jay

Seconder: Jeff

Abstract

Change most complex block types that are composed of sub items into containers (e.g. slider or accordian) and change the sidebar settings UI to one that makes it easy edit the settings of the main block and its sub blocks at the same time.
This will be done by having all parent blocks settings displayed in the settings as well as the currently selected child and using a sticky scroll system to keep context and make it easy to navigate.

Motivation

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

• it is more work that it needs to be to create such blocks because this is done custom for each case
• the result is often inconsistencies in the UI with different ways to do the same thing for different blocks.
• making these containers would make it much easier to extend. For example a slider of images instead of the inbuilt slide component.
• 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.

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) plone/volto#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

Sticky scroll block hierarchy settings

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.

• Merge the page and block tabs into one
  • or alternatively remove the tabs completely including the order tab as it is could end up being redundant. This would save space.
• replace with headings for each parent container starting with the Page and ending with the currently selected block.
  • ie the side bar now has three levels of headings. Block, Setting group, Field.
  • This would make it look similar to the table mockups in original quanta design where "current cell" has a heading except that "Cell" is now a block level heading.
    • 
  • 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.
  • Each Block heading as a context menu to add after, delete, copy etc.
• Use sticky scroll so hierarchy is visible as a kind of breadcrumb even when deep. Allowing quickly jumping to a parent.
  • clicking a block heading would select that parent. 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 goes up the parent.
  • see vscode sticky scroll
• If a container is selected then the bottom setting group for that block is "Blocks"
  • Uses a submenu type widget so you can "open" a subblock, but it also allows adding after and reordering.
  • 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 there is only one block allowed this would just be created and no Blocks widget is needed
  • 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.
  • Lists are used for in some block schemas. Perhaps containers could support lists storage for backwards compatibility and block ids added on the fly?

Another example of how this would work is the slider block

• 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
  • 

Deliverables

• Start with grid block as it's already a container
• 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

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

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]

Not sure this is the right place for it but this is an idea that tries to solve a few different things.

• navigating around blocks esp parents
• adding a block without selection being enabled. and as a secondary way
• quanta removing tabs on the sidebar
• just generally how to make containers less confusing.

The idea follows on from quanta design for tables, where cell settings are part of table settings but I've generalised it.

• All the settings of the current selected block and each of it's outer containers is shown on the sidebar at the same time.
  • Top level block at the top to selected at the bottom
  • Within each block section there can be collapsable sections
• if a container is selected then the last section is blocks navigator that lets you add, remove, reorder or open a sub block. It can be collapsed like any other section.
  • or maybe removal can be moved into the subblock settings?
  • this does allow for multiple named slots within one container
• Opening a sub block replaces this section with a block panel for this opened block. So it's at the bottom.
  • this is the same level as the block title at the top of the sidebar so there is no indentation. The more levels the sidebar just gets longer.
  • selecting the subblock on the frontend does the same but will scroll the sidebar down to this section
• closing the subblock selects the parent
  • and shows the container subblock selection again
• if you scroll down, possibly the block heading could stick at the top of the screen to make it easier to jump to the parent?
• Some blocks might not have any settings other than subblocks.
  • we can possibly not show the parent when the child is selected/open because it will be empty. closing the child when open the parent anyway.
• Table is kind of a special case because we generally want to add columns instead of cells to each row.
  • There should be a way to add custom actions to a block that know about subblock selection and can act on it.
    • so the table block can then have special add row before, add row after, add column before, add column after etc buttons.
    • this can appear on both the quanta toolbar and in the table settings.
• This subblock navigator would appear on the page settings also since the page is itself a container
  • but in this case opening the subblock doesn't leave the page settings at the top. instead opens that block as the top level.
    • it would just get too much page the page settings always at the top of the sidebar I think

Here are some mockups

TODO:

• where does remove block go?
• should there be a quanta toolbar menu replicated in the sidebar
• currently the add in the sidebar means you have to go back to the parent, add at the top and then move it. You can "add after" current block like you can with the frontend add button. Is that a problem?
• in a table, if you did add a cell to a row, this should automatically create a column instead? should this kind of customisation be baked in or can setup rules like this yourself?
• the close button for the top level block and for a subblock have different meanings. For the top it means close the sidebar and leave the selection unchanged. for the subblock it means select the parent.
  • maybe use a different symbol? like a back icon?
• if you edit the title of an accordian, does it change selection to the accordian and lose selection of the inner block?
  • ie can you change parents with selection switching to just the parent

[djay]

I did a mockup of including the page settings as the top most pinned accordion. It is a container. It also means the settings in the toolbar can be just a toggle to open or close the sidebar (plone/volto#3912)

Settings on the toolbar would open with the sidebar scrolled to the top showing the page settings. Clicking a block would include the block and its parents on the sidebar (skipping any with no settings like Row). If the selected block is a container you can manage it's sub-blccks or select one. And if you want to go to the page settings then you just scroll up (or you can unselect the table)
I've also put in a block menu so you can delete, cut copy blocks etc. That lets you move blocks out of containers.

[djay]

I've made mockups for how sliders would work.

One complication is that for a slider you need to slide the selected slide into view on sidebar selection.
Todo this we will use the data-block-selection (see readme) or a callback

[djay]

@JeffersonBledsoe I think first step is to make this a PLIP