List View: try respecting a max width #35605
Conversation
|
Size Change: +388 B (0%) Total Size: 1.07 MB
ℹ️ View Unchanged
|
|
Here I am grouping stuff until it's 8 nesting levels deep and starts stacking:
Nice, this feels like a good safety valve. It might even be all we need to do to handle this, considering it'll likely be a 20% edgecase that needs this guardrail. If we need to do more, we can look at collapsing/hiding ancestors smartly, or just handling some horizontal scroll. I don't know that this needs any additional tweaks. What do you feel is missing to land this? |
The site editor has a number of blocks with long labels, so the width of the sidebar can change pretty easily when we nest only 2 or 3 in. For example: "Query Pagination Previous". Other languages like German probably push this out even further, so I think we do need to help limit the block label size. |
|
Ah right, good point. I think we might need some eliding (text-overflow: elllipsis;), I'll take a stab at that. |
|
It may just be me but I find the stacking very confusing because it eliminates all visual hierarchy cues. In the following gif none of the clicks behave in a way that feels predictable:
If there is a way to preserve that visual hierarchy – even its a case of reducing the indentation to a few pixels – I think that would be enormously helpful. |
We don't limit nesting programmatically so if this is something we favor, we'll need to think through horizontal scrolling. One thing we should try to avoid is having the sidebar take up so much space that the main editor panel is unusable. Modifying the limit to 4 was just an example. I'm fine with keeping this at 8, but I suspect we do want to help limit label length. |
Horizontal scrolling is worth exploring as an alternative to stacking I think. I do worry it will also feel a little disorienting though. Is it worth asking the question: do we really need to visually support extreme nesting? In Figma (for example) they just hide the contents altogether: nesting.mp4Not ideal, but how often do folks really need to nest that deeply? Maybe we can mitigate how soon this effect occurs by revisiting things like spacing / icon size and further optimising the use of space. Ultimately, the more I think about this the more a user-customisable width (probably with sensible min / max values) feels like the best all-round solution. |
If it's possible people will do it ;) I think a hard overflow:none is a little too unfriendly for the extreme edge case. If need be we could try to pair up a horizontal overflow with resizing if folks feel pretty strongly. Note that I am seeing items go over 350px width in the site editor at a more reasonable 2-3 depth. |
|
Just to be sure I'm getting this right: the vertical stacking of items will only ever happen if you nest 8+ levels deep, correct? Or will it also happen if labels are really really long? In case of the former, stacking feels like a decent alternative, or at least a simple holdover, to both horizontal scrollbars and more advanced behaviors. |
On trunk that is correct, on this PR it occurs at 4 levels. For me the stacked approach feels very awkward to use, at any level. One of the key components of trees like this is the visual communication of hierarchy, so when it no longer does that effectively the usability degrades a lot. I'm not sure I've ever seen a file tree UI do this 🤔 Perhaps it's worth trying the horizontal scroll with no stacking? |
|
I think it's worth a shot! One of the challenges with this is that actions were added into the ellipsis menu which is aligned to the right. So if we do have a horizontal scrollbar, then currently folks will need to scroll to the right to access actions. It's something to think through. In some native desktop applications, resizable sidebars don't have this problem since they rely on right-click for additional options vs a visual button. (I'm not suggesting we add right-click but wanted to leave a note). |
This feels like a really important point. |
| // Indent is a full icon size, plus 4px which optically aligns child icons to the text label above. | ||
| $block-navigation-max-indent: 8; | ||
| $block-navigation-max-indent: 15; |
There was a problem hiding this comment.
If we want to allow arbitrary levels, it'd be ideal to be able to do some margin-left: calc( $icon-size * $aria-level ). Unfortunately it doesn't look like https://developer.mozilla.org/en-US/docs/Web/CSS/attr() has good support, so we bump this to a highish number that doesn't generate too much css from:
@for $i from 0 to $block-navigation-max-indent {
.block-editor-list-view-leaf[aria-level="#{ $i + 1 }"] .block-editor-list-view__expander {
@if $i - 1 >= 0 {
margin-left: ( $icon-size * $i ) + 4 * ($i - 1);
}
@else {
margin-left: ( $icon-size * $i );
}
}
}
|
Interesting, there's also named labels. I'll rebase in a bit with trunk after I finish up some other work.
|
gwwar
force-pushed
the
update/list-view-maxwidth
branch
from
a8d6515 to
376749c
Compare
|
Rebased with trunk to get the latest list view label changes 👍 |
|
For the ellipsis, we can try making it sticky so that regardless of scroll point it's always easily accessible. I made a quick prototype to try this and horizontal scrolling:
You do end up with these peculiar "empty looking" rows like the Paragraph at the bottom of the tree, but that is inevitable with infinite nesting if we preserve the visual hierarchy. To (somewhat) remedy that we might reduce the spacing of the rows themselves:
(Left is current spacing, right is an aggressively reduced alternative with small icons). The alignment isn't as neat, but that trade-off is probably worth it if the usability improves. |
|
@jameskoster @jasmussen We're hitting the same problems in #39290. I wonder if the controls could show overlayed on top of the current item only on hover. |
|
How do you mean, overlaid? Coming back to this, I think horizontal scrolling, and other mechanisms to minimize the chance of the scrollbar appearing (such as eliding text if too long) are probably good starting points. |
Presuming by 'controls' you mean the movers and ellipsis? If they functioned like the ellipsis in this gif I think that might work ok:
|
In #35230 we noticed that the persistent list view may expand past 350px in width for the secondary sidebar. This can happen if a block has a particularly long label, or if items are nested deeply.
It'd be ideal if the secondary sidebar width can remain consistent in width. In a follow up being able to resize this to an arbitrary width may make sense too.
The current max nesting depth is 8. We can see how this behaves in the following video. Any items nested past this point end up on the same visual level. Toggling expansion may change width, but with a max nesting depth it's more difficult to take up all the editor screen space.
CleanShot.2021-10-13.at.10.56.00.mp4
Some challenges I found so far:
This is just an early exploration, but feel free to explore and push directly to the branch if y'all have ideas cc @jasmussen @jameskoster