[VsD Refresh] Lockscreen Visual Refresh > Notifications background colour picker looks too light

RESOLVED FIXED in Firefox OS v2.0

Status

Firefox OS
Gaia::System::Lockscreen
P1
normal
RESOLVED FIXED
4 years ago
4 years ago

People

(Reporter: amylee, Assigned: mnjul)

Tracking

unspecified
2.0 S4 (20june)
ARM
Gonk (Firefox OS)

Firefox Tracking Flags

(blocking-b2g:-, feature-b2g:-, b2g-v2.0 fixed, b2g-v2.1 fixed)

Details

(Whiteboard: ux-tracking, visual design, visual-tracking, bokken [p=1])

Attachments

(3 attachments)

(Reporter)

Description

4 years ago
Created attachment 8437836 [details]
2014-06-10-14-18-52.png

Hi, 

Can the colour picker be checked to make sure that it is 70% opacity and 50% brightness? The overlay looks a bit on the lighter side.
(Reporter)

Updated

4 years ago
Whiteboard: ux-tracking, visual design, jian [fxos:media] → ux-tracking, visual design, jian [fxos:media]ux-tracking, visual design, visual-tracking, bokken [p=2]
(Reporter)

Updated

4 years ago
Whiteboard: ux-tracking, visual design, jian [fxos:media]ux-tracking, visual design, visual-tracking, bokken [p=2] → ux-tracking, visual design, visual-tracking, bokken [p=2]
(Reporter)

Updated

4 years ago
Summary: [VsD Refresh] Lockscreen Visual Refresh > Notifications background colour picker not working → [VsD Refresh] Lockscreen Visual Refresh > Notifications background colour picker looks too light
Assignee: nobody → jlu
Created attachment 8438237 [details]
wallpapers_notification_overlays.png

Hi Amy,

The overlay is fixed at 70% opacity.

Currently, the color averaging algorithm does not modify the lightness of resulting color; you get a dark overlay for a dark wallpaper, and a bright overlay for a bright wallpaper. So, since different wallpapers have different brightness by their own, I'm not exactly sure what we should do with "50% brightness". Do we want to :
1. Fix the lightness of resulting color at 50% (overlay for very-dark wallpapers may look quite brighter)
or
2. Decrease the calculated lightness by 10% (overlay will always look a bit darker than wallpaper)
(Note that the default wallpaper's calculated lightness is 55%, so this approach would make the resulting lightness about 50%)

I have attached the results of some different overlay lightness for different wallpapers, please check. Thanks!
Flags: needinfo?(amlee)
blocking-b2g: --- → 2.0?
(Reporter)

Comment 2

4 years ago
(In reply to John Lu [:mnjul] @MoCoTaipei from comment #1)
> Created attachment 8438237 [details]
> wallpapers_notification_overlays.png
> 
> Hi Amy,
> 
> The overlay is fixed at 70% opacity.
> 
> Currently, the color averaging algorithm does not modify the lightness of
> resulting color; you get a dark overlay for a dark wallpaper, and a bright
> overlay for a bright wallpaper. So, since different wallpapers have
> different brightness by their own, I'm not exactly sure what we should do
> with "50% brightness". Do we want to :
> 1. Fix the lightness of resulting color at 50% (overlay for very-dark
> wallpapers may look quite brighter)
> or
> 2. Decrease the calculated lightness by 10% (overlay will always look a bit
> darker than wallpaper)
> (Note that the default wallpaper's calculated lightness is 55%, so this
> approach would make the resulting lightness about 50%)
> 
> I have attached the results of some different overlay lightness for
> different wallpapers, please check. Thanks!

Hi John, 

I would go with option 2, decreasing the calculated lightness by 10%. Thanks a lot, much appreciated :-)
Flags: needinfo?(amlee)
Created attachment 8438869 [details] [review]
Patch

Hi Tim,

Could you review this trivial patch for me? Thanks :D
Attachment #8438869 - Flags: review?(timdream)
Attachment #8438869 - Flags: review?(timdream) → review+
Master: https://github.com/mozilla-b2g/gaia/commit/212c738afccf96c009354ab299fc948edc49e380
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Whiteboard: ux-tracking, visual design, visual-tracking, bokken [p=2] → ux-tracking, visual design, visual-tracking, bokken [p=1]
Please note that the picker is currently broken due to bug 1024395
This is a polish issues, not something we would block a release ok, please seek approval here to consider it for 2.0 uplift.
blocking-b2g: 2.0? → -

Comment 7

4 years ago
Bhavana, we need to revisit these calls. A few weeks ago, I was told to block the 2.0 visual refresh with the feature-b2g flag on the meta bugs, because the entire visual refresh by definition blocks 2.0. Now I see individual bugs that are part of the 2.0 visual refresh being minused or termed not blocking, and referred to as polish, when they're actually a blocker. Let's just figure out a systematic way to proceed so that all pieces of the visual refresh block and ship as expected. Thank you!
Blocks: 1024845
(In reply to Stephany Wilkes from comment #7)
> Bhavana, we need to revisit these calls. A few weeks ago, I was told to
> block the 2.0 visual refresh with the feature-b2g flag on the meta bugs,
> because the entire visual refresh by definition blocks 2.0. Now I see
> individual bugs that are part of the 2.0 visual refresh being minused or
> termed not blocking, and referred to as polish, when they're actually a
> blocker. Let's just figure out a systematic way to proceed so that all
> pieces of the visual refresh block and ship as expected. Thank you!

We need to identify the minimum work required for visual refresh to land at this point in the release cycle, and hence I emailed UX to help identify those pieces among all the Lockscreen issues. Based on how all these bugs read, all of these are definitely not blockers to shipping the release. Feel free to bring bugs to triage if we are not in agreement on the blocking call.
No longer blocks: 1024845

Comment 9

4 years ago
So just to be clear - before I create this bug flood: every single bug required for VR 2.0 to be complete should get a blocking-b2g? flag. Please confirm.
(In reply to Stephany Wilkes from comment #9)
> So just to be clear - before I create this bug flood: every single bug
> required for VR 2.0 to be complete should get a blocking-b2g? flag. Please
> confirm.

* Set Blocking if we would block a release on it using the same guidelines as here: https://wiki.mozilla.org/B2G/Triage#Blocker_Triage_Guidelines
* If all these are VR 2.0 bugs are feature/user story misses, I would like to know why were these not called out before, as we have given exceptions to some features which block the release and did not make the FL milestone. This feature work is being tracked as feature-b2g and goes through approval process to get uplifted on the branch

Stephany, if there are further questions, I recommend we take this process discussion offline outside of this bug.
Comment on attachment 8438869 [details] [review]
Patch

NOTE: Please see https://wiki.mozilla.org/Release_Management/B2G_Landing to better understand the B2G approval process and landings.

[Approval Request Comment]

[Bug caused by] (feature/regressing bug #): bug 1023448 was due to UX thinking that implementation of bug 950884 and bug 1020115 is not perfect and needs minor polish-ups

[User impact] if declined: low, just visual issues

[Testing completed]: Yes.

[Risk to taking this patch] (and alternatives if risky): low, as there is just one line of JS to modified computed color lightness by 90% multiplication factor

[String changes made]: None
Attachment #8438869 - Flags: approval-gaia-v2.0?

Updated

4 years ago
status-b2g-v2.0: --- → affected
status-b2g-v2.1: --- → fixed

Updated

4 years ago
Attachment #8438869 - Flags: approval-gaia-v2.0? → approval-gaia-v2.0+
v2.0: https://github.com/mozilla-b2g/gaia/commit/4861367d326b2fa2c3358d383051cf6969714433
status-b2g-v2.0: affected → fixed
Target Milestone: --- → 2.0 S4 (20june)
(Reporter)

Updated

4 years ago
feature-b2g: --- → -
(Reporter)

Updated

4 years ago
feature-b2g: - → ---
(Reporter)

Updated

4 years ago
feature-b2g: --- → -
You need to log in before you can comment on or make changes to this bug.