909536 - Support suggestions from multiple providers

Status: RESOLVED INACTIVE

(Firefox for Android Graveyard :: Awesomescreen, defect)

Description

[Wesley Johnston (:wesj)]

Attachment: Patch

+++ This bug was initially created as a clone of Bug #851969 +++

Split off from the amazon bug. We can support multiple suggestion providers. Should we?

APK with the test build at: http://people.mozilla.com/~wjohnston/suggest.apk

This also includes Yahoo and a hacked Amazon provider, so 4 of the 5 will provide suggestions, for maximum craziness.

Comment 1

[Ian Barlow (:ibarlow)]

(In reply to Wesley Johnston (:wesj) from comment #0)
> Created attachment 795681 [details] [diff] [review]
> Patch
> 
> +++ This bug was initially created as a clone of Bug #851969 +++
> 
> We can support multiple suggestion providers.
> Should we?

Ideally, yes. Realistically... Maybe? The two biggest questions in my mind are

1. How do we deal with different suggestions coming in at different speeds?
2. How do we keep making the Awesomescreen useful by leaving room for both search suggestions *and* history/bookmarks results. This will be easier on tablets, but harder on small phone screens

Arun is doing some thinking about this, stay tuned to this bug!

Comment 2

[Arun Balachandran Ganesan [:abc]]

Behavior of Search Suggestions

Overall thoughts

For phones & tablets (in landscape):
- Show search suggestions only for primary (2 lines) & secondary (1 line) search providers

For tablets (in portrait):
- Show search suggestions for all search providers. Show primary (2 lines) at top. For sake of consistency with landscape mode, we can show secondary search provider (1 line) next and then show suggestions from other providers (1 line) as they arrive [or] we could just show all non-default ones as they arrive.

Some options

1. Phones

Given 1.limited screen estate 2. to make space for awesome bar results (history + bookmarks) 3. to avoid cognitive/information overload for user, we would like to restrict the amount of search suggestions we show for the user.

With these on mind, by default, we can show search suggestions for the following *only*:

- Search suggestions from Default search provider at the top (in this case, Google) limited to two lines

- Search suggestions from one of the other search providers (Amazon, Twitter & Wikipedia) limited to one line. A few options on how we could choose this search provider follows.

  > First arrival: Since, the search suggestions from different search providers may be returned at different time intervals, we can choose to automatically show the one that arrives first.

  > User choice: We can allow the user to choose a search engine in the settings, in addition to choosing the default search provider.

  > Automatic: Can we choose the secondary search provider automatically in a way that makes more sense 1. based on user usage data 2. based on search query entered?

2. Tablets – Portrait

Given that we have enough room and are convinced of the value provided by the 4 major search providers, we can show search suggestions for all of them ordered as per the following notes.

- Search suggestions from Default search provider at the top (in this case, Google) limited to <---> lines

- Search suggestions from the other search providers (Amazon, Twitter and Wikipedia) ordered as per follows limited to <---> lines:

  > Order of arrival: We can show results in the order that search data is returned by the different search providers

  > Automatic: Can we order the search results automatically in a way that makes more sense 1. based on user usage data 2. based on search query entered?

2. Tablets – Landscape

Given limited real estate, should we just follow the same rules as for phones? I think so… i.e show only two search providers.

Comment 3

[Arun Balachandran Ganesan [:abc]]

Attachment: draft-search-suggestions (phones).pdf

Comment 4

[Arun Balachandran Ganesan [:abc]]

 > - Search suggestions from Default search provider at the top (in this case,
> Google) limited to <---> lines

Limit to 2 lines.
 
> - Search suggestions from the other search providers (Amazon, Twitter and
> Wikipedia) ordered as per follows limited to <---> lines

Limit to 1 line each.

Comment 5

[Wesley Johnston (:wesj)]

I originally started playing with limiting the suggestions to one line primarily because the row growing in height when the suggestions came in caused easy mistakes in tapping. I still kinda think we should limit to one line for ALL providers, but on very small screens, it could become useless. Then again, on small screens they may come in so slowly they're not useful anyway?

I'm also not completely convinced we need to show two providers all the time. It seems like pulling in multiple providers, if we do it right, should only happen when we're really out of ideas and we start actually showing other potential search providers (not sending queries to those rows until they're on-screen might help with some of the networking concerns as well?)

That said, when they do come in, its a bit overwhleming having a screen FULL of words. Maybe we can do something to remove redundent words (I don't know that there are many...), or show them in a more consolidated list? Something with a little more structure so that it doesn't feel so random... We filter the Google list down to the top three. Maybe on secondary providers, we're better to just show one suggestion?

Comment 6

[Arun Balachandran Ganesan [:abc]]

Hi Wes:

Thanks for your comments. I and Ian discussed your thoughts and more options as well. We also  sketched few ideas for the settings UI (assuming the current model of showing search suggestions for 2 providers for phones and all 4 for tablets in the order of the results coming in). Then Ian came up with a nice idea (design attached). 

For phones, we can show search suggestions for as many providers as there is room for, with history+bookmarks given higher priority to occupy at least one half of the screen (I know this sounds complicated – the design attached should be clear.)

Trying to rephrase that, we show search suggestions for two providers when plenty of history+bookmarks matching the url/search phrase are available. When not many are available, and there is visible empty screen estate, then we show search suggestions from 3 or 4 search providers depending on how much room is available.

Also, the results are ordered in the order that they come in, just like for tablets.

Let’s try this; we would like to see how it works. Thanks!

Arun

Comment 7

[Arun Balachandran Ganesan [:abc]]

Attachment: search-suggestions (phone)

Comment 8

[Karen Rudnitski [:kar]]

I'm looping in Joanne to get her opinion based on what she thinks would be acceptable from a search provider perspective.

Comment 9

[Joanne Nagel]

Thanks, Karen.  Strictly from a search provider perspective, as a default provider, the inclusion of other provider's suggestions would dilute the value of being "default", especially if the results are redundant.  I can see where adding results for Wikipedia might make sense and if there are no suggestions, layering in Twitter instead.

Comment 10

[Brad Lassey [:blassey] (use needinfo?)]

There are still some differences between being default and not. Primarily, that the default search engine is displayed at the top, above all awesoembar results. The effect for a user with a normal amount of history is that typically the default engine is shown, while non-default engines are offscreen.

Also (although this is completely pending UX design), non default engines could be limited to one row of suggestions, while the default has multiple rows.

Comment 11

[Joanne Nagel]

I understand what you are proposing, but help me craft a message that explains the value of default if we make this change.  It would need to explain why a provider would pay more (or anything) to be in that position.  It is obvious to me on desktop, but I'm struggling based on this design.

Comment 12

[Karen Rudnitski [:kar]]

I think we would need to run some tests on beta (and ONLY on beta) for a period of 2 - 3 months with our UI telemetry probes at-the-ready and actually measure the number of times users select the search suggestions from the default provider vs other suggestions. We would also need to run it with Google as default (showing more results) and then Bing as a default due to Google's prominence in search (and therefore also account for those changing their default engine).

Can we engineer such a test so that 50% of our beta population run Google as default with this new design and 50% of our beta population with Bing as default so we can collect some user data to indicate if there's actual value in that default position with this design?

Can we do something else more visually appealing to show more prominence to the default's suggestions while still surfacing other results?

I do think it would be an easier sell to have one 'general' search provider showing suggestions and complementary engines for additional search suggestions (like yell, a webapp search engine, wikipedia, etc etc).

Comment 13

[Mark Finkle (:mfinkle) (use needinfo?)]

What's the upside to multiple search suggestion providers active at the same time? I foresee duplicate suggestions, which we'll need to remove/filter. I'd rather spend time/effort on other areas that have more impact.

Comment 14

[Brad Lassey [:blassey] (use needinfo?)]

(In reply to Mark Finkle (:mfinkle) from comment #13)
> What's the upside to multiple search suggestion providers active at the same
> time? I foresee duplicate suggestions, which we'll need to remove/filter.
> I'd rather spend time/effort on other areas that have more impact.

why would you need to remove or filter? they would be confined to the search row of each search provider.

As far as impact, I'd think that features that can increase the value of the search UI we offer our uses would be relatively high priority. As far as time and effort, we already have a patch (granted, old and bit rotted).

Comment 15

[Brad Lassey [:blassey] (use needinfo?)]

(In reply to Brad Lassey [:blassey] (use needinfo?) from comment #14)
> (In reply to Mark Finkle (:mfinkle) from comment #13)
> > I foresee duplicate suggestions,

As for this assumption, I agree that google and bing may give similar suggestions. However I'd fully expect twitter, amazon and wikipedia to give quite different results.

Comment 16

[Brad Lassey [:blassey] (use needinfo?)]

Karen, what do you want to do about tracking this for a release?

Comment 17

[Karen Rudnitski [:kar]]

I would like to see some updated workflows from UX on what this would conceivably look like. I could also go as far as putting this into nightly/aurora, but don't yet want to track this for a release as I'm worried about the current experience being confusing or taking up too much real estate with little benefit (I'm not a fan of duplicate 'general searches' throwing up the same suggestions).

I also fundamentally think this would de-value our 'default' more so, which isn't a place we want to be right now. I'm also leery of putting too much effort into this given the search activity work, unless we think one will feed into the other.

Comment 18

[:Margaret Leibovic]

I think antlam was thinking about this. Let's see if he has any UX ideas.

Comment 19

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

Thanks for adding me in here Margaret! :)

I have given this quite some thought and I actually think the real value here is offering users a quick way to perform a search with the term that they already have, with a specific engine/site. As opposed to offering suggestions that aim to get the user to type less.

That being said, I'd like to see some telemetry for this stuff and I know that Mark is already on that. :) But, let me have a dig around as well. Who knows, maybe people don't actually use the suggestions that much and/or typing a bit isn't much of a pain since people type so fast nowadays.

(In reply to Brad Lassey [:blassey] (use needinfo?) from comment #15)
> (In reply to Brad Lassey [:blassey] (use needinfo?) from comment #14)
> > (In reply to Mark Finkle (:mfinkle) from comment #13)
> > > I foresee duplicate suggestions,
> 
> As for this assumption, I agree that google and bing may give similar
> suggestions. However I'd fully expect twitter, amazon and wikipedia to give
> quite different results.

We tried to hack together some of this stuff with FiFi (repo is on our GitHub I believe). I think we got it working with one major engine providing "suggestions" while we offered users the ability to get the 
"results" for said suggestions via any site they wanted (Twitter, Amazon, Wikipedia, etc).

It may have been a bit of a hack but from a UX point of view it kept a nice balance of having a "strong default", not having repeating results, visual and interactive clarity, and user choice.

(In reply to Karen Rudnitski [:kar] from comment #17)
> I would like to see some updated workflows from UX on what this would
> conceivably look like.

I can work on some mocks here around how this might look for:

1) getting suggestions from a couple sites all at once

2) getting suggestions from just one search engine and easily submitting a search to other sites

How does that sound?

Comment 20

[Brian Nicholson (:bnicholson)]

(In reply to Anthony Lam (:antlam) from comment #19)
> 2) getting suggestions from just one search engine and easily submitting a
> search to other sites

Just pointing out that this is possible now (though not obvious) by long-pressing the search suggestions, which puts the search text in the URL bar. After doing that, the user can click any of the search engines.

Also, this reminds me of bug 1050943. Not sure what the outcome of that will be, but if we make it easy for suggestions to be shared across providers, we should be wary of any potential TOS violations.

Comment 21

[Karen Rudnitski [:kar]]

Getting some mocks and flows would be a great initial step. There does have to be an emphasis on also providing value to that default provider, for obvious reasons.

Once the mocks and flows are in a state that we're fairly comfortable with, I'd like them circulated to our major providers (or at least our partner managers working with our search partners) to ensure no red flags before we continue coding for further exploration and experimentation on this topic. We can also get a better sense of there are any violations of ToS or other issues with these visuals / flows.

Comment 22

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

Attachment: ux_searchsuggest_mock1.png

I had a quick crack at this based on the comments I left last time. Again, this is just a mock and not final in any way, shape, or form. 

This is generally in the direction that I was thinking in terms of improving our current search suggest UI/UX on mobile. I think that there will probably need to be some maneuvering based on our contracts, ToS, and what not but I tried to keep that in the forefront here and look for opportunities to improve within those constraints.

Again, the UI of it is not at all final, just trying to convey the ideas right now around the basic flow that I'm picturing.

Let me know if anything is unclear, any thoughts/comments are welcome :)

Comment 23

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

Friendly ping on the status here for next steps?

Comment 24

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

NI-ing a couple people in case there are email filters to conquer

Comment 25

[Richard Newman [:rnewman]]

I think next step here is a decision from Karen and Joanne.

Comment 26

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to Richard Newman [:rnewman] from comment #25)
> I think next step here is a decision from Karen and Joanne.

Right. In any case, this is a low priority compared to the other active work we have to get done.

Comment 27

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

Splitting off (what could be a quick win) the suggestions clean up into bug 1071730.

Comment 28

[Brad Lassey [:blassey] (use needinfo?)]

filter on [mass-p5]

Comment 29

[:Margaret Leibovic]

We should work on this as part of the awesomescreen improvements the UX team has been exploring.

Comment 30

[Karen Rudnitski [:kar]]

Let's revisit when we have our new search deal in place to know which partner we'll be able to work with on this.

Comment 31

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

(In reply to Karen Rudnitski [:kar] from comment #30)
> Let's revisit when we have our new search deal in place to know which
> partner we'll be able to work with on this.

Sounds good!

Comment 32

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

Bumping these Awesome screen improvements since deal is ironed out now.

Comment 33

[Karen Rudnitski [:kar]]

Adding Deb to add to our list of things to explore in the new year

Comment 34

[Joanne Nagel]

Now that Bug: 851969 is resolved, we should discuss what user testing is going to be conducted in order to validate the assumption that multiple provider suggestions adds user value.  There should be a cost benefit analysis to be sure we are not unnecessarily driving up search calls to partners services.