Split control for URL and Text within Link UI #33849
Conversation
getdave
added
[Block] Navigation
|
Size Change: +880 B (0%) Total Size: 1.07 MB
ℹ️ View Unchanged
|
|
Ok @jasmussen here is a PoC for the dual controls for text and URL. Considerations:
There's probably more I forgot... |
|
Thanks for working on this. This is what I see:
A couple of responses:
The designs at least for the dropdowns themselves are still mostly up to date, but yes most of the unique per-block-type behavior is probably fine to explore and separately, but start with the simplest. At the same time, one thing that becomes clear in testing this is that the link suggestions are very prominent here. Which in part makes sense since they all skew heavily towards pages and existing content on the site. But at the same time, one of the benefits of the tailored destination picker is that it can be smarter in the suggestions. So in that way, the placement of the submit button is likely dependant on some tweaks to the suggestions list itself. I'd be happy to jump in with tweaks directly in this branch when I have a moment (possibly next week).
Not sure. In a later mockup made for a different ticket (#32373), the title is a key part of the flow being first:
Yes, this is perhaps the most important discovery of your PR here (thank you!). As shown in the mockup above, an initial instinct with these designs was for the suggestions to be an even more light-weight search-suggestions dropdown that appeared as you started typing, rather than right off the bat. At the same time, the value of those suggestions intrinsically becomes reduce when hidden until you start typing. So I might need to noodle on this a bit more.
I think so too! I think we might know better, depending on where this PR goes. From testing the PR here, the split dialog allows you to fill out the text label before you select a destination. Right now that's not saved in this PR, and in order to fix that it seems like we might have to also address #33091 while we're at it. As also noted above, the biggest mindbender to think about is how to integrate the search suggestions in a way that keeps their suggestive value, but still work within the reduced design and smaller dialog that includes the label. Perhaps it's fine to just simplify those suggestions (a la Google Docs as you suggest), but it needs some design tinkering which I'll return with. Nice work! |
|
Appreciate your review and thoughts @jasmussen 👍
I agree that the suggestions list needs some design attention. Mainly we need to make it clearer these are results associated with the search input. Also we need to consider that any design tweaks needs to be backwards compatible with the Link UI when the text control is not enabled (if we're going to make this opt in...).
Re: auto-focusing the URL input as opposed to the text input. I'd like to clarify the expectations around the link text. For example, do we consider a link valid (and thus submittable) if there is no URL? How does that work in the Nav Block vs in Rich Text? Also note that currently you have to click "Submit" for the text to be retained. I think that's correct.
Personally I don't like the suggestions showing right off that bat. It's distracting and additional visual noise. I think we added it as a nice way to show "most recent", but I think it's easy to turn that off via a prop if we wish to do so. Something else to consider is that users have specifically indicated use cases whereby having lots of detail in the search suggestions is very helpful/important. We should be mindful of this before streamlining these suggestions too much.
Initially I disabled the text input until the user had selected a URL. However that meant you couldn't adjust the text until after which I didn't think was the best UX. However note that the text is not "saved" until you click submit which you can't do until you've also selected a URL. If we can clarify the expected flow here I can adjust the code to suit.
Thank you 🙇 . |
The genesis of #33091 was to allow designers to create patterns that had navigation menus with preset labels, but whose links were empty. The idea being that you could create highly opinionated navigation patterns that suggested not only a specific amount of menu items, but specific labels as well. All the while still keeping those menu items in "draft states", i.e. having the wavy underline until both link and label were filled out, and not showing on the frontend until that was the case. If we were to unify so both text and URL are shown also for hyperlinked rich text, you're asking: what would happen if you then edited a link to not have a label? I think we could do two things:
I agree, but I'd like to explore a few directions just to be sure we're improving.
Absolutely. I think we can do things with compression, font size, font appearance, color, margins, paddings, and if we go deeper, even better contextuality. I always get the same 3 page suggestions when I've made no search yet, (though perhaps that's an argument to make it on-type contextual). |
That's what we do in this PR already. If you add a link without text (or delete existing text) and click submit you will see it uses the hyperlink as the title unless there is a title provided by the suggestion you clicked.
Looking forward to seeing next steps for me to implement in terms of UI, specifically around suggestions 👍 |
I haven't forgotten this one! I'll return as soon as I get space to expand this! Thanks for your patience. |
Im AFK until next week now so no worries 🙂 |
|
I did some design work in #30170 (comment), which I think I need to sleep on, or at least step away for lunch and then come back to. |
|
Just as a small update, this is still on my radar, but #34041 has come around and become a priority. The good news is there is likely some overlap between the efforts here and the efforts there. I'll be sure to update here when I have more. |
|
I have some new mockups in #30170 (comment) that I would love your thoughts on at your convenience. Thank you. |
Responded #30170 (comment) |
|
Nice, there was already some work on this one. I'll try to catch up on this one, I was playing around with patterns and using label text as a placeholder in #35063. |
Yeh it's this PR 😆 I'm working on it right now. Would love more 👀 |
getdave
force-pushed
the
try/link-control-split-url-text
branch
from
02859ee to
cf01dc8
Compare
Attempts to address #33849 (comment)
Avoid need to show the block toolbar and also avoid forcing stress testing the collapsed selection. Addresses #33849 (comment)
…the code under test
…kControl ignoring any text selection Resolves #33849 (review)
getdave
force-pushed
the
try/link-control-split-url-text
branch
from
7fca70e to
1e94414
Compare
|
🎉 nice to see that this one landed. Great work @getdave ! |
Description
This PR adds a text field to the Link UI. When editing an existing link are now two separate
<input>s within the Link UI provided by the<LinkControl>component for both:This change effects:
core/linkformat type - that's pretty much all usage ofRichText.Whilst this UX slightly deviates from the "direct manipulation" paradigm, I believe that in this case it is both necessary and proportionate due to the unique UX considerations around the creation and modification of links.
To quote from the Issue:
This is based on my original proposal in #19413 which never got anywhere.
Fixes #30170
Closes #22435
How has this been tested?
Manual testing
URLfield when first creating the link. No text field.Editin the Link UI.ENTER). You should see the underlying link text in the paragraph block change to match the contents of the Link UI's text field.Automated tests
Run the unit tests:
and also:
Run the e2e tests:
Screenshots
Screen.Capture.on.2021-10-13.at.13-57-22.mov
Types of changes
New feature (non-breaking change which adds functionality)
Checklist:
*.native.jsfiles for terms that need renaming or removal).