Gutenberg: Nav Block: URL item in the search results should appear first

Created on 11 Nov 2019  Â·  9Comments  Â·  Source: WordPress/gutenberg

A usability thing, I wonder if the URL item in the search results should appear first, as it has the instructions 'Press ENTER to add this link'.

Created from https://github.com/WordPress/gutenberg/issues/18135.

This is not a definitively confirmed task (ie: use of "I wonder..." in issue).

It would be good to get a view from @karmatosed and @shaunandrews before we proceed here.

[Block] Navigation

Most helpful comment

Always showing the URL result at the top doesn't feel right. Look at this scenario, where I've searched for the word "Off":

image

The "Offers" page is the result I'm looking for, but the URL result of "Off" is presented first. In this case — and with most input that doesn't _look_ like a valid URL (i.e. searching) — presenting the URL result is unhelpful.

--

That said, I think we're looking to address a few different problems here:

  1. The URL result can be hidden at the bottom of a long list.
  2. The URL result prompts users to hit ENTER, but this fails once you use the keyboard to navigate other items.
  3. Often times, the URL result is listed at the bottom of a long list, but hitting ENTER selects it even though its out of view.

To solve #1, I think we could try parsing the input to attempt to determine if its a valid(-ish) URL. If so, then show the URL result first.

To solve #2, I think we should change the text to something simpler: "Add a link to this URL".

To solve #3, change the text as mentioned above and ensuring that the first item in the list is defaulted to active — that is, hitting ENTER will choose the first item.

Here's those three things visually:

image

All 9 comments

Just adding visual to context:

image

You can easily not even see it:

image

For exact matches it doesn't show so this makes sense:

image

My concern with showing it at the top is that it would/could push down more relevant content (post/pages) results.

Random question that this brings to mind: Is there keyboard navigation integrated? That is, can I use the up/down arrows on my keyboard to navigate the results?

Another related question: The "Press ENTER" message should likely only display when its the only results — otherwise, I'd expect to be able to use the keyboard to navigate results and press enter to insert any item.

What if instead of showing the link option in the list, it waits for the first dot in the URL before showing? It seems strange to me to show UI for adding a link when I've typed "hello", that's not even a valid URL yet.

@shaunandrews Thanks for these observations.

Random question that this brings to mind: Is there keyboard navigation integrated? That is, can I use the up/down arrows on my keyboard to navigate the results?

Yes, you use the arrows to move into the search results.

Another related question: The "Press ENTER" message should likely only display when its the only results — otherwise, I'd expect to be able to use the keyboard to navigate results and press enter to insert any item.

You can do exactly what you describe so it is valid. That said, as we expand the possibilities for the data used to back to search suggestions the ENTER text will likely be replaced by some more pertinent information about the link you're about to create.

What if instead of showing the link option in the list, it waits for the first dot in the URL before showing? It seems strange to me to show UI for adding a link when I've typed "hello", that's not even a valid URL yet.

@apeatling I think the wider issue here is refining the valid "URL" detection. Remember however that direct entry encompasses

  • URL
  • URL fragment (eg: #someanchorpoint)
  • mailto
  • tel

...and it might be that the "dot" detection wouldn't work in that scenario.


Did we decide if we're happy with the position of the URL or we want to move it?

@apeatling I think the wider issue here is refining the valid "URL" detection. Remember however that direct entry encompasses

Happy to chat on a different issue about this one. I think only triggering on exact matches like mailto or tel, hashes, and dots/periods could cover a broad usage.

I think in its current state it has to show at the top, even if it pushes relevant content down further. That is still much better than the mystery of pushing the enter key when it's not visible in the popup (because it's at the bottom of the list).

Always showing the URL result at the top doesn't feel right. Look at this scenario, where I've searched for the word "Off":

image

The "Offers" page is the result I'm looking for, but the URL result of "Off" is presented first. In this case — and with most input that doesn't _look_ like a valid URL (i.e. searching) — presenting the URL result is unhelpful.

--

That said, I think we're looking to address a few different problems here:

  1. The URL result can be hidden at the bottom of a long list.
  2. The URL result prompts users to hit ENTER, but this fails once you use the keyboard to navigate other items.
  3. Often times, the URL result is listed at the bottom of a long list, but hitting ENTER selects it even though its out of view.

To solve #1, I think we could try parsing the input to attempt to determine if its a valid(-ish) URL. If so, then show the URL result first.

To solve #2, I think we should change the text to something simpler: "Add a link to this URL".

To solve #3, change the text as mentioned above and ensuring that the first item in the list is defaulted to active — that is, hitting ENTER will choose the first item.

Here's those three things visually:

image

As we seem to have design feedback and I agree with @shaunandrews, going to remove that label for now.

Prioritizing local sources seems correct to me.

Was this page helpful?
0 / 5 - 0 ratings