Closed Bug 1220251 Opened 9 years ago Closed 8 years ago

First run panel to select a lightweight theme

Categories

(Firefox for Android Graveyard :: General, defect)

Product:
Firefox for Android Graveyard
Component:
General
Version:
35 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: Margaret, Assigned: liuche)

References

Details

Attachments

(7 files, 2 obsolete files)

lwtPickerDialog-prototype
16.74 KB, patch
Details | Diff | Splinter Review
LWT_pack1.zip
3.25 KB, application/zip
Details
theme_sticker_buttons1.zip
135.85 KB, application/zip
Details
prev_picktheme2_0_XHDPI.png
162.78 KB, image/png
Details
wip-screenshot
130.58 KB, image/png
Details
LWT_darkpack.zip
37.04 KB, application/zip
Details
background_circle.zip
38.34 KB, application/zip
Details 
We should explore making a first run panel that lets you choose from a set of lightweight themes.

This patch has an example of how to install a lightweight theme from a resource we ship:
https://hg.mozilla.org/mozilla-central/rev/c4cd293d7edd
We want to add this panel to the family-friendly browsing first run experience.
Blocks: family-friendly-browsing-2
Anthony, can you start thinking about what this should look like?
Flags: needinfo?(alam)
Assignee: nobody → ally
:antlam thinks he might have time to start thinking about this after the end of next week.
(In reply to Allison Naaktgeboren :ally from comment #3)
> :antlam thinks he might have time to start thinking about this after the end
> of next week.

Ally - I think Chenxia mentioned this on IRC, but you can probably start building a WIP without mocks from Anthony. We know a few things:
* This will be a new Panel, so start by adding a Panel. Use a button+dialog to pick a LWT, or just make a list of LWTs on the panel.
* This will include a few built-in lightweight themes, so make the code needed to install a bundled LWT.
I'd agree ^

I remember Chenxia and myself did some prototyping around using the CTA button (big orange button) of a first run slide to launch a dialog. This dialog would just be a list of bundled LWT that we ship. 

I'll leave the NI here for following up with more concrete designs
Flags: needinfo?(ally)
Flags: needinfo?(alam)
Ally,

UX doc here: https://invis.io/JE4VQLOQF .

things to note:
 - remove home pager navigation along the top (currently says "Welcome")
 - Roboto Light (text and tabs tray grey #363B40) 30sp for Title
 - will attach graphics next
Attached image prev_picktheme1_1_XHDPI.png (obsolete) — 
For quick visual reference
I'm also worried about the "+" icon being too dominated by the color/LWT in the back. 

Ally, 
 - how would you like me to prepare these "themes"? should I just give you a color value?
 - is it possible to tint this "+" icon to white for certain themes only?
Attached patch lwtPickerDialog-wip-prototype (obsolete) — — Splinter Review 
:antlam's mock has gone in a very different direction from the prototype we were discussing in irc last week. I don't expect to get to re-use much of this, but in case it's useful to future work, I am uploading it here.
Flags: needinfo?(ally)
We need to talk about this mock-up, I think there's some confusion about the restraints here.

What we need is a new *single* first run panel that can be added to the existing first run experience, either in restricted profiles, or in regular Firefox profiles.

I don't think we should have any sort of "swipe" or "next" concept as part of the "pick a theme panel", to avoid creating a confusing interaction with other first run panels.

We can do something similar to this proposed design, where we have a set of different "theme" buttons on the panel, and the user hits a button to "try out" a theme, but we should not have an interaction where the user is visiting different panels to try out different themes.

Another piece of feedback I have is that when the user first sees this screen, they are not going to know that they are "trying out" a currently selected theme, since they haven't seen anything change. So I think we need to be clear about instructing them to press different buttons to try things out, perhaps starting in the default gray state, and only changing when they hit a button. We could even disable the "Choose this one" button until they do try out a theme.
(In reply to :Margaret Leibovic from comment #10)

> What we need is a new *single* first run panel that can be added to the
> existing first run experience, either in restricted profiles, or in regular
> Firefox profiles.
> 
> I don't think we should have any sort of "swipe" or "next" concept as part
> of the "pick a theme panel", to avoid creating a confusing interaction with
> other first run panels.

Agreed. I think the invisio mockup is a bit too complicated.

> We can do something similar to this proposed design, where we have a set of
> different "theme" buttons on the panel, and the user hits a button to "try
> out" a theme, but we should not have an interaction where the user is
> visiting different panels to try out different themes.

Also agree. The "foxes" did not seem like "themes" to me. I mean, it's kinda cute, but I think we should be a bit more explicit in onboarding. Why not do a low-fidelity image of the window in the theme color. Let the user tap to try on a theme. Make sure we have a "no theme" option (I assume) and then they can swipe/'>' to the next panel.

> Another piece of feedback I have is that when the user first sees this
> screen, they are not going to know that they are "trying out" a currently
> selected theme, since they haven't seen anything change. So I think we need
> to be clear about instructing them to press different buttons to try things
> out, perhaps starting in the default gray state, and only changing when they
> hit a button. We could even disable the "Choose this one" button until they
> do try out a theme.

Yes. More copy would be helpful. I don't want people wondering "what the heck is the point of this panel?"
has red, blue, yellow, and green themes and can switch between them. 

- still attached to the regular first run as I still have restricted profile issues on tablet
Attachment #8685843 - Attachment is obsolete: true
(In reply to :Margaret Leibovic from comment #10)
> We need to talk about this mock-up, I think there's some confusion about the
> restraints here.
> 
> What we need is a new *single* first run panel that can be added to the
> existing first run experience, either in restricted profiles, or in regular
> Firefox profiles.
> 
> I don't think we should have any sort of "swipe" or "next" concept as part
> of the "pick a theme panel", to avoid creating a confusing interaction with
> other first run panels.
> 
> We can do something similar to this proposed design, where we have a set of
> different "theme" buttons on the panel, and the user hits a button to "try
> out" a theme, but we should not have an interaction where the user is
> visiting different panels to try out different themes.

Apologies for the confusion, my goal is still a "1 slide" design.

I added the <- and -> arrows as a supplementary navigation. Mostly because we're dealing with a younger target audience. I wasn't sure if it was touch friendly enough. But, we can get rid of it since it's causing confusion (the invision mock had both hooked up so that might be the confusion).

The idea is still to have the "buttons" on the panel be the navigation.

> Another piece of feedback I have is that when the user first sees this
> screen, they are not going to know that they are "trying out" a currently
> selected theme, since they haven't seen anything change. So I think we need
> to be clear about instructing them to press different buttons to try things
> out, perhaps starting in the default gray state, and only changing when they
> hit a button. We could even disable the "Choose this one" button until they
> do try out a theme.

I like that idea. I thought about doing this too.

I'll revisit this to show more "direction".

(In reply to Mark Finkle (:mfinkle) from comment #11)
> > We can do something similar to this proposed design, where we have a set of
> > different "theme" buttons on the panel, and the user hits a button to "try
> > out" a theme, but we should not have an interaction where the user is
> > visiting different panels to try out different themes.
> 
> Also agree. The "foxes" did not seem like "themes" to me. I mean, it's kinda
> cute, but I think we should be a bit more explicit in onboarding. Why not do
> a low-fidelity image of the window in the theme color. Let the user tap to
> try on a theme. Make sure we have a "no theme" option (I assume) and then
> they can swipe/'>' to the next panel.

The idea here is to go with a "representation" of the theme rather than being more concerned with providing a more detailed/accurate representation here because i felt it more engaging for the younger audience. 

I think focusing their attention to seeing the toolbar actually change as they pressed these buttons should be enough. Ultimately, that relationship is more accurately represented (by looking at the actual toolbar with the LWT applied) than a low fi image of the window.
Attached file LWT_pack1.zip — 
Here's the LWT images, currently these are the Mozilla brand colors (as mentioned on Vidyo, we'll likely have to play with these a bit to see how they look in product)
Flags: needinfo?(ally)
Also, here some buttons for you!
I've also started iterating on the "default state" from some of the feedback. 
Taking from the the idea of the original "welcome screen", I've added some copy to help give a bit more context for this panel and make it feel more welcoming.

Also, the "pick this theme" button doesn't come out until the user selects a theme. 

I'm working on a simple animation to bounce the "orange theme" button if a user were to tap anywhere other than that one - I can show the Framer.JS mock. 

This visual cue will give first time users a hint at what they are supposed to do (like when you click somewhere in the invision mock that isn't "hooked up", you get the blue box visual hint). This effectively funnels them to picking a theme.

Ally, let me know how this is coming along and we can keep iterating on this together :)
Attachment #8685640 - Attachment is obsolete: true
(In reply to Anthony Lam (:antlam) from comment #16)
> Created attachment 8687030 [details]
> prev_picktheme2_0_XHDPI.png
> 
> I've also started iterating on the "default state" from some of the
> feedback. 
> Taking from the the idea of the original "welcome screen", I've added some
> copy to help give a bit more context for this panel and make it feel more
> welcoming.
> 
> Also, the "pick this theme" button doesn't come out until the user selects a
> theme. 
> 
> I'm working on a simple animation to bounce the "orange theme" button if a
> user were to tap anywhere other than that one - I can show the Framer.JS
> mock. 
> 
> This visual cue will give first time users a hint at what they are supposed
> to do (like when you click somewhere in the invision mock that isn't "hooked
> up", you get the blue box visual hint). This effectively funnels them to
> picking a theme.
> 
> Ally, let me know how this is coming along and we can keep iterating on this
> together :)

While iterating on the design here, we seem to have lost the original "Welcome" slide that informs users they're running a special version of Firefox in a restricted profile.

We shouldn't have anything specific to family-friendly browsing in this new lightweight theme panel, so we will still need a separate panel for a link to learn more about family-friendly browsing.
(In reply to :Margaret Leibovic from comment #17)
> While iterating on the design here, we seem to have lost the original
> "Welcome" slide that informs users they're running a special version of
> Firefox in a restricted profile.

From running through the entire set-up flow (including what the system makes our user do), it seems to me like the "Welcome slide" is not as necessary.

Partly, this is due to the long winding road of setting up a restricted profile and all the context that comes with it, but the other part is that (I think) this screen is already showing that they're running a "special version" of Firefox.

Do we really need a separate "slide" here for "welcome to firefox"? My goal here is to engage the younger audience as soon as the parent hands off the device. I think what's most engaging here for the younger audience would be to dive right into interacting with this "new app" that's been placed in front of them. 

That being said, if we want to have a first slide that introduces to the parent to "hand off" the device. I could perhaps see that working.

> We shouldn't have anything specific to family-friendly browsing in this new
> lightweight theme panel, so we will still need a separate panel for a link
> to learn more about family-friendly browsing.

Hmmmm, what do you mean by "anything specific to family-friendly browsing"? I'm not sure why we need the link to be in a separate panel?
Flags: needinfo?(margaret.leibovic)
(In reply to Anthony Lam (:antlam) from comment #18)

> > We shouldn't have anything specific to family-friendly browsing in this new
> > lightweight theme panel, so we will still need a separate panel for a link
> > to learn more about family-friendly browsing.
> 
> Hmmmm, what do you mean by "anything specific to family-friendly browsing"?
> I'm not sure why we need the link to be in a separate panel?

My main concern is that I want us to be able to re-use this lightweight theme panel in the first run tour in normal profiles. A link to learn about family-friendly-browsing would not make sense in normal profiles.
Flags: needinfo?(margaret.leibovic)
Ah, right!

I want to re-use this "slide/panel" as well but I think we would still adjust the tone/visuals to be more for general audiences anyways (when we move this to general first run). That would require some things like copy changes and image swaps but the basic interaction and implementations are what I think we should keep the same.

In that same breath though, if this were to be in general Firefox, that link would be "start browsing" or "next" anyways and not "Learn more about Family Friendly Browsing". 

So that's kind of how I see us re-using/scaling this.
I am concerned that we are getting bogged down.

I generally agree with Anthony that copy(and subsequent links) and especially the images that would make the best sense for the general audience do not make sense for young children.

I also agree that young children are most likely to be engaged by big bouncing buttons than a block of text directing them to do something. 

Let's then agree that the guts & layout should be re-usable, and to be able to swap out the text/images in the future.

To be conservative, we'll keep the existing welcome screen until the theme picker panel is landed. If after landing we can agree that it's not adding anything, we can remove it then.

Sound fair?
Flags: needinfo?(ally)
Attached image wip-screenshot — 
wip, for :antlam who is anxious to see how it is going.
Attached file LWT_darkpack.zip — 
I think we should add this darker/purple theme to replace the yellow theme to help alleviate some of the concerns around maturity of this UI. I think it's also a nice balance to add some blue hue to the currently red hue dominated themes.
(In reply to Allison Naaktgeboren :ally from comment #22)
> Created attachment 8688205 [details]
> wip-screenshot
> 
> wip, for :antlam who is anxious to see how it is going.

Thanks! looking good!

(In reply to Allison Naaktgeboren :ally from comment #21)
> I am concerned that we are getting bogged down.
> 
> I generally agree with Anthony that copy(and subsequent links) and
> especially the images that would make the best sense for the general
> audience do not make sense for young children.
> 
> I also agree that young children are most likely to be engaged by big
> bouncing buttons than a block of text directing them to do something. 
> 
> Let's then agree that the guts & layout should be re-usable, and to be able
> to swap out the text/images in the future.

Yes, and this is important because we do want to reuse this possibly so we should make it so that we can remove the FFB specific content/images easily.

> To be conservative, we'll keep the existing welcome screen until the theme
> picker panel is landed. If after landing we can agree that it's not adding
> anything, we can remove it then.
> 
> Sound fair?

I talked with Margaret and we think 1 panel is OK here. I can't see the value of having a separate "welcome screen" panel if we can relay that same info in the "picker panel". Plus, given that we're unsure when this app will be launched after a restricted profile is set up, this will simplify the UX for our new users as well.

In summary, let's remove the existing welcome screen. and just go straight into this picker panel.

Thanks ally!
Attached file background_circle.zip — 
background circle asset I forgot to attach
Ally, can you share whatever progress you've made here with Chenxia?
Assignee: ally → liuche
Flags: needinfo?(ally)
I think we should put this on the back burner. I don't think we should continue to add things to restricted profiles until we get data to understand how much people are using this feature.

We should still explore a lightweight theme picker as part of our normal first run experience, but we should prioritize that relative to the other new first run panels we want to add.
Flags: needinfo?(a.m.naaktgeboren)
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: