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?

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

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

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

I'm seeing the dark_mode_setting set to 0 correctly in minerva in my testing for some reason, this is in beta @Edtadros

Failure is due to the current issue with the beta cluster (T358393)

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.

If we haven't decided yet, I vote for 'auto', as the field value indicates what it's measuring. If the team has already decided using '2', that's also okay. We can document the meaning of the field value in the data hub. Due to caching, it may take 3-4 weeks until the old instrument fades off. If there are definition changes in the future, we need to assign a new value instead of using the old one, so that we don't have to wait for 4 weeks to start analysis.

I followed up with @jwang on Slack to confirm that we went with "2". Jennifer will update associated documentation.

Test Result - Prod

Status: ✅ PASS
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".
See Below

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"
//See Below

Vector 2022	Minerva