plone
Blocks Layout Navigator
Supersedes: #4745
https://github.com/plone/volto/assets/486927/8bdaf35d-3828-49c4-b1ef-78255811d99d
Deploy Preview for plone-components canceled.
| Name | Link |
|---|---|
| Latest commit | b74d0f1ac2d101b6dea39c51a35669d3109e09d2 |
| Latest deploy log | https://app.netlify.com/sites/plone-components/deploys/66694bed0aa68d00085eb069 |
![netlify[bot] avatar](https://avatars.githubusercontent.com/in/13473?v=4 "Published by a pub.dev verified publisher"){kind=small}
Deploy Preview for volto canceled.
| Name | Link |
|---|---|
| Latest commit | af56e9c086fc146061cfd376a139e5fa11a5c2a7 |
| Latest deploy log | https://app.netlify.com/sites/volto/deploys/664653c326cf9700073e5d00 |
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.
@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 :)
@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 the block tab is specific and contextual to a single block. This feature is global to the page, same as the "Metadata" tab. IMHO, having this feature in there, also bloating the tab itself it would be wrong. The fact that Elementor and others place this feature globally also confirm that this decision is ok.
@djay the block tab is specific and contextual to a single block. This feature is global to the page, same as the "Metadata" tab. IMHO, having this feature in there, also bloating the tab itself it would be wrong. The fact that Elementor and others place this feature globally also confirm that this decision is ok.
I agree with Victor on this one.
@sneridagh maybe. But that's only becuase you currently have the mental model of the block tab being there only when the block is selected rather than always being there. To me it just clutters up the tabs on the top and will make it harder to use on slim devices like mobile. The fact that there is going to have to be a name for it like blocks or layout signifies this waste of space and I can't see it being clear to the user from whatever name you settle on.
you also lose the ability to see the breadcrumb or structure of thrr current block while looking at the block. So that would have to added again somewhere else like at the bottom of the screen like on gutenburg, taking up more space.
Single line at the top of the block tab seems like a good deal to me. It could replace the current label for the block type so there is no loss in space.
@djay did you try the last version? Please do.
@robgietema has spent a lot of time debugging and polishing the interface so it's not only showing, but also interacting with the rest of the page. To me, this feature is by far one of the best additions to Volto in the last four years. It not only addresses the d&d inside containers, but also provides a user experience while editing quite unbeatable. Combined with the Volto 18 improvements (and the one that is coming in the main blocks zone d&d experience) it's the best that we ever had.
I had to double check StoryBlock too, they also in the first level, as global settings, not inside the block settings, as one could expect.
This is so much better than what we and other CMSs currently have.
make it harder to use on slim devices like mobile
Who edits a site on mobile? Come on, let's get real. Look at your web stats and tell me what clients are editing your sites 99.9% of the time.
@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.
@robgietema I've end up by commenting out the onFocus that was stealing the focus from the slate block on creation.
https://github.com/plone/volto/pull/5642/commits/26b56324d524ea854c7e47868919c620f51fb168
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.
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
@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.
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.
@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.
https://github.com/plone/volto/assets/152852/bcda59cc-f5a8-4e6d-97dc-76306b2cc5b0
@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.
https://github.com/plone/volto/assets/152852/9202d1c2-e768-4f87-add2-e881009e079d
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
@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.
@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 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.