Earlier this week we added a scheduling feature to the extension that let's us enable/disable experiments in a future date.
In hindsight that patch should have been tagged with this ticket:
https://gitlab.wikimedia.org/repos/web/web-experiments-extension/-/commit/b6868fd0ee885e02717379ccf9dbacd0cd262f68
The second experiment was scheduled to be enabled on Sept 24, 19:00 UTC.

Some clarification. It turns out the notebook originally posted in the task description is not the one intended for summarization purposes (but rather for simplification).
The approach we should go with is better reflected in this notebook:
https://public-paws.wmcloud.org/User:MGerlach%20(WMF)/text-simplification/section-gists_v01.ipynb
where (for experimentation purposes) we just use the Cohere API to generate article summaries.

For QA purposes, I'm attaching a dev build of the chrome extension which features the sidebar experiment.
Here are instruction for installing unpacked extension: https://knowledge.workspace.google.com/kb/load-unpacked-extensions-000005962

Ok! finally got @MGerlach jupyter notebook tutorial up and running on the stat1008 box.

@JScherer-WMF the documentation on this feature is pretty sparse, but it essentially allows a free-form HTML page inside a popup window when clicking the extension icon:

❓ The search functionality works as expected and the temporary flash of the recommender is no longer there. This is an odd edge case that you may want to look into If you type a query in the search box, and either press Enter, click Search, or select a search suggestion, then click back on the browser, clear the search field, click out and back into it, there are no recommended articles.

Just to summarize the progress here. We've currently deployed the more prominent donate link to the beta cluster for anonymous users, so I'm signing off this ticket based on that criteria.

This change rode the train this week and is now in production!

@bwang am I correct in assuming that this work is mainly targeting tables in content?
There are situations where tables are used in extensions and special pages. e.g.

I'm wondering, given that we've implement accessibility tests in Pixel, which discover HTML issues: https://pixel.wmcloud.org/reports/desktop-a11y/default.html do we still need a separate HTML validator?

Given the task is technical in nature and has a POC patch that illustrates the preferred solution, I don't think it requires further investigation. Moving this to "groomed".

We've set up the QuickSurvey on beta cluster that links to the browser extension:
https://en.wikipedia.beta.wmflabs.org/w/index.php?title=T352930&quicksurvey=true

hi @jwang the "morelike API request" uses the webrequest table to track requests to an API like this:
https://en.wikipedia.org/w/api.php?action=query&list=search&srsearch=morelike:radium&srlimit=3&srprop=size&formatversion=2

@matmarex thanks for going to great lengths to inspect this fix, and for uncovering my favourite superfluous and nearly extinct browser feature (seriously this is the only reason I keep Microsoft Edge installed on a Mac)

There is also the "3D View" tab, which tries to show the layers "stacked" in 3D instead of just drawing some borders, and lets you manipulate the view as if you were Tom Cruise in Minority Report. I found this view difficult to read and navigate and it crashed several times as I tried using it, but it is quite neat when it works.

The Search platform team does track Related Pages in the following graph
Related Articles pageview actors as portion of all pageview actors; Plus clicks-to-impressions

@Jdlrobson I just added the following to the README.md
https://gitlab.wikimedia.org/repos/web/web-experiments-extension/-/blob/main/README.md?ref_type=heads

@GMikesell-WMF thanks for verifying, the Monobook issue:

❌ Came out as a normal "J" unlike the other skins

This is due to Monobook using a sans-serif font for headings, unlike other skins which use a Serif font. The title is still italic like the other skins, and I don't see it being cut off, so it looks like it passes to me.

The repo for an experimental browser extension has been set up here:
https://gitlab.wikimedia.org/repos/web/web-experiments-extension
The setup is based on CRXjs + Vite. CRX is a library that helps build chrome extensions. It comes with a nifty Vite plugin that enables hot module reloading the extension in the browser.
I've added the following dev dependencies

@matmarex great idea! I've updated the patch accordingly. I was hoping we could also use that approach in the Vector 22 "sticky" header as well, but because that heading is limited to one line, it looks like it requires overflow:hidden specifically for text-overflow:ellipses to work.

👆The patch above deletes one line of CSS that's been around for almost 14 years.
I've pinpointed the exact origin of this rule to the following commit:

@Jdlrobson

Did you consider banners? It's a bit of an unconventional use of them, but it could also be used as a delivery mechanism without those same community concerns.

@Krinkle I've created an upstream bug report here: https://github.com/less/less.js/issues/4276 . Personally, I think the fact that the output is treated differently based on whether a Less comment or CSS comment is used is surprising, so I've framed the issue in that way.

From an earlier ticket T365893 (closed since this one has been groomed & estimated )

This is similar to T349436 but the fix is likely more straight forward. We can probably use overflow: visible for the .mw-first-heading element.
This is in contrast to the sticky header, where we limit the page title to one line and cut it if off with ellipses, which means we have to use overflow: hidden in conjunction with text-overflow: ellipsis; and can't just use overflow:visible.

similar to T349436

Given the second part of this spike is underway using the survey provided above, I'm moving this into sign off.

@JScherer-WMF from the documentation it looks like QuickSurvey results are sent to eventLogging analytics platform, so accessing the results does require special permissions (generally limited to WMF staff) and might require help from analytics, but the aggregate results are usually made public in a report of some kind.

The following is a table of possible delivery channels for an experiment

For a more in-depth analysis of the morelike traffic estimates, the search team has performed their own high-level spike on the topic:
High level plan of how to scale MoreLike

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).