The Vector specific banner has been created and deployed in T370303.
To run the centralNotice campaign, we still need to create a vector specific banner. This banner will be similar to the minerva banner, but it will load a different module.

Some takeaways from a meeting with the search team:

What is the current level of traffic this API experiences?

Using the following Superset query, querying the sum of the num_morelike_req column from 2024-06-22 to 2024-07-22, we can see that the morelike API gets on average 97m requests per day.

☝️just fyi, the patch above has been amended to address both issues.

@GMikesell-WMF the gif you provided (attached below with size=full to show animation) actually demonstrates the transition with opacity successfully (the reference toast fades in). Looks like a pass to me 👍

meeting notes: we estimated this as a 3 because although the CSS implementation seems straight forward, the usage of the * selector almost always has unintended consequences and the moving the content in CSS like this can have implications for a11y (e.g. tab order).

What is the expected level of traffic it might experience? Investigate: how much traffic the search widget currently generates, how likely we are to have this content be cached / other caching implications, how many requests we experience per unit time and the characteristics of this traffic (eg are there surges / other interesting aspects?)

@Gehel Right now we're mainly interested in content related suggestions (suggestions based on the current article).

Regarding questions about the campaign,

Do any modifications need to be made to the campaign e.g. around skin or are all these changes only in the Minerva banner? Do we need to set up a new campaign as part of this ticket or are we reusing the existing campaign (could that be added to the ticket to help test this better?)

I think we'll want to run the campaign on certain wikis for mobile, and on other wikis for desktop. From my (limited) understanding of CentralNotice, I think this will require two separate campaigns. One targeting mobile wikis, and another targeting desktop wikis.

Regarding some of the open questions, here are some answers concerning the banner itself, I'll look into the ones related to the campaign shortly.

Does Vector manage multiple overlays or do we need to manage this ourselves?

I think we need specific examples of where overlays occur on pageload. The banner doesn't use the standard #mw-teleport-target element to attach the overlay (this was an oversight) so it could interfere with other overlays, but personally I don't know when this would actually happen.

Will any styling modifications be required for Vector 2022?

The design relies on the standard Codex dialog component and doesn't specify any style changes other than the copy and the missing button. Below is the version of the banner for Minerva on the left vs. the one for Vector on the right. The version for Minerva includes the blue button, whereas the one for Vector does not.

Meeting notes: putting back to needs analysis to investigate caching implications.

What is the current level of traffic this API experiences?
At a quick glance, we can use the webrequest table and Turnilo to query the number of hits with gsrsearch=morelike in the URL. The results show about 0.7m hits per day.

💡One more idea! (that's pretty simple to implement).
Since this tool will be focused on helping editors fix template issues going forward, we can also limit the scan to just the #mw-content-text or .mw-parser-output element so that it doesn't catch other UI related issues. (It would still be good to know what those are though).

During this investigation, the following improvements were made:

1. Added screenshot capabilities to the contrast checker to to visually debug issues
2. Limit the axe core library to only run the color contrast test
3. Diagnosing the performance issues when running the contrast checker locally

Meeting notes: The Manual:Dark_mode page should be linked from the Reading for Accessibility page and FAQ page, (while acknowledging that the audience for that page is slightly wider than Wikimedia projects).

meeting notes: Sign-off step: set up a meeting with Traffic to go through our these observations.

all I want to do is test the latter so I can fix pages, templates and scripts for the lay readers who use it, while continuing to use the skin I prefer the rest of the time.

The nature of this alert

I've been looking through the graphs and I noticed an increase in the CSS payload on July 5, from 25.2kB to 25.9kB
I think this could be related to the baseline increase in the fully loaded metric, from 2.28s on July 4 to 2.30s on July 5 (a 20ms increase).

thank you for the suggestion @Batorsz the HTML comment looks much simpler :)

@Jdlrobson T369368 is specifically concerned with the unusual wikitext <no<includeonly></includeonly>include> used to achieve the desired outcome, being potentially(likely) treated as an error by translators. I added patch that clarifies that this unusual wikitext is intentional:

This task is still relevant, however, it might be a bit of an epic (or at least several tasks). The goal of this work is to remove as many custom Less variables from Vector as possible, and replace them with Codex design tokens. Doing this will:

• reduce maintenance overhead in Vector
• Improve UI consistency between Vector and Codex (and thereby any extensions that use Codex).
• Centralize design decisions in Codex

@Sgs your right, this 1px offset seems to be affecting all OOUI popups. Personally though, I don't think this is a high priority issue. OOUI is in maintenance mode and the 1px offset doesn't hinder functionality in any way. Design-System-Team currently maintains OOUI.

So I dug through PreloadContentBuilder.php, and it looks like the preload param doesn't really work with special pages. It does however, work with the MediaWiki namespace. The pages in the mediawiki namespace are actually translation messages, which serve as a way for editors to override translation message through on-wiki edits.

thanks for that context @Pppery, we're currently exploring the feasibility and risks associated with this.

I'm a maintainer in so far that I do stuff, if WMF doesn't do it. But I can't make promises as to what and when.

@TheDJ thanks, just wasn't sure what the maintenance status of this extension was.

In this situation, I think using the invert approach to achieve dark-mode compatibility could be problematic for the following technical reasons:

• The Wikitext editor includes an embedded content preview. This preview already uses the dark-mode color palette
• The Wikitext editor includes OOUI icons which have already been inverted
• The Wikitext editor includes OOUI dialogs which use the dark-mode color palette.

Just noting that the Echo icon is actually one of the few icons in Minerva that is using Codex, it's the rest of the icon in Minerva that are using invert and appear darker than they should. Most icons should probably be the same color as the label beside them, e.g:

@Jdrewniak proposes updating the CSS filter just for this icon to use brightness to make it appear like the rest.

The patch above enabled dark-mode in the mobile editor, however, it looks like there's a few more hard coded colors in VE that will need to be fixed before we merge that.

The VE submodule in Extension:VisualEditor has just been merged https://gerrit.wikimedia.org/r/c/mediawiki/extensions/VisualEditor/+/1048001
So the following patch that removes the .notheme class from VE in Vector is ready to be reviewed now :)
https://gerrit.wikimedia.org/r/c/mediawiki/skins/Vector/+/1039804

White-on-white text issues in dark-mode in VE

The patch linked above - Replace hardcoded colors with Codex design tokens - replaces all static color values in Extension:VisualEditor with Codex tokens. From previous experience, these kinds of changes can introduce risk because the changes are widespread (the patch touches 25 files). Also, I'm not even sure if these changes resolve the white-on-white text issues (or if the most important changes should actually be made in the core VisualEditor repo).

meeting notes: AC3 requires enable "content translation" user preference on beta.

Not sure how this task differs from T358405 - Special:Notifications has color contrast issues in night mode

I'm looking at the Special:Notifications page with the in-progress OOUI update, and there are still a fair bit of color values that need to be changed in the Echo extension for this page to work in dark-mode. Luckily with the magic of codesearch, hardcoded hex values (#([A-Fa-f0-9]{6}|[A-Fa-f0-9]{3})) are easy to identify: