Closed Bug 1009353 Opened 6 years ago Closed 5 years ago

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

Categories

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

x86
macOS
defect

Tracking

(feature-b2g:2.0, tracking-b2g:backlog, b2g-v2.0 verified)

VERIFIED FIXED
2.0 S3 (6june)
feature-b2g 2.0
tracking-b2g backlog
Tracking Status
b2g-v2.0 --- verified

People

(Reporter: pdol, Assigned: benfrancis)

References

Details

(Keywords: feature, Whiteboard: [ucid:System85, ft:systemsfe, 2.0])

User Story

As an OEM/operator, I want to be able to configure the search provider that is used on Enter press from Rocketbar allow me to provide relevant content to my users and monetize my device offering.

Acceptance Criteria:
1. I can set the default search provider to be used when Enter is pressed from Rocketbar as part of the build configuration (as is done for the current Browser, using the MNC/MCC pairs to define it per network/country).
2. I can configure the list of search providers which are available for the user to choose from in the Settings (as is done for the current Browser, using the MNC/MCC pairs to define it per network/country).
3. I can configure the search code associated with each search provider (this will be defined by the search provider) which will be used when that provider is in use.

Current implementation: https://developer.mozilla.org/en-US/Firefox_OS/Developing_Firefox_OS/Market_customizations_guide#Browser_bookmarks_.26_default_search_engine

Attachments

(1 file)

No description provided.
User Story: (updated)
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.
Summary: [User Story] Rocketbar: Other Search Providers → [User Story] Rocketbar: Configure search providers on Enter press
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)
feature-b2g: --- → 2.0
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.
feature-b2g: 2.0 → -
Assignee: kgrandon → nobody
Depends on: 1009633
Priority: -- → P3
(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?
Flags: needinfo?(kgrandon)
User Story: (updated)
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.
Flags: needinfo?(kgrandon)
No longer depends on: 1009633
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
Flags: needinfo?(fdjabri)
(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?
feature-b2g: - → 2.0
blocking-b2g: --- → backlog
Assignee: nobody → dale
Target Milestone: --- → 2.0 S3 (6june)
Assignee: dale → bfrancis
> 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.
Flags: needinfo?(fdjabri)
Flags: in-moztrap?(jsmith)
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.
Attachment #8432663 - Flags: feedback?(kgrandon)
Flags: needinfo?(acperez)
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+!
Attachment #8432663 - Flags: feedback?(kgrandon) → feedback+
Clearing ni as this has been discussed on IRC
Flags: needinfo?(acperez)
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.
Attachment #8432663 - Flags: review?(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.
Attachment #8432663 - Flags: review?(yurenju.mozilla)
Comment on attachment 8432663 [details] [review]
https://github.com/mozilla-b2g/gaia/pull/19887

Seems simple enough, nice work!
Attachment #8432663 - Flags: review?(kgrandon) → review+
Depends on: 1020167
https://github.com/benfrancis/gaia/commit/a200ce149086cbc1cff549ea119d82f7a234e5fc
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Mass modify - set status-b2g-v2.0 fixed for fixed bugs under vertical homescreen dependency tree.
Flags: in-moztrap?(jsmith) → in-moztrap?(nhirata.bugzilla)
Flags: in-moztrap?(nhirata.bugzilla) → in-moztrap+
Status: RESOLVED → VERIFIED
blocking-b2g: backlog → ---
You need to log in before you can comment on or make changes to this bug.