Add: Absorb block UI on parent mechanism. #42684
Conversation
jorgefilipecosta
added
the
[Feature] Patterns
|
Size Change: +975 B (0%) Total Size: 1.26 MB
ℹ️ View Unchanged
|
|
Thanks @jorgefilipecosta, this is fun to play with!
Personally I find that this behaviour kind of erodes the 'single unit' editing experience that we're aiming for. It would be interesting to try having the toolbar retain position based on the root-level container, regardless of which child block is selected. Granted we may need to do something about the parent selector to handle additional nesting, but we can cross that bridge when we get there. Regarding the Inspector:
Since the listed blocks serve as links to their associated settings panels, I find the separation of 'parent', 'content', and 'selected block' to be a bit strange. It feels a bit unexpected how blocks like Image just 'pop' into place when you select them on the canvas. Maybe its worth trying how this UI would feel if it looked more like list view? Speaking of which, we might also try simplifying Section appearance in list view. Essentially migrating the nested blocks from list view to the Inspector. A rough mockup:
Thinking a little further down the road this can potentially work well for synced patterns with overrides, where everything is locked except for content:
Looking at the mockups above it seems to be there's scope to define a more coherent relationship between the block name / description and its children, but that's also something we can look at in more details if the general ideas work well. |
|
Hi @jameskoster, thank you for the feedback!
I can give it a try to have the toolbar on the parent.
I think the whole idea of showing the content blocks was to allow the user to easily go to the blocks where there is content in a very complex pattern without needing to worry about the hierarchy of blocks. I can easily know which blocks are content that I'm supposed to change. But I agree parent content selected seems a bit strange. Ideally, we would just have content, but I faced a challenge if the user really wants to open the inspector of a non-content block, how can we allow that? The solution I found was to show the selected block so the user can easily open that inspected if needed, but I guess we can just show content and have some button or better UI to open the inspector of the selected block. |
Isn't the easiest way to do that to simply click on the canvas? Seeing as the block links in the Inspector are only opening settings panels, I don't really see any need to give content blocks increased prominence. |
That's one way to do it but also, having a list of all the content seems like an option. Sometimes there may be text on a pattern that is not supposed to be changed while another text is really content that is supposed to be changed. I guess showing clearly what is content helps to better identify what should be changed.
They are opening the settings panels but also selecting the block. So if we go for this proposal: Where we don't give content blocks increased prominence, we discard this UI where we are giving more prominence: So the plan is to not have a list of content blocks anywhere? |
shaunandrews
changed the title
|
The problem (as you already identified) is how to handle non-content blocks. The 'selected block' ui feels a bit awkward, and also extends the process to access block settings to two clicks (click once on the canvas to select, click again in the Inspector to open the settings panel). We also need to consider that non-content blocks can potentially have overrides too.
I think it all depends on how we handle overrides of synced patterns. I shared a prototype recently in #34352 (comment), which I've updated a bit here to demonstrate the flow of editing an un-synced pattern (IE a group) and making it into a synced pattern (sound on): absorbedd.mp4It would be good to get @SaxonF's input here since he has thought a lot about all of this :) |
|
@jameskoster and @jorgefilipecosta: on the toolbar debate, I wonder if this could be an interesting middle ground: #42399. The "main" toolbar would sit by the container block, and occasionally inline controls might float next to whatever text is being edited. |
|
We had a fairly extensive discussion about this one on Slack, here’s a summary of the action points we came up with for this PR (@jorgefilipecosta let me know if I missed anything): When a container is ‘content locked’:
Needs design:
Considering the fairly significant reduction of interactive elements these features will produce, the current toolbar behaviour may actually work just fine. But it's good to have the ideas mentioned in comments above, and the setting @mcsf pointed out, in the back pocket and ready to try. |
|
Closed as now content lock is available in #43037. |
Part of #39281.
This PR implements a mechanism where a block, e.g., pattern, group, etc., can specify it absorbs the UI of the descendants.
If a block is absorbing the UI of the children, there are some changes happening:
A block is a content block if any of its attributes have a content role no matter where on the hierarchy that block is. I guess if we have schemas for patterns, we can also rely on schema information, and we could also try to expand the roles we consider content, e.g., in some cases, an image could be content of a pattern.
Jul-25-2022.2018-53-10.mp4
Jul-25-2022.2018-54-45.mp4
cc: @mtias, @jameskoster, @mcsf Any feedback on this exploration? What do you think should be the next steps to explore, or what can we improve on this try?
API
To mark a block is absorbing thethe UI a block needs to define absorveDescendentUI attribute as true. For now only group supports this. The attribute needs to be added to the code editor. We don't yet have any UI for it.
This allows us to test the behavior in a simple way.
In the future, how we specify absorbing behavior is something we need to find out. Should it happen only for pattern blocks? Should it happen for all patterns or just some patterns?
I used the group because the pattern block for now still does not supports saved innerblocks, so the group is a good target to test this behavior.
Testing Instructions
Paste the following block into the editor and interact with it:
Verify the behavior is the one described above and shown in the screenshots/videos.