1054121 - Improve description on FTU sharing data window

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia::First Time Experience, defect)

Description

[Ravi Dandu]

First Time User (FTU) window for user approval of sharing data with Mozilla has two steps to agreement: specifically select a button during the FTU and then click Next. eg: https://bug982663.bugzilla.mozilla.org/attachment.cgi?id=8448077  

Proposal is to simplify this by making agreement a one step: User is shown two buttons. One for "Share info with Mozilla" and other for "Don't share" (i.e. there is no "Next" button). This make it one click instead of two clicks to send us the info.

Reasons that this request
 1) Increased collection: opt-in are expected to be <<10% with current design. Users will keep pressing next and not take the step of checking the above button. Making it an explicit user choice way has the possibility of increasing the number of users who agree for sharing.

 2) Simpler UX: Arguably it is simpler as user has one button (rather than two steps) to make choice of send us info.

Comment 1

[Marshall Culpepper [:marshall_law]]

Val, do you know who the right person in UX would be to mock up / sign off on this change for 2.1 would be?

I think the key UX decision that needs to be made is how / where the current "Learn More" link would be shown in this updated dialog..

Comment 2

[Stephany Wilkes]

This is for Jacqueline, per Ravi's email.

Comment 3

[Mika]

Hi Jacqueline - thanks for sharing the UX screens with me.  Here's the requested change.  The screen in question is #13 in the Proposed FxOS 2.0 Setup Flow (screenshot here: http://screencast.com/t/5cVeD44o)

My proposal for the changes is here: https://docs.google.com/a/mozilla.com/presentation/d/1Us0fQTXMgGo_iT9dBHm5Big10M-SfSOefGB2rZQWaho/edit?usp=sharing

Please note - I don't have legal, engineering and metrics sign-off on this yet, so the change cannot yet be implemented.  I'm sending this to you guys to review (you may also have feedback, please comment on the doc).  Once everyone is on board, the change can be made.

Thanks,
Mika

Comment 4

[Mika]

John, Taras, and Benjamin - please check the proposed changes to the data collection phrases in the FxOS device screenshots (linked in comment 3.  screenshots to device activation and settings screens).  If they make sense, then we can proceed with implementation.  I used the word "Analytics" instead of "Telemetry".  

In this scenario, for users who select "Yes! Send data" we'll receive the app usage metrics that Ravi proposed.  Once the "FHR for FxOS" (whatever that will be called) is implemented, this same data can be collected by default (same as FHR data collection on Fx).

Thanks,
Mika

Comment 5

[Benjamin Smedberg]

I am not FxOS engineering or UX and so I'm not willing to be responsible for this decision.

Comment 6

[Mika]

Marshall - I forgot to add you for review.  Can you please check the link in comments 3 and 4.
Thanks,
Mika

Comment 7

[Jacqueline Savory [:jsavory] UX]

Attachment: AboutFirefoxOS_Screen.png

Hi Mika

I have a few concerns about the design proposal, currently every screen in FTE contains both the next and the back button and I am very hesistant to break the UX pattern for only one of the screens. Currently, we are exploring options for upgrading the navigation to reduce the number of clicks, however this won't be done for 2.1.

Also, generally we do not use two check boxes to show enable and disable, if the check box is not selected that works as the disable option. 

I've tried to adjust the screen according to your other suggestions and have attached a screenshot. Let me know if this redesign will work for now or if there are any other changes I can make. Thanks!

Comment 8

[John Jensen]

Hi Mika,

Like Benjamin, I'm not the product owner, and don't feel it's appropriate for me to be in the decision chain for this. I do have some comments for the Google Doc and will add them now.

Comment 9

[(dormant account)]

I don't approve privacy policy strings. Generally we are explicit about what types analytics data we send.

Comment 10

[Marshall Culpepper [:marshall_law]]

I added some comments in the document, otherwise my main concern is that we will need to add another bullet point to the Privacy Notice to cover app usage metrics (right now the new bullet point only covers the Activation ping?)

Comment 11

[chris hofmann]

adding some people that do try to influence and direct privacy related things.

Its hard for me to comment as a firefoxOS product person, but I can comment as a long time mozillian.

I can't follow all that goes on here and don't know if I understand that we've meet two long time standards.

First is "No Suprises".  Would a reasonable user that encounters this dialog and check the box be surprised by the types or amount of data that it results in being sent to mozilla.

Second is "Real Choices."  Is there a way for a privacy sensitive person to follow links to understand the exact set of data that is sent to mozilla, and conditions on which it is sent.  This is along the lines of Taras' comment 9.

There is probably a few more principals on which this can be judged that Alex and Sid can weigh in on.

My general sense is that we aren't meeting those standards here, but open to more discussion.  Mozilla as an organization is better off collecting less data, and preserving the perception and practice that we value user privacy in my mind.  But that is also up for discussion.

As a representative of the localization community this should also get legal and technical review not only for the US but in as many markets as possible to make sure we are in compliance with laws and best practices in privacy sensitive markets such as Germany, Brasil, etc.....    We will need the wording and the action match requirements there, and the legal team and localizers will be happy to participate in that discussion once you have something that seems to work for the US in english.

Comment 12

[Mika]

(In reply to jsavory from comment #7)
> Created attachment 8477597 [details]
> AboutFirefoxOS_Screen.png
> 
> Hi Mika
> 
> I have a few concerns about the design proposal, currently every screen in
> FTE contains both the next and the back button and I am very hesistant to
> break the UX pattern for only one of the screens. Currently, we are
> exploring options for upgrading the navigation to reduce the number of
> clicks, however this won't be done for 2.1.
> 
> Also, generally we do not use two check boxes to show enable and disable, if
> the check box is not selected that works as the disable option. 
> 
> I've tried to adjust the screen according to your other suggestions and have
> attached a screenshot. Let me know if this redesign will work for now or if
> there are any other changes I can make. Thanks!

Hi Jacqueline, 

Thanks for your feedback on the call this morning.  Here is the final wording for the second paragraph in your mockup from comment 7:

"You can help us improve our products and services by automatically sending analytics data.  See our Privacy Notice [hyperlink] to learn how we handle data from your device."

Let me know if you have any questions.
Thanks,
Mika

Comment 13

[Jacqueline Savory [:jsavory] UX]

Attachment: AboutFirefoxOS_Screen_v2.png

Thanks Mika, I've updated the screenshot with the reworked paragraph text. Let me know if this looks right to everyone.

Comment 14

[Marshall Culpepper [:marshall_law]]

Looks good to me, I'll try to patch a post later tonight.

Comment 15

[Mika]

The text in the revised screenshot is good.  Thanks!

Comment 16

[Ravi Dandu]

Thanks team for converging on this. Lets implement Jacqueline's comment #13 (https://bugzilla.mozilla.org/show_bug.cgi?id=1054121#13).

One of the request in this bug was to make "agree to collect" a one click operation(Comment #1,  https://bugzilla.mozilla.org/show_bug.cgi?id=1054121#1). This request will not implemented for this bug. A new bug will be filed for it, and explored in context for an overall enhancement of the FTU experience to increase user opt-in for Analytics, FxOS Accounts, Geolocation User etc..

Comment 17

[Marshall Culpepper [:marshall_law]]

[Blocking Requested - why for this release]: To provide clearer language that describes the new app usage metrics we are collecting if the user opts-in

Comment 18

[Marshall Culpepper [:marshall_law]]

Attachment: string update - v1

[Testing completed]: Locally tested on Flame
[Risk to taking this patch] (and alternatives if risky): Minor amount of code added to inject links into paragraphs
[String changes made]: Moved link to existing 1st paragraph, added a second paragraph

Comment 19

[Marshall Culpepper [:marshall_law]]

Attachment: 2014-09-08-03-35-37.png

screenshot

Comment 20

[Jacqueline Savory [:jsavory] UX]

Comment on attachment 8486770 [details]
2014-09-08-03-35-37.png

The screen looks great to me, thanks Marshall.

Comment 21

[chris hofmann]

Thanks for making it clear about where a user can go to find out how we think about and handle data at Mozilla, and I like the flow of the single radio button to opt-in, or just move to next set if FTU decisions.

One part that still is not clear to me from reading the screen is about exactly what data is collected, or where I would go to get a detailed list of the data so I can understand if I'd want to participate.

Comment 22

[Francisco Jordano [:arcturus] [:francisco]]

Comment on attachment 8486644 [details] [review]
string update - v1

Great job, looking pretty good.

Just left a couple of suggestions, as Sam mentioned we need to add a new version to the string id modified.

Also we can start using the new mozL10n way of translating (setting the data-l10n-id node attribute).

As well I think we need to mark this bug as late-l10n

Thanks!

Comment 23

[Marshall Culpepper [:marshall_law]]

(In reply to Francisco Jordano [:arcturus] [:francisco] from comment #22)
> Great job, looking pretty good.

Thanks!
> Also we can start using the new mozL10n way of translating (setting the
> data-l10n-id node attribute).

All of the tags should already have data-l10n-id attributes, but FYI these strings have embedded links so they need to use mozL10n.get / mozL10n.localize and getLocalizedLink to fill in the localized link elements. I couldn't find another way to do this?

Comment 24

[Marshall Culpepper [:marshall_law]]

Attachment: string update - v2

update to bump the string ID. will also need late-l10n approval to land

Comment 25

[Axel Hecht [:Pike]]

We'll need to get the welcomeBrowser to be changed more, too, as welcomeBrowser.innerHTML falls back to welcomeBrowser as text content, and that's likely going to blow up at runtime.

Comment 26

[Marshall Culpepper [:marshall_law]]

(In reply to Axel Hecht [:Pike] from comment #25)
> We'll need to get the welcomeBrowser to be changed more, too, as
> welcomeBrowser.innerHTML falls back to welcomeBrowser as text content, and
> that's likely going to blow up at runtime.

Hrm, I can't find any examples of the plain text fallback in any of the other 'innerHTML' strings, can you elaborate?

Comment 27

[Axel Hecht [:Pike]]

Localizations have a string for welcomeBrowser right now, but not for welcomeBrowser.innerHTML.

What the l10n lib does once you change the strings is that it tries to find .innerHTML to use for .innerHTML, and if it doesn't find that, it'll use the string for welcomeBrowser as .textContent

Comment 28

[John Jensen]

Hi all -- simple confirmation question. If the user does not select "yes", does this mean that the current FTU ping would not be sent?

Comment 29

[chris hofmann]

hey john, get in line.  ;-)  

if my question in comment 21 gets answered, yours would be too.

can someone respond to both?

Comment 30

[Sam Foster [:sfoster] (he/him)]

Jacqueline, can you clear this up with an updated/up-to-date spec for this do you think? See comment #28 and comment #21

Comment 31

[Ravi Dandu]

#28: Activation ping is not related to this opt-in. The activation ping will be sent, if the user does not select "yes". Activation ping has been approved by Privacy policy team at Bug 992487 and Legal at Bug 980920.

#21: A link to the "privacy page" is present on the opt-in FTU window. the server page should contain the information on the data saved. https://www.mozilla.org/en-US/privacy/firefox-os/. 
Currently "App usage" is the data saved. The privacy page update should happen before the the commercial launch of this release. 
Mika, Can we update this bug, with the proposed wording of the webpage.

Comment 32

[Marshall Culpepper [:marshall_law]]

(In reply to Axel Hecht [:Pike] from comment #27)
> Localizations have a string for welcomeBrowser right now, but not for
> welcomeBrowser.innerHTML.
> 
> What the l10n lib does once you change the strings is that it tries to find
> .innerHTML to use for .innerHTML, and if it doesn't find that, it'll use the
> string for welcomeBrowser as .textContent

Makes sense. I've pushed an amended branch that is now visible on my pull request, which includes welcomeBrowser and helpImprove default 'plain text' strings..

Comment 33

[Axel Hecht [:Pike]]

Comment on attachment 8487239 [details] [review]
string update - v2

Sorry, but you figured this out the wrong way around.

You need to change the base ID of welcomeBrowser for this to be picked up. Now you're just adding strings that people shouldn't localize.

Something like htmlWelcome would be good.

Comment 34

[Marshall Culpepper [:marshall_law]]

Attachment: string update - v3

Updated again, let me know if this is what you meant :)

Comment 35

[Francesco Lodolo [:flod]]

Attachment: Flame with pseudolocale

I tested the last version of the patch, but I'm seeing a couple of funny things:
* opening the "Firefox OS" link take you to the first page on FTU. Is '#about-your-rights' right as a link?
* page doesn't scroll, so longer text is cut (you can try with pseudolocale Accented English, see screenshot)

Comment 36

[Francesco Lodolo [:flod]]

Comment on attachment 8487953 [details] [review]
string update - v3

I'm stealing Pike's flag but switching to f+ (not sure if Francisco needs to check the code again, better to have a module owner/peer r+ on file).

Strings look good and we're not using welcomeBrowser.innerHTML anymore. Also tested, now link and scroll work.

Comment 37

[Marshall Culpepper [:marshall_law]]

Comment on attachment 8487953 [details] [review]
string update - v3

Francisco, flagging you again for review now that this is approved by l10n :)

Comment 38

[Marshall Culpepper [:marshall_law]]

Comment on attachment 8487953 [details] [review]
string update - v3

These string changes in FTU have been requested by product management and legal to cover the new app usage metrics feature in 2.1.

[Bug caused by] (feature/regressing bug #): Bug 982663
[User impact] if declined:
[Testing completed]: Tested on a flame with en-US and accented english, and by flod.
[Risk to taking this patch] (and alternatives if risky): minimal (this is almost entirely string changes)
[String changes made]: inserted a link / renamed 'welcomeBrowser' to 'htmlWelcome', and added a 2nd paragraph

Comment 39

[Sam Foster [:sfoster] (he/him)]

Comment on attachment 8487953 [details] [review]
string update - v3

Marshall, looks like the Try run turned up a couple of unit test failures (the Gij/marionette failure looks unrelated). Can you get those passing? I'll leave francisco flagged as he started review on this already, but feel free to pass it along to me.

Comment 40

[bhavana bajaj [:bajaj]]

waiting for r+/master landing before approving on 2.1

Comment 41

[Marshall Culpepper [:marshall_law]]

Comment on attachment 8487953 [details] [review]
string update - v3

Thanks for pointing out the unit test failures. I've addressed them locally and rebased/pushed the changes, awaiting a new Try run :)

Comment 42

[Marshall Culpepper [:marshall_law]]

Try run looks good!

Comment 43

[Sam Foster [:sfoster] (he/him)]

(In reply to rdandu from comment #31)

> #21: A link to the "privacy page" is present on the opt-in FTU window. the
> server page should contain the information on the data saved.
> https://www.mozilla.org/en-US/privacy/firefox-os/. 
> Currently "App usage" is the data saved. The privacy page update should
> happen before the the commercial launch of this release. 
> Mika, Can we update this bug, with the proposed wording of the webpage.

yes, the text says we send analytics data, but nowhere on this page or on the linked privacy policy do we describe what this means (comments #21). The question "what data is sent" is never answered. I'm going to r+ this patch as it stands, because the window for string changes is closing and this represents an improvement over what we have. but lets make sure there is follow-up to get this question answered. Jacqueline, can you drive this?

Comment 44

[Marshall Culpepper [:marshall_law]]

I've opened Bug 1066748 to track the updates to the privacy notice page for FirefoxOS

Comment 45

[Sam Foster [:sfoster] (he/him)]

Comment on attachment 8487953 [details] [review]
string update - v3

Looks good to me. Tested on master and 2.1

Comment 46

[Marshall Culpepper [:marshall_law]]

master: https://github.com/mozilla-b2g/gaia/commit/c357d17d90debd8d171f5b16e3af0c6ff0370987

Preparing a v2.1 PR for approval now

Comment 47

[Marshall Culpepper [:marshall_law]]

Attachment: v2.1 string update

Hey Bhavana.. this has landed in master, just need approval for the v2.1 pull request :)

Comment 48

[Marshall Culpepper [:marshall_law]]

v2.1: https://github.com/mozilla-b2g/gaia/commit/944e5b4582c4efa1b67cd33245dbb8f6aa25d09f

Comment 49

[Sam Foster [:sfoster] (he/him)]

Clearing out needinfos. Bug 1066748 is tracking the follow-up questions about the nature of the data being shared

Comment 50

[chris hofmann]

can someone add me to Bug 980920 ?

Comment 51

[Ravi Dandu]

Chris Hofmann, added you on 980920.

Comment 52

[SandKing]

This issue has been verified successfully on Flame2.1&2.2
Verify video:"verify_1054121.mp4".

Flame2.1 build:
Gaia-Rev        38e17b0219cbc50a4ad6f51101898f89e513a552
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/8b92c4b8f59a
Build-ID        20141205001201
Version         34.0
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20141205.035305
FW-Date         Fri Dec  5 03:53:16 EST 2014
Bootloader      L1TC00011880

Flame2.2 bulid:
Gaia-Rev        0e429d970c160e580e19e61ad8ff5612de159f00
Gecko-Rev       https://hg.mozilla.org/mozilla-central/rev/035a951fc24a
Build-ID        20141207040205
Version         37.0a1
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20141207.085047
FW-Date         Sun Dec  7 08:51:07 EST 2014
Bootloader      L1TC00011880

Comment 53

[SandKing]

Attachment: Verified video: verify_1054121.mp4