Page MenuHomePhabricator

Update WikimediaEvents "is_dark_mode_on" field
Open, HighPublic3 Estimated Story Points

Description

Current State: The "is_dark_mode_on" field in the Wikimedia Event Emitters is hardcoded to default to false, which doesn't accurately reflect the user's current browsing environment.
Proposed Update: Modify the WikimediaEvents webAccessibility.js to dynamically capture the dark mode status of the webpage by extracting it from the relevant HTML property.
SC: The event emitters provide precise information about the user's dark mode preferences.

UPDATE: We are deprecating is_dark_mode_on and using dark_mode_setting instead.

Testing Instructions:
Event Firing Verification - Night Mode Enabled:
Steps:

  1. Enable dark mode on the webpage.
  2. Monitor the emitted events in Network Tab.
  3. Verify that the "dark_mode_setting" field in the event object is set to "1".

Event Firing Verification - Night Mode Disabled:

Steps:

  1. Disable dark mode on the webpage.
  2. Monitor the emitted events in Network Tab.
  3. Verify that the "dark_mode_setting" field in the event object is set to "0"

https://phabricator.wikimedia.org/

QA Results - Beta

ACStatusDetails
1T356335#9574126
2T356335#9574126

Event Timeline

Hey @jwang , @Jdlrobson and I have discussed adding the script to determine if the page is in dark mode, as we are now able to set this. Currently, it's hardcoded to false (is_dark_mode_on: false), but we want to make it configurable as true or false. However, we're unsure how to handle the case when dark mode is set to automatic. Should the script return true or false in this scenario? What would be the most useful approach for you to analyze the data?

Jdlrobson set the point value for this task to 3.Thu, Feb 1, 6:35 PM

To elaborate on automatic mode:

  • We currently log is_dark_mode_preferred_by_operating_system AND is_dark_mode on.
  • When "Off" has been selected the user will see dark mode even when "is_dark_mode_preferred_by_operating_system" is true. is_dark_mode will be False.
  • When "On" has been selected the user will see dark mode regardless of the value of is_dark_mode_preferred_by_operating_system, is_dark_mode will be True.
  • When "Automatic" has been selected the user will see dark mode if "is_dark_mode_preferred_by_operating_system". It won't see dark mode if not. is_dark_mode will be ___ ?

Options off the top of my head are:

  1. We change is_dark_mode to a string which is either 0, 1 or auto.
  2. We make is_dark_mode always reflect whether dark mode is enabled (but it won't be possible to tell if they are using auto mode or On mode to get that)
  3. We make is_dark_mode null when auto is selected. (probably the easiest option)

Hi, thank you for bringing up and clarifying that.

To calculate the non-default rate, it would be better for is_dark_mode to reflect the user’s option selections on our website. Given that, I think the option1 you proposed, i.e., is_dark_mode set to a string value, either '0', '1', or 'auto', serves the purpose best.

I have a minor question regarding the string value of is_dark_mode. Could it be 'on', 'off', or 'auto'? Since we are using a string type, 'on' and 'off' would be easier to interpret than '0' and '1'.

To calculate the non-default rate, it would be better for is_dark_mode to reflect the user’s option selections on our website. Given that, I think the option1 you proposed, i.e., is_dark_mode set to a string value, either '0', '1', or 'auto', serves the purpose best.

Okay this would require a schema change (as we'd be switching from a boolean to a string) which in the past have been a little risky so we'll need to factor that into the task and QA more closely.
The is_dark_mode_prepared_by_os field would stay a boolean - is that okay? Perhaps if we are changing the schema we could also fix the typo in the name (change to is_dark_mode_preferred_by_os) ?

I have a minor question regarding the string value of is_dark_mode. Could it be 'on', 'off', or 'auto'? Since we are using a string type, 'on' and 'off' would be easier to interpret than '0' and '1'.

Yes, if we are switching to use a string that would be fine.

@Jdlrobson @jwang Could we use "2" instead of "auto"? This way the value saved is the same as the client pref value

Change 1005149 had a related patch set uploaded (by Kimberly Sarabia; author: Kimberly Sarabia):

[schemas/event/secondary@master] Updates web accessibility schema

https://gerrit.wikimedia.org/r/1005149

Change 1005134 had a related patch set uploaded (by Bernard Wang; author: Bernard Wang):

[mediawiki/extensions/WikimediaEvents@master] Make is_dark_mode field not hardcoded

https://gerrit.wikimedia.org/r/1005134

bwang removed bwang as the assignee of this task.Tue, Feb 20, 8:32 PM
bwang moved this task from Doing to Code Review on the Web-Team-Backlog (FY2023-24 Q3 Sprint 3) board.
bwang added a subscriber: bwang.

Schema-wise, we are not technically allowed to make type changes. Apologies for missing this. This is why the patch to update the schema is currently failing. It's recommended we make an entirely new field if we are to make a type change.

Some options
dark_mode_status
dark_mode_pref

@bwang @Jdlrobson @jwang Please drop your thoughts on here whenever you have a chance.

Fine with me. I'll defer to Jennifer about 2 vs auto. I think it's better to do 2 personally in case these definitions ever change in future this will be more resilient to change.

Change 1005149 abandoned by Kimberly Sarabia:

[schemas/event/secondary@master] Updates web accessibility schema

Reason:

I'm going to make a new patch because I need to run build using our new solution with a new field

https://gerrit.wikimedia.org/r/1005149

Change 1005201 had a related patch set uploaded (by Kimberly Sarabia; author: Kimberly Sarabia):

[schemas/event/secondary@master] Adds new field to webA11y schema

https://gerrit.wikimedia.org/r/1005201

@Jdlrobson and @bwang and I chatted about this and the condition in this patch just needs to be updated to '0'

Change 1005201 merged by jenkins-bot:

[schemas/event/secondary@master] Adds new field to webA11y schema

https://gerrit.wikimedia.org/r/1005201

Change 1005134 merged by jenkins-bot:

[mediawiki/extensions/WikimediaEvents@master] Add dark_mode_setting field and make is_dark_mode field not hardcoded

https://gerrit.wikimedia.org/r/1005134

KSarabia-WMF assigned this task to Edtadros.
KSarabia-WMF updated the task description. (Show Details)

Change 1006016 had a related patch set uploaded (by Kimberly Sarabia; author: Kimberly Sarabia):

[mediawiki/extensions/WikimediaEvents@master] Update mobile schema version

https://gerrit.wikimedia.org/r/1006016

Change 1006016 merged by jenkins-bot:

[mediawiki/extensions/WikimediaEvents@master] Update mobile schema version

https://gerrit.wikimedia.org/r/1006016

Edtadros added a subscriber: Edtadros.

Test Result - Beta

Status: ❌ FAIL
Environment: beta
OS: macOS Sonoma
Browser: Chrome
Device: MBA
Emulated Device:NA

Test Artifact(s):

QA Steps

Event Firing Verification - Night Mode Enabled:

Enable dark mode on the webpage.
Monitor the emitted events in Network Tab.
✅ AC1: Verify that the "dark_mode_setting" field in the event object is set to "1".
Vector

screenshot 557.png (359×872 px, 74 KB)

Minerva
screenshot 558.png (355×837 px, 76 KB)

Event Firing Verification - Night Mode Disabled:

Disable dark mode on the webpage.
Monitor the emitted events in Network Tab.
❌ AC2: Verify that the "dark_mode_setting" field in the event object is set to "0"
This doesn't appear to be saving the Day mode option when logged in.