Closed Bug 769145 Opened 12 years ago Closed 12 years ago

Add an opt-in for the search suggestions feature

Categories

(Firefox for Android Graveyard :: General, defect)

Product:
Firefox for Android Graveyard
Component:
General
Platform:
x86_64
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(firefox18 verified, firefox19 verified)

Status:
VERIFIED FIXED
Milestone:
Firefox 18
Tracking Flags:
Tracking Status
firefox18 --- verified
firefox19 --- verified

People

(Reporter: mfinkle, Assigned: bnicholson)

References

Details

(Keywords: privacy)

Attachments

(8 files, 6 obsolete files)

Part 1: Move search engine logic to AllPagesTab
12.68 KB, patch
mfinkle
: review+
Details | Diff | Splinter Review
Part 2: Remove mSuggestEngine and use mSearchEngines for all engines
11.30 KB, patch
mfinkle
: review+
Details | Diff | Splinter Review
Part 3: Add mSuggestionsEnabled boolean
6.57 KB, patch
mfinkle
: review+
Details | Diff | Splinter Review
Screenshot of the prompt
184.96 KB, image/png
Details
Suggested UI, scribble
40.68 KB, image/png
Details
Part 4: Add search suggestions opt-in prompt
24.61 KB, patch
mfinkle
: review+
Details | Diff | Splinter Review
Part 5: Search suggestion opt-in animations, v3
20.44 KB, patch
lucasr
: review+
Details | Diff | Splinter Review
Part 6: Update test cases for layout changes
2.43 KB, patch
mfinkle
: review+
Details | Diff | Splinter Review 
The new search suggestion feature basically sends all URL requests to the search provider (Google for example) and some people might not like the privacy implications.

We already have a preference to disable the feature, but it might not be discovered before some users feel their privacy was abused.

What if we added an opt-in for the feature. I think a doorhanger would not be the best UX here. Maybe the row used for search suggestions in the Awesomebar could show a "Enable live search suggestions?" button-ish thing. When the user clicks, we'd enable and do the searches. If the user never clicks the button, but manually disables in Settings, we'd hide the button in the Awesomebar too, if it was still in the mode where it was being shown.

Thoughts?
I think that sounds like a good idea - those with privacy concerns should be satisfied with the feature being off by default, and a persistent, inline row should be noticeable enough for those who want it.

As a counterargument, we have search suggestions enabled by default in desktop Firefox, so people may expect this feature to be enabled already. It might surprise existing users when it lands, though; another dead simple idea would be to show some kind of notification/toaster when the Awesomebar is first shown to alert users that search suggestions are on.
Mark, is this something we could whip up a quick demo build of?

Your idea makes sense to me, I'm mostly curious to see how it feels going from the tabbed awesomescreen view, then starting to type, and then seeing this alert in the row underneath the url bar. 

Then if we all agree it works I can go and style a nice little message to put in there.
My inclination would be to default to ON, and have a pref to turn it off in the privacy/security section. It's really that useful. Are we doing everything we can to make this as privacy-conscious as possible?
To be more clear about that last question  - are we being as anonymous as the suggest API allows, etc?

If so, again, I'd turn this on by default. Our user-research shows that people use mobile browsers to search, more than anything, so this is a huge help (not to mention with cutting down typing). As for potential privacy costs, this is no different from when they type into a google search field, and we're going to let people turn it off in prefs.
As soon as we send any character to Google to attempt a search, we also have sent your IP address, which has it's own set of privacy concerns. On desktop, you have to type in the search box to get suggestions. Fennec is doing it in the URL editbox, which doesn't allow users to opt-out by not using.

I totally agree about the usefulness of the feature. I am just offering up some ideas for people who go through a lot of effort to try to keep their Android experience private. It's not easy to keep Google from knowing about what you do on an Android phone to begin with.
Thanks, Mark, for articulating these concerns.

Privacy is highly sensible particularly on mobile. By making contact to Google servers, you have revealed information to Google that I had carefully tried to hide before, namely the link between my DSL IP address (fixed) and my mobile IP address. The latter is a national pool, and I try to use that only on mobile. I live in a small village, and my DSL IP hostname shows my village, and use an alternative operator, so I am trivial to single out. To download Fennec, I had to switch to WiFi, and I wanted to test Fennec specifically on a website that I know doesn't use Google tracking, by merely by entering the URL, you had contacted Google. Google now not only knows that these 2 IP addresses are the same user/family, but also knows where I live. Damage done. I then found the pref to disable these Search suggestions, but that was too late.

(And I know that Google does keep that information, because earlier tests showed that Google kept my profile even though I deleted all cookies. Only when I changed IP address and deleted cookies *at the same time* could I get out of Google's tracking.

Privacy is the one thing that Google cannot compete on, that's our strength. Privacy is highly important in Germany, one of Firefox' biggest markets, and the reason why Google Chrome uptake is so slow in Germany. Do *not* imitate Google in these respects, be very and clearly, obviously different, upholding highest, impeccable standards, then you have a good selling point for Firefox against Google, also on Android.)

So, opt-out is too late and the IP address (esp. with cookies) alone is too much already.
(In reply to Mark Finkle (:mfinkle) from comment #0)
> Maybe the row used for search suggestions in the
> Awesomebar could show a "Enable live search suggestions?" button-ish thing.
> When the user clicks, we'd enable and do the searches. If the user never
> clicks the button, but manually disables in Settings, we'd hide the button
> in the Awesomebar too, if it was still in the mode where it was being shown.
> 
> Thoughts?

Good idea, I like it.

FWIW, the facebook, twitter and co could be disabled as well until the user enables it. If you're not containg their servers, it's not a privacy issue, but the UI is annoying (I never use facebook etc.), and the user can't really know whether we contact the server or not, so keeping all this off until the user enables it gives the user more a feeling of control.
Keywords: privacy
Clearly we have strong reasons both for and against :)

Given that, I would prefer not to make a UX call until we can see a prototype build with Mark's suggested implementation.
This moves all search engine code into AllPagesTab so we don't have to pass it between AwesomeBar/AwesomeBarTabs.
Assignee: nobody → bnicholson
Attachment #639595 - Flags: review?(mark.finkle)
Rather than handling mSuggestEngine and mSearchEngines separately, this puts them all in the same array. The suggest engine is enabled when mSuggestClient != null, and this patch puts it at the front of the array so we know which one it is.
Attachment #639596 - Flags: review?(mark.finkle)
This allows us to create the suggest engine without having to use it, which we need for switching suggestions from disabled->enabled.
Attachment #639598 - Flags: review?(mark.finkle)
Adds the opt-in prompt row. I didn't want to complicate things with an additional ViewHolder type since there's only one row, and also because this view will be permanently gone once the user makes a choice.
Attachment #639607 - Flags: review?(mark.finkle)
Attachment #639595 - Flags: review?(mark.finkle) → review+
Comment on attachment 639596 [details] [diff] [review]
Part 2: Remove mSuggestEngine and use mSearchEngines for all engines

Seems like some good simplification
Attachment #639596 - Flags: review?(mark.finkle) → review+
Comment on attachment 639598 [details] [diff] [review]
Part 3: Add mSuggestionsEnabled boolean

>diff --git a/mobile/android/chrome/content/browser.js b/mobile/android/chrome/content/browser.js

>     sendMessageToJava({
>       gecko: {
>         type: "SearchEngines:Data",
>         searchEngines: searchEngines,
>         suggestEngine: suggestEngine,
>-        suggestTemplate: suggestTemplate
>+        suggestTemplate: suggestTemplate,
>+        suggestEnabled: Services.prefs.getBoolPref("browser.search.suggest.enabled")
>       }
>     });

My OCD is kicking in and I almost want you to change the JSON, but I'll hold off for now. It could be:

  gecko: {
    type: "SearchEngines:Data",
    engines: searchEngines,
    suggestions: {
      engine: suggestEngine,
      template: suggestTemplate,
      enabled: Services.prefs.getBoolPref("browser.search.suggest.enabled")
    }
  }
Attachment #639598 - Flags: review?(mark.finkle) → review+
(In reply to Mark Finkle (:mfinkle) from comment #5)
> As soon as we send any character to Google to attempt a search, we also have
> sent your IP address, which has it's own set of privacy concerns. On
> desktop, you have to type in the search box to get suggestions. Fennec is
> doing it in the URL editbox, which doesn't allow users to opt-out by not
> using.

Doesn't this happen as soon as anyone uses Google at all (i.e. google.com or otherwise)?

> I totally agree about the usefulness of the feature. I am just offering up
> some ideas for people who go through a lot of effort to try to keep their
> Android experience private. It's not easy to keep Google from knowing about
> what you do on an Android phone to begin with.

Yup - I appreciate it! I just still think that defaulting an extremely useful capability and UX improvement to off here is disproportionate to the concerns, given that we do allow people to turn it off (already well ahead of what others do).
Comment on attachment 639607 [details] [diff] [review]
Part 4: Add search suggestions opt-in prompt

>diff --git a/mobile/android/base/awesomebar/AllPagesTab.java b/mobile/android/base/awesomebar/AllPagesTab.java

>+        private void setSuggestionsEnabled(boolean enabled) {

>+            // show suggestions if user just enabled them
>+            if (enabled)
>+                AllPagesTab.this.filter(mSearchTerm);

Do we need the "AllPagesTab.this." part?

>diff --git a/mobile/android/base/locales/en-US/android_strings.dtd b/mobile/android/base/locales/en-US/android_strings.dtd

>+<!ENTITY suggestions_prompt "Enable live search suggestions?">

We might want to think about the text a bit more:
* "Enable" is not very friendly, maybe "Use" ?
* "live search suggestions" might be too hard to grok

"Search as you type?" but "Search" is a bit vague


>diff --git a/mobile/android/base/resources/layout/awesomebar_suggestion_prompt.xml b/mobile/android/base/resources/layout/awesomebar_suggestion_prompt.xml

>+<RelativeLayout xmlns:android="http://schemas.android.com/apk/res/android"
>+                android:layout_width="fill_parent"
>+                android:layout_height="wrap_content"
>+                android:minHeight="@dimen/awesomebar_row_height"
>+                android:padding="6dip">
>+
>+    <TextView android:id="@+id/suggestions_prompt_title"
>+              android:layout_width="fill_parent"
>+              android:layout_height="wrap_content"
>+              android:textAppearance="?android:attr/textAppearanceMedium"
>+              android:textColor="?android:attr/textColorPrimary"
>+              android:layout_marginLeft="6dip"
>+              android:text="@string/suggestions_prompt" />
>+
>+    <Button android:id="@+id/suggestions_prompt_yes"
>+            android:layout_below="@id/suggestions_prompt_title"
>+            android:layout_height="wrap_content"
>+            android:layout_width="wrap_content"
>+            android:textSize="13sp"
>+            android:layout_marginLeft="6dip"
>+            android:text="@string/button_yes" />
>+
>+    <Button android:id="@+id/suggestions_prompt_no"
>+            android:layout_below="@id/suggestions_prompt_title"
>+            android:layout_toRightOf="@id/suggestions_prompt_yes"
>+            android:layout_height="wrap_content"
>+            android:layout_width="wrap_content"
>+            android:textSize="13sp"
>+            android:text="@string/button_no" />
>+
>+</RelativeLayout>

We might want to add an image to the left side, something to draw attention that we are prompting. The text is a bit too big too. Make the font size the same as the sub-title rows? The buttons are a bit too big too IMO

We'll work with Ian to get this looking right.

>diff --git a/mobile/android/chrome/content/browser.js b/mobile/android/chrome/content/browser.js

>+    } else if (json.name == SearchEngines.PREF_SUGGEST_ENABLED) {
>+      Services.prefs.setBoolPref(SearchEngines.PREF_SUGGEST_PROMPTED, true);

A comment in the block saying "Any change to enabling suggestions will disbale the prompt"

>     sendMessageToJava({
>       gecko: {
>         type: "SearchEngines:Data",
>         searchEngines: searchEngines,
>         suggestEngine: suggestEngine,
>         suggestTemplate: suggestTemplate,
>-        suggestEnabled: Services.prefs.getBoolPref("browser.search.suggest.enabled")
>+        suggestEnabled: Services.prefs.getBoolPref(this.PREF_SUGGEST_ENABLED),
>+        suggestPrompted: Services.prefs.getBoolPref(this.PREF_SUGGEST_PROMPTED)
>       }

Hello my old friend. File a followup bug to restructure the JSON a bit. Won't block landing this, but I think we should clean it up.

r+ from me, but let's wait to land until Ian has had some UX feedback.
Attachment #639607 - Flags: review?(mark.finkle) → review+
(In reply to Madhava Enros [:madhava] from comment #16)
> (In reply to Mark Finkle (:mfinkle) from comment #5)
> > As soon as we send any character to Google to attempt a search, we also have
> > sent your IP address, which has it's own set of privacy concerns. On
> > desktop, you have to type in the search box to get suggestions. Fennec is
> > doing it in the URL editbox, which doesn't allow users to opt-out by not
> > using.
> 
> Doesn't this happen as soon as anyone uses Google at all (i.e. google.com or
> otherwise)?

Yes, but it takes explicit work to go to google.com. Merely typing a letter in the awesomebar is all it takes with search suggestions enabled. Actually, we need to make sure that just requesting the Search Engines list itself doesn't trigger a ping.
I tried the build, and seeing this in action makes for a somewhat confusing experience:

I see a prompt asking me if I want to use live search suggestions, *and* I see google, amazon, twitter, wikipedia, all with little tiles that have my search term in them. So in my head I think: "Why are you asking me if you are already doing this?"

(I personally know that's not what is actually happening, but that's what it looks like is happening)

---

So my two issues are: 

1. The prompt doesn't play nicely with our built in amazon/google/twitter/wikipedia search shortcuts, and we certainly should not get rid of those

2. Are we really so worried about sending searches to Google, especially when people are already on a Google Phone? Search is a primary use case on mobile browsers, and I have to echo Madhava here that the benefit of including search suggest (with an option to opt out) far outweighs the cost of defaulting to off and making people decide.
(In reply to Ian Barlow (:ibarlow) from comment #19)
> confusing experience:
> I see a prompt asking me if I want to use live search suggestions, *and* I
> see google, amazon, twitter, wikipedia, all with little tiles that have my
> search term in them. So in my head I think: "Why are you asking me if you
> are already doing this?"

Exactly. That's what I meant in comment 7.
I don't think this should be opt in. This is expected behavior. We don't ask people to opt in to it in Firefox desktop when it happens in the very prominent search box. If we combine search and addressing on desktop, I don't intend it to be opt in.

Can we mitigate sending things which are likely to be URLs like Chrome does?
(In reply to Asa Dotzler [:asa] from comment #21)
> I don't think this should be opt in. This is expected behavior. We don't ask
> people to opt in to it in Firefox desktop when it happens in the very
> prominent search box. If we combine search and addressing on desktop, I
> don't intend it to be opt in.
> 
Though one difference in our case is that we have already released Firefox for Android, so landing search suggestions would be a sudden change users probably won't expect.

If we care about this, maybe we could default suggestions to "on" for new users and show the prompt for existing users.
Blocks: 586885
> This is expected behavior. 

It clearly wasn't.

> We don't ask people to opt in to it in Firefox desktop ... search box.

Already discussed and answered. When I go to search, I expect Google to be contacted.

When I go to an arbitrary URL, I do *not* expect Google to know about it. I must be able to go to an arbitrary website without Google knowing it and knowing my existence.
(In reply to Ben Bucksch (:BenB) from comment #24)
> > This is expected behavior. 
> 
> It clearly wasn't.
> 
> > We don't ask people to opt in to it in Firefox desktop ... search box.
> 
> Already discussed and answered. When I go to search, I expect Google to be
> contacted.
> 
> When I go to an arbitrary URL, I do *not* expect Google to know about it. I
> must be able to go to an arbitrary website without Google knowing it and
> knowing my existence.

Ben, we're not designing this phone for you. We're designing it for a much larger audience. Your expectations are interesting and I'm happy to listen to them, but they're just one of many inputs. 

I assert that this is AND SHOULD BE expected behavior for most people and so opt out is a fine solution for the minority who share your concerns.  I've also asked about mitigation, like Chrome has made, to not send things that look like URLs.
(In reply to Asa Dotzler [:asa] from comment #25)
> I assert that this is AND SHOULD BE expected behavior for most people and so
> opt out is a fine solution for the minority who share your concerns.  I've
> also asked about mitigation, like Chrome has made, to not send things that
> look like URLs.

Can you elaborate on this? In both desktop and mobile Chrome, I see suggestions when I begin typing URLs (e.g., I see "http://xyz123.biz/check" as a suggestion if I enter "http://xyz").
(In reply to Brian Nicholson (:bnicholson) from comment #26)
> (In reply to Asa Dotzler [:asa] from comment #25)
> > I assert that this is AND SHOULD BE expected behavior for most people and so
> > opt out is a fine solution for the minority who share your concerns.  I've
> > also asked about mitigation, like Chrome has made, to not send things that
> > look like URLs.
> 
> Can you elaborate on this? In both desktop and mobile Chrome, I see
> suggestions when I begin typing URLs (e.g., I see "http://xyz123.biz/check"
> as a suggestion if I enter "http://xyz").

I don't know the specifics, but Peter Kasting, the creator of the Omnibox, has said in various public communications that it does not send all keystrokes to Google. I vaguely remember him correcting me on this and saying that there were heuristics in there to prevent sending off strings that didn't look like search terms. Because I can't find records of this with a quick Bing or Google search, I've cc'd Peter so he can hopefully enlighten us.
> Ben, we're not designing this phone for you.

And it isn't just about me, but all of Germany and big parts of Europe, as I have mentioned in comment 6. Privacy is a constitutional right, just like freedom of speech is for you in the USA, and we react similarly emotional to infractions. Remember that your biggest market is Europe, not the US.

> SHOULD BE expected behavior

Because you say so? I think it's fair to expect that I can visit (for example my own) website without any central entity (e.g. Google) knowing it.

---

I think particularly the suggestion in comment 7 actually improves usability. It's completely pointless to always offer searches on each of Google, Facebook, Twitter, you-name-it.com, even if I never used Twitter, but it keeps offering it every single time I type something. I call this advertizing, not a feature. I think it's good when these services are opt-in (which can be just 1-2 clicks/tabs). Then you can also offer a lot more variety in search services, not just 4.
Recent robocop failure on m-i:

1 INFO TEST-START | testSearchSuggestions
Exception caught during test!
java.lang.RuntimeException: Error setting SuggestClient
	at org.mozilla.fennec.tests.testSearchSuggestions.connectSuggestClient(testSearchSuggestions.java:121)
	at org.mozilla.fennec.tests.testSearchSuggestions.testSearchSuggestions(testSearchSuggestions.java:47)
	at java.lang.reflect.Method.invokeNative(Native Method)
	at java.lang.reflect.Method.invoke(Method.java:521)
	at android.test.InstrumentationTestCase.runMethod(InstrumentationTestCase.java:204)
	at android.test.InstrumentationTestCase.runTest(InstrumentationTestCase.java:194)
	at android.test.ActivityInstrumentationTestCase2.runTest(ActivityInstrumentationTestCase2.java:186)
	at org.mozilla.fennec.tests.BaseTest.runTest(BaseTest.java:93)

...looks like it might be related to the recent landings (comment 22).
(In reply to Asa Dotzler [:asa] from comment #25)
> I assert that this is AND SHOULD BE expected behavior for most people and so
> opt out is a fine solution for the minority who share your concerns.  I've
> also asked about mitigation, like Chrome has made, to not send things that
> look like URLs.

While I agree on your assessment about what *behavior* is appropriate for most people, this change is also going to send a message.  In light of past statements on this issue by Mozillians -- including yourself on multiple occasions [1][2] -- any change here is sure to become a huge focus for the press and for our users and contributors.  I know you have personally experienced how badly-managed publicity can detract from our intended messaging and create more work and distractions for everyone.

One of the best ways we can control the messaging and publicity when we add this feature is by being very careful and thoughtful about the engineering and UX design of the feature itself.  If we had included suggestions in the addressbar from day one, that would be one thing, but we didn't.  We're changing an existing product because we've changed our thinking, and so we have a transition to manage.  We need to transition in the product to acknowledge the transition in our thinking.

If we just flip the switch as though we had never made those past arguments, then the (unintentional) message that we are sending -- and that the press and our users are sure to hear and repeat -- is that we have simply forgotten or given up on our old principles.  But if we show that we are still doing things differently from other browsers, and go out of our way to respect the users like Ben who chose us because they care especially deeply about privacy, then the message is very different.

I think the proposed opt-in mechanism (which happens inline within the awesomebar suggestions) is ideal because it does not interrupt the user's work flow, it's inviting to users who do want to try the new feature, and it's unintrusive to users whether they opt in or not.

1. http://www.quora.com/What-features-does-Firefox-have-that-Chrome-does-not/answer/Asa-Dotzler
2. http://www.quora.com/Web-Browsers/Why-hasnt-Firefox-merged-their-search-bar-and-address-bar-similar-to-Chrome/answer/Asa-Dotzler
Depends on: 771677
(In reply to Geoff Brown [:gbrown] from comment #29)
> Recent robocop failure on m-i:
> ...looks like it might be related to the recent landings (comment 22).

I filed bug 771677 separately to keep track of this.
(In reply to Matt Brubeck (:mbrubeck) from comment #30)
> (In reply to Asa Dotzler [:asa] from comment #25)
> > I assert that this is AND SHOULD BE expected behavior for most people and so
> > opt out is a fine solution for the minority who share your concerns.  I've
> > also asked about mitigation, like Chrome has made, to not send things that
> > look like URLs. 

> If we just flip the switch as though we had never made those past arguments,
> then the (unintentional) message that we are sending -- and that the press
> and our users are sure to hear and repeat -- is that we have simply
> forgotten or given up on our old principles.  But if we show that we are
> still doing things differently from other browsers, and go out of our way to
> respect the users like Ben who chose us because they care especially deeply
> about privacy, then the message is very different.

Or we can say "mobile is different because there's no room for two fields" or "we're changing our stance. we tried, but the rest of the industry went the other way and we're not going to be the only ones who don't have a great user experience here for a few people who understand the distinction. For those who want more privacy, just like the other browsers offer, Firefox offers an opt out."

> I think the proposed opt-in mechanism (which happens inline within the
> awesomebar suggestions) is ideal because it does not interrupt the user's
> work flow, it's inviting to users who do want to try the new feature, and
> it's unintrusive to users whether they opt in or not.

It is not "ideal" at all. Truly "in the flow" opt-ins means that next to no one will get the benefit because it's too unobtrusive to get noticed. If you make it optrusive, you'll end up with a random mix of people who click whatever they think will get it out of the way fastest, people who get exactly the opposite of what they wanted, and a sliver of the population actually ending up with their desired results.  If it's opt-out, on the other hand, those who care will find it and opt out and everyone else will get the benefit of the new feature.
obtrusive, of course.
I agree that an opt-out would be the best design if we were considering the UX in isolation.  But I think a good opt-in mechanism can do a lot to avoid a PR shitstorm and communicate with our users better without making the UX significantly worse.  You might not care much about PR, but I think the mobile team needs to weigh it fairly heavily since we have an uphill perception battle just to get Android users to try our browser.

> Truly "in the flow" opt-ins means that next to no
> one will get the benefit because it's too unobtrusive to get noticed. If you
> make it optrusive, you'll end up with a random mix of people who click
> whatever they think will get it out of the way fastest, people who get
> exactly the opposite of what they wanted, and a sliver of the population
> actually ending up with their desired results.

A "sliver" of the population?  Even if it were completely random, 50% of people would get the right experience; are you suggesting we can't even design something that performs as well as random?  On the contrary, if this is a concern then we can easily change the design to guide users to what we think is the best default behavior.

For example, the opt-in could be a one-tap action inline in the search results ("Tap here to see search suggestions"), so users would get a convenient one-touch invitation to opt in every time they do a search.  Hiding that prompt completely could require a more explicit action in the settings screen, like the current opt-out preference.
(In reply to Asa Dotzler [:asa] from comment #32)
> Or we can say "mobile is different because there's no room for two fields"

An argument somewhat undermined by Apple's success selling mobile devices with two fields in the browser...

> or "we're changing our stance. we tried, but the rest of the industry went
> the other way and we're not going to be the only ones who don't have a great
> user experience here [...]"

I think you overestimate our ability to shape the discussion with fairly subtle arguments like this.  It's what we do in-product that users and reviewers will ultimately comment and judge us on.  And what exactly has changed in the industry since just seven months ago when you were publicly arguing *against* search suggestions in the address field?  We've made it clear that this was a matter of principle, so I think it demands a much more careful transition than what amounts to "nevermind, we give up."

(Is Apple not part of "the rest of the industry"?)
Adding afowler to the bug in regards to privacy
(In reply to Matt Brubeck (:mbrubeck) from comment #34)
> For example, the opt-in could be a one-tap action inline in the search
> results ("Tap here to see search suggestions"), so users would get a
> convenient one-touch invitation to opt in every time they do a search. 
> Hiding that prompt completely could require a more explicit action in the
> settings screen, like the current opt-out preference.

Exactly.
[ Sho ]
[> Show search suggestions from Google ]
[> Show more search sites]

Once enabled, the suggestions can stay until I disable them again.

[ Sho ]
[g] Shoes
[g] Shogin
[g] Sholin
[> Show more search sites]

---

The "Show more search sites", when tapped on, allows me to see a long list of search providers, like Twitter, DuckDuckGo, Shopping and others. I can then select those I want to see regularly.

[V Show more search sites]
[ ] Facebook
[ ] Twitter
[ ] Youtube
[ ] Google picture search
[ ] Google News
[ ] Google Shopping
[ ] Amazon
[ ] Craigslist
[x] DuckDuckGo

Ideally, even when enabled, these would still work the same way as Facebook does today, without server ping, but open a search result page on the site when I tap on it.
[ Sho ]
[g] Shoes
[g] Shogin
[g] Sholin
[Facebook Sho]
[DuckDuckGo Sho]
(Here, I have chosen to enable Google search suggestions, and the Facebook and DuckDuckGo search link buttons specifically. The latter 2 are nevertheless not contacted until I tap on their respective button.)

Of course, these are just scribbles, just ideas. Matt and others might be able to improve upon it.

---

I wonder whether we can more explicitly differentiate between search and URLs, though.
If we can current spend 4 rows for Facebook, Twitter, then we can offer 2 textfields, no?

---

Asa, opt-out is too late. Once I see the feature, the damage is already done and can never be undone anymore.

Asa, I realize this is a philosophical difference between you and me, but imitating the competition to the last bit was never a good strategy for winning, *especially* so for open source projects, because it removes the point of competition in the first place.
(In reply to Matt Brubeck (:mbrubeck) from comment #34)
> I agree that an opt-out would be the best design if we were considering the
> UX in isolation.  But I think a good opt-in mechanism can do a lot to avoid
> a PR shitstorm and communicate with our users better without making the UX
> significantly worse.  You might not care much about PR, but I think the
> mobile team needs to weigh it fairly heavily since we have an uphill
> perception battle just to get Android users to try our browser.

Part of that perception problem is that we don't do what the users and the reviewers expect from their browser. You know how we took users from IE with Firefox? By matching and then beating their expectations. Parity on stuff that users actually like was critical. It wasn't enough -- we had to be better at some things, but if we didn't meet their basic expectations, we'd have never gained significant share.

Every user who fails the opt in test, for what ever reason, will be having a less good than the competition experience here. That's not meeting and beating the competition, IMO. That's leaving a large number of users with a worse experience because some very small number of users will want an alternative experience.

> > Truly "in the flow" opt-ins means that next to no
> > one will get the benefit because it's too unobtrusive to get noticed. If you
> > make it optrusive, you'll end up with a random mix of people who click
> > whatever they think will get it out of the way fastest, people who get
> > exactly the opposite of what they wanted, and a sliver of the population
> > actually ending up with their desired results.
> 
> A "sliver" of the population?  Even if it were completely random, 50% of
> people would get the right experience; are you suggesting we can't even
> design something that performs as well as random?  On the contrary, if this
> is a concern then we can easily change the design to guide users to what we
> think is the best default behavior.

I'm suggesting that if you make it obtrusive, most people will dismiss it without any attention to getting it right. That's not "getting what they wanted" for any of them because they didn't even attempt to express a preference. About half of them would get the experience they should have, (what I want for them) but that's not the same as getting their desired results. That's not "opting" anything.  A minority will try to digest it and I think they'll get it right a bit better than random  but that would still be a lot of them getting something they didn't desire, leaving only a sliver of the total population actually engaging and getting their desired results.

Opt in isn't really an opt at all for most users then. And for those who engage, it's something of a crap shoot. That's why opt in sucks. We treat it like we're giving all of our users a choice but we're not really. We get to be all self-congratulatory about letting users decide, but the truth is that most of them don't want to decide. They want it to just work (and probably "just work like the product they were using before they tried yours" unless that was something really broken that you're attempting to fix.) 

Opt in is sort of like adding more preferences.  We do it when we're afraid to make the right choice to support most of our users. It's something of a cop-out. It doesn't actually help most users. In fact, it impedes most users.

In the rare case that we really believe our users care deeply about a behavior AND they're split about 50/50 on which way it should behave, then a choice might make some sense. I don't think that this is one of those rare cases. 

Finally, before making important decisions because of a concern about PR, it'd be nice to consult with PR about whether or not it actually is or should be a concern and if it is then how to mitigate.
(In reply to Matt Brubeck (:mbrubeck) from comment #35)
> And what exactly has
> changed in the industry since just seven months ago when you were publicly
> arguing *against* search suggestions in the address field?  We've made it
> clear that this was a matter of principle, so I think it demands a much more
> careful transition than what amounts to "nevermind, we give up."
> 
> (Is Apple not part of "the rest of the industry"?)

Several things happened. Apple joined search and address on Safari. Chrome became #1 or #2 browser in many public measures. I discovered by talking to lots of people over the last 6 months (since I started investigating joining the two on Desktop) that it made sense to approximately zero percent of the dozens of people I asked about it even after trying to explain to them the "keylogging" aspects of it.
If we make this opt-in, then we've basically killed the feature and removed one of the very nice usability enhancements that Fennec has. There is lots of research to show that users never change default settings [1].

Please don't make search suggestions opt-in by default.

[1] http://www.uie.com/brainsparks/2011/09/14/do-users-change-their-settings/
For one thing, if we change the behavior there, we need a privacy review and possibly changes in our privacy policies.

For the other, me, Ben and others have been actively going out to people and explaining them how Firefox (on both desktop and mobile) is so much better than Chrome with one of our main arguments being that it doesn't send every keystroke out into the internet to be analyzed and used for targeting ads to you. I had success with almost every I talked to, but we probably talked to different people. A change like this takes this away. And yes, I know that other people actually vote for a different browser *because* of search suggestions. I want Firefox on desktop and mobile to have added value to what "the others" provide. Privacy is one of the few things where we can do that. Or we can vote to dump that principle and just copy what "the others" do. But why should someone chose Firefox then, if it has no differentiators at all and just copies what $other-company-from-MV does? Anyhow, Bugzilla is not a discussion forum, this policy discussion probably belongs elsewhere.
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #41)
> For one thing, if we change the behavior there, we need a privacy review and
> possibly changes in our privacy policies.

Yep. We do. 

> For the other, me, Ben and others have been actively going out to people and
> explaining them how Firefox (on both desktop and mobile) is so much better
> than Chrome with one of our main arguments being that it doesn't send every
> keystroke out into the internet to be analyzed and used for targeting ads to

Well, that would be a lie. Google doesn't use those keystrokes for ads. They use them for suggests and they anonymize them almost immediately. They have a whole separate policy around them from their searches submitted with actual submission buttons. 

So, your argument seems to me to be that because we've effectively misrepresented the competitors feature (I admit I've misrepresented the feature, and was corrected publicly by it's creator) that we must keep a worse experience for our users?

> you. I had success with almost every I talked to, but we probably talked to
> different people. 

We talked to different people for sure. I've been actively investigating this for months in order to better understand the situation for desktop and I have had zero success helping users actually understand the difference between what Google actually does and what we do. It may be that you're explaining things in a scarier way (less accurate?) than I have been but I do not believe that if you truly educated a person, German or American, about the real difference between today's Firefox and Chrome (desktop) that they would think our current solution is obviously better. 

> I want Firefox on desktop and mobile to have added value to
> what "the others" provide. 

Me too. But that must be truly *added* value and not, as an opt in would create *lessened* value for most people. It's only added value when you are as good as and then better. If you are less good than it isn't added value.

We cannot hope to succeed unless we do as good as they do and then better. Giving users a less good experience and saying "but we do these other cool things" is not a winning formula. 

We can offer privacy here just like we do in Firefox on desktop OSes, with a preference to turn off suggestions.
(In reply to Asa Dotzler [:asa] from comment #42)
> Well, that would be a lie. Google doesn't use those keystrokes for ads.

They may or may not. Other than one developer statement, we have no prove and cannot have any, as we know they easily can do that if they want to. If they don't, I guess the only reason for that is that it would be too much data to analyze at this point. But it's only a weak guess, we do and can not actually know what's really going on there.

> [...] but I
> do not believe that if you truly educated a person, [...]

We won't be able to resolves differences in our beliefs in the limited fashion Bugzilla provides where we are distracting the actual work with a religious discussion. We are both known to be very emotional and outspoken about what we believe in, and that's good, but probably not helpful right here. ;-)

> We can offer privacy here just like we do in Firefox on desktop OSes, with a
> preference to turn off suggestions.

Once we have sent this once, we have given Google a lot of data already and they probably set some cookie-equivalent tracking on their side, as Ben states. An after-the-fact opt-out is no solution to that.
Some random thoughts to help reduce the privacy impact, even while it's active (opt-in or opt-out):

* Stop using suggestions once the user types any of |.:/|. Any of those 3 characters would indicate that the typed value is likely a url. (Perhaps re-enable once a space has been typed, consider "3.14 volume" or "jake 2.0").
* If the initial input is "www" don't use suggestions.
* Integrate with adaptive learning. EG when you type "foo" and then click a particular result, Firefox's (desktop at least) awesomebar uses that to weight that result higher in the future. That weighting could also be used to suppress search suggestions.
* Trickier: if awesomebar has highly-weighted results for what you're typing, stop (pause?) suggestions to give the user a chance to tap and existing result.
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #43)
> (In reply to Asa Dotzler [:asa] from comment #42)
> Once we have sent this once, we have given Google a lot of data already and
> they probably set some cookie-equivalent tracking on their side, as Ben
> states. An after-the-fact opt-out is no solution to that.

That's just not true. Read Google's privacy policy on search suggestions. They do not track search suggestions. It's not just the word of one Google employee.
There are different kinds of opt-in. If it's somewhere hidden in the settings (like smooth scrolling used to be), you can indeed expect users to keep them at default. However, I'm quite sure people do tick "Remember my login" boxes on lots of sites, for example, for the simple reason because it is in sight :)

If people expect the browser to show search suggestions, but instead see the opt-in button where they would think those suggestions would be, they *will* click it. They might think "Why wouldn't they do this by default?" for a few seconds, but as it just works later on, they will forget about it. If implemented correctly, it really is hardly a pain for those who want it, and a big relief for those who don't. On the other hand, having this as an opt-out will hurt people who care about this.

The actual question is "Do we want to annoy lots of users or fuck everything up for just a few of them?". I tend to choose the first one.
(In reply to Tim from comment #46)
 > The actual question is "Do we want to annoy lots of users or **** everything
> up for just a few of them?". I tend to choose the first one.

Wow. I think I'm going to have to let that sink in for a while.
Sorry guys for all the noise. I lost control there. I'mma back off for a while, put together a proposal for how Product thinks this should work, collect some privacy people expertise on the subject, and return at a later date. In the mean time, UX should probably drive here.
(In reply to Asa Dotzler [:asa] from comment #45)
> That's just not true. Read Google's privacy policy on search suggestions.
> They do not track search suggestions. It's not just the word of one Google
> employee.

Slightly playing devil's advocate here (and slightly I'm a tinfoil hat kinda guy), but the same company was knowingly caught sniffing and storing private data from random people's wifi networks. A practice that was also against their own privacy policy. In any case, trusting a third party's (closed-source) code and privacy policies as a form of security for our users seems a bit silly.

I'm still not sure what the problem with this is though (but I haven't tried the patch yet). ian, would it be better if the prompt was on its own line the first time the awesomebar was used, with two buttons? "OK" and "Never ask again". Or can we just tweak its placement/wording/style? i.e. A subtle "Suggestions?" button on the far right of the row. Maybe change it to an 'x' if the user selected it to make it easy to turn off as well? Heck, a "Suggest?" button in the urlbar itself?
For those who have not tried the build, here is a screenshot of the inline prompt.
(In reply to Wesley Johnston (:wesj) from comment #49)
> (In reply to Asa Dotzler [:asa] from comment #45)
> > That's just not true. Read Google's privacy policy on search suggestions.
> > They do not track search suggestions. It's not just the word of one Google
> > employee.
> 
> Slightly playing devil's advocate here (and slightly I'm a tinfoil hat kinda
> guy), but the same company was knowingly caught sniffing and storing private
> data from random people's wifi networks. A practice that was also against
> their own privacy policy. In any case, trusting a third party's
> (closed-source) code and privacy policies as a form of security for our
> users seems a bit silly.
> 
> I'm still not sure what the problem with this is though (but I haven't tried
> the patch yet). ian, would it be better if the prompt was on its own line
> the first time the awesomebar was used, with two buttons? "OK" and "Never
> ask again". Or can we just tweak its placement/wording/style? i.e. A subtle
> "Suggestions?" button on the far right of the row. Maybe change it to an 'x'
> if the user selected it to make it easy to turn off as well? Heck, a
> "Suggest?" button in the urlbar itself?

These are the problems that I see with this:
1) Users who aren't sure how to answer the question will not respond to it and leave it visible (I'm assuming the prompt stays visible until a response is received). This will cause users to visually scan over this question every single time they type in the awesome bar (causing mental overhead as well as a reduction of the number of visible results).

2) It is very easy to hit the wrong thing on a touch screen. What does a user do if they hit No? The discoverability and the chances that a user will go to the Preferences to enable this is very low.

3) If people try to solve the problem (1) by moving the prompt to the bottom of the screen, it can get covered by the keyboard and also will be harder to find.

4) The prompt here doesn't really tell users why they're not enabled by default. Are users going to think that this is an experimental feature and that Mozilla doesn't have enough confidence in it yet? There isn't necessarily a direct privacy relationship here that 80% of users will understand right away. Giving users the perception that we aren't confident in our software is not something we should be doing (especially for a new product like Fennec).

5) The percentage of users concerned about privacy is the minority (see the percentage of users who enable DNT as well as other privacy related features of the desktop browser). Features like Private Browsing are opt-in by design. We don't have Private Browsing enabled by default because it takes away some really great usability features of the browser. We should not be altering the default operation of our users 100% of the time for the rare cases where users want to look at something in private.

In summary, I feel pretty strongly that search suggestions should remain an 'opt-out' feature. Moving this to 'opt-in' kills the feature for 95% of our users.
Attached image Suggested UI, scribble — 
This is a scribble of comment 37.
Created with <http://builds.balsamiq.com/b/mockups-web-demo/>
Thanks for the input, everyone.

Dolske (in c44) - those are good suggestions. I think the first two are things we could try almost right away (not going to suggestions as soon as we see that the text entered is a URL).

Jared (in c52) - yes, I agree with pretty much all of this.

Wes (in c49), and others -- Generally, it's not the the opt-in UI is terrible, so much as that going with opt-in adds an extra step and some confusion about something that is actually a huge help to the vast majority of users. On a mobile phone, we _want_ people to have this feature. It helps minimize typing; it supports what we see as a greater and greater percentage of what mobile users do in a browser - searching; and it makes our awesomescreen even more effective, by balancing websearch with history. For people who don't want to use it, we're including an opt-out option for this in prefs already. Do we really need another speedbump in the main flow?

The cost-benefit ratio seems particularly low in light of what Asa was saying of how Google uses this data -- in c42: "Google doesn't use those keystrokes for ads. They use them for suggests and they anonymize them almost immediately. They have a whole separate policy around them from their searches submitted with actual submission buttons."

Robert - in terms our our being able to advocate for Firefox usage here -- you'll still be able to turn this off in prefs. Aren't we the only browser that will let you do that?
> It helps minimize typing

Word completion can and should be done entirely without server. It seems to me that the problem is the same for every textfield, be it in the browser or in the SMS app.

Furthermore, most people will just type common website names, like "Facebook", so the awesome bar can already take care of a lot of that.

Combined, you can give a good suggestion without ever hitting any server.

And FWIW, the media does make a difference whether things (e.g. speech recognition or maps) are with servers or local, whereby local is considered far better, for speed, privacy and many other reasons.

[privacy policy]

"anonymize them almost immediately" is not the same as "doesn't use". Please see the case in comment 6. Nothing said that Google promises not use this ping to record my IP.
Furthermore, privacy policies can be changed, and they did, dramatically so. Counting on them is naive.
(In reply to Madhava Enros [:madhava] from comment #54)
> Robert - in terms our our being able to advocate for Firefox usage here --
> you'll still be able to turn this off in prefs. Aren't we the only browser
> that will let you do that?

1) As Ben explained, that's already too late, as data has already been sent. 2) It's relatively "hard" to change prefs for normal users as most probably don't even find where they are - and we know default prefs are rarely changed.
This is a breakage of our promise to be privacy-sensitive and takes the privacy argument completely out of PR (including peer communication / word-of-moth effects), as there only the defaults really count.
Depends on: 774517
(In reply to Asa Dotzler [:asa] from comment #21)
> Can we mitigate sending things which are likely to be URLs like Chrome does?

I posted a patch for this in bug 774517.
Thanks, but note that this doesn't solve the problem here at all, not even a little.
Sorry for the revival, but i think ive got a good peace making solution:

Everyone agrees we should change something, and the 2 opinions seem to be, in content opt-in (A) and opt-out(B). The main complaint against opt-in is that most users wont, the main complaint against opt-out is it will mess things up for privacy conscious users before they find out and react (and ensuing media frenzy based on previous comments made by mozilla people).

Worst case for A is feature is disabled (same as no change, presumably progressivly worse over time as users drop firefox, eventually assumed to be very bad)

Worst case for B is media feeding frenzy with firefox as main dish. Unlikely to do deadly harm, but could be significant, almost entire effect will be instantaneous.

Clearly, its best to be sure of anything we can be sure of. Media feeding frenzies are pretty random, so instead, look at the other missing data. If we build the best opt-in we can, what does telemetry tell us the opt-in rate is. if we do this for nightly, it wont even get into a release (though that might produce skewed results). and if the result is <80%, then we know it isn't good enough, if the result is >95% we know it probably is good enough. if it's somewhere in the middle, we can argue some more.

Even if we let it release, the result will be (at worst) a mildly annoying option for 6 weeks whilst we find out what we want to do. At best we'll find out our opt-in is super good, and this entire argument was pointless. Even if we go with A in the end, wont it be better to lead into it for 6 weeks and giving the privacy conscious lot a chance to opt-out, which would reduce the harm done?

Isn't that better than continuing the argument and then risking one or the other result without knowing for sure?
Finn, sounds like a good plan. That was my hope, that the opt-in would be obvious, simple and in-place, as shown in attachment 640024 [details].
UX and Privacy have come up with an opt-in design they can live with:

Flow diagram: http://cl.ly/image/0b3U1W0v1G0R
Movie of transitions: https://dl.dropbox.com/u/2182500/Mozilla/Firefox%20Mobile/Google-Search-Suggest-120824.mov

Let's re-start the implementation based on these designs
This design is great.  I'd like to see the text be a bit more indicative that we're sending data to Google ("ask Google for..." or "Request suggestions from google"), but the opt-in flow and experience as proposed here satisfies most of my concerns.
This patch just uses a simple margin shrink animation to slide the prompt while pulling the list up. Nothing fancy, but it's (relatively) straightforward without too much code. To have this effect, the prompt has to be a separate view outside of the list, which results in the following changes:

1) The prompt does not scroll with the list
2) The prompt is shown regardless of whether the user has typed anything or not (though we can change this by adding a TextWatcher if it's a problem)

A test build is here: http://dl.dropbox.com/u/35559547/fennec-opt-in-animations-simple.apk. To make it easier to test, I disabled saving the prompted pref to JS, so it won't remember your choice after the AwesomeScreen is closed.
Attachment #639607 - Attachment is obsolete: true
Attachment #665183 - Flags: feedback?(ibarlow)
Thanks Brian, this is looking good. Just tried this on a Galaxy Nexus and a Nexus 7. My comments are below. If there are things below we can do on HC/ICS/JB but not on GB, could you let me know?

1. Let's only show the prompt when a user starts typing. 
2. In my mockups, opting in our out causes the opt in message to slide horizontally off the screen, before collapsing the row. Is this something we can do?
3. When a user opts in to suggestions, can we make the suggest tiles appear one after the other, rather than all at once? It's a subtle detail, but helps communicate where search suggestions now live.
4. Can transitioning the Google search row from 1 tile high to 2 tiles high be done smoothly? (this actually is a more general question, not specifically tied to the opt in UX)
Comment on attachment 665183 [details] [diff] [review]
Part 4: Add search suggestions opt-in prompt, v2

Review of attachment 665183 [details] [diff] [review]:
-----------------------------------------------------------------

::: mobile/android/base/awesomebar/AllPagesTab.java
@@ +546,5 @@
> +        GeckoAppShell.sendEventToGecko(GeckoEvent.createBroadcastEvent("Preferences:Set", jsonPref.toString()));
> +
> +        final LinearLayout allPagesView = getAllPagesView();
> +        PropertyAnimator pa = new PropertyAnimator(ANIMATION_DURATION);
> +        pa.attach(allPagesView, Property.SHRINK_TOP, -1 * prompt.getHeight());

SHRINK animations are being removed as part of bug 767980 btw. You should not be animating on margins as they cause relayouts on each frame. The animation wil definitely not look smooth—especially on less powerful devices. Implement your animations either in terms of scroll or, ideally, translation.
Attachment #665183 - Flags: feedback-
(In reply to Ian Barlow (:ibarlow) from comment #64)
> Thanks Brian, this is looking good. Just tried this on a Galaxy Nexus and a
> Nexus 7. My comments are below. If there are things below we can do on
> HC/ICS/JB but not on GB, could you let me know?

Having played with LayoutTransitions, I don't think they can be effectively used on ListViews (which is what we're using in the AwesomeScreen). ListViews don't implement ViewGroup's addView()/removeView() which are used to handle the animations of child views. So unless we change the results in the AwesomeScreen to not use a ListView, I don't think that newer APIs will help much.

> 2. In my mockups, opting in our out causes the opt in message to slide
> horizontally off the screen, before collapsing the row. Is this something we
> can do?

Sliding left/right is easy enough, but I'm not sure how we can nicely collapse the row without using the shrink animation (which Lucas says we're removing). We could slide the whole ListView up, but that won't resize the ListView during the animation, so it would create a gap below the view during the animation. I'll post a build with this change to see what it feels like.

> 3. When a user opts in to suggestions, can we make the suggest tiles appear
> one after the other, rather than all at once? It's a subtle detail, but
> helps communicate where search suggestions now live.

Yes, I'll try adding this.

> 4. Can transitioning the Google search row from 1 tile high to 2 tiles high
> be done smoothly? (this actually is a more general question, not
> specifically tied to the opt in UX)

Unfortunately, I'm not aware of any way to do this.
Here's an updated build with comments from comment 64 mostly addressed: http://dl.dropbox.com/u/35559547/fennec-opt-in-animations-simple-2.apk

As expected, using translation rather than shrinking the margins causes a gap to appear below the list, which is ugly. Lucas, do you know of any alternatives?
Attachment #665183 - Attachment is obsolete: true
Attachment #665183 - Flags: feedback?(ibarlow)
Attachment #665707 - Flags: feedback?(lucasr.at.mozilla)
Attachment #665707 - Flags: feedback?(ibarlow)
I was able to fix the gap issue by increasing the view's height during the animation, then resetting it after the animation is over. It feels a bit hacky, but it works.

I made this build available at the same URL (http://dl.dropbox.com/u/35559547/fennec-opt-in-animations-simple-2.apk).
Attachment #665707 - Attachment is obsolete: true
Attachment #665707 - Flags: feedback?(lucasr.at.mozilla)
Attachment #665707 - Flags: feedback?(ibarlow)
Attachment #665813 - Flags: feedback?(lucasr.at.mozilla)
Attachment #665813 - Flags: feedback?(ibarlow)
Wow. Huge improvement Brian, I just have a couple of remaining nits. In general we want to make the whole transition feel as continuous and seamless as possible. 

1. Make the Yes / No slide animation about 50% faster
2. Make the row collapse animation that follows 50% faster as well
3. When you opt in to search suggestions, there is a noticeable stop in the flow, between when you've said Yes, to when you actually see search suggestions. Can we make the suggestions appear more quickly? Possibly even by pinging for the search terms as soon as you tap Yes, so that by the time the animations are over they appear seemingly instantaneously.
4. I know I said it before, but the transition from 1 search tile row to 2 is pretty janky.
Comment on attachment 665813 [details] [diff] [review]
Part 4: Add search suggestions opt-in prompt, v4

Review of attachment 665813 [details] [diff] [review]:
-----------------------------------------------------------------

I only looked at the animation bits of this patch btw. Let me know if you were expecting a more general feedback on this patch. Ideally, these animations would be implemented using the new PropertyAnimator from bug 767980. But you shouldn't have to block on this, of course. So please file a follow-up to implement these animations based on PropertyAnimator.

::: mobile/android/base/awesomebar/AllPagesTab.java
@@ +563,5 @@
> +        // pref observer in gecko will also set prompted = true
> +        PrefsHelper.setPref("browser.search.suggest.enabled", enabled);
> +
> +        TranslateAnimation anim1 = new TranslateAnimation(0, mSuggestionsOptInPrompt.getWidth(), 0, 0);
> +        anim1.setDuration(ANIMATION_DURATION);

Don't you want to use a non-linear interpolator to make this animation look nicer? Just wondering. Ask Ian's feedback.

@@ +578,5 @@
> +        set.addAnimation(anim2);
> +        set.setAnimationListener(new Animation.AnimationListener() {
> +            public void onAnimationStart(Animation a) {
> +                // Increase the height of the view so a gap isn't shown during animation
> +                LayoutParams tallerParams = new FrameLayout.LayoutParams(allPagesParams);

You could probably just update height on allPagesParams and requestLayout() on the view. Saves you one new object.

@@ +580,5 @@
> +            public void onAnimationStart(Animation a) {
> +                // Increase the height of the view so a gap isn't shown during animation
> +                LayoutParams tallerParams = new FrameLayout.LayoutParams(allPagesParams);
> +                tallerParams.height = getAllPagesView().getHeight() + mSuggestionsOptInPrompt.getHeight();
> +                getAllPagesView().setLayoutParams(tallerParams);

From my experience, changing layout in onAnimationStart causes weird flickering before the animation starts in Honeycomb. I recommend you to try this code in a tablet with Honeycomb to make sure it looks good. For instance, I had to move the onAnimationStart() to be run directly just before the startAnimation() call in browsertoolbar to make it look good on all Android versions.

@@ +584,5 @@
> +                getAllPagesView().setLayoutParams(tallerParams);
> +            }
> +            public void onAnimationRepeat(Animation a) {}
> +            public void onAnimationEnd(Animation a) {
> +                GeckoAppShell.getMainHandler().post(new Runnable() {

I assume you're posting to handler here (instead of running directly) because you're removing a view in onAnimationEnd(), right?
Attachment #665813 - Flags: feedback?(lucasr.at.mozilla) → feedback+
The animation part of this bug is getting big, so I'll split these to make review easier. This patch is essentially the same as the one way back in comment 12.
Attachment #665813 - Attachment is obsolete: true
Attachment #665813 - Flags: feedback?(ibarlow)
Attachment #666761 - Flags: review?(mark.finkle)
I tried to address all comments from comment 69. After a lot of work, I think I was able to fix the height transition, though our code is getting more complex with all of these animation changes.

For "priming" the suggestions, I added mPrevQuery and mPrevResults fields to the SuggestClient. If the query is the same as mPrevQuery, the previous results are reused.

For the height transition, I added the HeightChangeAnimation and SuggestionRow classes. When the dimensions for the SuggestionRow change after measuring, an animation is done (if we're not already doing one). This requires a relayout at each stage of the animation, and this may not look good on older phones, but I don't know of any alternatives.


> Don't you want to use a non-linear interpolator to make this animation look nicer? Just wondering. Ask Ian's feedback.

Ian, any preference? Looking at the mockup video, the interpolation looks linear to me.

> I assume you're posting to handler here (instead of running directly) because you're removing a view in onAnimationEnd(), right?

Yeah, I added a comment in the code to explain why this was necessary.
Attachment #666764 - Flags: feedback?(ibarlow)
Cleaned up some old code.
Attachment #666764 - Attachment is obsolete: true
Attachment #666764 - Flags: feedback?(ibarlow)
Attachment #666768 - Flags: feedback?(ibarlow)
This looks excellent Brian. 

> > Don't you want to use a non-linear interpolator to make this animation look nicer? Just wondering. Ask Ian's feedback.
> 
> Ian, any preference? Looking at the mockup video, the interpolation looks
> linear to me.

I am assuming you mean something that adds a more natural acceleration to the animations? If so, then yes please. Other than that, I have no additional comments :)
Added non-linear interpolators.
Attachment #666768 - Attachment is obsolete: true
Attachment #666768 - Flags: feedback?(ibarlow)
Attachment #666791 - Flags: review?(lucasr.at.mozilla)
Comment on attachment 666761 [details] [diff] [review]
Part 4: Add search suggestions opt-in prompt

Seems like a good foundation. Do we attempt to land this part, for testing. Then land the animation part when it gets finished?
Attachment #666761 - Flags: review?(mark.finkle) → review+
(In reply to Mark Finkle (:mfinkle) from comment #77)
> Seems like a good foundation. Do we attempt to land this part, for testing.
> Then land the animation part when it gets finished?

Done.

http://hg.mozilla.org/integration/mozilla-inbound/rev/ecaff73e5a63
http://hg.mozilla.org/integration/mozilla-inbound/rev/580f710a84e8
Backed out for rc failures:

http://hg.mozilla.org/integration/mozilla-inbound/rev/d5a3c148545c

I forgot that the prompt will require changes to the search suggestions test.
Comment on attachment 666791 [details] [diff] [review]
Part 5: Search suggestion opt-in animations, v3

Review of attachment 666791 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good. I haven't tried the build myself. I'm assuming ibarlow has given his design approval.

::: mobile/android/base/HeightChangeAnimation.java
@@ +21,5 @@
> +
> +    @Override
> +    protected void applyTransformation(float interpolatedTime, Transformation t) {
> +        mView.getLayoutParams().height = Math.round((mFromHeight * (1 - interpolatedTime)) + (mToHeight * interpolatedTime));
> +        mView.requestLayout();

I'll be adding HEIGHT animation to PropertyAnimator btw (in bug 772940). Please file a follow-up bug to replace this with PropertyAnimator where appropriate.

::: mobile/android/base/SuggestClient.java
@@ +58,5 @@
>      /**
>       * Queries for a given search term and returns an ArrayList of suggestions.
>       */
>      public ArrayList<String> query(String query) {
> +        if (query.equals(mPrevQuery)) {

nit: mfinkle would probably ask you to remove the {}'s here :-)

::: mobile/android/base/SuggestionRow.java
@@ +10,5 @@
> +import android.view.animation.Animation;
> +import android.view.animation.DecelerateInterpolator;
> +import android.widget.RelativeLayout;
> +
> +public class SuggestionRow extends RelativeLayout {

Do you really want to animate every SuggestionRow for any height change? i.e. don't you want to only enable the animation for a specific row as needed? Just wondering if we might end up with all SuggestionRows animating to new their heights at the same time in some cases (which would look weird).

The code here doesn't seem specific to SuggestionRow at all. So, maybe you could use a more generic name for the new widget? AnimatedHeightLayout? You pick :-)

@@ +16,5 @@
> +    private static final int ANIMATION_DURATION = 200;
> +    private boolean mAnimating;
> +
> +    public SuggestionRow(Context context, AttributeSet attrs) {
> +        super(context, attrs);

Init mAnimating with false here just to be explicit about it.

::: mobile/android/base/awesomebar/AllPagesTab.java
@@ +153,5 @@
>  
> +    /**
> +     * Query for suggestions, but don't show them yet.
> +     */
> +    private void primeSuggestions() {

Love this method name somehow :-)

@@ +433,5 @@
>              
>              // add additional suggestions given by this engine
>              int recycledSuggestionCount = suggestionView.getChildCount();
>              int suggestionCount = engine.suggestions.size();
> +            boolean showedSuggestions = false;

nit: add empty line here.

@@ +467,5 @@
>                  suggestionView.getChildAt(i).setVisibility(View.GONE);
>              }
> +
> +            if (showedSuggestions) {
> +                mAnimateSuggestions = false;

nit: no need for the {}'s

@@ +580,5 @@
> +        TranslateAnimation anim1 = new TranslateAnimation(0, mSuggestionsOptInPrompt.getWidth(), 0, 0);
> +        anim1.setDuration(ANIMATION_DURATION);
> +        anim1.setInterpolator(new AccelerateInterpolator());
> +        anim1.setFillAfter(true);
> +        mSuggestionsOptInPrompt.setAnimation(anim1);

Please file a follow-up to convert these animations to use PropertyAnimator. Not a big deal, just something for us track.

@@ +607,5 @@
> +                        mSuggestionsOptInPrompt = null;
> +
> +                        if (enabled) {
> +                            // Reset the view height
> +                            getAllPagesView().getLayoutParams().height = LayoutParams.FILL_PARENT;

Don't you need a requestLayout() call here?
Attachment #666791 - Flags: review?(lucasr.at.mozilla) → review+
(In reply to Lucas Rocha (:lucasr) from comment #80)
> Please file a follow-up to convert these animations to use PropertyAnimator.
> Not a big deal, just something for us track.

> I'll be adding HEIGHT animation to PropertyAnimator btw (in bug 772940).
> Please file a follow-up bug to replace this with PropertyAnimator where
> appropriate.
> 

Filed bug 798067 for replacing animations with the PropertyAnimator.

> Do you really want to animate every SuggestionRow for any height change?
> i.e. don't you want to only enable the animation for a specific row as
> needed? Just wondering if we might end up with all SuggestionRows animating
> to new their heights at the same time in some cases (which would look weird).

For the animation, there's a "oldHeight != 0" check which prevents suggestion rows from animating when they appear. The only time they should animate is if the user types a ton of text and makes the suggestion item wrap to the next line, but I tested this case, and it looks good IMO (at least better than all of them suddenly jumping to a new height).

> @@ +607,5 @@
> > +                        mSuggestionsOptInPrompt = null;
> > +
> > +                        if (enabled) {
> > +                            // Reset the view height
> > +                            getAllPagesView().getLayoutParams().height = LayoutParams.FILL_PARENT;
> 
> Don't you need a requestLayout() call here?

This is already covered with notifyDataSetChanged(): http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android/1.5_r4/android/widget/AdapterView.java#787.
Filed bug 798661 for opt-in prompt test case.
Attachment #668681 - Flags: review?(mark.finkle) → review+
Whiteboard: [leave open]
Depends on: 798859
Search suggestion opt-in prompt is triggered as expected on the latest Nightly.

I talked earlier with Brian regarding 3 possible scenarios:

1. User taps on "No" when the prompt is triggered. Will the prompt be triggered again?
Expected: The prompt will be never triggered again in this case.

2. User taps on "Yes" but he/she decides later to uncheck this option from Settings. Will the opt-in prompt be displayed again?
Expected: The prompt will be never triggered again in this case as well.

3. User enable and disable this option from Settings, before going to Awesomescreen. 
Expected: There will be the same result as for previous 2 cases.

Everything works fine, so I will close this bug as verified fixed on:

Firefox 18.0a1 (2012-10-08)
Device: Galaxy Note
OS: Android 4.0.4
Status: RESOLVED → VERIFIED
status-firefox18: --- → verified
:xti, can you update any changes in tests for the 18 branch?
Flags: in-moztrap?(nicolae.cristian)
(In reply to Aaron Train [:aaronmt] from comment #87)
> :xti, can you update any changes in tests for the 18 branch?

Sure. I checked the testcases regarding the search suggestions and the best solution was to add 2 TCs for this feature:

https://moztrap.mozilla.org/manage/cases/?filter-id=2739

https://moztrap.mozilla.org/manage/cases/?filter-id=2740

TCs were added for Firefox 18+, both for phones and tablets in Firefox Mobile: Search suggestions suite.
Flags: in-moztrap?(nicolae.cristian) → in-moztrap+
Status: VERIFIED → RESOLVED
Closed: 12 years ago → 12 years ago
status-firefox18: verified → ---
Status: RESOLVED → VERIFIED
status-firefox18: --- → verified
status-firefox19: --- → verified
Depends on: 813057
Depends on: 815937
Depends on: 816902
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: