Try read only navigation sidebar in browse mode #48971
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
draganescu
added
Needs Design Feedback
|
Size Change: +107 B (0%) Total Size: 1.34 MB
ℹ️ View Unchanged
|
draganescu
requested review from
jameskoster,
jasmussen,
richtabor and
jorgefilipecosta
|
Thanks for putting this together, it's helpful to get feel for how the panel would work without edit capabilities. A couple of notes:
nav.mp4If we could display the children of Page List that would help. I'm not sure how it would feel so perhaps something to try: being able to see blocs like Search might help, even if you can't do anything with them. It would clarify the connection between the sidebar and the frame a bit. They could be simply styled with no hover effects. We might do the same for Custom Links. |
|
@jameskoster I missed the page list from filtering great catch 😆 I will push a commit with this in. Edit: done in ae73512 - @jameskoster try your example now, the need to show non link blocks is less. I do agree I should try to stryle custom links so that they don't show pointer on hover. |
|
For me the most annoying part is that clicking on an item that has a chevron to expand, navigates instead of expanding! It's so easy to mistake click! |
|
Since this is read only, do we need to display the Page List parent / structure? The appearance is broken (Page List is selectable, children have odd background):
Simply displaying the children as root level items would likely be better, and fix the chevron issue you mentioned (for Page List at least, submenus are another story).
It is less, but I still think it's worth a try, purely because it makes that connection with the frame 1:1. Crude example:
|
|
Yes, I dislike the page list too showing up there like a parent ... I remember @jorgefilipecosta had an approach to hide it ... Edit: yes in #48725 we try to hide the parent - but only if the menu is only a page list. Given that the page list block could be filtered by parent ID this makes things a bit more complicated. |
|
One small detail we might consider here, since the menu items are read only: Adding a drilldown indicator (chevron) to the relevant items.
Related: #48962 |
I don't consider that the experience in this PR is any worse for these block than it is in trunk, we just need to get that blue box to fill the container: IMO this approach removes some of the confusion around what can and cannot be edited, without degrading the experience, but I'll leave the decision about whether to merge it someone who is working on it more closely. |
|
Given the work in #49043 which hides the navigation screen in core this exploration can be closed. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What?
Alternative to #48933
Complementary to #48935
Makes the navigation in browse mode unable to edit the menu it displays. It works only as a way to browse through the site using the primary navigation menu which should be visible on the site already.
Why?
The editing experience in the navigation sidebar is very rough around the edges. The feature itself - being able to browse the website and edit each page you browse to - is extremely valuable in the site editor. However editing the navigation can be better accomplished using the navigation block.
We can follow up later on this feature and make it able to edit the navigation as well.
How?
For now, pretty hack-y:
Testing Instructions
Testing Instructions for Keyboard
Screenshots or screencast
read-only-navigation.mp4
👋🏻 @jorgefilipecosta this PR is pretty rough - I meant it as a way to see how having this as a last reasort feels. Not sure on my implementation choices.