another one here: https://en.wikipedia.org/wiki/Brian_Eno#1980s

some missing here, too: https://en.wikipedia.org/wiki/Teenage_Engineering

another one that's skipping a bunch of images: https://en.wikipedia.org/wiki/Buchla_Electronic_Musical_Instruments?wprov=rarw1

Took some prod debugging as the the production code path is different than the local development path, and the former also includes a comparison between the image’s src (where some characters, like comma, are encoded) and the filename; unless they match, the image is not included, as is the case with both of these examples.

Pages like these might be good candidates for page-level exclusion via community config because they have fewer than 3 other kinds of images from what I've seen.

I'm not sure what our minimum resolution is right now, but we should probably just double it. Would love to listen to informed opinions on actual minimum size if folks have it.

Quick note, I tweaked the designs today based on a conversation with @DTorsani-WMF. I changed the chips to small buttons with a couple overrides. I also updated the icons being used to match the new codex icon set.

Ok, so the toast component makes the most sense, and we can use the exact same copy and CTA.
I mocked this up in Figma and marked it ready for dev.

In T422268#11955084, @lwatson wrote:

Given our goal is feature parity with the Mobile Frontend viewer, should we match their existing error display method, or is it okay to introduce the Codex Toast component?
Can you confirm where to display the error message? @JScherer-WMF

Legacy version:
The Mobile Frontend viewer displays the error message.

@mfossati Here are the SVGs for the beta.

Based on what I see above, I think the only other issue still present is the font size issue @lwatson picked up.

Wikipedia logo styling doesn't follow through to download
wikipedia-quote-espressionismo.png (1×576 px, 718 KB)
The Wikipedia logo doesn't look correct in the downloaded card or in the preview of a share card?

In T424591#11919975, @lwatson wrote:

dialogue is stuck to the bottom of viewport when it should be centre-aligned

In Figma, the dialog is center-aligned to the viewport, whether mobile or desktop.
In code, the dialog is displayed as a bottom sheet on mobile, and center-aligned on larger screens based on this task T417102: [Share Highlights] Create dialog container for the share actions

Does this need to be addressed/must-have for the experiment launch?

• "Downloading..." loading message isn't localized

{couldn't get a screenshot in time}

@SherryYang-WMF These should be ready for pointing and spikes. I'll leave it to you to attach this to the epic when we make it. Tagged it with our team and experiments for now.

In T423110#11840228, @matthiasmullie wrote:

@JScherer-WMF @SherryYang-WMF When sharing, we feed the native share functionality 3 pieces of info: a title, text & the dialog image. These look something like this:

files: <the dialog image>
text: '"Whatever text I just selected, or the intro text"\n\nRead more: http://localhost:8080/wiki/My_page?wprov=shhu0#:~:text=Whatever%20text%20I%20just%20selected,%20or%20the%20intro%20text'
​title: 'Quote from "My_page" — Wikipedia'

The title seems to be ignored often, which begs the question: is there any important information in there that we may want to move to text instead?

It would replace the button in that loading state

Please use the Progress indicator with label from codex.

Sorry @egardner just getting to this today.

In T387382#10591610, @Jdlrobson-WMF wrote:

@JScherer-WMF @ovasileva this poses twos question:

• given what we saw with roll out (interference with browser extensions/people unexpectedly getting dark mode) would we ever re-consider making "automatic" the default

I'd be curious how many people have changed the default light setting to automatic since launch. If there's a meaningful adoption of non-default colour settings since launch by logged out readers, I think it's worth pursuing. If not, we should keep the default as is. We can discuss what "meaningful adoption" would look like in this context. One important nuance is that Wikipedia's brand is very much tied up with black text with blue links on a white background, even more so than with the puzzle globe logo. My intuition is that casual readers who are new to the site or do not come very often would lose trust/confidence in the wikis if the interface were presented to them in dark mode without them expecting it. This represents a significant brand risk.

token list
Title: UI-text-bold with line-height x-small and text colour base
close button: medium neutral-normal
Author: caption-text color-subtle
The description and attribution link are text-color-base and caption-text sizing with primary-progressive links
The key line above the pagination buttons is border-color-muted
Background is background-color-interactive-subtle
pagination text is caption as well

Might be worth checking the styling against the[[ https://www.figma.com/design/Pl5dJQk7D6FjIt7GjtXuSX/Image-browsing-scaling?node-id=101-42&m=dev&t=c4aRAtCME5iNQ2uv-1 | dev mode link in Figma. ]]
Style all assume everything is in dark mode.

Have a look at this comment for a bit more context on the design:
https://phabricator.wikimedia.org/T419740#11723464

Added the carousel designs to[[ https://www.figma.com/design/Pl5dJQk7D6FjIt7GjtXuSX/Image-browsing-scaling?node-id=101-42&m=dev&t=c4aRAtCME5iNQ2uv-1 | the ready for dev tab in figma. ]]

Just wanted to document the tweak to the carousel designs we spoke about before, but I can't find any records of it. In user testing, people didn't know that more images were available in the carousel unless one of them was overlapping the right side. Correct me if I'm wrong here, but since we decided not to crop carousel images to a uniform width/height, we don't have any way of knowing whether or not more images are "hiding" off the right side of a reader's viewport.

Removed the image selection from the design spec and uploaded a new Figma Dev mode link.

Also note that the article share will need coach marks on initial release. Those need designing on their own.

@egardner @SherryYang-WMF Have a look at the design spec and the Figma link and let me know if you need any clarification on any of the notes or specs.

In T417932#11634574, @SherryYang-WMF wrote:

unless @JScherer-WMF feels strongly otherwise, I would like to propose that only the top two bugs are launch blocking and the others are nice to have (maybe we get to them now that we've moved launch out by a day but if not we can still go), so please work on fixes in this order: #2, #1, the rest. thank you!!!

UI bugs that I found:

• When you deep link into the page, whether with the ToC or otherwise, the scroll position of the ToC defaults to the top. Whatever the active section is should be in the center of the ToC.

Given that we now know what the intended behaviour is, we can estimate it properly going into next sprint. cc @HSwan-WMF

realizes weeks later that he forgot to hit submit on this comment...

cc @lwatson Let me know if you have any questions about these. Also probably worth flagging @Jdlrobson-WMF for the paragraph hoisting bug.

In T413401#11562373, @lwatson wrote:

Regarding the editor help button: I logged in and enabled the newcomer homepage

Editors can toggle this feature at Special:Preferences → User profile → Newcomer editor features → Display newcomer homepage.

... but I don't see the help button or help panel appearing.

Also, the task description mentions https://en.wikipedia.org/wiki/Wikipedia:Growth_Team_features#Community_configuration

I've been playing around with quote cards a bit if we want to have something as a placeholder:

Ok, so lemme zag on this a little bit. We know readers are scanning text looking for links. Why not surface the 3-5 most-clicked links in a long section at the top of that section? Maybe we spike on what kind of section-level data we can get? This is a concept from last year that I adapted to show how this might show up:

For now, it might make sense to spike the highlight interaction without specifying exactly what we'll put inside the module that pops up when a user highlights something.

Had a look at this just now and there are a few improvements to the network view that would make it better on mobile:

Thanks for your work on this @matthiasmullie ! Answers below.

In T410325#11419281, @matthiasmullie wrote:

+1 for the sticky header option looking more feasible, and it looks pretty neat!

I'm not personally a big fan over floating buttons (option #2) obscuring my content, but that's very subjective.
My main concern with that option is the "search" addition: I would expect an in-page search here, but that feels like a can of worms:

• in-page search would behave differently from regular search (direct text match; no stemming, keywords, wildcards, ...)
• would require some additional UI elements (e.g. button for navigating to next match)
• does it find hidden text (e.g. within collapsed sections) or not? (window.find() does not), and if yes, how do we surface it?
• window.find() is not a standardized feature

Another good option with less fiddly interaction design would be to have a floating action button with search and contents buttons.

I did some design exploration on this yesterday. The appearance of the ToC pane itself is less of a worry to me, we can either adopt what we already have or re-build it using codex. I'm more concerned with IA and scrolling interaction.

In T410325#11393609, @lwatson wrote:

The TOC (#toc element) is hidden on smaller viewports via display: none. This is an example of the existing TOC if shown on a mobile device:

Collapsed	Expanded

In T410325#11383516, @A_smart_kitten wrote:

xref T366026: [Design needed] In-article navigation for Minerva: ToC and sticky headers