Blocks Layout Navigator

[sneridagh]

Supersedes: #4745

Screen.Recording.2024-06-10.at.09.45.32.mov

[netlify]

✅ Deploy Preview for plone-components canceled.

Name	Link
🔨 Latest commit	b74d0f1
🔍 Latest deploy log	https://app.netlify.com/sites/plone-components/deploys/66694bed0aa68d00085eb069

[netlify]

✅ Deploy Preview for volto canceled.

Name	Link
🔨 Latest commit	af56e9c
🔍 Latest deploy log	https://app.netlify.com/sites/volto/deploys/664653c326cf9700073e5d00

[tiberiuichim]

May I suggest the following UI changes:

• Don't name the tab "Layout", as the term is already used in the "Dexterity Layout" feature
• Hide the block UIDs, show them as a tooltip
• Allow the block configuration to provide a preview component. For example, for the image block, a preview component could look like (pseudo-code):

Image (...image title or alt)

When hovering over the text, I would get a floating thumbnail of the image.

For the slate text, the preview component could be like:

...cropped text (first two words)

When hovering over the text, I can get a floating preview of the entire text block.

[sneridagh]

@tiberiuichim no worries, still under development, I just updated it. There are a couple of things to polish and others that do not work well. The UI should be far more fancy, for sure. Now it's debugging mode :)

[djay]

@sneridagh I would be inclined to have it more hidden away. Instead of a tab, it could be inside the block tab at the top as a rolldown. So when collapsed it shows the indent and identity of the current block. uncollapsing it lets you see the current block in context of parents and switch to another block.

[djay]

@sneridagh I'm not saying to change how it works. It's great and it's an important part of the decoupled editor.
Im just suggesting making not in another tab and having it be a drop down at the top of the block so it also acts as a single line breadcrumb making it better still.

[sneridagh]

@robgietema I've end up by commenting out the onFocus that was stealing the focus from the slate block on creation.

26b5632

I cannot see any different behavior by removing it, probably I'm missing an edge case. If it's that so, we have to come back to it, but for now, it's good enough for me not to hold it any more.

[davisagli]

Look at your web stats and tell me what clients are editing your sites 99.9% of the time.

@stevepiercy I would not trust the stats for this on a system that does not work well for editing on mobile. See: https://en.wikipedia.org/wiki/Survivorship_bias

[stevepiercy]

@davisagli drag and drop on a tiny mobile screen is difficult to use, if not impossible. It's a matter of choosing the right tool for the job. You can choose not to trust the data and insist that DnD be fixed, but then you would spend significant effort on something that is extremely difficult to implement.

[davisagli]

You can choose not to trust the data and insist that DnD be fixed, but then you would spend significant effort on something that is extremely difficult to implement.

Oh sorry, I jumped into the conversation in the middle and wasn't trying to argue against merging this PR. I think the new navigator is an improvement over the status quo for all screen sizes, both in terms of usability (it's hard to drag large blocks currently) and maintainability.

[ichim-david]

@sneridagh @robgietema there is no drag handle visible on FF and trying to click and drag within the section where the icon should be doesn't do anything.
The Block is highlighted in the order sidebar and in the main section but no drag ability.

This doesn't happen in Edge where the drag handle shows up and you can drag.

[ichim-david]

@sneridagh besides the missing functionality altogether on FF there has to be some regression introduced recently as it seems that even on Edge and Safari although I can drag and drop it doesn't change the order, have a look at this screen recording.

drag-not-changing.mp4

[ichim-david]

@sneridagh sorry for all of these extra comments, I found out why the drag and drop doesn't work on Edge and Safari,
it happens when you have an unknown block, you cannot do any reordering until that unknown block is removed.

unknown-block.mp4

Don't know if you want to try to treat this or simply add a documentation entry that it won't work until those blocks
are removed.

EDIT: the issue on FF remains even if I am on a page without any unknown blocks

[sneridagh]

@ichim-david thanks for the report.
This is bad news, since Rob is out for the next month.
@plone/volto-team it would be great if someone is up to look into the issues raised. I don't have to tell you how important is this feature to be in core, and what they mean for the user experience.

[sneridagh]

@ichim-david I think I quick fixed the FF problem, please take a look.
I guess the "unknown block" can be addressed lately (if we think it's still a relevant issue).

[ichim-david]

@ichim-david I think I quick fixed the FF problem, please take a look. I guess the "unknown block" can be addressed lately (if we think it's still a relevant issue).

@sneridagh Confirmed working now on FF. Up to you on how you think we should proceed about the unknown block. For me it's enough to have a doc entry that it doesn't work on pages where you have unknown blocks until you remove them.
We could also give it 1-2 days to see if we can figure out what's the issue there but it might take longer to figure out and we would be ok with this release with info about this limitation.