Closed Bug 1238780 Opened 5 years ago Closed 5 years ago

Core firstrun v2

Categories

(Firefox for Android :: First Run, defect)

ARM
Android
defect
Not set
normal

Tracking

()

RESOLVED FIXED
Firefox 46
Tracking Status
firefox46 --- fixed

People

(Reporter: liuche, Assigned: liuche)

References

(Depends on 1 open bug)

Details

Attachments

(8 files, 2 obsolete files)

This bug is to track the v2 of onboarding, where we increase the size of firstrun to highlight more features.
Summary: Firstrun v2 → Core firstrun v2
After talking to Michael Verdi (UX on onboarding from the Desktop side) and doing some competitive analysis research, I've opted for a more "story line"approach vs. a literal, point-and-teach UX.

I think we have so much to say and so much to show, that it's almost impossible to fit it all in (and do it well) a single onboarding experience. Breaking this stuff apart makes sense, but even then, it's a lot to front-load our users with and I worry about how difficult it would be to retain specific information.

A storyline approach gives us the ability to add whimsy and warmness to our user's first impressions of us and it has an inherent cohesion to it that I think is more engaging and welcoming.

That said, this is still our first iteration of a "V2" and we should keep an eye on the response we get and continuously iterate on this multi-slide story going forward.

Here's the invision link to the design mocks: https://invis.io/4J5IM02MR (the second last slide in this example is the Market specific one - more on that later).
Pinging Matej to see if he has any thoughts on this copy - my copy is obviously just placeholders at this point but I hope it gives a good sense of the direction/ message I'm trying to convey in this storyline.

Title on navigation, Slide title, and body copy are the main parts that need some help here :)

Matej - do you have any time for this?
Flags: needinfo?(matej)
(In reply to Anthony Lam (:antlam) from comment #2)
> Pinging Matej to see if he has any thoughts on this copy - my copy is
> obviously just placeholders at this point but I hope it gives a good sense
> of the direction/ message I'm trying to convey in this storyline.
> 
> Title on navigation, Slide title, and body copy are the main parts that need
> some help here :)
> 
> Matej - do you have any time for this?

I can definitely help out with this, but I'm wondering about timing and where this fits in with a few other things that are going on. 

There's a copy audit going on of in-product strings (being run by Bill and Gemma, with the help of a contractor) that's going to produce a report and some recommendations about things we can improve, streamline, etc. There's also some brand positioning work happening that may help inform this. Could this wait until those are complete?

You already mentioned the desktop onboarding work, which is going to start this quarter. Is there a reason this is being treated separately from that? It would be nice if users had similar experiences on both desktop and mobile. We could even potentially reuse some assets.
Flags: needinfo?(matej)
(In reply to Matej Novak [:matej] from comment #3)
> I can definitely help out with this, but I'm wondering about timing and
> where this fits in with a few other things that are going on. 

Definitely, that's a good point too.

> There's a copy audit going on of in-product strings (being run by Bill and
> Gemma, with the help of a contractor) that's going to produce a report and
> some recommendations about things we can improve, streamline, etc. There's
> also some brand positioning work happening that may help inform this. Could
> this wait until those are complete?

When do you expect that work to be finished? 

While I think there's value in waiting and coordinating our efforts to be synchronized, this work is also ongoing by nature. I'd like to get something in to test, iterate and improve as soon as we can because this will definitely be an ongoing effort.

The goal of this on mobile right now is to address some well known issues that we've seen come up quite often. But the method and story-like approach that I've started going towards is something I've been talking to Michael and Michelle about too so they're aware of this work.

> You already mentioned the desktop onboarding work, which is going to start
> this quarter. Is there a reason this is being treated separately from that?
> It would be nice if users had similar experiences on both desktop and
> mobile. We could even potentially reuse some assets.

Definitely agree here. And I'm working with Michael Verdi on the overall onboarding experience as well. So we're keeping both experiences in mind as we continue to iterate on both products. But in the mean time, I think we can still move forward with improving our own product and we can loop back and update this when the time comes.
Flags: needinfo?(matej)
Hi Anthony,

Thanks for the reply. I can review the copy in the current mockup, but I'd still love for this to get integrated into the larger oboarding project this quarter. Would you be the right person to loop in when that gets kicked off? I want to make sure our team knows all the places the assets may be used before we begin designing anything.
Here's the new layout matching your mocks, but with the same visuals as before.

Let me know if the colors, padding, fonts look good, or need change.

(Notes: there is no padding on either side of the image - that's just the size of the image. The padding on top/bottom of the image are the same, and I think the font of the text is making it look slightly unbalanced to me.)
Assignee: nobody → liuche
Status: NEW → ASSIGNED
Attachment #8707208 - Flags: feedback?(alam)
(In reply to Matej Novak [:matej] from comment #5)
> Hi Anthony,
> 
> Thanks for the reply. I can review the copy in the current mockup, but I'd
> still love for this to get integrated into the larger oboarding project this
> quarter. Would you be the right person to loop in when that gets kicked off?
> I want to make sure our team knows all the places the assets may be used
> before we begin designing anything.

Definitely! I am also continuously keeping Verdi in the loop and looking out for that work so let me know! :) appreciate the help!
Comment on attachment 8707208 [details]
Screenshot: New firstrun layout

Awesome! I'll supply some images.
Attachment #8707208 - Flags: feedback?(alam) → feedback+
We can continually improve the copy in our products, but I do not want to block on a more general project before we start landing some improved first run experiments.

Let's pick a few different permutations of new panels and get them in the product to test ASAP.

I am expecting something to be in Fx46, and merge day is the 25th. That means Chenxia needs to land patches for this next week, so we need to just pick something and go with it. We can (and should) always improve on this in the future.
(Also, I'm not a fan of "vN" bugs, since they have a tendency to become dumping grounds. Let's just make the bug summary reflect what we're trying to achieve in this iteration.)
Sorry for the delay. Here are my revisions and suggestions. 

I tried to create a flow and a rhythm to the experience, so you'll see that all of the headings (except for the first one), are made up for two statements separated by a comma and the copy below always starts with a verb. I also wrote slide titles, which I tried to keep to one word, but I wasn't sure how to do that for slide 2. Any thoughts?

You'll see I also swapped the order of slides 3 and 4. I think it's better to have the one about Sync be right before the CTA to sign in.

Have a look and let me know if you have any questions.


SLIDE 1 — WELCOME

Welcome to Firefox
Find things faster with helpful search suggestion shortcuts.


SLIDE 2 — BOOKMARKS & HISTORY

Your faves, front and center
Get results from your bookmarks and history for easy access.


SLIDE 3 — DATA | OFFLINE | SEARCH

Less data, more savings
Block images to spend less data on every site you visit.

Offline, on the go
Save Web pages to make them available when you're offline.

Your search, your way
Choose any search engine you like as your default.


SLIDE 4 — SYNC

Firefox, always by your side
Sync your browsing data everywhere you use Firefox.


SLIDE 5 — SIGN IN

Get connected, get started
Sign in to Sync


TOP SITES

Welcome to your homepage. Start here every time you open a new tab.
Flags: needinfo?(matej)
Awesome, thanks Matej!
Attached file v2slides_XXHDPI.zip
Attaching assets for next round of First Run slides and testing.

In our conversation about testing, these slides would cover B and C.
Flags: needinfo?(liuche)
Attached image Onboarding A: UI changes from new code (obsolete) —
Anthony, I realized that some of the code changes that I made are not back-port-able to our original "blue" first run. Is this acceptable, or should we not run with it anymore? My concern is that it looks pretty inconsistent...

Apk up here, with the interactive slide: http://people.mozilla.org/~liuche/bug-1238780/firstrun2-v1.apk
Flags: needinfo?(liuche)
Attachment #8709793 - Flags: feedback?(bbermes)
Attachment #8709793 - Flags: feedback?(alam)
Attachment #8709793 - Flags: feedback?(adavis)
Comment on attachment 8709792 [details]
MozReview Request: Bug 1238780 - Add interactive slide. r=sebastian

This is for feedback - I have all the parts working, but I need to update the pref, which I have to look up and will do tomorrow.

Please prioritize this in your queue if you can, sebastian! We'd like to land this for 46.
Attachment #8709792 - Flags: review?(s.kaspari) → feedback?(s.kaspari)
Comment on attachment 8709790 [details]
MozReview Request: Bug 1238780 - Remove old firstrun panels. r=sebastian

https://reviewboard.mozilla.org/r/31545/#review28299
Attachment #8709790 - Flags: review?(s.kaspari) → review+
Attachment #8709791 - Flags: review?(s.kaspari) → review+
Comment on attachment 8709791 [details]
MozReview Request: Bug 1238780 - Add static slides. r=sebastian

https://reviewboard.mozilla.org/r/31547/#review28301

::: mobile/android/base/resources/layout/firstrun_basepanel_fragment.xml:20
(Diff revision 1)
> +            <ImageView android:id="@+id/firstrun_image"

NIT: This element has a different indentation.
Comment on attachment 8709792 [details]
MozReview Request: Bug 1238780 - Add interactive slide. r=sebastian

https://reviewboard.mozilla.org/r/31549/#review28303

::: mobile/android/base/java/org/mozilla/gecko/firstrun/DataPanel.java:1
(Diff revision 1)
> +package org.mozilla.gecko.firstrun;

NIT: license

::: mobile/android/base/java/org/mozilla/gecko/firstrun/DataPanel.java:25
(Diff revision 1)
> +                isEnabled = !isEnabled;
> +                int newResource = isEnabled ? R.drawable.firstrun_data_on : R.drawable.firstrun_data_off;
> +                ((ImageView) view).setImageResource(newResource);
> +                if (isEnabled) {
> +                    // TODO: set pref;
> +                }

In theory you could use an ToggleButton (or maybe Checkbox?) here with different styles for enabled/disabled. This way you avoid handling state and image resources yourself. However I'm okay with the manual approach too.
Attachment #8709792 - Flags: review+
Attachment #8709792 - Flags: feedback?(s.kaspari) → feedback+
(In reply to Chenxia Liu [:liuche] from comment #17)
> Created attachment 8709793 [details]
> Onboarding A: UI changes from new code

I do not want us to spend a lot of time chasing after bugs with this tab strip. Let's please come up with a design that doesn't require us to do more custom UI here.

Given this change, maybe we should drop the "A" test with a single panel. I know it's not as scientific, but we already have retention numbers for a single panel release (basically our entire history), so can we compare against that to test the hypothesis that a more full-fledged onboarding leads to greater retention?
(In reply to Chenxia Liu [:liuche] from comment #17)
> Created attachment 8709793 [details]
> Onboarding A: UI changes from new code
> 
> Anthony, I realized that some of the code changes that I made are not
> back-port-able to our original "blue" first run. Is this acceptable, or
> should we not run with it anymore? My concern is that it looks pretty
> inconsistent...

If you are referring to this: https://bug1238780.bmoattachments.org/attachment.cgi?id=8709793
I think it looks fine and very similar to our original control. I had to really think about what the blue looked like before. 

(In reply to :Margaret Leibovic from comment #22)
> (In reply to Chenxia Liu [:liuche] from comment #17)
> > Created attachment 8709793 [details]
> > Onboarding A: UI changes from new code
> 
> I do not want us to spend a lot of time chasing after bugs with this tab
> strip. Let's please come up with a design that doesn't require us to do more
> custom UI here.

Agreed. Let's keep it simple.

> 
> Given this change, maybe we should drop the "A" test with a single panel. I
> know it's not as scientific, but we already have retention numbers for a
> single panel release (basically our entire history), so can we compare
> against that to test the hypothesis that a more full-fledged onboarding
> leads to greater retention?

I think we will still need a control because our historical data will be tossed in the garbage with this test. Retention will now need to be measured with Telemetry instead of FHR. If we compare our versions B and C measured with Telemetry to a historical control measured with FHR, it won't be very accurate IMO.
Attached image Screenshot: Onboarding A - No Tabstrip (obsolete) —
Here's a quick and dirty version without the tab strip for our A version. No "Welcome". Is that sufficient? I'd like some positioning/size feedback from antlam, because it looks a little funny.

Does that work for you guys? There's no tab strip to hint about our tab strip behavior, but maybe that's fine because when we had a single item that didn't really hint at tab strip behavior anyways. That way we can keep some continuity.

I still have a slightly funny feeling that we're just setting up our experiment to skew one version to win (C, the interactive one) and it seems weird to be trying to collect all this data for things we'll probably throw away anyways.
Attachment #8710032 - Flags: feedback?(bbermes)
Attachment #8710032 - Flags: feedback?(alam)
Attachment #8710032 - Flags: feedback?(adavis)
Comment on attachment 8710032 [details]
Screenshot: Onboarding A - No Tabstrip

Looks good to me.
Attachment #8709793 - Flags: feedback?(adavis) → feedback?
Comment on attachment 8709793 [details]
Onboarding A: UI changes from new code

Yeah, this is weird. We should just hide the header if possible
Attachment #8709793 - Flags: feedback?(alam) → feedback-
Comment on attachment 8710032 [details]
Screenshot: Onboarding A - No Tabstrip

+ for removing the header as a quick and dirty solution.

If you're looking to fix the layout issue, try adding the same 48dp padding to the top of the blue area, and then vertically center the image inside the new blue space.

That should do it!

Thanks Chenxia!
Attachment #8710032 - Flags: feedback?(alam) → feedback+
(In reply to Chenxia Liu [:liuche] from comment #24)

> I still have a slightly funny feeling that we're just setting up our
> experiment to skew one version to win (C, the interactive one) and it seems
> weird to be trying to collect all this data for things we'll probably throw
> away anyways.

I don't think we're favoring version C in any way but if we make it super awesome to guarantee it's victory, that's ok too. We want to win.

The goal of testing is to quantify the improvement brought by our efforts, to learn something, document these learnings (maybe we create a Onboarding Playbook), and to soft launch behind a flag to make sure we didn't break anything. We may be throwing away 2 versions after but we will always be preserving the acquired knowledge from the outcome.

In terms of process, when going through a backlog of tests, we have to favor those that are likely to win. No point in spending time on tests that are doomed to fail from the start. That would be sillier. Despite this, 50% of tests we think will win will ultimately fail.

Let's just remind ourselves of our last test which provided no improvement. We all thought it would improve retention. Thanks to the test, we know "import" has no impact and it's now one less feature to regularly maintain in the onboarding flow. Although it was a "loss", it feels more like a "save" to me.
Attachment #8710032 - Flags: feedback?(adavis) → feedback+
Have we decided on the slide titles yet? (the ones at the top of the screen)
Flags: needinfo?(matej)
Flags: needinfo?(alam)
I used the ones in Comment 11 - Except "Bookmarks & History" is awfully long, so I suggest we only use either "Bookmarks" or "History" for that title.
Flags: needinfo?(alam)
(In reply to Anthony Lam (:antlam) from comment #30)
> I used the ones in Comment 11 - Except "Bookmarks & History" is awfully
> long, so I suggest we only use either "Bookmarks" or "History" for that
> title.

Yeah, I wasn't sure what to do there. Maybe "History" is better because it covers both.

Another option is to number them so the user knows how many screens there will be: 1/5, 2/5, 3/5…
Flags: needinfo?(matej)
Good question, while I think titles are more explicit, I could see people loving the "oh I'm almost done, it's 3/5" etc. Completing steps is something people like to do or at least know where they are at.

Antlam?
Flags: needinfo?(alam)
Chenxia! Nice work. I just installed the apk. You are faaaast.

Does the interactive slide actually work / set the setting?  
I'm worried people don't know they can use the switch in this slide, might be good to monitor this via probes. Anthony, do you think we need to point this out more?

Also, I suggest to move the data savings slide before the sync one, so that the last two slides will talk about sync and then sign-in.

Btw, how do you all navigate through it? I don't use the next button, I swipe, how about you?
Flags: needinfo?(liuche)
(In reply to Barbara Bermes [:barbara] from comment #32)
> Good question, while I think titles are more explicit, I could see people
> loving the "oh I'm almost done, it's 3/5" etc. Completing steps is something
> people like to do or at least know where they are at.
> 
> Antlam?

Let's go with History.

We had page indicators in the first iterations but we ran into some implementation issues. We can try to revisit that in the next iteration but these page header tabs should be titles to be more platform agnostic.
Flags: needinfo?(alam)
(In reply to Chenxia Liu [:liuche] from comment #17)
> Apk up here, with the interactive slide:
> http://people.mozilla.org/~liuche/bug-1238780/firstrun2-v1.apk

couple notes:

 - first slides illustration should be the other one (attached in this bug). It looks like you're using the old one
 - "Bookmarks & History" title should change to "History"
 - Is the background color #f5f5f5?
 - the tabs page header background color should be #e8e8e8
Attachment #8709793 - Attachment is obsolete: true
Attachment #8710032 - Attachment is obsolete: true
Attachment #8709793 - Flags: feedback?(bbermes)
Attachment #8709793 - Flags: feedback?
Attachment #8710032 - Flags: feedback?(bbermes)
Flags: needinfo?(liuche)
Attachment #8710101 - Flags: feedback?(alam)
Comment on attachment 8710101 [details]
Screenshot: No tabstrip, bigger sizing

\o/ NICE!
Attachment #8710101 - Flags: feedback?(alam) → feedback+
(In reply to Matej Novak [:matej] from comment #11)
> SLIDE 1 — WELCOME
> 
> Welcome to Firefox
> Find things faster with helpful search suggestion shortcuts.
> 
> 
> SLIDE 2 — BOOKMARKS & HISTORY
> 
> Your faves, front and center
> Get results from your bookmarks and history for easy access.

Hi Matej, I'm preparing the details of our A/B test on mana: https://mana.mozilla.org/wiki/pages/viewpage.action?pageId=57508096

I was re-looking at the slides in order with the images included and it was more apparent that the 2nd slide might be unclear to new users. It isn't obvious that we're referring to search which is mentioned in slide 1. Since users flip through these quickly, I want to make sure it's super clear or it won't provide value.

Here are some suggestions as an example (but you can prob still do better than me):

(example 1)

SLIDE 2 — BOOKMARKS & HISTORY

Your faves, front and center
Search results include your bookmarks and history for easy access.

(example 2)

SLIDE 2 — BOOKMARKS & HISTORY

Your faves, front and center
Get easy access to your bookmarks and history through search.

(example 3)

SLIDE 2 — BOOKMARKS & HISTORY

Your faves, front and center
Search highlights matching bookmarks and history with new web results.

---

One more small suggestion... for slide 4, would you be ok with changing:

(your suggestion)
Firefox, always by your side
Sync your browsing data everywhere you use Firefox.

to

(my edit)
Firefox, always by your side
Sync your favorites, history and passwords everywhere you use Firefox.


As you can imagine, I hate making it longer but I think it will remove any ambiguity around "browsing data" and make the benefit more clear to users. This normally outweighs the benefit of short text.

Let me know your thoughts. Thanks in advance for the help.
Flags: needinfo?(matej)
(In reply to Alex Davis [:adavis] from comment #38)
> (In reply to Matej Novak [:matej] from comment #11)
> > SLIDE 1 — WELCOME
> > 
> > Welcome to Firefox
> > Find things faster with helpful search suggestion shortcuts.
> > 
> > 
> > SLIDE 2 — BOOKMARKS & HISTORY
> > 
> > Your faves, front and center
> > Get results from your bookmarks and history for easy access.
> 
> Hi Matej, I'm preparing the details of our A/B test on mana:
> https://mana.mozilla.org/wiki/pages/viewpage.action?pageId=57508096
> 
> I was re-looking at the slides in order with the images included and it was
> more apparent that the 2nd slide might be unclear to new users. It isn't
> obvious that we're referring to search which is mentioned in slide 1. Since
> users flip through these quickly, I want to make sure it's super clear or it
> won't provide value.
> 
> Here are some suggestions as an example (but you can prob still do better
> than me):
> 
> (example 1)
> 
> SLIDE 2 — BOOKMARKS & HISTORY
> 
> Your faves, front and center
> Search results include your bookmarks and history for easy access.
> 
> (example 2)
> 
> SLIDE 2 — BOOKMARKS & HISTORY
> 
> Your faves, front and center
> Get easy access to your bookmarks and history through search.
> 
> (example 3)
> 
> SLIDE 2 — BOOKMARKS & HISTORY
> 
> Your faves, front and center
> Search highlights matching bookmarks and history with new web results.
> 

I see what you're saying. Let's change this to the following:

Your faves, front and center
Get results from your bookmarks and history when you search.


> One more small suggestion... for slide 4, would you be ok with changing:
> 
> (your suggestion)
> Firefox, always by your side
> Sync your browsing data everywhere you use Firefox.
> 
> to
> 
> (my edit)
> Firefox, always by your side
> Sync your favorites, history and passwords everywhere you use Firefox.
> 

I'd really rather not make this longer or repeat too many things from earlier slides so people understand the key message for each one. I'm also not sure what "favorites" refers to here and if that will be clear to users.

Maybe we could say something like "browsing info" or change it to "Make your Firefox your own everywhere you use it," but I'm not sure that's any better.

If it's OK with everyone, I'd recommend keeping this one as is.
Flags: needinfo?(matej)
My bad... I meant to say bookmarks, not favorites.

I just keep thinking that my mom does not know what "browsing data" or "browsing info" means. This is our final call to action to create an account. I just want to make sure our value proposition is crystal clear.

I'm going to take a few more minutes to reflect on this one and will add them to the bug. I think we know what we want to achieve. Question is how to say it.
@Matej, How about we stay away from history and bookmarks. We could say:

"Firefox, always by your side
Sync your tabs, passwords and more, everywhere you use Firefox."

(not sure about punctuation there)

This way, we still bring a clear value proposition without being redundant.
Flags: needinfo?(matej)
(In reply to Alex Davis [:adavis] from comment #41)
> @Matej, How about we stay away from history and bookmarks. We could say:
> 
> "Firefox, always by your side
> Sync your tabs, passwords and more, everywhere you use Firefox."

That's better, though I still worry about length for l10n. Maybe we don't have to repeat "Firefox," since it's already in the headline, and save at least a few characters:

Firefox, always by your side
Sync your tabs, passwords and more everywhere you use it.
Flags: needinfo?(matej)
Love it! You rock! Thanks for the really fast turn around! :)

Recap. We have updated the following to: 

SLIDE 2
Your faves, front and center
Get results from your bookmarks and history when you search.

SLIDE 4
Firefox, always by your side
Sync your tabs, passwords and more everywhere you use it.
(In reply to Alex Davis [:adavis] from comment #43)
> Love it! You rock! Thanks for the really fast turn around! :)
> 
> Recap. We have updated the following to: 
> 
> SLIDE 2
> Your faves, front and center
> Get results from your bookmarks and history when you search.
> 
> SLIDE 4
> Firefox, always by your side
> Sync your tabs, passwords and more everywhere you use it.


Slides updated.

Chenxia, can we get these copy changes?
Flags: needinfo?(liuche)
Comment on attachment 8709791 [details]
MozReview Request: Bug 1238780 - Add static slides. r=sebastian

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/31547/diff/1-2/
Comment on attachment 8709792 [details]
MozReview Request: Bug 1238780 - Add interactive slide. r=sebastian

Review request updated; see interdiff: https://reviewboard.mozilla.org/r/31549/diff/1-2/
Attachment #8709792 - Flags: feedback+
https://reviewboard.mozilla.org/r/31549/#review28303

> In theory you could use an ToggleButton (or maybe Checkbox?) here with different styles for enabled/disabled. This way you avoid handling state and image resources yourself. However I'm okay with the manual approach too.

That's a good point, I didn't think of that! I decided to keep this the same though so we don't have to include another resource file for the Data page and a drawable selector, and can simply special case handling that click. But I will definitely keep it in mind :)
Depends on: 1241627
Depends on: 1241630
Comment on attachment 8710603 [details]
MozReview Request: Bug 1238780 - Remove Tab strip for Onboarding A. r=sebastian

https://reviewboard.mozilla.org/r/31801/#review28627
Attachment #8710603 - Flags: review?(s.kaspari) → review+
I noticed that we have ~500KB of firstrun_* images in mobile/android/base/resources/drawable-nodpi/

I ran pngquant on them and got the total down to ~146KB
https://hg.mozilla.org/integration/fx-team/rev/f1a2a698f92b119641003f8a3ab23274be23461e
Bug 1238780 - Follow-up: use pngquant and pngcrush to reduce file sizes. rs=rnewman
Comment on attachment 8711349 [details] [diff] [review]
shrink-firstrun-images v0.1

Landed with a few tweaks.
Attachment #8711349 - Flags: review?(rnewman) → review+
(In reply to Mark Finkle (:mfinkle) from comment #52)
> I noticed that we have ~500KB of firstrun_* images in
> mobile/android/base/resources/drawable-nodpi/
> 
> I ran pngquant on them and got the total down to ~146KB

This would be a good mobile-firefox-dev post, to tell other people they should do this when adding images.
Depends on: 1242467
Depends on: 1242589
Blocks: 1243216
Blocks: 1243835
Flags: needinfo?(liuche)
I'm surprised the data savings slide doesn't show the users how to change the preference (e.g. give them a toggle on the slide, or show them where to find it in Settings). Was this intentional? What is the reasoning behind it?
Flags: needinfo?(alam)
(In reply to Michael Comella (:mcomella) from comment #58)
> I'm surprised the data savings slide doesn't show the users how to change
> the preference (e.g. give them a toggle on the slide, or show them where to
> find it in Settings). Was this intentional? What is the reasoning behind it?

There is a toggle on the slide, you just didn't notice it.

This is being addressed in bug 1243216.
(In reply to Michael Comella (:mcomella) from comment #58)
> I'm surprised the data savings slide doesn't show the users how to change
> the preference (e.g. give them a toggle on the slide, or show them where to
> find it in Settings). Was this intentional? What is the reasoning behind it?

Having them navigate through a series of hoops is going to be near impossible to illustrate in an interesting way. Instead, making it a simple ON/OFF interaction makes a lot more sense. So, the goal was to just have them turn it ON/OFF here, rather than in Settings.

Yes, Margaret is also right, we have a bug to address the "obviousness" of said switch too ^ :)
Flags: needinfo?(alam)
No longer blocks: 1243216, 1243835
Depends on: 1243216, 1243835, 1246130
You need to log in before you can comment on or make changes to this bug.