Closed Bug 1051973 Opened 6 years ago Closed 5 years ago

Refine appearance of suggestions/search history items

Categories

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

34 Branch
ARM
Android
defect

Tracking

(Not tracked)

RESOLVED FIXED
Firefox 35

People

(Reporter: aaronmt, Assigned: Margaret)

References

Details

Attachments

(5 files, 2 obsolete files)

Attached image 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.
Attached image Chrome screenshot.png
Chrome with similar searching optimizes for results shown above the keyboard
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.
Summary: Search results shown under the keyboard is not helpful → Improve "suggestions" UI during typing stage
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.
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.
Flags: needinfo?(alam)
Priority: -- → P1
Summary: Improve "suggestions" UI during typing stage → Refine appearance of suggestions/search history items
I agree, I'm working on a simple alternative to address vertical space issues and in turn, styling confusion.

Stay tuned!
Attached image XXHDPI - Mobile - Typing 6.png (obsolete) —
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.
Flags: needinfo?(alam)
(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?
(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 (?).
^ 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?
Flags: needinfo?(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 :)
Flags: needinfo?(margaret.leibovic) → needinfo?(bnicholson)
(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)
Flags: needinfo?(margaret.leibovic)
(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.
Assignee: nobody → bnicholson
Flags: needinfo?(bnicholson)
(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.
Flags: needinfo?(margaret.leibovic)
(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.
Assignee: bnicholson → margaret.leibovic
Duplicate of this bug: 1065065
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.
Attachment #8483060 - Attachment is obsolete: true
Attachment #8485074 - Attachment is obsolete: true
Attached file icon_clock.zip
Icons!

Vertically centered, padded 15dp from the left, and 10dp on the right just before the text.
No longer depends on: 1063703
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
Attachment #8489751 - Flags: review?(wjohnston)
Attachment #8489751 - Flags: review?(liuche)
So this removes the animation? Is that what we want? I don't see that decision in here?
(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.
Flags: needinfo?(alam)
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.
Flags: needinfo?(alam)
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 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.
Attachment #8489751 - Flags: review?(wjohnston) → review+
https://hg.mozilla.org/mozilla-central/rev/7531fb14300b
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 35
Attachment #8489751 - Flags: review?(liuche)
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.