1518874 - [META] Search Widget for Fennec

Status: RESOLVED INCOMPLETE

(Firefox for Android Graveyard :: General, enhancement, P2)

Description

[:sdaswani]

I'm restricting this to Mozilla Internal until we figure out what we want to do.

Product would like us to create a simple 'search widget' for Fennec. See the user story.

Please note - we have had this already - see https://bugzilla.mozilla.org/show_bug.cgi?id=1221344#c5

The first part of this task is to 1) understand what we used to have and 2) describe how what we used to have is different than what is described above.

Comment 1

[Kevin Brosnan [Ex-Mozilla]]

We had a hard time keeping the user selected search engine in sync with the widget in the old version. I recall that Gecko would not flush the change to disk immediately and thus keeping the widget in sync was difficult.

Comment 2

[Andreas Bovens [:abovens]]

If this poses problems, we could also add an option to the widget allowing users to select an engine that's different from the one set in the browser.

Comment 3

[Andreas Bovens [:abovens]]

For reference: Chrome's approach is interesting, and could serve as a possible way forward here. When you focus on the Chrome search widget (the one that's installable via widgets), Chrome is immediately opened with the cursor placed in the address bar. This avoids keeping search engine preference in sync between widget and browser.

Comment 4

[Andrei Lazar]

Also from [https://developer.android.com/reference/android/appwidget/AppWidgetProviderInfo.html#widgetCategory]:

"widgetCategory

Determines whether this widget can be displayed on the home screen, the keyguard, or both. A widget which is displayed on both needs to ensure that it follows the design guidelines for both widget classes [...]"

I think this is also a nice to have, what are your thoughts Andreas?

Comment 5

[Kevin Brosnan [Ex-Mozilla]]

Can we show a responsive UI quick enough to do the Chrome thing?

Why would we care about the keyguard widget when they are only usable on Android 4.x and lower. "The widgetCategory attribute declares whether your App Widget can be displayed on the home screen (home_screen), the lock screen (keyguard), or both. Only Android versions lower than 5.0 support lock-screen widgets. For Android 5.0 and higher, only home_screen is valid." https://developer.android.com/guide/topics/appwidgets/

Comment 6

[Andreas Bovens [:abovens]]

Agree with Kevin. Just home_screen is enough.

Comment 7

[Andrei Lazar]

Attachment: Bug 1518874 Search Widget for Fennec (WIP) r=VladBaicu

Comment 8

[Andrei Lazar]

The build can be found here: https://drive.google.com/file/d/16MRFLInz5I1wv7rlwaQTPv1KevN9i4Lw/view?usp=sharing
The patch is still work in progress, with the UI being uncompleted as it serves a demo purpose for now.

In order to proceed further here:

1. I need some UI indications in order to proceed further here, should I copy the design from the previous widget?
2. Please review the functionality of the widget from the given demo.

Comment 9

[vzare]

Andreas, I propose that we copy the design from the previous widget. Also can we have the search widget default to search in private mode? And if we do that does it hinder our ability to collect telemetry?

Comment 10

[Kevin Brosnan [Ex-Mozilla]]

It would look dated. It was a pre-quantum design. It contained a couple problematic design elements most notably the new tab button. There were several issues resulting from incorrect Activity states (Android developer options -> Don't keep activities)

http://archive.mozilla.org/pub/mobile/nightly/2017/10/2017-10-01-10-03-34-mozilla-central-android-api-16-old-id/fennec-58.0a1.multi.android-arm.apk is a build that still has the widget and will install to org.mozilla.fennec.nightly and will not affect your Play Store Nightly build if you have one

Comment 11

[Andreas Bovens [:abovens]]

I agree with Kevin. Copying the design from the previous widget doesn't make much sense as the new widget's functionality will be simplified, and the design should be modern. So, let's go for a design that is close to what Chrome ships, albeit visually aligned with Photon. Who from the graphics team could assist with this? Vesta, as this will go into Fenix eventually, is there a chance you can help finding a design resource?

We should also make sure that we collect telemetry on usage.

Also can we have the search widget default to search in private mode?

Why is that? I think users just want to do a normal search, not necessarily a private one.

Comment 12

[vzare]

After discussing this with product leads, the request is to just build a basic regular search widget (no private search).

I reviewed the functionality of the build that was posted. It looks good. It take a few seconds to launch (as it brings up the full browser, tries to load the last open tab, and then switches to search mode) and I was wondering if there was a way to make it faster. It seems like Chrome just launches a search view and not the full browser (bypasses the existing open tabs) so I am wondering if that's something we can consider?

In the meantime, I am working on finding a design resource.

https://docs.google.com/document/d/1Rk7e-3Tz1t0tYO33hQCGQ4goMt3BaSZnECDKcnsvgTM/edit

Comment 13

[Pascal Chevrel:pascalc (PTO until April 26)]

Andreas, is that something we want to ship in 67 or is it planned for later? Thanks

Comment 14

[vzare]

Andreas, I have secured a UX resource to work on this. Can we get this into 67?

Comment 15

[Andrei Lazar]

Vzare, I considered your suggestion and after investigating further, I concluded that we can't get a much better performance/experience on this feature without a significant amount of work and time.

The best experience improvement we can get at this point, with the lowest risk of regression would be to simply avoid restoring old tabs state and start with a fresh session. Anything else involves considerable more time and we would have to make sure we don't have anything more pressing in our backlog.

How should I proceed further?

Comment 16

[vzare]

Thank you for investigating Andrei. I agree that we don't want to spend a significant time on this, and I like your proposed improvement of avoiding restoring old tabs an starting with the fresh session, I think that will make a huge performance improvement to the overall experience. I would like to proceed with that. How big is the effort and how long will it take?

Comment 17

[:sdaswani]

Andrew what would happen to the old tabs state? Is it still recoverable if I launch Fennec later from the app launcher?

Comment 18

[Andreas Bovens [:abovens]]

Sorry for the delayed response.

I'm happy to aim for 67.

Is the initial delay also an issue when Firefox is open in the background, and a search is initiated through the widget? I'm a bit concerned about trashing the old tabs and starting with a fresh session, esp. if the old tabs state is lost.

Comment 19

[Andrei Lazar]

Andreas and Susheel, regarding the old tabs state, let's take a look at the following scenario:

1. I have some tabs open already (let's call this session X)
2. I decide to open Fennec from the search widget
3. Fennec will open with no old tabs state
4. I continue my browsing, maybe generate even more tabs in this fresh new session (let's call this session Y)
5. I decide to close Fennec
6. Later, I decide to reopen Fennec from the app shortcut (normal app launch)

What should I see now?

case A: session X's tabs? (medium risk implementation)
case B: session Y's tabs? (the less error-prone implementation)
case C: a new session (let's call this session Z) which represents the merge between X's tabs and Y's tabs? (high risk of regression, a very complex and error-prone implementation)

Comment 20

[vzare]

Andrei, I misunderstood when you suggested not restoring old tabs and opening a new session, I thought you were suggesting opening a new tab.

Using your test build, initiating a search by tapping the search box (1)opens the existing Fennec session, (2)tries to restore existing tabs first, (3)then brings up a new tab with the cursor in the URL bar and the keyboard invoked.

My ask was to remove step 2 only (restoring existing tabs) and going directly to a new tab without killing the existing tabs/session.

If that's not possible, then I think we shouldn't make any changes to the behaviour. Would love Andreas thoughts on this.

Comment 21

[:sdaswani]

I hate case B - it makes me not want to use the search widget, as it blasts my previous 'work'.

Is it possible to have a case D - put Fennec in 'Focus mode' - you can't open new tabs, i.e., there is only one tab based on your search; include a method to 'launch the app' from Focus mode, leading to session X + this new tab added.

This may be hard, just giving you my wish :) .

Comment 22

[vzare]

When do you need the UX mock/specs in order to get this in 67 before code freeze on March 11?

Comment 23

[Andrei Lazar]

(In reply to vzare from comment #22)

When do you need the UX mock/specs in order to get this in 67 before code freeze on March 11?

I think March 3 should be fine. Thank you for your prompt reply!

(In reply to :sdaswani only needinfo from comment #21)

I hate case B - it makes me not want to use the search widget, as it blasts my previous 'work'.

Is it possible to have a case D - put Fennec in 'Focus mode' - you can't open new tabs, i.e., there is only one tab based on your search; include a method to 'launch the app' from Focus mode, leading to session X + this new tab added.

This may be hard, just giving you my wish :) .

I agree with you, case B is not optimal indeed. On the other hand, case D seems more appropriate to what we want to obtain.
Let me investigate a bit further on this case and maybe I will come back with a build or, at least an answer by the end of the week.

I'm going to make a follow-up bug for this experiment. See https://bugzilla.mozilla.org/show_bug.cgi?id=1526887

Meanwhile, I'm waiting for your questions, concerns or any suggestion regarding Susheel's proposal.

Comment 24

[Andreas Bovens [:abovens]]

When I do a search from the search widget, I simply expect the search to open in a new tab. If that's slower than expected, so be it. I don't want us to work around slow performance by trashing tabs or doing other complex stuff.

Comment 25

[vzare]

I agree with Andreas. My initial ask was to skip restoring existing tabs (not killing them) and going directly to a new tab. If that is not possible, then let's not change anything.

Comment 26

[vzare]

Andrei, would you please provide a rough estimate on the engineering effort for the following 2 scope items based on these mocks (second page): https://docs.google.com/document/d/1Rk7e-3Tz1t0tYO33hQCGQ4goMt3BaSZnECDKcnsvgTM/edit

-Adding a homescreen widget (mockup is at the bottom of the screen)
-Adding a just in time prompt to help users discover this new feature

Comment 27

[Kevin Brosnan [Ex-Mozilla]]

The plan is to make Google the only option or is should it track Firefox's search settings?

Comment 28

[vzare]

The search widget should use the same search preferences as the browser.

Comment 29

[vzare]

Hi Andrei, can I have an estimate on the engineering work required based on the mocks shared above by Wednesday?

Comment 30

[Andrei Lazar]

Hello vzare, it would take roughly ~2 weeks, but I'm going to need all the specifications and assets from this invision - https://mozilla.invisionapp.com/share/UJQJP4IC7WN#/screens/347173313_Widget as soon as possible.

Comment 31

[Pascal Chevrel:pascalc (PTO until April 26)]

(In reply to Andreas Bovens [:abovens] from comment #18)

Sorry for the delayed response.

I'm happy to aim for 67.

Is the initial delay also an issue when Firefox is open in the background, and a search is initiated through the widget? I'm a bit concerned about trashing the old tabs and starting with a fresh session, esp. if the old tabs state is lost.

Hi Andreas and Vesta, are you still aiming 67? I am asking because the 67 beta cycle starts in 3 weeks.

Comment 32

[Andrei Lazar]

Also the "Add automatically" option from the mock can't be implemented on versions lower than Android Oreo (API 26) [see https://developer.android.com/guide/topics/appwidgets/#Pinning]

Comment 33

[Andreas Bovens [:abovens]]

Yes, we'd still like to aim for 67. As for the Oreo limitation, that is fine: we can restrict it to just that version. Users on older Android versions can just add it from the widgets drawer.

Comment 34

[Kevin Brosnan [Ex-Mozilla]]

Uplifting a feature with strings will cause some problems for the localization teams.

Comment 35

[vzare]

We can limit this feature to English locales only.

Comment 36

[Andrei Lazar]

Attachment: v11.mp4

Comment 37

[Andrei Lazar]

Attachment: v12.mp4

Comment 38

[Andrei Lazar]

Hello everyone, here you can find the new build.

What is different from the previous build:

• Faster text/voice search action (now it should no longer wait for the previous tabs to load)
• Improved design (still missing the final assets and the size configuration)
• Handles the deep link (from Leanplum) which will generate an intent for adding the widget

I also created an experiment in Leanplum dashboard that demonstrates the feature discoverability through Leanplum.
It can be found under the name Search Widget – (Andrei) on "Firefox Android Dev" project.

Please check the functionality either by installing the APK or by watching the "Add automatically" and "Drag & Drop" videos.

Comment 39

[vzare]

Thanks Andrei, I tested it and it looks good. And thank you for creating the LeanPlum experiment. Can we also add a Unique source value for the widget so we can record when user initiates search using the widget vs browser search bar?

Also here are the final UX mocks and specs: https://mozilla.invisionapp.com/share/UJQJP4IC7WN#/screens/349402550_Searchwidget

Let me know how you want the assets.

Comment 40

[Andrei Lazar]

(In reply to vzare from comment #39)

Thanks Andrei, I tested it and it looks good. And thank you for creating the LeanPlum experiment. Can we also add a Unique source value for the widget so we can record when user initiates search using the widget vs browser search bar?

Yes, I am currently working on this, the old event is "E_Interact_With_Search_URL_Area".
I am going to name the one triggered by the search widget "E_Interact_With_Search_Widget_URL_Area" for the moment.
Please let me know if the marketing team decides on a new name.

Also here are the final UX mocks and specs: https://mozilla.invisionapp.com/share/UJQJP4IC7WN#/screens/349402550_Searchwidget

Let me know how you want the assets.

The measurement specs (size, color, font etc.) from invision are enough, no need for extra stuff, thank you!

Comment 41

[Andreas Bovens [:abovens]]

I've tested the functionality, and have filed a number of issues: see above.

Comment 42

[Andrei Lazar]

Hello everyone, this is the status for the tickets open by Andreas:

• 1532613 - Work in progress
• 1532614 - Fixed by 1526934
• 1532617 - Fixed by 1526934
• 1532619 - Work in progress
• 1532620 - Invalid because any change that refers to the Leanplum's prompt design and behavior should be addressed to the marketing team (e.g: color, alignment, triggering conditions etc.) (more explanations)

You can find here another build with the most recent changes and fixes.

Except the two WIP issues, do you feel like there are any other improvements to be made or blockers to be addressed before a PI request?

I am going to add Andrei Bodea from the QA team to this thread, so he can validate these issues on the latest build.

Comment 43

[vzare]

Andrei, thanks for the new build! It looks good and I can see that some bugs are fixed - but it's hard to test since the "add widget" prompt keeps popping up. Can we disable the prompt for users that have already added the search widget to their homescreen, and limit how often it pops up for other users?

Comment 44

[Verdi [:verdi] Best to slack me]

(In reply to Andrei Lazar from comment #42)

You can find here another build with the most recent changes and fixes.

Hi Andrei,
I just installed this latest version. Overall this is such a HUGE improvement - thank you. I did see a few things that I think would be great to fix if we can:

• The voice search action should just perform the search instead of making the user hit return. This would make it work like other voice search widgets.
• When the widget is resized down to 3x1 the copy is truncated but the intention was to just make it say "Search" at this point.
• When the widget is resized down to 2x1 there should be no copy at all. Currently it has ".."
• Add the 1x1 widget size.
• The widget install dialog doesn't have an accurate image of the widget (see attachment)
• The font in use looks like Roboto Thin on my device. If it's actually "Regular" maybe we should try making it "Medium" to help with legibility.

Comment 45

[Verdi [:verdi] Best to slack me]

Attachment: install.png

Comment 46

[Andrei Lazar]

Hello everyone,
this is the overall status for this feature.

Status

Andreas

• 1532613 - Fixed
• 1532614 - Fixed by 1526934
• 1532617 - Fixed by 1526934
• 1532619 - Fixed by 1532613
• 1532620 - Invalid

Andrei B.

• 1533611 - Fixed by 1532613

Kevin

• 1533611 - Work in progress
• 1533634 - Work in progress
• 1533645 - Fixed
• 1533646 - Work in progress

You can find here the latest build with the most recent changes and fixes.

What's different from the previous build

• Widget's layouts are more responsive (1x1, 2x1, 3x1 and 5x1)
• Added preview image for in-app prompt and widgets picker
• Search widget intent no longer triggers "Tab queue prompt"

BIG NOTE

As per Android documentation due to a variety of sizes, densities and shapes, we can't know for sure what is/going to be the exact size of a 1x1, 2x1, 3x1 widget grid, but Android can guarantee us some "constraints" through the formula 70 × N − 30, where N is the number of cells.

number of cells	minimum size (dpi)
1	40
2	110
3	180
...	...
N	70 × N − 30

Example

• an S8 has a cell width = 66dpi
• an S9 has a cell width = 80dpi

Conclusion

We can conclude that there may be devices where we'll never hit a specific configuration of widget (1x1 or 2x1 or 3x1).

Comment 47

[Liz Henry (:lizzard) (relman/hg->git project)]

n-i to myself to ask biz dev if there is any reason to keep this confidential. The code is in m-c at this point.

Comment 48

[Liz Henry (:lizzard) (relman/hg->git project)]

Discussed with mconnor, mcrandon. No reason to keep this hidden. We can also open up the dependent bugs.

Comment 49

[Andreas Bovens [:abovens]]

When will the remaining fixes land?

Comment 50

[Pascal Chevrel:pascalc (PTO until April 26)]

Added to our 67 beta Release Notes with this wording:
A new Firefox Search widget can be added to the home screen from the Android Widget Menu

Comment 51

[Andrei Bodea[:andrei]]

For now I will clear my NI, as I was added to the bug so I can see it(as it was private) and validate the issues(done everything above).

Comment 52

[Marcia Knous [:marcia]]

There is still one dependent bug linked to this bug, Bug 1535616. I guess when that is addressed we can close it out?

Comment 53

[Andrei Lazar]

Un-assigning myself from this since this META looks completed.

Comment 54

[Chris Peterson [:cpeterson]]

Downgrading priority from P1 to P2

Comment 55

[BMO Automation]

We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.