1009353 - [User Story] Rocketbar: Configure search providers on Enter press

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia::System, defect, P3)

Comment 1

[Peter Dolanjski [:pdol]]

Note that we will try this configuration out to determine if use cases with more complex strings can be better fulfilled - matching closer to user expectations.
There is a chance we'll want to revert back, so design accordingly.

Comment 2

[Peter Dolanjski [:pdol]]

It likely makes sense to just align this so it using the existing configuration, meaning that the search provider will apply in the Browser app and in Rocketbar (doesn't really make sense to have separate ones)

Comment 3

[Kevin Grandon :kgrandon]

Peter - I think we will be able to have OEMs select one as in bug 1009358, but I do not think we will be able to have these user configurable in 2.0. We don't have time this late in the game to build this feature, and I don't think it makes sense to do as it needs to change in 2.1.

Comment 4

[Peter Dolanjski [:pdol]]

(In reply to Kevin Grandon :kgrandon from comment #3)
> Peter - I think we will be able to have OEMs select one as in bug 1009358,
> but I do not think we will be able to have these user configurable in 2.0.
> We don't have time this late in the game to build this feature, and I don't
> think it makes sense to do as it needs to change in 2.1.

Won't we still need this general configuration ability even if they are just picking one?

Comment 5

[Kevin Grandon :kgrandon]

Originally I was thinking of a more standard "Go to {X} url on enter press". Having to also support the ability to open the current E.me results makes it more difficult. One option may be to consider the current results screen a URL and open a local app which does the same search. I guess there's more scope to this than I thought, so it may be harder to get this into 2.0 than I originally thought.

Comment 6

[Ben Francis [:benfrancis]]

I already implemented this feature in the browser app with search engines configurable at build time [1][2].

The way this works is that the search engines are populated in an indexedDB database on first run from a JSON file generated at build time (basically a title and a URL template for each provider). Then the UI presents the options to the user and saves the chosen search engine in the database. When the user submits a non-URL string it just gets applied to the chosen URL template to load a search engine.

If the UI to choose the search engine was in the search app rather than the Settings app then it would be fairly easy for me to port this code over to the search app.

Francis, I previously saw a UX spec which allowed the user to choose the search engine by pressing the search provider icon next to suggestions. How would you feel if this was the only method to choose a search engine in 2.0? You could argue that it shouldn't be in the Settings app because it's very specific to our search app and if the user chooses an alternative homescreen that homescreen may not even trigger our search app so the setting would have no effect.

One potential issue I can see with the icon approach is that if the search provider's icon is next to the suggestions then it would imply that changing the search provider would also change the provider of suggestions. I've done some research into search suggestions and through discussions with Mike Connor it turns out that OpenSearch suggestions are actually surprisingly well standardised across Google, Yahoo and Bing and a simple implementation of multiple providers wouldn't actually be hugely difficult. But that would definitely be high risk for 2.0 as we only have one sprint left and are discouraged from landing features in the last week.

It's a shame that e.me would have to work inconsistently because they don't have their own web app like all the other search providers, but maybe it isn't too hard to create a special case for them which shows the expanded results screen instead of loading the search in a browser tab.

1. https://github.com/mozilla-b2g/gaia/blob/master/apps/browser/js/settings.js#L36
2. https://github.com/mozilla-b2g/gaia/blob/master/apps/browser/js/browser_db.js#L39

Comment 7

[Ben Francis [:benfrancis]]

(In reply to Kevin Grandon :kgrandon from comment #5)
> One option may be to consider the current results screen a
> URL and open a local app which does the same search.

This is how I would ideally like all of our search providers to work. Submitting search terms in the Rocketbar shows the results in a new app window of the search app for that provider (like the Bing app).

But wouldn't that be dependent on bug 996039?

Comment 8

[Francis Djabri [:djabber]]

> Francis, I previously saw a UX spec which allowed the user to choose the
> search engine by pressing the search provider icon next to suggestions. How
> would you feel if this was the only method to choose a search engine in 2.0?
> You could argue that it shouldn't be in the Settings app because it's very
> specific to our search app and if the user chooses an alternative homescreen
> that homescreen may not even trigger our search app so the setting would
> have no effect.
> 
> One potential issue I can see with the icon approach is that if the search
> provider's icon is next to the suggestions then it would imply that changing
> the search provider would also change the provider of suggestions. I've done
> some research into search suggestions and through discussions with Mike
> Connor it turns out that OpenSearch suggestions are actually surprisingly
> well standardised across Google, Yahoo and Bing and a simple implementation
> of multiple providers wouldn't actually be hugely difficult. But that would
> definitely be high risk for 2.0 as we only have one sprint left and are
> discouraged from landing features in the last week.

I'm a bit concerned about using an icon for the reasons you mentioned. I'd prefer to hold off from using it until we're able to change the search suggestions as well. Even then, I would prefer to allow the user to  change the search provider via settings as well, as accessing the setting via an icon feels a bit hidden.

Comment 9

[Ben Francis [:benfrancis]]

Attachment: https://github.com/mozilla-b2g/gaia/pull/19887

Comment 10

[Ben Francis [:benfrancis]]

Comment on attachment 8432663 [details] [review]
https://github.com/mozilla-b2g/gaia/pull/19887

This work in progress patch is the first piece of the puzzle which allows the homescreen search provider to be customized at build time with the use of a simple URL template.

This can be customized by editing customization/settings.json and setting search.urlTemplate to something like https://www.google.com/search?q={searchTerms}

the {searchTerms} string will get replaced by the user's search terms and the resulting URL will be opened in the browser app. There is a special case for e.me which has a different UX.

Currently this patch doesn't allow for different settings in a single variant configuration for multiple MCC/MNC combinations. I'm hoping Albert may be able to provide some help with that!

Later in bug 1009358 I will look at also configuring a search provider name and icon and providing multiple options to the user in the Settings app.

Comment 11

[Kevin Grandon :kgrandon]

Comment on attachment 8432663 [details] [review]
https://github.com/mozilla-b2g/gaia/pull/19887

It is weird having to have that special case in there - but I can't really think of a better option, so F+!

Comment 12

[Albert [:albert]]

Clearing ni as this has been discussed on IRC

Comment 13

[Ben Francis [:benfrancis]]

Comment on attachment 8432663 [details] [review]
https://github.com/mozilla-b2g/gaia/pull/19887

OK, I have now added settings for the other search engine metadata we need, setting the foundations for bug 1009358.

You can now configure the following settings:
* search.urlTemplate
* search.suggestionsUrlTemplate
* search.iconUrl

which have defaults in build/config/common-settings.json and can be customised in customization/settings.json by building with GAIA_DISTRIBUTION_DIR=customization

Currently only search.urlTemplate is used by the search app but the others can be configured (as per the acceptance criteria) and will be used in bug 1009358.

Also, there is now a default list of search providers in apps/settings/resources/search/providers.json and an icon file for each provider. These can be configured in a customization/search directory, the contents of which will overwrite app/settings/resources/search if it is found to exist at build time with GAIA_DISTRIBUTION_DIR=customization.

This patch does not do single variant customization, which Albert has kindly offered to work on in a follow-up.

Comment 14

[Kevin Grandon :kgrandon]

Comment on attachment 8432663 [details] [review]
https://github.com/mozilla-b2g/gaia/pull/19887

Nice! Will take a look soon. Adding Yuren to the R? for the build changes in settings/customization.

Comment 15

[Kevin Grandon :kgrandon]

Comment on attachment 8432663 [details] [review]
https://github.com/mozilla-b2g/gaia/pull/19887

Seems simple enough, nice work!

Comment 16

[Yuren [:yurenju] (AFK ~ Oct. 12) (volunteer mode)]

Comment on attachment 8432663 [details] [review]
https://github.com/mozilla-b2g/gaia/pull/19887

that's great and could you also add information for this customization to MDN? thanks!

https://developer.mozilla.org/en-US/Firefox_OS/Developing_Firefox_OS/Market_customizations_guide

Comment 17

[Ben Francis [:benfrancis]]

https://github.com/benfrancis/gaia/commit/a200ce149086cbc1cff549ea119d82f7a234e5fc

Comment 18

[Kevin Grandon :kgrandon]

Mass modify - set status-b2g-v2.0 fixed for fixed bugs under vertical homescreen dependency tree.

Comment 19

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

bug 1031524 filed for multiple MNC/MCC:
https://moztrap.mozilla.org/manage/case/13917/
https://moztrap.mozilla.org/manage/case/13895/