from @Catrope in Slack:

It looks like it's not used by Minerva itself, but there are other extensions that use it, and you can presumably view those pages using the Minerva skin (the Growth team's newcomer homepage for example)

For this task I'd be curious to hear from @dst-designers what they think about using the Dialog as a notification in this way, or if they think a different component should be used (whatever that would be probably isn't implemented yet though)

Relatedly, there's no explicit technical documentation for how to open a dialog without user interaction. But that shouldn't be too difficult to figure out, and we can help with that if needed.

@JScherer-WMF The Dialog is a great component for this purpose. Regarding colors, we are currently working through the decision tokens for night mode, but what you have is essentially what we're thinking. The one difference would be that the Primary Progressive Button should be the same style/colors as it is in day mode.

Rendering Codex Dialog's requires pulling down additional JavaScript and CSS that isn't loaded on page load so this has some performance implications to think through. With this in mind I'd suggest limiting the audience somewhat and delaying the display.

Would any of the following options work for this?:

• Display the dialog on 2nd or 3rd page view (at this point most JavaScript and CSS should be in cache
• Delay the overlay display until a certain time has passed e.g. after 5 seconds
• Show the dialog only on the main page
• Show the dialog after the user has scrolled down the page a certain amount
• Show the dialog on a % of page views. For example 1 in 100 page views has a chance of displaying the dialog.
• Limiting the dialog to logged in users.

If it's not a significant change in scope, I'd like to propose using the onboarding dialog variant with the illustration/image.

In T361047#9682954, @Jdlrobson wrote:

Rendering Codex Dialog's requires pulling down additional JavaScript and CSS that isn't loaded on page load so this has some performance implications to think through. With this in mind I'd suggest limiting the audience somewhat and delaying the display.

Would any of the following options work for this?:

• Display the dialog on 2nd or 3rd page view (at this point most JavaScript and CSS should be in cache
• Delay the overlay display until a certain time has passed e.g. after 5 seconds
• Show the dialog only on the main page
• Show the dialog after the user has scrolled down the page a certain amount
• Show the dialog on a % of page views. For example 1 in 100 page views has a chance of displaying the dialog.
• Limiting the dialog to logged in users.

The scroll option could work. If it's a very small amount of scrolling, so that it's almost instant for most people.

@JScherer-WMF @ovasileva need to finalize copy/illustration.

Medium confidence estimate as there are still some unanswered questions - @SToyofuku-WMF to return and document what was confusing to us in the hopes that it can get cleared up before we move to ready for development

Notes from estimation meeting:

1. It would be great if we could split up this ticket as it feels like a number of different steps
2. We still need to finalize the circumstances under which we will lazy load the resources
3. Ideally we would use the dialog with the image as it looks better and helps with comprehension
4. For users whose system is in night mode already, we really need to show them the dialog as soon as possible
5. We should agree on how to store that the user has seen and dismissed the dialog

In T361047#9682954, @Jdlrobson wrote:

Rendering Codex Dialog's requires pulling down additional JavaScript and CSS that isn't loaded on page load so this has some performance implications to think through. With this in mind I'd suggest limiting the audience somewhat and delaying the display.

Would any of the following options work for this?:

• Display the dialog on 2nd or 3rd page view (at this point most JavaScript and CSS should be in cache
• Delay the overlay display until a certain time has passed e.g. after 5 seconds
• Show the dialog only on the main page
• Show the dialog after the user has scrolled down the page a certain amount
• Show the dialog on a % of page views. For example 1 in 100 page views has a chance of displaying the dialog.
• Limiting the dialog to logged in users.

When the reader has enrolled in night mode automatically and didn't turn it on themselves, we need to show the dialogue as soon as possible. I'll leave it to the devs to determine which of the above scenarios gets us the dialog fastest without negative loadtime impact.

When the reader has a day mode device and we want to promote the feature to them, showing the dialogue on the second page load in a session is alright.

The video about Minerva night mode launch notification design is a good thing. It's certainly very technical, but I think this kind of initiative can help communities to understand the thought process and should be more promoted.

Change #1035792 had a related patch set uploaded (by Jdrewniak; author: Jdrewniak):

[mediawiki/skins/MinervaNeue@master] fCreate dark-mode launch banner component

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

The first patch submitted above creates a modal per the design spec .It uses Codex and Vue so the implementation is pretty straight forward. This is what it looks like so far:

The engineering team has been discussing the performance implications of loading Vue.js for this banner, so we might opt for a version using the CSS-only Codex components. With Vue.js, the payload is quite high, it's about 131kB (gzipped!). The flip-side of this argument is that this modal will only ever be loaded once for any user, ever, so maybe the performance hit isn't such a big issue (131kB still seems like quite a bit).

That loading requirement of showing this banner only once for any user is critical. If someone closes this banner and sees it again on a subsequent pageload, I would consider that a UBN, so we want to implement the persistence logic to avoid that scenario at all costs.

We could implement that logic ourselves, but I'm considering running this as a CentralNotice campaign. When discussing this idea with the rest of engineering team, CentralNotice was dismissed because we'd prefer to use localStorage instead of cookies as the persistence layer (localStorage is more resilient than cookies).

I recently discovered that CentralNotice has a feature called "Impression Diet" where it can show a banner only once per user, and that feature does use localStorage under the hood, so I'd like to explore that option further before rolling our own logic. The benefit of that approach would be that we'd be able to instantly turn the campaign on or off if needed.

Instead of adding HTML as a banner, the code would be a script tag that would load the launch component like so:

<script>
mw.loader.using( 'skins.minerva.DarkModeLaunchBanner', r => r( 'skins.minerva.DarkModeLaunchBanner')() );
</script>

Change #1035792 merged by jenkins-bot:

[mediawiki/skins/MinervaNeue@master] Create dark-mode launch banner component

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

Change #1036709 had a related patch set uploaded (by Jdrewniak; author: Jdrewniak):

[mediawiki/skins/MinervaNeue@master] [POC] Dark-mode launch banner wiring

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

After talking with the team, we think running this modal as a CentralNotice banner is easier and less risky than rolling our own loading logic.
(If that turns out not to be the case, I made a POC of the loading & persistence logic in Minerva in the patch above).

The benefits of using CentralNotice for this modal:

1. Presentation and persistence logic has already been thoroughly tested
2. Fine-grained control over when & where we want to display the modal (and and instant off-switch if we have to disable the modal for any reason)
3. Less temporary code in Minerva (no need for extra configuration key or feature-wiring code)

The code for this banner would consist of the following script:

<script> 
    const CNContext = mw.centralNotice.kvStore.contexts.GLOBAL;
    const CNBannerKey = 'impression_diet_minerva-dark-mode-banner';
    const impressions = mw.centralNotice.kvStore.getItem( CNBannerKey, CNContext );
    const matchMediaDark = window.matchMedia( '(prefers-color-scheme: dark)' );
    const clientPrefDark = document.documentElement.classList.contains( 'skin-theme-clientpref-night' );
    const clientPrefAuto = document.documentElement.classList.contains( 'skin-theme-clientpref-auto' );
    const isPageInDarkMode = ( clientPrefDark || ( clientPrefAuto && matchMediaDark ) );

    if ( isPageInDarkMode && impressions.seenCount === 1 ) {
        mw.loader.using( 'skins.minerva.DarkModeLaunchBanner', function( require ) {
            require( 'skins.minerva.DarkModeLaunchBanner')();
        } );
    }

    if ( !isPageInDarkMode && impressions.seenCount === 2 ) {
        mw.loader.using( 'skins.minerva.DarkModeLaunchBanner', function( require ) {
            require( 'skins.minerva.DarkModeLaunchBanner')();
        } );
    }
</script>

We'd want to run this banner only on mobile devices.

The key to achieving the requirement of "only showing the banner once" is to create a campaign with the impression diet feature like so:

The identifier for client-side storage should be: minerva-dark-mode-banner
Maximum impressions any individual will see should be: 2 - this is to satisfy the requirement of showing the banner on the second page view for users in day-mode.

@sgrabarczuk can you help set up a campaign like this? possibly on a closed wiki for testing purposes?

With @sgrabarczuk's help, we've created a banner that loads the notification:
https://meta.wikimedia.org/wiki/Main_Page?banner=sgrabarczuk_test
The next phase of this work involves creating and testing (and eventually enabling) the campaign to show this banner. That work is now captured in T366296.

Change #1036709 abandoned by Jdrewniak:

[mediawiki/skins/MinervaNeue@master] [POC] Dark-mode launch banner wiring

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