Full feature page: https://wiki.mozilla.org/Features/Fennec/Google_Play_Review_Solicitation Meta Goal: The 2012 Firefox Mobile goal is a 4.5 Start Play Google review average Feature Desc: This feature solicits review feedback from active Firefox Mobile users in order to boost the number of 5-star ratings.Both positive and negative feedback will be collected. Metrics of Success: Increase of 25% of 4 and 5 star ratings Majority of 3, 2, & 1 star ratings redirected as Input messages Specific Requirements: P1 - A user will receive a solicitation message after a set number of uses P1 - Positive feedback directs user to the Google Play ratings for Firefox Mobile P1- Negative feedback is captured by Mozilla P1 - User can opt out of giving feedback P1 - User's privacy must be protected

Etherpad capturing notes on implementation, here: https://etherpad.mozilla.org/ReviewSolicit

This patch gets the basics in place for an about:feedback page. I even made a button that takes you to our app in the play store! Issues to address: -Factor out the app id so that this will work on beta as well -Figure out what the content of this page should actually look like ;) -Figure out when/how we'll open this page for users (launch from app icon after 10 uses, or something like that? add image/link to about:home? create menuitem?)

Comment on attachment 647385 [details] [diff] [review] WIP >diff --git a/mobile/android/base/GeckoApp.java b/mobile/android/base/GeckoApp.java >+ } else if (event.equals("Feedback:OpenPlayStore")) { >+ Intent intent = new Intent(Intent.ACTION_VIEW); >+ intent.setData(Uri.parse("market://details?id=org.mozilla.firefox")); >+ startActivity(intent); I think we have support for "market:" URLs in the platform. We will try to open the URL in a helper app. Can we try to just use code lie this from the aboutFeedback JS itself? http://mxr.mozilla.org/mozilla-central/source/mobile/android/chrome/content/HelperApps.js#52 Overall looks good. Can you throw up a screen shot to give UX something to start with?

(In reply to Mark Finkle (:mfinkle) from comment #3) > >diff --git a/mobile/android/base/GeckoApp.java b/mobile/android/base/GeckoApp.java > > >+ } else if (event.equals("Feedback:OpenPlayStore")) { > >+ Intent intent = new Intent(Intent.ACTION_VIEW); > >+ intent.setData(Uri.parse("market://details?id=org.mozilla.firefox")); > >+ startActivity(intent); > > I think we have support for "market:" URLs in the platform. We will try to > open the URL in a helper app. Can we try to just use code lie this from the > aboutFeedback JS itself? > http://mxr.mozilla.org/mozilla-central/source/mobile/android/chrome/content/ > HelperApps.js#52 I tried just using a link, but a dialog came up to confirm whether or not the user actually wanted to go ahead and go to another app (it didn't even mention the play store in that dialog), and I didn't want to give the user the opportunity to bail. I think that's fair if we make it obvious where the button is going to go ;)

This patch opens about:feedback in a new tab when opening from the app icon after a certain number of history visits. Because I put this logic in onNewIntent, but not in onCreate, we'll only run into this if fennec was already running in the background when you tapped the shortcut icon. I think this is a nice feature of this patch because that means the feedback page will open really fast, which a good experience to have right before writing a review. I tested this manually (with a lower history count), but I'd like to try to write a test for this.

Comment on attachment 647668 [details] [diff] [review] (Part 2) open about:feedback from onNewIntent Review of attachment 647668 [details] [diff] [review]: ----------------------------------------------------------------- ::: mobile/android/base/GeckoApp.java @@ +1937,5 @@ > + return false; > + > + // Check to see that there are at least 20 history visits already > + final int minVisits = 20; > + Cursor c = BrowserDB.getRecentHistory(getContentResolver(), minVisits); I already spotted a problem here. This query does way more than we need here, but right now it's the only way to do this without modifying LocalBrowserDB. We could a new method to LocalBrowserDB that lets us see if we have at least a certain number of history visits. On the bright side, this will only ever get called multiple times if the user has a very small history DB!

Comment on attachment 647668 [details] [diff] [review] (Part 2) open about:feedback from onNewIntent Use a name const instead of "20", but this looks OK to me as a way to start.

(In reply to Margaret Leibovic [:margaret] from comment #6) > I already spotted a problem here. This query does way more than we need > here, but right now it's the only way to do this without modifying > LocalBrowserDB. We could a new method to LocalBrowserDB that lets us see if > we have at least a certain number of history visits. On the bright side, > this will only ever get called multiple times if the user has a very small > history DB! Agreed. Let's not pre-optimize until we know we need too.

I moved this to BrowserApp, since this doesn't need to be a generic GeckoApp thing. Also, using loadUrlInTab makes the back button close the about:feedback tab, instead of taking you out of the app.

https://bugzilla.mozilla.org/attachment.cgi?id=648534&action=diff#a/mobile/android/base/BrowserApp.java_sec2 Could this move into integers.xml? It's better to have constants there.

(In reply to Sriram Ramasubramanian [:sriram] from comment #10) > https://bugzilla.mozilla.org/attachment.cgi?id=648534&action=diff#a/mobile/ > android/base/BrowserApp.java_sec2 > Could this move into integers.xml? It's better to have constants there. It looks like we currently just use that for when we want to vary the integer for different layouts. I don't really see a problem declaring it as a private field if it's only ever used inside that class.

Comment on attachment 648534 [details] [diff] [review] (Part 2) open about:feedback from onNewIntent We will likely tweak the FEEDBACK_MIN_HISTORY value, but this is good.

This patch starts to implement the mockups that Ian gave me. Ian, an APK is available here, and I'd appreciate feedback: https://dl.dropbox.com/u/3358452/about-feedback.apk The main challenge I'm facing here is that input.mozilla.org doesn't seem to like the format of my POST request (I'm getting HTTP 500 responses). I've been using a different HTML page to test on desktop so I can peek inside the network requests, but I haven't been able to come up with anything. My suspicion is that we need to actually submit a form, not make an XMLHttpRequest with a FormData object, but I haven't tested that out yet.

Margaret this is looking pretty fantastic. I have a couple bits of feedback for the moment, based on looking at my Galaxy Nexus. I'm going to try this on a couple of different phone / tablet sizes when I get into the office tomorrow, I'll post some more thoughts then. - Let's make the whole button areas tappable, not just the blue links - Please change the header font (Help us spread Firefox) to Open Sans Light - Adjust the text alignment on the Give Feedback page: https://dl.dropbox.com/u/2182500/margins.png - Margins on the input pages need should be a little bigger -- they should match that of the Give Feedback / Help us spread Firefox pages.

How is the script/glyph coverage of Open Sans Light? See http://www.mozilla.org/vi/firefox/channel/ for an example how things can look if single glyphs are not supported. Vietnamese is a language that we may actually need in the future, too.

We're getting closer. This actually submits data to input.mozilla.org, and I'm getting close to matching the styling in the mockups. Ian, I updated the APK in my dropbox space if you want to check it out. The only main thing left to do is to handle the case where the user taps "Maybe later", so we'll have to store a pref about showing the page again after some interval. Here are some other concerns I had: -We were planning on putting this page in a new tab, so I think we should have links to close the page, rather than go to about:home, on the "Thank you!" page. -The checkbox next to "Include your last visited site?" seems pretty useless. Is there a way to just indicate that the URL field is optional? I'm only sending a URL if something is in that field anyway. -I added a "This field is required" error message under the description textarea if the user tries to submit an empty form. Ian, do you want to give feedback about how that should be styled?

(In reply to Margaret Leibovic [:margaret] from comment #16) > Created attachment 654023 [details] [diff] [review] > WIP v3 > Here are some other concerns I had: > -We were planning on putting this page in a new tab, so I think we should > have links to close the page, rather than go to about:home, on the "Thank > you!" page. If you open the tab with "about:home" as the parent tab, closing the tab will go back to about::home > -The checkbox next to "Include your last visited site?" seems pretty > useless. Is there a way to just indicate that the URL field is optional? I'm > only sending a URL if something is in that field anyway. Maybe just add placeholder text in the URL textbox? Something like "(optional)" and change the label to "Last visited site:" (and use <input type="url">) > -I added a "This field is required" error message under the description > textarea if the user tries to submit an empty form. Ian, do you want to give > feedback about how that should be styled? Can we use HTML5 form validation?!?!? :)

Comment on attachment 654023 [details] [diff] [review] WIP v3 >diff --git a/mobile/android/chrome/content/aboutFeedback.xhtml b/mobile/android/chrome/content/aboutFeedback.xhtml >+ <textarea class="feedback-description" placeholder="&feedback.placeholder;" rows="10"/> Should we use HTML5 form validation for the "required" feature? >+ <input class="feedback-url" placeholder="&feedback.urlPlaceholder;"/> Use type="url" for better validation and keyboard support >+ function closePage(showAgain) { >+ // XXX actually do something with this in Java >+ sendMessageToJava({ >+ gecko: { >+ type: "Feedback:Shown", >+ showAgain: showAgain >+ } >+ }); I wonder what the best way to trigger this again would be? Also, how do we stop from triggering it when we are done? If we use Java, we need to use SharedPreferences off the main thread. I suppose controlling this in Java makes the most sense. Looks like we still need to add the "Copy Feedback" part of the one feature, right? >diff --git a/mobile/android/locales/en-US/chrome/aboutFeedback.dtd b/mobile/android/locales/en-US/chrome/aboutFeedback.dtd >+<!ENTITY thanks.happyMessage "Wow, that was some very nice feedback! Would you be willing to help us spread &brandShortName; by sharing what you said in the Google Play Store for others to see?"> >+<!ENTITY thanks.sadMessage "We are always working to improve &brandShortName; for our users. You can rest assured that real people are going to look at your feedback and do their very best to resolve it."> >+<!ENTITY thanks.ideaMessage "That's a cool idea! We are always working on ways to improve &brandShortName; for our users, so we appreciate you taking the time to share your thoughts on how to make it better."> I know these are not from you, but they are borderline _too_ whimsical :)

(In reply to Mark Finkle (:mfinkle) from comment #18) > I know these are not from you, but they are borderline _too_ whimsical :) Don't worry we are still finalizing copy :) Which reminds me, L10n folks please do no start translating this text yet, we are still working on it!

(In reply to Margaret Leibovic [:margaret] from comment #16) > -We were planning on putting this page in a new tab, so I think we should > have links to close the page, rather than go to about:home, on the "Thank > you!" page. Hm I actually wonder if we even need a "close page" link at that point. Maybe just having a thank you message is enough? And users can either close the tab if they want or go somewhere else from this page. > -The checkbox next to "Include your last visited site?" seems pretty > useless. Is there a way to just indicate that the URL field is optional? I'm > only sending a URL if something is in that field anyway. I like Marks comment about changing the title to "Last Visited Site" and indicate that it's optional. What if we also pre-filled the field with the URL of your last site? > -I added a "This field is required" error message under the description > textarea if the user tries to submit an empty form. Ian, do you want to give > feedback about how that should be styled? Sure I will mock something up and post it shortly.

(In reply to Ian Barlow (:ibarlow) from comment #20) > (In reply to Margaret Leibovic [:margaret] from comment #16) > > > -We were planning on putting this page in a new tab, so I think we should > > have links to close the page, rather than go to about:home, on the "Thank > > you!" page. > > Hm I actually wonder if we even need a "close page" link at that point. > Maybe just having a thank you message is enough? And users can either close > the tab if they want or go somewhere else from this page. I feel like having a link to close the tab easily is nice, instead of making users open up the tab UI to do it. Also, when that tab is closed, the tab that we would have shown when opening the app will be right there and they can get back to their business (instead of them thinking they need to go back to the awesomebar to navigate to a different page). > > -I added a "This field is required" error message under the description > > textarea if the user tries to submit an empty form. Ian, do you want to give > > feedback about how that should be styled? > > Sure I will mock something up and post it shortly. I got HTML5 form validation to work, so don't trouble yourself with this!

I believe this has everything except the finalized copy/graphic assets. I built this on top of the other patch I wrote in this bug, and I changed the preference behavior to keep track of the number of times the app is launched from the shortcut, rather than using history count as a metric for showing the page. Tapping "Maybe later" just resets that count, so we start over again. Otherwise, we'll stop counting and never show the page again. One potential flaw with this approach is that we only go through the onNewIntent code path if the app is already running, so it's not counting launches from a killed app, but maybe that's ok? If it's not, we may need to keep track of a separate boolean pref about whether or not we've shown the feedback page, since we would be incrementing the launch count in a different place where we're not deciding to show the feedback page (or we could change that as well).

Comment on attachment 654374 [details] [diff] [review] WIP v4 * New launch system looks OK. I think using onNewIntent is fine. We might miss some launches, butI'd rather miss some and fire a bit late than fire too early. * Missing functionality is in there now Looks good.

Hi folks here is our latest UI flow with finalized copy in it. (I'll post all the strings that we need to translate in the next comment) We have tweaked the flow to make it more optimal in terms of getting happy people over to Google Play, and people with potentially negative feedback over to Firefox Input. If I have time before tomorrow I might do a couple of fun illustrations to add in, but other than that this can be considered final UI. :)

1. Landing screen ----------------- Have a minute? Tell us what you think about Firefox for Android so far. I love it I ran into some problems I have an idea If you need help or have a problem with Firefox, please visit Firefox Support. 2. "I love it" input screen --------------------------- That's great to hear! Want to share the love by giving us a 5 star rating on Google Play? It takes less than a minute and feels great. Yes, go to Google Play Maybe Later No thanks 3A. "I ran into some problems" input screen ------------------------------------------- We’re sorry that you had some problems with Firefox. Please tell us what happened so that we can fix it. [Enter your feedback here] Last visited site (optional) For your privacy, please don’t include any personally identifiable information in your feedback. 3B. "I ran into some problems" thank you screen ----------------------------------------------- Thanks for letting us know. We’re always working to make Firefox better. Rest assured that real people will look at your feedback and do their very best to resolve your issue. Or else. 4A. "I have an idea" input screen --------------------------------- We love hearing your ideas! Please share your thoughts below. (Just the ones about Firefox, please.) [Enter your idea here] For your privacy, please don’t include any personally identifiable information in your feedback. 4B. "I have an idea" thank you screen ------------------------------------- Thanks! We appreciate you taking the time to share your thoughts. We’re always working to make Firefox better and contributions like yours can lead to great things. You can't see it, but we're giving you a high five right now.

(In reply to Ian Barlow (:ibarlow) from comment #25) > 3B. "I ran into some problems" thank you screen > ----------------------------------------------- > > Thanks for letting us know. > > We’re always working to make Firefox better. Rest assured that real people > will look at your feedback and do their very best to resolve your issue. How will it work for non-English feedback? Will these "real people" look at non-English comments? If not, then localized builds should not promise it.

(In reply to Alexander L. Slovesnik from comment #26) > (In reply to Ian Barlow (:ibarlow) from comment #25) > > 3B. "I ran into some problems" thank you screen > > ----------------------------------------------- > > > > Thanks for letting us know. > > > > We’re always working to make Firefox better. Rest assured that real people > > will look at your feedback and do their very best to resolve your issue. > > How will it work for non-English feedback? Will these "real people" look at > non-English comments? > If not, then localized builds should not promise it. Feedback on the input.mozilla.org dashboard has a "Translate Message" option, so real people can look at a message translated by a machine ;) I agree we shouldn't make any false promises, but I think that given our translation capabilities, we should at least be able to get the gist of what a non-English user has to say.

Re fielding international feedback, agreed, and also we've been doing sprints reaching out to our l10n community to field the input in other languages before for desktop, with quite some success. On the actual feature, this turns out to be a healthy amount of strings, that need careful translation for tone etc. Not exactly the type of work I'd favor to rush to end-users on the side of localized builds.

This has the updated flow and strings, but it still has a few polish issues. Ian, I updated the APK in my dropbox, but here are the issues I'm facing: -Using font-family:"Open Sans Light"; for the header text doesn't change anything for on my Galaxy Nexus. Do we know what fonts phones ship with? Is there something different we should use, if anything? -For the buttons, I used CSS gradients that imitate the styles of the sync promo button. You may want to double check my colors there (and all the other colors in my CSS, for that matter). -I'm having a tough time putting the stars in the middle of the border like in the mock-ups. I can keep trying to get this to work, but maybe we can put the stars somewhere else, or ditch them? We can also work on making high-quality localization notes for this feature. I agree with Axel that tone is really important here, and we need to make sure localizers understand what we're aiming for.

If localization for Fx16 is too much of a crunch (we are late), we can turn off this feature for everything but en-US. Marketing has large goals for end-of-year and they feel this type of mechanism is key to achieving those goals. Axel and Margaret's concern for the tone of the translations is spot on, and that alone might be reason enough to hold off on other locales for Fx16.

(In reply to Margaret Leibovic [:margaret] from comment #29) > Created attachment 654840 [details] [diff] [review] > WIP v5 > > This has the updated flow and strings, but it still has a few polish issues. > Ian, I updated the APK in my dropbox, but here are the issues I'm facing: > > -Using font-family:"Open Sans Light"; for the header text doesn't change > anything for on my Galaxy Nexus. Do we know what fonts phones ship with? Is > there something different we should use, if anything? We should be shipping "Open Sans Light" with Fennec, but you probably need one of Brian's patches, which moves the CSS to content.css, in order to use it in the about page. This should not block getting this feature landed though. > -For the buttons, I used CSS gradients that imitate the styles of the sync > promo button. You may want to double check my colors there (and all the > other colors in my CSS, for that matter). The "Send Feedback" button looks good to me :) > -I'm having a tough time putting the stars in the middle of the border like > in the mock-ups. I can keep trying to get this to work, but maybe we can put > the stars somewhere else, or ditch them? We'll play around a bit and try to get them working.

I agree, it'd probably be better to wait and get the translated copy feeling right for this UI. Particularly if we can still ship the English one for now and disable this feature for other languages until it's ready. -- Margaret this is looking great. I have some comments attached in a mockup here. Mostly just minor colour nitpicking, and font styling. Updating that background image so the UI flows into the header more smoothly would be great too. You can grab an updated graphic here: https://dl.dropbox.com/u/2182500/abouthome_bg.png I'd also like to keep pushing on the star design, since Mark sounds like he might have a plan for how to implement it. :)

Okay, I think this is finally ready for review. I decided to just fold my big patch into the previous patch I wrote about opening about:feedback from onNewIntent because most of the changes from that patch were getting changed again in the next patch. Things that went into this latest version: -Addressed Ian's style nits. -Auto-filling "Last visited site". I changed the placeholder to "http://", so the user will see that if their browser history is empty, or if they delete the auto-filled URL. -Added stars on the "rate us" page. -Added a max-width to the section style rules, so that this will look okay on tablets.

Comment on attachment 655172 [details] [diff] [review] patch I think this is ready to get into Nightly. Things we still might do: * Limit the appearance of the feedback prompt to en-US only, since this very late for l10n. * Limit the appearance of the feedback prompt to Beta and Final releases. For now, let's keep it on for Nightly and Aurora so we can test the feature.

https://hg.mozilla.org/integration/mozilla-inbound/rev/20b009e26b4c If we want to give this a chance to bake on Nightly for a bit before Aurora users see it, we should consider turning off the prompt in Aurora after the merge tomorrow, and we can re-enable it after giving bugs a chance to surface on Nightly. Also, we should start thinking about how we'd go about turning off the prompt for certain locales if we want that as a option. I feel like we may need to switch some of our logic around to get that to work.

Hey Margaret, can you provide QA a short summary here of the trigger mechanisms and pre-conditions required to start the solicitation process?

(In reply to Aaron Train [:aaronmt] from comment #37) > Hey Margaret, can you provide QA a short summary here of the trigger > mechanisms and pre-conditions required to start the solicitation process? We'll open a new "about:feedback" tab after the user launches the app by tapping on the app shortcut icon 10 times. Because of the way we implemented this by putting the check in onNewIntent, we will only count launches when the app is already running (so cold starts won't count). If the user selects "Maybe later", we reset this counter to 0 and start over. Otherwise, we should never show it again. You can also test the feedback page directly by navigating to "about:feedback". If there is only one tab open, the "Maybe later" and "No thanks" links won't work, since those just close the tab, and we never close the last tab. Also, the link to the play store may seem like it doesn't work properly, but that's because there's no "org.mozilla.fennec" in the play store. It should work correctly for beta/release (something good to check when verifying those builds in the future).

Hi, would anyone please post a screenshot with the "Or else." string visible. I have no idea how to translate it to make sense.

(In reply to Rimas Kudelis from comment #39) > Hi, would anyone please post a screenshot with the "Or else." string > visible. I have no idea how to translate it to make sense. Ian's mockups contain all of the strings in context: https://bug774479.bugzilla.mozilla.org/attachment.cgi?id=654747 I also filed bug 786013 about adding more localization notes to make it easier to translate this text. The "Or else." is supposed to be humorous, and I worry that the humor might get lost in translation.

Is "Or else." equivalent to "Or not." here?

(In reply to Rimas Kudelis from comment #41) > Is "Or else." equivalent to "Or not." here? This makes me feel that bug 786013 is very important. "Or not." is exactly the opposite of "Or else." "Or else." is an English idiom meaning "No matter what." See http://en.wiktionary.org/wiki/or_else

Your source says that "or else" "implies an unspecified threat". I'm not sure Firefox should deliver threats to its (already unhappy) users. :)

(In reply to Rimas Kudelis from comment #43) > Your source says that "or else" "implies an unspecified threat". I'm not > sure Firefox should deliver threats to its (already unhappy) users. :) In this case the implicit threat would be against ourselves. "We're going to look at your feedback and try to resolve your issue. Or else [... we'll fire all the people working on Firefox for Android]." Or something like that. It makes sense in English :) Anyway, for translation purposes, I think localizes should just treat the phrase as "No matter what." and do whatever sounds good in their locale :)

Ah, right. Thanks for clarification! :)

I'm not sure that "or, else" really works in english either. When I read it I interpreted as meaning "otherwise or as an alternative" but we gave no meaning to the case that people might not be able to look at the feedback, or we might not be able to fix the problem. I'm not sure if we have a guaranteed response rate or problem resolution rate for the part where we state that "Rest assured that real people will look at your feedback and do their very best to resolve your issue" but unless its close to 5 nines I don't think we should make these kind of claims. who is on the hook for replies the to feedback and fixing of problems? I'd recommend that we just remove 37 <!ENTITY sad.thanksMessageBottom "Or else.">

We can't reply to Feedback in the marketplace without a Google top developer account. Michele Luna has been reviewing feedback and reporting back in the Firefox for Android engineering and Platform coordination meetings.

(In reply to chris hofmann from comment #46) > I'm not sure that "or, else" really works in english either. Maybe not, but realize that we are trying to be a bit playful here and not too cold. Maybe we should use "Scout's honor" or "We promise". In any case, each locale will need to try something suitable, or decide to go cold and clinical. It's up to them. > When I read it I interpreted as meaning "otherwise or as an alternative" but > we gave no meaning to the case that people might not be able to look at the > feedback, or we might not be able to fix the problem. > > I'm not sure if we have a guaranteed response rate or problem resolution > rate for the part where we state that "Rest assured that real people will > look at your feedback and do their very best to resolve your issue" but > unless its close to 5 nines I don't think we should make these kind of > claims. 5 nines? :) I think you are taking this a bit too seriously. No user signed a Service Level Agreement with Mozilla. > who is on the hook for replies the to feedback and fixing of problems? The SUMO team has been handling feedback so far. > I'd recommend that we just remove > > 37 <!ENTITY sad.thanksMessageBottom "Or else."> Noted. We should at least make sure the space is hidden if a locale decides to leave the text empty.

Just to be clear, we (SUMO team) aren't going to be replying to the feedback here either. There's not mechanism at the moment for this and if we do it, it needs to undergo a crapton of privacy review first.

(In reply to Margaret Leibovic [:margaret] from comment #44) > Anyway, for translation purposes, I think localizes should just treat the > phrase as "No matter what." and do whatever sounds good in their locale :) Not sure if it will help other localizers looking into this bug, but I decided to translate it as "It's a promise" (not too formal and still makes sense as a standalone sentence).

(In reply to [:Cww] from comment #49) > Just to be clear, we (SUMO team) aren't going to be replying to the feedback > here either. There's not mechanism at the moment for this and if we do it, > it needs to undergo a crapton of privacy review first. We're not saying — or even implying — that there will be a response, just that someone will "try their best" to resolve the user's issue. Then we make a joke. I think comment 44 and comment 48 explain it very well. I've also created some localization notes over at bug 786013 if anyone's interested.

we've used similar light-hearted approaches on crash reporting and other feedback places. users (especially non-technical users) don't read it that way, especially under stressful situations where they have a problem, and they want to tell us about it, and get it resolved. joking around under these kind of situations only throws gasoline on the fires of their frustration.

(In reply to Matej Novak [:matej] from comment #51) Was just responding to comment 46/48 where it was implied. I'm not following the bug very closely. I think the summary here is that some users like a lighthearted tone, some users are upset by it. If you want data, I can give you examples of both in reaction to the "this is embarrassing" messaging but would that really help us make a decision here? I think we're overrotating on things in this bug -- if these two words really piss people off, I'm sure we'll hear about it (this is feedback after all).

(In reply to chris hofmann from comment #52) > we've used similar light-hearted approaches on crash reporting and other > feedback places. users (especially non-technical users) don't read it that > way, especially under stressful situations where they have a problem, and > they want to tell us about it, and get it resolved. joking around under > these kind of situations only throws gasoline on the fires of their > frustration. Except this doesn't come up after a crash or in some other negative situation. It's a voluntary form. And even if they have negative feedback, this comes up after they've submitted it and it only serves to reinforce that we want to help resolve the issue. Ultimately, who has final say on something like this?

Comment on attachment 655172 [details] [diff] [review] patch [Approval Request Comment] Bug caused by (feature/regressing bug #): new feedback solicitation feature, we want to uplift this to get more feedback/ratings sooner rather than later User impact if declined: users won't be encouraged to give us feedback Testing completed (on m-c, etc.): landed on m-c 8/27 Risk to taking this patch (and alternatives if risky): low risk, self-contained page String or UUID changes made by this patch: lots of strings, but the plan is to disable the feature for locales that aren't ready yet (see bug 786856)

I'd like to see the strings here ignored on the dashboard by patching mobile/android/locales/filter.py

(In reply to Axel Hecht [:Pike] from comment #56) > I'd like to see the strings here ignored on the dashboard by patching > mobile/android/locales/filter.py Filed bug 787150 for this.

Comment on attachment 655172 [details] [diff] [review] patch [Triage Comment] Approving for FF16 beta, in support of getting feedback. Sounds like Axel is already aware of the need to uplift this change.

https://hg.mozilla.org/releases/mozilla-beta/rev/403be1588e9e When we make an official beta build, we should double check to make sure the play store link opens the Firefox Beta app listing. Marking qawanted to make sure this gets onto someone's checklist :)

TCs were added in MozTrap in Firefox Mobile: Google Review Solicitation. More details can be found here: https://moztrap.mozilla.org/manage/cases/?filter-suite=113

(In reply to Margaret Leibovic [:margaret] from comment #59) > https://hg.mozilla.org/releases/mozilla-beta/rev/403be1588e9e > > When we make an official beta build, we should double check to make sure the > play store link opens the Firefox Beta app listing. Marking qawanted to make > sure this gets onto someone's checklist :) I am waiting for the next Beta build I will handle this. Everything works as expected on m-a. -- Firefox 17.0a2 (2012-09-04) Device: Galaxy Note OS: Android 4.0.4

Comment on attachment 655172 [details] [diff] [review] patch >+ } else if (event.equals("Feedback:OpenPlayStore")) { >+ Intent intent = new Intent(Intent.ACTION_VIEW); >+ intent.setData(Uri.parse("market://details?id=" + getPackageName())); >+ startActivity(intent); Should we guard for non-official broken/different Android phones where this doesn't work?

(In reply to Aaron Train [:aaronmt] from comment #62) > Comment on attachment 655172 [details] [diff] [review] > patch > > >+ } else if (event.equals("Feedback:OpenPlayStore")) { > >+ Intent intent = new Intent(Intent.ACTION_VIEW); > >+ intent.setData(Uri.parse("market://details?id=" + getPackageName())); > >+ startActivity(intent); > > Should we guard for non-official broken/different Android phones where this > doesn't work? Do you have examples of these phones and how common this situation would be? If the phone can't handle a market:// URI, that implies it doesn't have the Play store, which means that we have a different problem, right?

It's been a while since I installed CyanogenMod, from what I remember the Android Market at the time was not bundled unless I installed a third party GApps package (http://wiki.cyanogenmod.com/index.php?title=Latest_Version/Google_Apps).

FWIW, I was able to set up a Nexus 7 tablet last week without specifying a Google account. I don't know that it is common to set up a tablet without a Google account but it is certainly possible.

(In reply to Lawrence Mandel [:lmandel] from comment #65) > FWIW, I was able to set up a Nexus 7 tablet last week without specifying a > Google account. I don't know that it is common to set up a tablet without a > Google account but it is certainly possible. I'm talking about the lack of a vending.apk (Google Play) application on the device which is setup to handle those intents :-) Perhaps this can be simulated by disabling Google Play (pm disable com.android.vending) ? I don't have root to try out.

To check for Google Play http://stackoverflow.com/questions/10551531/cannot-determine-whether-google-play-store-is-installed-or-not-on-android-device

(In reply to Margaret Leibovic [:margaret] from comment #59) > https://hg.mozilla.org/releases/mozilla-beta/rev/403be1588e9e > > When we make an official beta build, we should double check to make sure the > play store link opens the Firefox Beta app listing. Marking qawanted to make > sure this gets onto someone's checklist :) Firefox Beta is opened in Google Play as expected. No issues were noticed so far regarding this feature on the latest Beta build. -- Firefox 16.0b2 (2012-09-04) Device: Galaxy Note OS: Android 4.0.4

This feedback does not work for me in Samsung Galaxy Tab 10'1 with Android 3.1 nor in Samsung Galaxy S2 with Android 4.0.3 using the latest Firefox Beta in both devices.