In bug 688513 comment 15, mfinkle asked for a bug to revise the telemetry opt-in string. https://bugzilla.mozilla.org/show_bug.cgi?id=699513#c15 The opt-in string created by the patch in that bug does not clearly cover all the things Telemetry wants to collect, for example hardware attributes or network capabilities. Here's what landed: > "Help improve %S by sending anonymous usage information to Mozilla." We don't want a laundry list, but the shortest string we've come up with that covers our collection in desktop Firefox is documented in bug 685373. My impression is that a wider variety of probes is collected on mobile, and we should provide an opt-in string that gives people an accurate picture of what is being collected without them needing to dig into the privacy policy to be informed. Picking up here from comment 11 in the previous fennec telemetry opt-in bug: https://bugzilla.mozilla.org/show_bug.cgi?id=699513#c11 String length here is constrained due to screen size, which is why the desktop Firefox string is not being used here. Mark, what are the size limits?

Unless the information is actually anonymous, we shouldn't call it anonymous. Isn't it arcane and pseudonymous?

I'm still hoping to hear a little bit about constraints on the string here. The string that landed is a bit misleading and not very well informing, so I'd like to know what kind of space we have to work with to craft a better message.

mfinkle - Can you comment on the string length restrictions? Can we include a link in the string so that we can discuss the possibility of linking to more information (not necessarily directly to the privacy doc). Something like: "Help improve %S by sending usage information to Mozilla. Learn more." where Learn more is a link to a mobile specific page (with more space than we have in a door hangar) that contains a short form of the details.

If it's going to get longer than about a sentence, I think we probably do want to have something short and accurate but not threatening, and and "Learn More" link. The page we take you to should let you opt in there, as well.

I'd rather have a shorter string which uses general terms to describe a superset of what's being collected, with a "Learn more" link. However, if we can use adjectives to allude to the category of data being collected, that would be ideal. I don't know how frequently people click "learn more", and I'd love to see UX comment on that, or if there are better strings than "Learn more" that see more interaction.

(In reply to Lawrence Mandel [:lmandel] from comment #3) > mfinkle - Can you comment on the string length restrictions? Can we include > a link in the string so that we can discuss the possibility of linking to > more information (not necessarily directly to the privacy doc). Something > like: > > "Help improve %S by sending usage information to Mozilla. Learn more." > where Learn more is a link to a mobile specific page (with more space than > we have in a door hangar) that contains a short form of the details. We do not have support for links in the native UI doorhangers. We do have support for buttons. I think one sentence is the maximum we want for string length.

(In reply to Mark Finkle (:mfinkle) from comment #6) > We do not have support for links in the native UI doorhangers. We do have > support for buttons. Can we have three buttons: Yes, No, Learn More? (If it makes sense I can file a bug to add support for links in mobile door hangars. I think there should be no expectation that this will get into the first native UI release.)

"Learn more" links in doorhangers are a method that we're going to want to use a significant amount in the future. I'm not happy with a button because I don't think that they have the right user-experience for this feature. I think that we should add support for links in doorhangers, and use a button until that's ready.

(In reply to Lawrence Mandel [:lmandel] from comment #7) > (In reply to Mark Finkle (:mfinkle) from comment #6) > > We do not have support for links in the native UI doorhangers. We do have > > support for buttons. > > Can we have three buttons: Yes, No, Learn More? (If it makes sense I can > file a bug to add support for links in mobile door hangars. I think there > should be no expectation that this will get into the first native UI > release.) Three buttons means it will be very tight in portrait mode. Instead of "Learn More", you might consider alternatives. Maybe "Help" or "Info" - something that won't expand too much for l10n.

Then let's aim for a "Learn more" link once that feature is ready, and go with Yes/No/Info until then.

Also, string proposal: "Send info to Mozilla to that we can fix and improve %s."

(In reply to Tom Lowenthal [:StrangeCharm] from comment #11) > Also, string proposal: > > "Send info to Mozilla to that we can fix and improve %s." Fixing is improving right. :) How about just "Send info to Mozilla so that we can improve %s." This would go along with yes, no, info buttons, where the info button will be replaced with a Learn more link once links are supported in mobile door hangars.

Do we have a page to link to from the "Learn more" link?

We do. https://support.mozilla.org/kb/how-can-i-help-submitting-performance-data

In desktop, we append "how-can-i-help-submitting-performance-data" to "app.support.baseURL" (http://mxr.mozilla.org/mozilla-central/source/browser/components/nsBrowserGlue.js#834). We have a different baseURL on mobile, so doing the same thing yielded an invalid URL. I created the "browser.telemetry.infoURL" preference which contains the telemetry "Learn more" URL. We'll need to change this page (or point to a different one) since it uses desktop Firefox in the opt-in/out screenshots.

I've updated the patch to use the server owner rather than hard-coding "Mozilla". I'm not sure what to call this pref. We already have a "toolkit.telemetry.infoURL", but thats points to http://www.mozilla.com/legal/privacy/firefox.html#telemetry.

Sid, Tom - The current patch uses the string that I proposed in comment 12. This is not as descriptive as the string we use on desktop but is much shorter for the mobile space restrictions. Concerns? "Send info to %S so that we can improve %S?"

(In reply to Brian Nicholson (:bnicholson) from comment #15) > Created attachment 603523 [details] [diff] [review] > patch > > In desktop, we append "how-can-i-help-submitting-performance-data" to > "app.support.baseURL" > (http://mxr.mozilla.org/mozilla-central/source/browser/components/ > nsBrowserGlue.js#834). We have a different baseURL on mobile, so doing the > same thing yielded an invalid URL. I created the "browser.telemetry.infoURL" > preference which contains the telemetry "Learn more" URL. > > We'll need to change this page (or point to a different one) since it uses > desktop Firefox in the opt-in/out screenshots. I have created a Telemetry article that is specific to mobile. Once approved the URL will be https://support.mozilla.org/kb/how-can-i-help-submitting-mobile-performance-data

Bug 725546 has promise for "fixing" the app.support.baseURL issue, but I can't get it to work yet. Let's try to use that approach though, instead of making "browser.telemetry.infoURL" just to be consistent with desktop.

Comment on attachment 603557 [details] [diff] [review] patch v2 This is fine except for the support URL. We really should wait to land this until we get that sorted.

The SUMO article for mobile has been published at https://support.mozilla.org/kb/how-can-i-help-submitting-mobile-performance-data

(In reply to Lawrence Mandel [:lmandel] from comment #21) > The SUMO article for mobile has been published at > https://support.mozilla.org/kb/how-can-i-help-submitting-mobile-performance- > data Can we get this URL turned into a Firefox UI friendly link? As mentioned in bug 725546. That will allow us to switch to the better app.support.baseURL

Updated the URL to point to baseURL + "how-can-i-help-submitting-mobile-performance-data", which currently 404s. The assumption is that this URL will eventually redirect to the correct URL (https://support.mozilla.org/kb/how-can-i-help-submitting-mobile-performance-data).

(In reply to Mark Finkle (:mfinkle) from comment #22) > (In reply to Lawrence Mandel [:lmandel] from comment #21) > > The SUMO article for mobile has been published at > > https://support.mozilla.org/kb/how-can-i-help-submitting-mobile-performance- > > data > > Can we get this URL turned into a Firefox UI friendly link? As mentioned in > bug 725546. That will allow us to switch to the better app.support.baseURL cc Michelle Luna from SUMO mobile for help with the Firefox UI friendly link.

Comment on attachment 604817 [details] [diff] [review] patch v3 Let's land this and updated later if needed

The topics names can (should?) be the same across different platforms and we can target different articles based on product among other things (locale, platform, version, etc). I just added a redirect for the "how-can-i-help-submitting-performance-data" topic that goes to the mobile version of the article when the product is mobile. For example: https://support.mozilla.org/1/mobile/13.0a1/Darwin/en-US/how-can-i-help-submitting-performance-data Goes to: https://support.mozilla.org/en-US/kb/how-can-i-help-submitting-mobile-performance-data?as=u

Brian - make sure to update your patch before checkin to point to the URL in comment 26

http://hg.mozilla.org/integration/mozilla-inbound/rev/29be02f524cf I updated the baseURL to point to http://support.mozilla.org/1/mobile/%VERSION%/%OS%/%LOCALE%/. This is now parallel to the desktop baseURL (http://support.mozilla.org/1/firefox/%VERSION%/%OS%/%LOCALE%/), and it works for the URL given in comment 26 and the Support link we currently have on the about: page.

Why/how exactly did you approve a patch that changes significantly a string (telemetry.optin.message) adding a new variable without changing the entity name? And to create even more confusion this change landed just before the move to aurora, so now the problem is on two different repositories.

Comment on attachment 604817 [details] [diff] [review] patch v3 Review of attachment 604817 [details] [diff] [review]: ----------------------------------------------------------------- ::: mobile/android/locales/en-US/chrome/browser.properties @@ +56,5 @@ > blockPopups.label=Block Popups > > # Telemetry > +telemetry.optin.message=Send info to %S so that we can improve %S? > +telemetry.optin.learnMore=Learn more Yeah, this should have changed the key, and also, added a comment what those place holders actually stand for. Also, it' good to just use %1$S and %2$S right away, if you're using more than one parameter. Helps also to document what's what.

[Approval Request Comment] Fixes l10n issues described in comment 30 and comment 31.

Comment on attachment 605850 [details] [diff] [review] follow-up patch Review of attachment 605850 [details] [diff] [review]: ----------------------------------------------------------------- r=me, too, thanks.