Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
getdave opened this issue Nov 11, 2019 · 9 comments
Closed

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

getdave opened this issue Nov 11, 2019 · 9 comments
Labels
[Block] Navigation Affects the Navigation Block

Comments

@getdave
Copy link
Contributor

getdave commented Nov 11, 2019

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 #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.

@getdave getdave added the [Block] Navigation Affects the Navigation Block label Nov 11, 2019
@talldan talldan added the Needs Design Feedback Needs general design feedback. label Nov 11, 2019
@karmatosed
Copy link
Member

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

@shaunandrews
Copy link
Contributor

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.

@apeatling
Copy link
Contributor

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.

@getdave
Copy link
Contributor Author

getdave commented Jan 8, 2020

@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
Copy link
Contributor

@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.

@apeatling
Copy link
Contributor

apeatling commented Jan 8, 2020

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).

@shaunandrews
Copy link
Contributor

shaunandrews commented Jan 9, 2020

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

@karmatosed
Copy link
Member

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

@karmatosed karmatosed removed the Needs Design Feedback Needs general design feedback. label Jan 21, 2020
@mtias
Copy link
Member

mtias commented Mar 10, 2020

Prioritizing local sources seems correct to me.

@mtias mtias closed this as completed Mar 10, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Block] Navigation Affects the Navigation Block
Projects
None yet
Development

No branches or pull requests

6 participants