Try using interface package in navigation screen re-design #28686
Conversation
…erything. Also, a nasty hack to fix the block focus outlines.
…elow their parent link.
talldan
added
[Type] Enhancement
talldan
requested review from
adamziel,
draganescu,
kevin940726,
noisysocks and
tellthemachines
as code owners
|
Size Change: +6.34 kB (0%) Total Size: 1.37 MB
ℹ️ View Unchanged
|
There was a problem hiding this comment.
This is a great improvement to @shaunandrews 's already very promising PR 🎉
Two things we can iterate on in subsequent PRs:
- Header in mobile view isn't fully responsive:
- There's an extra tab stop when shift-tabbing from the block to its toolbar; focus goes from the contenteditable to the
liwrapper and only then to the toolbar.
| margin-right: 280px; | ||
|
|
||
| .edit-navigation-header { | ||
| // Stuff |
| } | ||
|
|
||
| // Hack: Stop useBlockSelectionClearer from clearing block selection when the | ||
| // block toolbar is clicked. |
There was a problem hiding this comment.
Hm, how's the block editor dealing with this?
There was a problem hiding this comment.
I think because the top toolbar is rendered outside of the editor canvas it won't receive click events. Similarly the non-top toolbar uses a slot to also render outside of the canvas, so both don't suffer from this issue.
We can probably fix in the same way, and I think we were going to look at removing the fixed toolbar, which should do that.
|
How does this |
@gziolo Good question. I didn't realise it's yet to be made stable. It seems generally pretty easy to work with. I wonder if we might consider renaming it |
@youknowriad, @mcsf, and @mtias – should we plan steps to make |
|
I think this might make sense, just not yet. Lets get the design PR this is based on merged first, then we can revisit the top area UI using the |
shaunandrews
force-pushed
the
try/menus-cleanup
branch
from
c18c9c9 to
c36468a
Compare
|
Is there anything missing here (apart from conflict solving) before we can merge? I'd really like to get this into #28675 before that one is merged, as the changes here improve usability substantially. |
talldan
force-pushed
the
try/menus-cleanup
branch
from
76df2d4 to
1f20e66
Compare
|
I've chatted to @shaunandrews about this PR, and it doesn't seem clear just yet how this fits in with the design direction of the navigation screen, so I won't be taking it forwards. If we don't end up implementing
I think the right way to go would be to build a navigation editor version of |
|
Curious to know what exactly in the the interface skeleton didn't fit the navigation screen? |
I will trust the implementation aspects to developers stronger than myself, but focus specifically on the visual and design motivation. And the design motivation is well outlined, and driven, by #28675. For me the key drivers were:
As I see it, #28675 was an impressive first step, and the key benefits it brought were:
I don't think the value of this can be overstated: it now feels like a screen dediated to editing navigation menus, just as it is. That said, I think it also opens op some opportunities for further refinements:
|
|
Maybe in previous communications I shouldn't have used the term 'top toolbar', as I feel like that's the part that has caused a strong negative reaction given the way it's in quotes 😬 But given what has been written, I feel like there are some misconceptions about what the interface package does. Some further detail. It provides:
It doesn't prevent us from using different colours or visual styles for the regions. The only differences in this PR to what was in #28675:
|
I do apologize if that came off as negative! That was not at all the intention. The potential next steps I suggested were meant to be inclusive of that as a legitimate path forward. The goal is to ship a great navigation block screen which can grow even better with iteration. Shaun's PR was a massive step towards that, and absolutely additional steps possible. Ultimately it doesn't matter if one design is superior, if it means a prohibitive extra work-load or adjacent headaches. That's why I wanted to let developers speak with authority on what makes sense in the scheme of things, and then as an adjacent designer I will do my best to try and thread the needle between dreams and patches. |
|
I think @talldan makes a great point in that using the interface package does not subtract from tweaking it in this instance to visually fit the requirements. I believe:
It looks from the conversation above that there was some genuine confusion around implementation. @talldan 's explanation of what we gain from using interface is quite on the spot and I do believe through (as @jasmussen nicely put it) "dreams and patches" we can make the editors have the best UI for their usecases. |
Description
Attempts to use the interface package with the design changes in #28675. This PR merges into that one rather than
master.There's a few things that'll probably need some cleanup or adjustment to align more with @shaunandrews' vision, and we don't necessarily have to stick with the exact same layout as the block editor.
How has this been tested?
Screenshots