1041904 - [Email] Customize Status Bar Color

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia::E-Mail, defect)

Description

[Michael Henretty [:mikehenrty][:mhenretty]]

For 2.1, each app will have a customized status bar color. Work to support this was completed in bug 1013913 and bug 1033364. Now we must update each of the apps with the appropriate meta tags as specified in the visual spec:

https://bug1041625.bugzilla.mozilla.org/attachment.cgi?id=8460033

Comment 1

[Michael Henretty [:mikehenrty][:mhenretty]]

Attachment: [Gaia PR] add theme color for email

Adding theme for email accord to spec: https://bug1041625.bugzilla.mozilla.org/attachment.cgi?id=8470321

Comment 2

[Michael Henretty [:mikehenrty][:mhenretty]]

Attachment: [screenshot] Email theme

Just to verify with you Eric, this is the weirdness we see with theme's in email when first setting up. I wanted to make sure you saw this before we land.

Comment 3

[James Burke [:jrburke]]

Comment on attachment 8471241 [details] [review]
[Gaia PR] add theme color for email

Stealing from :asuth since he is deep in some backend changes.

Comment 4

[James Burke [:jrburke]]

Comment on attachment 8471242 [details]
[screenshot] Email theme

Talking with :mhenretty, I am going to attempt a fix that set the color correctly if in this sort of setup card state. That would fix this specific case. 

However, even with that, we do have a card transition in the app where we go from orange header to the white header, when opening the email drawer, then going to account settings.

So it would still be good to get ui-review on what behavior is desired. I am going to assume that the change in status background should be done to match the card coloring for now.

Comment 5

[Michael Henretty [:mikehenrty][:mhenretty]]

Eric, see comment 4 ^^. James want to make the statusbar color dynamic for email based on the current card state. Do you see an problems with this?

Comment 6

[James Burke [:jrburke]]

Posted to dev-gaia, inquiring about some sort of "auto" or "sample" value for that meta tag, so that the platform could use the first pixel header color and automatically adjust to that, instead of the app manually tracking the color state:

https://groups.google.com/forum/#!topic/mozilla.dev.gaia/_EjGYlbaDZw

Comment 7

[Eric Pang [:epang] UX]

(In reply to Michael Henretty [:mhenretty] from comment #5)
> Eric, see comment 4 ^^. James want to make the statusbar color dynamic for
> email based on the current card state. Do you see an problems with this?

Yes, this would be ideal - the orange status bar looks odd on the light grey.  We just need to make sure other elements change as well such as the status bar icons, RB opacity, RB text, etc.  This screen should follow the specs of a settings screen.  Hope this is all possible, thanks!

Comment 8

[James Burke [:jrburke]]

After looking into this more, I think this is difficult to do reliably. I tried a quick branch to confirm the issues. I started a discussion on dev-gaia about perhaps having the platform do the work:

https://groups.google.com/forum/#!topic/mozilla.dev.gaia/_EjGYlbaDZw

But in the end, for the animation of the color in the status bar to look good, the meta tag needs to change before tansitions occur, but it is hard to know always what that next color will be, since sometimes the platform, not the app, is involved. See third post in that thread for more info. As that third post ends:

Can we keep the color stable across all views in an app, with the idea that the background color is more about giving the app an identity based on its icon, and the user a sense of place, vs giving the impression that the status bar is just an overlay on content that stretches to every corner of the screen. That, or just keep the status bar black?

Comment 9

[Eric Pang [:epang] UX]

(In reply to James Burke [:jrburke] from comment #8)
> After looking into this more, I think this is difficult to do reliably. I
> tried a quick branch to confirm the issues. I started a discussion on
> dev-gaia about perhaps having the platform do the work:
> 
> https://groups.google.com/forum/#!topic/mozilla.dev.gaia/_EjGYlbaDZw
> 
> But in the end, for the animation of the color in the status bar to look
> good, the meta tag needs to change before tansitions occur, but it is hard
> to know always what that next color will be, since sometimes the platform,
> not the app, is involved. See third post in that thread for more info. As
> that third post ends:
> 
> Can we keep the color stable across all views in an app, with the idea that
> the background color is more about giving the app an identity based on its
> icon, and the user a sense of place, vs giving the impression that the
> status bar is just an overlay on content that stretches to every corner of
> the screen. That, or just keep the status bar black?

In this case let's leave the status bar as the app colour (orange in this case).  In the future I'm hoping we'll be able to find a way to change it depending on the background/header.  Thanks for trying it out James!

Comment 10

[Eric Pang [:epang] UX]

(In reply to Eric Pang [:epang] from comment #9)
> (In reply to James Burke [:jrburke] from comment #8)
> > After looking into this more, I think this is difficult to do reliably. I
> > tried a quick branch to confirm the issues. I started a discussion on
> > dev-gaia about perhaps having the platform do the work:
> > 
> > https://groups.google.com/forum/#!topic/mozilla.dev.gaia/_EjGYlbaDZw
> > 
> > But in the end, for the animation of the color in the status bar to look
> > good, the meta tag needs to change before tansitions occur, but it is hard
> > to know always what that next color will be, since sometimes the platform,
> > not the app, is involved. See third post in that thread for more info. As
> > that third post ends:
> > 
> > Can we keep the color stable across all views in an app, with the idea that
> > the background color is more about giving the app an identity based on its
> > icon, and the user a sense of place, vs giving the impression that the
> > status bar is just an overlay on content that stretches to every corner of
> > the screen. That, or just keep the status bar black?
> 
> In this case let's leave the status bar as the app colour (orange in this
> case).  In the future I'm hoping we'll be able to find a way to change it
> depending on the background/header.  Thanks for trying it out James!

Would it be possible if we set the colour value for the status bar on these screens as opposed to checking the next colour?  Cause we already know what the colour will be.  Let me know, thanks!

Comment 11

[James Burke [:jrburke]]

(In reply to Eric Pang [:epang] from comment #10)
> Would it be possible if we set the colour value for the status bar on these
> screens as opposed to checking the next colour?  Cause we already know what
> the colour will be.  Let me know, thanks!

I am not sure I follow. Do you mean dynamically set the colour once a card is displayed, for every card, or set it to a specific colour just for the New Account case when no accounts are configured, but the orange color otherwise?

Comment 12

[Eric Pang [:epang] UX]

(In reply to James Burke [:jrburke] from comment #11)
> (In reply to Eric Pang [:epang] from comment #10)
> > Would it be possible if we set the colour value for the status bar on these
> > screens as opposed to checking the next colour?  Cause we already know what
> > the colour will be.  Let me know, thanks!
> 
> I am not sure I follow. Do you mean dynamically set the colour once a card
> is displayed, for every card, or set it to a specific colour just for the
> New Account case when no accounts are configured, but the orange color
> otherwise?

Hi James, sorry for the confusion.  I meant the later, setting the New Account page as light grey while the reset of the app is orange.

Comment 13

[Eric Pang [:epang] UX]

(In reply to Eric Pang [:epang] from comment #12)
> (In reply to James Burke [:jrburke] from comment #11)
> > (In reply to Eric Pang [:epang] from comment #10)
> > > Would it be possible if we set the colour value for the status bar on these
> > > screens as opposed to checking the next colour?  Cause we already know what
> > > the colour will be.  Let me know, thanks!
> > 
> > I am not sure I follow. Do you mean dynamically set the colour once a card
> > is displayed, for every card, or set it to a specific colour just for the
> > New Account case when no accounts are configured, but the orange color
> > otherwise?
> 
> Hi James, sorry for the confusion.  I meant the later, setting the New
> Account page as light grey while the reset of the app is orange.

meant rest not reset :)

Comment 14

[James Burke [:jrburke]]

Thinking more about this: the New Account page can show up after the account is configured: Tap the hamburger icon, then the settings icon, then Add Account. So initially the UI has an orange banner, but then converts to a white one once New Account is hit (or is it when Mail Settings is shown, a white card?).

Plus, the user, after filling in the form, could go to Manual Configuration. There are also a few white-based screens as part of the account flow, including a "confirmation" style dark background card before the finishing of the flow, which has a white card after that.

So I am unclear on when the switch from white to orange should occur. Any choice I can think of seems to result in at least one card looking weird depending on entry point/flow and when the color switches.

If your general desire is to "just avoid orange on the white, it is OK if orange is there for non-white cards, or for a confirm/dark card every so often, and sometimes that those might have a white status color if part of a white card flow", I can try to work up a patch based on that, but will likely ask for review of the experience before landing given the above. 

It would be more straightforward to just set the color once so all cards are the same (black works for all the cards :), but I am happy to try some experiments.

Comment 15

[Eric Pang [:epang] UX]

(In reply to James Burke [:jrburke] from comment #14)
> Thinking more about this: the New Account page can show up after the account
> is configured: Tap the hamburger icon, then the settings icon, then Add
> Account. So initially the UI has an orange banner, but then converts to a
> white one once New Account is hit (or is it when Mail Settings is shown, a
> white card?).

It would be when the Mail Settings is shown (as soon at the header turns to light grey)

> 
> Plus, the user, after filling in the form, could go to Manual Configuration.
> There are also a few white-based screens as part of the account flow,
> including a "confirmation" style dark background card before the finishing
> of the flow, which has a white card after that.

I believe Rob/Michael are working to have the confirmation screens completely cover the status bar so we can avoid this problem and not worry about the colour of the status bar.

> 
> So I am unclear on when the switch from white to orange should occur. Any
> choice I can think of seems to result in at least one card looking weird
> depending on entry point/flow and when the color switches.

The switch should happen based on the header colour.  A fading transition from one colour to the other will probably be needed so it looks smooth (both the status bar background colour and status bar icons will need to change).
Pretty much going between 'productivity' and 'settings' in this spec on box:
https://mozilla.box.com/s/6a3zw86uyu27slbk4yc8
> 
> If your general desire is to "just avoid orange on the white, it is OK if
> orange is there for non-white cards, or for a confirm/dark card every so
> often, and sometimes that those might have a white status color if part of a
> white card flow", I can try to work up a patch based on that, but will
> likely ask for review of the experience before landing given the above. 
> 
This sounds good, would be great to see what can be done :)

> It would be more straightforward to just set the color once so all cards are
> the same (black works for all the cards :), but I am happy to try some
> experiments.

I think if we have to stick with one colour for all cards we'll most likely need to stick with orange since the majority of the app has an orange banner.  But I'm hoping something can be done since the white headers look a little strange with the orange SB :).  Thanks James!

Comment 16

[James Burke [:jrburke]]

Attachment: GitHub pull request

This is a work in progress pull request no dev review needed yet. 

I created a zip file of the app:

http://jrburke.com/work/gaia/email-statuscolor.zip

which can be installed on Flame phones using instructions like the ones here:

https://github.com/jrburke/gaia-dev-zip#for-the-ux-person

:epang, can you review the behavior to see if that is the desired effect? It is a bit noticeable that the color changes. I set the color change before the email card transition starts. Except for initial startup, where we need to figure out the card first and that card is immediately displayed before transitioning in. Also, there are some dialogs that immediately display too.

In general, getting the system alert/confirm dialogs to properly set the color will not have a direct impact in email's case as we have avoided them since they interfere with messaging/notifications from other apps. But I tied the div-based dialogs we use into this status color code.

In any case, if this is the desired effect, then I will tighten up the code and proceed with review. Be sure to try the buttons in bulk edit mode from the message list, and doing things like replying to a message, starting a compose, wirting some text, then going back, and then navigating through the mail settings areas.

Comment 17

[Eric Pang [:epang] UX]

(In reply to James Burke [:jrburke] from comment #16)
> Created attachment 8474045 [details] [review]
> GitHub pull request
> 
> This is a work in progress pull request no dev review needed yet. 
> 
> I created a zip file of the app:
> 
> http://jrburke.com/work/gaia/email-statuscolor.zip
> 
> which can be installed on Flame phones using instructions like the ones here:
> 
> https://github.com/jrburke/gaia-dev-zip#for-the-ux-person
> 
> :epang, can you review the behavior to see if that is the desired effect? It
> is a bit noticeable that the color changes. I set the color change before
> the email card transition starts. Except for initial startup, where we need
> to figure out the card first and that card is immediately displayed before
> transitioning in. Also, there are some dialogs that immediately display too.
> 
> In general, getting the system alert/confirm dialogs to properly set the
> color will not have a direct impact in email's case as we have avoided them
> since they interfere with messaging/notifications from other apps. But I
> tied the div-based dialogs we use into this status color code.
> 
> In any case, if this is the desired effect, then I will tighten up the code
> and proceed with review. Be sure to try the buttons in bulk edit mode from
> the message list, and doing things like replying to a message, starting a
> compose, wirting some text, then going back, and then navigating through the
> mail settings areas.

Hey James, this looks amazing!  

Regarding the bulk edit mode - I'm hoping that this dialogue will eventually cover the entire screen, but if it can't the solution you've created is a good back up.

Only one issue I'm seeing, are the status bar icons set to be opposite, right now the light icons show when the dark should be showing and vice versa.

Thanks for all you're work on this, I'm really happy with the result :)

Comment 18

[James Burke [:jrburke]]

OK, I will formalize this change and land it for the email app.

On the confirmation screen from bulk edit (like from selecting trash can), we purposely went away from default confirm() or alert() boxes since they seemed to mess with the events we would receive from events like activities or notifications that wanted to transition the email app to different states. Background on that issue is in bug 985598. There is also concern about extra text noise for those types of calls, described in bug 959303.

There is a "fullscreen" option for apps, either via manifest[1] or via JS[2]. However, I do not believe the manifest pathway is desired (unlike camera, we likely want to show the status bar in email), and toggling fullscreen mode in JS will likely be more jarring as it means the web UI may need to adjust for that transition. At the very least it is likely another transition to add to the mix. 

Maybe longer term it may worth asking for some option on this status-color meta tag that would allow us to say "just show this background color without shading or icons". That likely needs a larger UX-dev conversation though. For this specific bug, I will focus on landing what I have so far to close it out.

I noticed the icon color issue too. Once I land this this change for email, I will file a bug with the system app about it. The only toggle I know of for an app to use is the background color, and I assume the status bar code decides to switch out the colors based on some color thresholds.

Comment 19

[James Burke [:jrburke]]

Comment on attachment 8474045 [details] [review]
GitHub pull request

UX review has been done, so I cleaned up the pull request, and added more docs to the pull request and in-code for the API. Starting dev review now.

Comment 20

[Andrew Sutherland [:asuth] (he/him)]

Comment on attachment 8474045 [details] [review]
GitHub pull request

r=asuth by inspection.

aside: The Cards.setStatusColor(blah) calls seems like useful markers for where thing are non-card things that need to be cards!  Which I suspect you're painfully aware of, since you had to put those markers there! :)

Comment 21

[James Burke [:jrburke]]

Definitely want to move those things into cards. I want to land bug 1005446 first though, as its quite disruptive for me to keep that pull request fresh with other front end changes, and writing new cards should be easier with those changes in place.

For this bug, merged into gaia master:
https://github.com/mozilla-b2g/gaia/commit/f6cdbd265a34dd73bc607c403e866c4230eb6a11

from pull request:
https://github.com/mozilla-b2g/gaia/pull/22947

Comment 22

[Edward Chen[:edchen]]

[Environment]
Gaia      e424c85eda87a40c0fa64d6a779c3fa368bf770b
Gecko     https://hg.mozilla.org/mozilla-central/rev/daa84204a11a
BuildID   20140824160205
Version   34.0a1
ro.build.version.incremental=94
ro.build.date=Tue May 20 09:29:20 CST 2014

[Result]
PASS