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.

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)

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.

(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?

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.

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

(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?

> 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 on attachment 8432663 [details] 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 on attachment 8432663 [details] 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+!

Clearing ni as this has been discussed on IRC

Comment on attachment 8432663 [details] 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 on attachment 8432663 [details] 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 on attachment 8432663 [details] https://github.com/mozilla-b2g/gaia/pull/19887 Seems simple enough, nice work!

Comment on attachment 8432663 [details] 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

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

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