1097337 - Inherit from Material theme and provide a theme color on Android L

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: Theme and Visual Design, defect)

Description

[Wesley Johnston (:wesj)]

We inherit from Holo so on L we look like a Holo app. We should update our theme to inherit from one of the Material design themes.

http://developer.android.com/training/material/theme.html

Comment 1

[Wesley Johnston (:wesj)]

We do have some color choices in these that we can fill out. Does UX want to do anything interesting?

Comment 2

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

Perfect! I was going to file a bug for this too but I don't have an L device yet.

I think the first part of this will just be deciding how to use our colors in the right spots. We could explore more interesting options after that base is established I think.

That being said, let's start with the color palette and the status bar, maybe the custom views.

I'll post specs later but if you just want a couple color values for specific things I'd be happy to provide those too. What specifically around "color choices" (i.e. which parts of the UI) were you looking at?

Comment 3

[Wesley Johnston (:wesj)]

The link in comment zero has an image with some colors you can specify (status bar, navigation bar, action bars, text, etc). We have a basic palette for this things, so I guess we just want to continue using those colors, but wanted you guys to know what was available.

Comment 4

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

Right, I just got my N9 with Lollipop too so I'm testing that out a bit. Will use this to gauge possibilities for now.

I think continuing to use those colors will be a good start. We should just double check to see our values are all the same though.

Comment 5

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

Attachment: mob_color_spec1.png

We've got this color spec that I made back in Aug/Sept that has most of our main colors congregated together, if it helps. :)

Comment 6

[Matt Brubeck (:mbrubeck)]

Attachment: ibarlow memorial patch: MORE ORANGE

I was playing around with this because I wanted to set the primary color (which shows up in the Lollipop app switcher).  There's probably a lot more work required before this can land.

Comment 7

[Matt Brubeck (:mbrubeck)]

Attachment: screenshot: primaryColor set to Firefox orange

Comment 8

[Matt Brubeck (:mbrubeck)]

Attachment: screenshot: settings with Material theme

Comment 9

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

Comment on attachment 8532238 [details]
screenshot: primaryColor set to Firefox orange

Thanks for picking this up Matt!

Though this looks pretty neat, I have two main concerns..

 1) Our build icon's don't look the best on this bright color
 2) Unlike apps like Yelp and Google Keep, we don't actually use this orange color that prominently in our UI.

Maybe we could try out light (#EBEBF0) and dark grey (#363B40) as well? These are our main colors in the toolbar.

Comment 10

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

Comment on attachment 8532239 [details]
screenshot: settings with Material theme

This is looking nice! I wonder if we need the build icon there still..

Comment 12

[Lucas Rocha (:lucasr)]

Comment on attachment 8532235 [details] [diff] [review]
ibarlow memorial patch: MORE ORANGE

Re-assigning feedback request to mhaigh.

Comment 13

[Martyn Haigh (:mhaigh)]

Attachment: Screenshot_2015-01-02-10-04-38.png

I think specifying a primaryColor is a good idea, however our prod build icon will get lost somewhat with that orange.  For an example of something similar in action, have a look at the youtube app icon in this screenshot.  Actually a load of apps suffer from this (Google Now, YouTube, Google+, Hangouts..) - Inbox does it well though. 

I would argue against using grey though as I think it looks a bit dull - a bright colour would make Fx pop out on the recents screen, just not a colour that our icons will get lost in.

Comment 14

[Paul [pwd]]

We could set the primary colour to orange and then set the overview icon be a white silhouette without needing to meddle with the launcher icon.

More info: http://www.bignerdranch.com/blog/polishing-your-Android-overview-screen-entry/

Comment 15

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

(In reply to Martyn Haigh (:mhaigh) from comment #13)
> Created attachment 8543242 [details]
> Screenshot_2015-01-02-10-04-38.png
> 
> I think specifying a primaryColor is a good idea, however our prod build
> icon will get lost somewhat with that orange.  For an example of something
> similar in action, have a look at the youtube app icon in this screenshot. 
> Actually a load of apps suffer from this (Google Now, YouTube, Google+,
> Hangouts..) - Inbox does it well though. 

My thoughts exactly. Also, if we add another bright color to the list of Google apps that add to this carrousel of color, we might find that we get lost in it as well. Not to mention, our UI just doesn't have a lot of orange in it.

> I would argue against using grey though as I think it looks a bit dull - a
> bright colour would make Fx pop out on the recents screen, just not a colour
> that our icons will get lost in.

Matt, Let's see if we can try the dark tabs tray grey (#363B40) and our toolbar grey (#EBEBF0)? :) I was going to suggest our blue (#0092DB), but I have the same concerns as the orange.

(In reply to Paul [pwd] from comment #14)
> We could set the primary colour to orange and then set the overview icon be
> a white silhouette without needing to meddle with the launcher icon.
> 
> More info:
> http://www.bignerdranch.com/blog/polishing-your-Android-overview-screen-
> entry/

I like this idea, but I don't want to over rotate on this right now. For issues of branding consistency, recognition and familiarity, I think we should keep the scope of this bug to just the color.

Comment 16

[Paul [pwd]]

(In reply to Anthony Lam (:antlam) from comment #15)
> (In reply to Martyn Haigh (:mhaigh) from comment #13)
> > Created attachment 8543242 [details]
> > Screenshot_2015-01-02-10-04-38.png
> > 
> > I think specifying a primaryColor is a good idea, however our prod build
> > icon will get lost somewhat with that orange.  For an example of something
> > similar in action, have a look at the youtube app icon in this screenshot. 
> > Actually a load of apps suffer from this (Google Now, YouTube, Google+,
> > Hangouts..) - Inbox does it well though. 
> 
> My thoughts exactly. Also, if we add another bright color to the list of
> Google apps that add to this carrousel of color, we might find that we get
> lost in it as well. Not to mention, our UI just doesn't have a lot of orange
> in it.
It's worth mentioning that by default everything is grey and also that recent apps persists across reboots. I'd argue that grey is far more likely to get lost.

> > I would argue against using grey though as I think it looks a bit dull - a
> > bright colour would make Fx pop out on the recents screen, just not a colour
> > that our icons will get lost in.
> 
> Matt, Let's see if we can try the dark tabs tray grey (#363B40) and our
> toolbar grey (#EBEBF0)? :) I was going to suggest our blue (#0092DB), but I
> have the same concerns as the orange.
Blue is a really popular colour for Android apps, so I'd trust your hunch on that one. I don't have any meaningful statistical data, but at a glance of my recent apps, I'm counting five blue apps including really common apps like Twitter. Assuming that they all decide to add colour, we'd really get lost.

I do like the orange idea as it's easy to spot at a glance, but perhaps simply going with white as per what Google's Calendar app does is a solution? It's another idea to throw out there.

Comment 17

[Paul [pwd]]

Looking at the Mozilla Design Guidelines[1], it really feels like we should set the primary colour per channel and go for Orange (#E66000 / Pantone 166 C) on RTM and Beta then Blue (#002147 / Pantone 282 C) on Nightly. Solving the solutions raised in comment 9 with the solution posted on comment 14.


[1] https://www.mozilla.org/en-US/styleguide/identity/firefox/color/

Comment 18

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

Matt, Let's see if we can try the dark tabs tray grey (#363B40)(In reply to Paul [pwd] from comment #17)
> Looking at the Mozilla Design Guidelines[1], it really feels like we should
> set the primary colour per channel and go for Orange (#E66000 / Pantone 166
> C) on RTM and Beta then Blue (#002147 / Pantone 282 C) on Nightly. Solving
> the solutions raised in comment 9 with the solution posted on comment 14.
> 
> 
> [1] https://www.mozilla.org/en-US/styleguide/identity/firefox/color/

I like the idea of using another color for our other builds.

But for now, let's just get a build to test the orange vs the dark grey.

Comment 19

[Matt Brubeck (:mbrubeck)]

Attachment: screenshot: primaryColor set to dark grey

Here's a shot of the app switcher with Fennec using dark grey.  I think it looks pretty good!

Comment 20

[Matt Brubeck (:mbrubeck)]

Attachment: patch v2

LESS ORANGE

Comment 21

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

(In reply to Matt Brubeck (:mbrubeck) from comment #19)
> Created attachment 8546064 [details]
> screenshot: primaryColor set to dark grey
> 
> Here's a shot of the app switcher with Fennec using dark grey.  I think it
> looks pretty good!

+1

Comment 22

[Paul [pwd]]

Attachment: Screenshot_2015-01-08-21-39-19.png

I certainly can't argue with the dark grey looking nice, but since it's a colour that falls outside of those defined in the styleguide[1] there needs to be a solid argument put forward to justify why it's going to be the colour of choice. Especially given that right now it just feels like an arbitrary colour choice. This is compounded by the fact the status bar tinting doesn't work as designed on Lollipop[2] nor HTC's running KitKat[3].

[1] https://www.mozilla.org/en-US/styleguide/identity/firefox/color/
[2] See attachment
[3] Bug 1056002 comment 20

Comment 23

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

(In reply to Paul [pwd] from comment #22)
> Created attachment 8546186 [details]
> Screenshot_2015-01-08-21-39-19.png
> 
> I certainly can't argue with the dark grey looking nice, but since it's a
> colour that falls outside of those defined in the styleguide[1] there needs
> to be a solid argument put forward to justify why it's going to be the
> colour of choice. Especially given that right now it just feels like an
> arbitrary colour choice. This is compounded by the fact the status bar
> tinting doesn't work as designed on Lollipop[2] nor HTC's running KitKat[3].

Thanks Paul. I'm glad we're having this conversation. I'm sorry you feel like this choice is "arbitrary".

Rest assured, this is not an "arbitrary colour choice". The style guide is a guide but as you can probably tell, some things in there are not the most up to date. Also, we must recognize our context and adapt accordingly, after all.

Allow me to elaborate.

I see that you feel very passionately about using orange as the banner color. But, it's worth pointing out that this "theme" color can represent both the brand and the UI (see apps referenced in the screenshots of this bug) but it's usually the latter. 

The dark grey that is depicted there (courtesy of mbrubeck) is actually the exact color we use in our tabs tray (the very same color that extends behind the "current tab" in our UI). This makes it a color that most of our users will probably have seen and recognize in a similar position. 

In addition to this, I feel that the orange alternative in discussion here too is just a bit much. Looking at our UI, our properties, and how we usually present our Firefox logo closely, you might notice that we don't use those bright oranges at large capacities (usually as accents). 

I hope that clears this reasoning up a bit more.

Comment 24

[Paul [pwd]]

(In reply to Anthony Lam (:antlam) from comment #23)
> Rest assured, this is not an "arbitrary colour choice". The style guide is a
> guide but as you can probably tell, some things in there are not the most up
> to date. Also, we must recognize our context and adapt accordingly, after
> all.
> 
> Allow me to elaborate.
> 
> I see that you feel very passionately about using orange as the banner
> color. But, it's worth pointing out that this "theme" color can represent
> both the brand and the UI (see apps referenced in the screenshots of this
> bug) but it's usually the latter. 
> 
> The dark grey that is depicted there (courtesy of mbrubeck) is actually the
> exact color we use in our tabs tray (the very same color that extends behind
> the "current tab" in our UI). This makes it a color that most of our users
> will probably have seen and recognize in a similar position. 
> 
> In addition to this, I feel that the orange alternative in discussion here
> too is just a bit much. Looking at our UI, our properties, and how we
> usually present our Firefox logo closely, you might notice that we don't use
> those bright oranges at large capacities (usually as accents). 
> 
> I hope that clears this reasoning up a bit more.

Thanks for the response. While bugzilla is a great insight into code, it's seldom the home of design discussion.

I'm not so much passionate about the use of the orange but rather the overall picture of branding and moving Firefox for Android forward. As stated in the styleguide, orange is one of the brand colours and there should be a very good reason to ignore that.

I somewhat anticipated the selection regarding the tabs tray, hence mentioning the problems faced regarding the status bar. While grey has been pivotal in the Holo design, there's a question as to its place in Lollipop.

That particular orange may be a bit too much, but the same could be said about Keep's yellow, Plus's red, Youtube's red, Play's green, Hangouts' green or Twitter's blue. As per the Mozilla styleguide there are alternative yellows for selection that fall in line with the overall branding of Firefox as a whole on both desktop and mobile. Especially given that as previously stated, the App Carousel only accumulates apps and the more that's in there, the more necessary colour is required in order to maintain efficiency. I myself find it easier to find Twitter, Google Plus and Youtube than any of the apps that have yet to embrace Lollipop refinements.

This is certainly a wider discussion as I don't believe this is something that can be looked at in complete isolation. I don't feel we should tack this on to our KitKat refinements. If this is a discussion about our Lollipop refinements, we first need to figure out how our increased action bar will look and behave (see bug 1074220, 1108584, bug 906426, bug 943037 and bug 833607) as we risk the colour of the tabs tray bearing no overall significance to Firefox for Android.

But without a doubt, we're starting from behind on this discussion and I'd like to ensure that Firefox isn't the last over the finishing line.

Comment 25

[Paul [pwd]]

I can't find the bug that someone filed regarding giving each tab it's own spot in the Apps Carousel as per what chrome does, but whether we do that or not, it's worth exploring the idea of giving tabs/the active tab theme-colour control (see bug 1119628 which is another parity-chrome).

Comment 26

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

Sounds like we're in somewhat of an agreement here. We can figure out other mediums for design discussion in the mean time. I know nothing ever works in isolation, so I will continue to keep all those bugs in mind.

But, I don't want to not do anything/ provide anything to users on L while we work on the other aspects of this. Let's re-purpose this bug to something simpler in the interest of getting things moving. 

We can have those larger conversations as a part of Toolbar refinements. 

NI-ing wesj/ mcomella to get this moving (when he gets back heh)

Comment 27

[Paul [pwd]]

(In reply to Anthony Lam (:antlam) from comment #26)
> Sounds like we're in somewhat of an agreement here. We can figure out other
> mediums for design discussion in the mean time. I know nothing ever works in
> isolation, so I will continue to keep all those bugs in mind.
> 
> But, I don't want to not do anything/ provide anything to users on L while
> we work on the other aspects of this. Let's re-purpose this bug to something
> simpler in the interest of getting things moving. 
> 
> We can have those larger conversations as a part of Toolbar refinements. 
> 
> NI-ing wesj/ mcomella to get this moving (when he gets back heh)

Let's start the larger discussion regarding our Lollipop strategy/plans/refinements, get some sort of road map in place and then we can decide whether or not to placate Lollipop users. If we can actually start moving towards where we should be in terms of our Lollipop refinements, we may be able to just release everything at once.

Comment 28

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

Is this the bug we're using to also track parts of our UI where we use "system defaults"? 

It seems we shouldn't hold up on the rest of the UI from inheriting updated styles (menus, drop downs, etc) just for debating about this color.

Comment 29

[Matt Brubeck (:mbrubeck)]

(In reply to Anthony Lam (:antlam) from comment #28)
> Is this the bug we're using to also track parts of our UI where we use
> "system defaults"? 
> 
> It seems we shouldn't hold up on the rest of the UI from inheriting updated
> styles (menus, drop downs, etc) just for debating about this color.

Yes, this patch switches our base theme to "Material" (new system default) on Android 5.

Comment 30

[Wesley Johnston (:wesj)]

Matt, do you want this reviewed? I don't mind landing it.

Comment 31

[Matt Brubeck (:mbrubeck)]

Comment on attachment 8546065 [details] [diff] [review]
patch v2

(In reply to Wesley Johnston (:wesj) from comment #30)
> Matt, do you want this reviewed? I don't mind landing it.

Sure, though if there are any complicated regressions to fix, I'd like to hand it off to a current Fennec developer.

Comment 32

[Wesley Johnston (:wesj)]

Comment on attachment 8546065 [details] [diff] [review]
patch v2

Review of attachment 8546065 [details] [diff] [review]:
-----------------------------------------------------------------

Simple backout if we need to on Aurora, so I'm not too worried. I'll try to make sure its tracking so that we review it in the Aurora uplift meetings.

Comment 33

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

Thanks for pushing this forward, Wes. Let me know if there's anything else to be done to ensure this patch (and it's followups) work correctly.

Comment 34

[Anthony Lam (:antlam) Find me, @antlam on Slack!]

Thanks for getting this moving guys!

Comment 35

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

https://hg.mozilla.org/integration/fx-team/rev/e1035da2a8dd

Comment 36

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

Thanks, Matt! :D

Comment 37

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/e1035da2a8dd