Nav block: Don't show the Link UI when you just added a link #35001
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
getdave
added
[Block] Navigation
|
Size Change: +14 B (0%) Total Size: 1.06 MB
ℹ️ View Unchanged
|
|
Thanks for experimenting with this approach, Dave. I've played with it a bit and I'm not sure it makes the flow smoother. This change requires users to switch their mindset to an "add then configure" one, as you mentioned, and at least in my personal experience, it would be a hard thing to ask. For example, it is difficult to know how many links of which type you need to add if links are still in a placeholder state, so it feels more natural to set the link before going to the next. On the other hand, if users want to set the link right after adding the link block, we are introducing an extra step in the flow to open the Link UI. I'd like to hear more opinions in this regard, though. |
|
Thanks for taking a look @priethor 🙌 This is one option - as you say it's worth exploring various angles so it's clear we've done due diligence. Another option is as per @tellthemachines's approach in #34899 which auto-inserts the Page variation. I didn't feel that was right - others may disagree. TBH neither option feels great. What we actually need here is feedback from users, but we won't get that until we've shipped one approach or the other. |
7 tasks
|
I personally like the control here of not having to fill in the details until later, but people will have different preferences. +1 for feedback from more folks if possible Edit: One other thought I had was that preventing the auto-open also matches how our other placeholders work. Imagine for example if we forced the media library open when someone inserts an image block.
|
I just changed it back to insert a generic Link instead of Page 😄
That's the thing: I'm not convinced we should use placeholders in Navigation. It's not really the same problem as the image block, that has a placeholder with three very different options. It wouldn't make sense to default open the media library because when creating content, at least half the time authors will be uploading new images. When adding a Nav Link, 100% of the time the next step for that block is to add a URL to it. And because the link text is related to the URL, a placeholder won't even be useful in determining how much space the block takes up, unless we add its text manually, which is a lot more work than picking out the link from the link control and having the text auto-fill. This flow might conceivably make sense when adding custom links to external pages, but it's very unlikely those will make up the majority of nav links. |
|
Passing by for a UX review. If too premature, feel free to ignore. The link UI opening is there to suggest the next desired step. Without it, you could end up with a broken nav and not sure why. I would suggest not implementing this as it makes for a more confusing UX. |
|
I think we've established this isn't the path we'd like to take. That's good as we can now rule it out and move on. Thanks to all who reviewed. |
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.
Description
Experimenting off the back of #34899 (review) to see if stopping the Link UI from automatically appearing when you add a link to a Navigation block improves the "flow" when adding items.
This PR changes things so that the Link UI will only appear when you actively click on the inserted link. That means you can go ahead and add a series of items to a Nav block and then come back and configure them as and when you are ready.
This confirms to the "add then configure" pattern I suggested in #34899 (review).
Obviously it's pretty unrefined but at this stage it's worth exploring a variety of options.
Also note that if and when #33849 is merged you will be able to configure text and link at the same time from within the Link UI so that will reduce the number of interactions yet further.
How has this been tested?
Screenshots
Screen.Capture.on.2021-09-21.at.11-40-48.mp4
Types of changes
New feature (non-breaking change which adds functionality)
Checklist:
*.native.jsfiles for terms that need renaming or removal).