Fenix: [Bug] Awesomebar results appear nearly offscreen, hurting usability & discoverability

[mcomella]

Steps to reproduce

• Add something to your awesomebar (e.g. visit boardgamegeek.com)
• Click the url bar
• Search for your awesomebar entry (e.g. "boardgame")

Expected behavior

My search result is high up enough on the list that I can select it without dismissing the keyboard.

I'm concerned that users unfamiliar with Firefox's awesomebar will be unable to discover the power of the awesomebar, a big differentiator from Chrome, and will not use the feature.

Actual behavior

On a device the size of the Pixel 2 (a normal sized device), the desired entry is half obscured by the keyboard, meaning I'd need to dismiss the keyboard for a clean click.

As a user who is actually familiar with Firefox, I often forget to use these awesomebar search results because they appear below the fold.

UNITO-UNDERSCORE!20190603-144314!

Device information

• Android device: Pixel 2
• Fenix version: 1.0.1920

[Cheap-Skate]

I still don't understand why you guys are so anti the old Fennec Awesomescreen with its search suggestion "chips". For the same search situation on Fennec I get 4x search suggestion "chips" AND 2x history URLs AND 1x bookmark URL AND 4x alternate search engines. High info density without confusion or clutter. What's not to like?

I really think you've thrown the baby out with the bathwater

Fennec:- 7x clickable URLs on Awesomescreen, plus alternate search engines
Chrome:- 5x clickable URLs on Search screen
Fenix:- 3.5x (or maybe 4) clickable URLs on Awesomescreen

[ekager]

We have the ability to add chips through AC we just aren't currently using them. I think this ticket needs more UX feedback

[bifleming]

@mheubusch can you help?

[mheubusch]

I am checking with Verdi to find out if we considered chips and had a strong reason to not use them. But I think it might be worth testing a chip version to compare to the current implementation. @vesta0 if this is something you'd like to test lmk and I can assign this as a design task to style chips based on the current functional implementation in the reference browser.

[mheubusch]

User research shows that the chips are very small touch targets and it was an deliberate decision to not use them. We recommended two affordances: the first one (once a user starts to scroll, the keyboard disappears) is implemented and the second one (interleaving search suggestions and prioritizing top hits) is dependent on GV, I think. @vesta0 do you want to won't fix this or put on the backlog

[vesta0]

@mheubusch thank you, this should go on the backlog as it's impacting awesomebar usability.

For the GV dependent item, do we have a bug filed?

[cpeterso]

We recommended two affordances: the first one (once a user starts to scroll, the keyboard disappears) is implemented and the second one (interleaving search suggestions and prioritizing top hits) is dependent on GV, I think.

For the GV dependent item, do we have a bug filed?

I think Fenix, not GV, is responsible for fetching and displaying search suggestions. Can we remove the needs:gv label?

[bifleming]

@boek can you provide thoughts on this?

[ekager]

Correct. It is not GV dependent.

[bifleming]

Closing per Emily's comment and Vesta's approval:
I recommend closing this ticket in favor of https://github.com/mozilla-mobile/fenix/issues/1211
and
https://github.com/mozilla-mobile/fenix/issues/482 /
https://github.com/mozilla-mobile/fenix/issues/2037