1051973 - Refine appearance of suggestions/search history items

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: Search Activity, defect, P1)

Description

[Aaron Train [:aaronmt]]

Attachment: screenshot.png

See screenshot.

There should be enough results shown above the keyboard so that the user can see what they are searching for without having to dismiss the keyboard.

I think if the padding around the appearance of the search results were better we could optimize space better.

See screenshot.

Comment 1

[Aaron Train [:aaronmt]]

Attachment: Chrome screenshot.png

Chrome with similar searching optimizes for results shown above the keyboard

Comment 2

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

I'd like to pivot this bug's scope to deal with the suggestions /"typing" phase as a whole. 

Some known issues with this state/phase revolve around differentiating search suggestions here and history items on the "pre-typing" state. Namely, being more visually efficient with this page as well.

Comment 3

[:Margaret Leibovic]

I think it would be nice if we could find a way to reduce the height of the suggestions so that more of them are visible while the keyboard is open.

Comment 4

[:Margaret Leibovic]

I'm morphing this bug again :)

I think the main problem described in comment 0 is that the individual search suggestions take up too much vertical space, so they keyboard ends up hiding some of them. I think we should investigate what kind of style tweaks we can make to show more suggestions on the screen at once.

And as the search suggestions are currently styled the same way as the search history items, we'll need to think about whether or not we want these styles to stay the same or start to diverge.

NI to antlam to contemplate.

Comment 5

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

I agree, I'm working on a simple alternative to address vertical space issues and in turn, styling confusion.

Stay tuned!

Comment 6

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

Attachment: XXHDPI - Mobile - Typing 6.png

Attaching a WIP for the time being.

It looks like we fixed suggestions at a maximum of 5 right now. But, do we have telemetry on how many hits each of these suggestions are actually getting? I think it'd be useful to see the numbers behind that to see what kind of UX wiggle room/ opportunities we might have there.

It would definitely help inform some other decisions even around bug 909536.

Comment 7

[:Margaret Leibovic]

(In reply to Anthony Lam (:antlam) from comment #6)
> Created attachment 8483060 [details]
> XXHDPI - Mobile - Typing 6.png
> 
> Attaching a WIP for the time being.
> 
> It looks like we fixed suggestions at a maximum of 5 right now. But, do we
> have telemetry on how many hits each of these suggestions are actually
> getting? I think it'd be useful to see the numbers behind that to see what
> kind of UX wiggle room/ opportunities we might have there.
> 
> It would definitely help inform some other decisions even around bug 909536.

No, we don't have telemetry about which item in the list is clicked, but in our discussion this morning we did notice that lots of other search apps will only show 3 suggestions (that's also what we do in Fennec). However, they often have other stuff to show, so maybe that's not a good data point. But I would be okay with playing around with 3 suggestions.

In your mock-up, you also have a result item listed, which we don't currently support. Would you still be happy with this design if that item isn't there?

Comment 8

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

(In reply to :Margaret Leibovic from comment #7)
> In your mock-up, you also have a result item listed, which we don't
> currently support. Would you still be happy with this design if that item
> isn't there?

Yeah, I think so. But we should definitely try to support that result item in P2 (?).

Comment 9

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

Attachment: XXHDPI - Mobile - Typing 7.png

Comment 10

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

^ wanted to attach a WIP of what it might look like now with the branding color instead of our own orange. I'm trying to give it a bit of visual separation as well in this mock.

Also worth noting is that this design does not have the same vertical alignment with the input field so the animation of the text flying up might have to be re worked if we decide to go with this.

Thoughts?

Comment 11

[:Margaret Leibovic]

(In reply to Anthony Lam (:antlam) from comment #10)
> ^ wanted to attach a WIP of what it might look like now with the branding
> color instead of our own orange. I'm trying to give it a bit of visual
> separation as well in this mock.

This seems like a cool experiment. We can file a separate bug for exploring this more, since I think it's out of the scope of this bug (and we don't have a way to get those colors yet).

> Also worth noting is that this design does not have the same vertical
> alignment with the input field so the animation of the text flying up might
> have to be re worked if we decide to go with this.

Good point. Is there any way we could keep that vertical alignment? I suppose that might make it look like we have too much padding on the left. Or maybe we should get rid of the magnifying glass while you're typing?

Brian, do you want to take this bug? It's a different list than the one in bug 1030896, but they're related :)

Comment 12

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

(In reply to :Margaret Leibovic from comment #11)
> (In reply to Anthony Lam (:antlam) from comment #10)
> > ^ wanted to attach a WIP of what it might look like now with the branding
> > color instead of our own orange. I'm trying to give it a bit of visual
> > separation as well in this mock.
> 
> This seems like a cool experiment. We can file a separate bug for exploring
> this more, since I think it's out of the scope of this bug (and we don't
> have a way to get those colors yet).

Is there anyway we can define specific active mode colors for the engines we ship with and if it's not in that list we default to our orange? (the one we currently use)

Comment 13

[Brian Nicholson (:bnicholson)]

(In reply to :Margaret Leibovic from comment #11)
> Brian, do you want to take this bug? It's a different list than the one in
> bug 1030896, but they're related :)

Sure, I can grab this.

Comment 14

[:Margaret Leibovic]

(In reply to Anthony Lam (:antlam) from comment #12)
> (In reply to :Margaret Leibovic from comment #11)
> > (In reply to Anthony Lam (:antlam) from comment #10)
> > > ^ wanted to attach a WIP of what it might look like now with the branding
> > > color instead of our own orange. I'm trying to give it a bit of visual
> > > separation as well in this mock.
> > 
> > This seems like a cool experiment. We can file a separate bug for exploring
> > this more, since I think it's out of the scope of this bug (and we don't
> > have a way to get those colors yet).
> 
> Is there anyway we can define specific active mode colors for the engines we
> ship with and if it's not in that list we default to our orange? (the one we
> currently use)

Yes, we could define them in the search plugin xml. We could also use our dominant color logic to pull colors out of the icons, but we'd probably still only want to do that for engines we ship, to avoid ugly colors from appearing.

We can work on that in bug 1049600.

Comment 15

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

(In reply to :Margaret Leibovic from comment #14)
> (In reply to Anthony Lam (:antlam) from comment #12)
> > (In reply to :Margaret Leibovic from comment #11)
> > > (In reply to Anthony Lam (:antlam) from comment #10)
> > > > ^ wanted to attach a WIP of what it might look like now with the branding
> > > > color instead of our own orange. I'm trying to give it a bit of visual
> > > > separation as well in this mock.
> > > 
> > > This seems like a cool experiment. We can file a separate bug for exploring
> > > this more, since I think it's out of the scope of this bug (and we don't
> > > have a way to get those colors yet).
> > 
> > Is there anyway we can define specific active mode colors for the engines we
> > ship with and if it's not in that list we default to our orange? (the one we
> > currently use)
> 
> Yes, we could define them in the search plugin xml. We could also use our
> dominant color logic to pull colors out of the icons, but we'd probably
> still only want to do that for engines we ship, to avoid ugly colors from
> appearing.
> 
> We can work on that in bug 1049600.

Agree. Let's stick with our orange for any non-defaults.

Comment 17

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

Attachment: prev_history_suggest_V1.png

Attaching designs for V1 of the searching and typing phase. I've added a new icon on the left of history terms to address issues of indication for V1.

Comment 18

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

Attachment: icon_clock.zip

Icons!

Vertically centered, padded 15dp from the left, and 10dp on the right just before the text.

Comment 19

[:Margaret Leibovic]

Attachment: Refine appearance of suggestions/search history items

This is based on top of my patches for bug 1049600, and similarly, you can find it broken down into smaller commits in the PR:
https://github.com/mozilla/fennec-search/pull/92

The only outstanding issue I can see is that we need to deal with the fact that the settings button will overlap a very long history list. I played around with making the list not extend all the way to the bottom of the screen, but that seemed to be awkwardly cut off.

Here's a build of Fennec with all these patches applied:
http://people.mozilla.org/~mleibovic/fennec-search-ux.apk

Comment 20

[Wesley Johnston (:wesj)]

So this removes the animation? Is that what we want? I don't see that decision in here?

Comment 21

[:Margaret Leibovic]

(In reply to Wesley Johnston (:wesj) from comment #20)
> So this removes the animation? Is that what we want? I don't see that
> decision in here?

This was something antlam and I discussed, but let me make sure he agrees with the decision.

In our discussion, we talked about removing the vertical text transition animation because the suggestion text no longer aligns with the search bar text. So, if we don't remove the animation, we'll need to at least update it to horizontally translate as well.

Comment 22

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

Yep, let's remove it. 

It seems to cause more issues than it solves and with the white frame expanding to fill the screen, the metaphor is obvious enough I think.

Comment 23

[:Margaret Leibovic]

FYI, I rebased the PR after merging bug 1049600, but it doesn't look like the hg patch needed any changes:
https://github.com/mozilla/fennec-search/pull/92

(I think it's easier to review the PR, since there are separate commits that describe the different steps I took.)

Comment 24

[Wesley Johnston (:wesj)]

Comment on attachment 8489751 [details] [diff] [review]
Refine appearance of suggestions/search history items

Review of attachment 8489751 [details] [diff] [review]:
-----------------------------------------------------------------

I made a few nit comment in the PRs.

Comment 25

[:Margaret Leibovic]

https://github.com/mozilla/fennec-search/commit/ddac9a19c2697f21d504f84f56c4a9d3efa159f2
https://hg.mozilla.org/integration/fx-team/rev/7531fb14300b

Comment 26

[Tim Taubert [:ttaubert] (inactive)]

https://hg.mozilla.org/mozilla-central/rev/7531fb14300b