Experiment: Try stacked mover in block navigation #22314
Conversation
talldan
added
the
[Feature] List View
|
Size Change: +239 B (0%) Total Size: 828 kB
ℹ️ View Unchanged
|
|
I'm not going to approve the review quite yet as there needs to be a decision here on movers that impacts wider than this issue. For those wanting to see what visually we have:
Now, this is just as per the iterations on #21935. However, I know that has a lot of debate to and fro. Ultimately, in our implementation here it's not about deciding how we have the movers as taking whatever decision comes from that issue into all movers. I don't see why these should differ. So, there needs to be a decision there we can then implement. For me, I think using movers up and down makes sense, again I am on the side that wants a unified pattern here so bringing that in works. I do think behaviour wise there are a few things to iterate. Overall, this is working as I would expect which is great! Ideally, we shouldn't be able to have 2 movers showing at same time as in screenshot above. To connect the conversation as moving should be a universe interaction, I am going to loop in @jasmussen here.
This I am assuming is referring to keyboard navigation. It is a ponder and I wonder what we could do about implementing that @enriquesanchez? |
|
I agree the keyboard interaction feels a bit confusing, I was also expecting to use up/down to navigate between the movers. One thing I'm not sure about is how this would be perceived by a visually impaired user. I'm assuming they won't have this same issue because they wouldn't perceive the stacked buttons, so they wouldn't have the expectation that they need to use the up/down arrows as I did. I'd like to think that for their use case, the current behavior makes more sense. Again, the above is an assumption. I also feel that the stacked movers have a very small hit target, which may make them hard to operate for folks with motor impairments. I assume the side by side movers have a bigger hit target? What other benefits besides consistency with block movers are we gaining by having the movers stacked? |
|
Ugh.. for some reason I'm getting this.
I'm going to step back, breathe, and assume I'm the problem here. 😄 The stacked arrows still cause me to do a double-take, and the limited click area feels tight. But I agree with Tammie, let's see what comes from the other issue to help inform the decision here. |
@karmatosed I agree that doesn't look visually great. I'm not sure what can be done about that, the focused mover button has to be visible for keyboard users as does the hovered mover button for mouse users.
@enriquesanchez I created a separate issue about the keyboard navigation - #22316, as this also happens on the block toolbar. I'm not sure how much of an issue it is based on what you mention above.
Wow, I couldn't reproduce it, but I have been noticing issues recently with Firefox maybe caching CSS, not sure if you're an FF user, @mapk. |
|
This is a really tricky design to get right, and lest we repeat the mistakes of movers in the editing canvas (additional tabstops) it's prudent to do this carefully. Zooming out a little bit and looking for a generic solution, I notice the "Navigation structure" is present for the Navigation block, but not for either Buttons or Social Links which strucutrally are the same. Although not part of this PR, any efforts to improve this interface should consider not just those other blocks, but perhaps any block with nesting, and indeed the block navigation popover itself. This likely does not change the particular implementation, but important to keep in mind so we don't write software just for the Navigation block. With regards to the specific implementation — it seems like there's an opportunity here to align with the efforts for improving the block mover for blocks. Specifically this design which I strongly feel we should try as soon as we can because it's so simple seems like it could work here as well — there's already a block icon. What if movers were integrated next to that, as a callback to where they will be on blocks? We could also be consistent with blocks in only showing the mover control onselect — this would reduce flickering and also eliminate tabstops. Seems like a mockup/prototyping effort exploring that might be an interesting next step. |
|
Hey @jasmussen, thanks for taking a look. Sorry it took a little while to respond.
Oh definitely. The iteration is mainly happening on the navigation block as part of an effort to improve the Navigation Menu page (because it really needs these features), and also because that block is experimental so we have more ability to break things 😄 It'll be easy to switch these features on in other places when the time comes.
The issue here is that there isn't really persistent selection in the block navigation. Clicking a block typically transfers focus to the block itself, and in the post editor it actually closes the popover. Potentially that could change though, I think it's a difficult design to get right as this tool becomes more about editing rather than just selecting, we're trying to fit a lot into a small space. |
💯 Glad to hear that you're learning in code, it definitely helps inform things. Just important that we silo it to just one block! |
We really need a decision on that movers issue. It's beginning to hold up other explorations. 😬 In response to displaying the stacked movers next to the icons, one of the better design iterations is removing the icons from the Navigator. (#22497) This lightens the UI and saves much needed horizontal space. In reference to the stacked movers, here's how they worked for me.
Feedback
If we do take a stacked mover approach, it's becoming more evident to me that we'll need to use the smaller arrows instead of these larger chevrons. (#21935 (comment)) unless we don't mind changing them out for the smaller arrows in the tighter places like this Navigator. |
It needs a PR more than anything — here's one: #22673 🎉
I'm not sure — I feel like the design Tammie and I landed on in #22497 (comment) strikes a good balance! |
|
Yeah, if the movers appear too squished, then just increase the height of the items in the block navigator to be the same height as the block toolbars. |
I left a comment there, but they still feel visually imbalanced. @ZebulanStanphill brings up an interesting solution... if we really want to keep the larger chevrons, maybe we need to widen the item. |
Great call, both. I actually also responded in #22497 (comment) addressing this. The line items are 48px tall affording two 24x24 (minimum touch size) targets for the movers, but they have been balanced better to match the new mover control.
Thanks for your patience! |
|
Superseded by #22796 |
Description
Related #22089
This is not meant to be code reviewed or merged, but a quick experiment to see what stacked movers in the block navigation look like, and what they're like to use.
Some notes about this:
How has this been tested?
Screenshots
Types of changes
Checklist: