Bawolff: Most of our projects are built on external resources we don't control, backed up by web archives we also don't control. The threats you mention are rare events we already cope with on the projects. (and we still manage to let e.g. wikivoyage maps render external layers)

A proxy service for calls to such caches of trusted + curated knowledge makes sense.
That doesn't seem specific to this OWID use case, is there an existing proxy library that could be generalized or extended?

Summarizing some concerns raised, and responses to them in the discussion:

Great! I see I have to work on my phab-search-fu.

Thanks @Gehel for catching the duplicate.

What a fantastic QOW improvement! Beautiful, fast, cleanly integrated into the special page. Thanks @Esanders

Alex: yes, a bit of compression will make it easier to leave 1-2 more items in the personal tools links w/o other design changes.

@Discott @GabrielLucas @Theklan @John_Cummings nice to see! I'd be glad to be part of a workshop on supporting new formats, the overarching needs / costs / reasons-for-stalling are quite similar. And I think the best approach to realize this [since there is a necessary WM-core bottleneck] is to define a time-delimited project to identify and add a range of formats [and then update the workflow for doing so, ping interested people, &c].

Seems great. Is measuring performance a separate issue?

@Amire80 @Tacsipacsi @Lectrician1 this is obviously an extremely high value idea. What's the best way to help get it onto a roadmap?

Ok, maybe now's a good time to revisit... sorry you're no longer involved AH but I'll look at what's holding up T316060 (which is also not assigned).
Quick comment ftr:

Thanks @Jdlrobson is this planned to be available to logged-out users? What made you list it as stalled?

Thanks (belatedly) for the idea of tagging umbrella discussions of what to do as [design spike]s so they're not triaged as tasks, and can have subtasks.

Updated description -- the page-width and persistence issues have been addressed. Still keen to see the latest v of your prefs idea jdlrobson :)

Ok, thanks -- and thanks for the essential archival work.

Many thanks @jwang and @ovasileva.

It may be helpful to distinguish (as separate issues)

Alright, filed a related issue at T330808

I've proposed editing the message on en:wp, and filed a separate task to update the default message: T330805

Thanks @Izno ! Doesn't address searching by substring, but covers the most common case of finding the message I'm looking at.

Interesting. How did this change once the toggle was made persistent for anonymous users? Does this include sessions where screens were too small to ever see the toggle?

Hi @Kizule why are you closing this? It's an unencumbered format.

Renaming this. I keep encountering people who want the old menus back and are glad to learn they can customize a skin if they log in. It's a very reasonable motivation to create an account [and an inroad to learning about the amazing array of other gadgets], but they need to know it's possible.

Related: T327734

Ok. But now that the others are there and the sticky header provides access to the links from anywhere in the page, the large notice is simply too large, not clearly worded, and misleading; clicking on it needlessly shifts your window up. Plus on en:wp the text always ends in an orphaned line.

@BCornwall exactly, my comment was about the top of the page, not the sticky header (its padding is quite good). The excess v-space is easy to see for small screens:

I like this approach. I'd also strongly encourage making it 2-3x less wide, and making the lineheight no greater than that of the article.
The excess whitespace is distracting and repaints an unnecessarily large part of the page.

@The_Discoverer very nice, still ULTRAWIDE, I'll comment there.

In general, the 24px between header and topmost sitenotice seems unnecessary. There is already padding at the bottom of the header, and most sitenotices have some as well. This is just the most visible when there's no banner at all.

Hopefully this is already covered somewhere else and can be closed and merged! I'd hope for the equivalent to include:

• A rough timeline for migration
• Current status of the decisions made / pending re: where and how to migrate
• A map of other components + services affected, so they can be notified and run their own downstream analysis

@Pintoch What do you see as the remaining issues to resolve for this issue?

cc @Gehel @KingsleyIdehen @Jheald

Hello, could you include data about currently active (5+ edits/mo) and very active (100+ edits/mo) editors? They may be more heavily affected by global prefs.

Looks very clean.

Two levels of numbering is extremely handy (4.1 ... 4.12). After that you could shorten back to the last number. Most readers will not encounter a TOC that deep.

Came here to say this. You're not the only one who noticed.

Ah I see, thank you.

Hi @Jdlrobson! I don't believe this is related to the roll-out of page tools.

For the "unchanging position" vs "getting space back" tradeoff: I agree user choice [of how much space to have for the body] should be a priority. But explicitly choosing "with sidebars" or "expanded / body-focused / full-width" feels different to me than choosing which menus to pin, leading opaquely to 3 different positions for the body.

+1 to fixing this. It is a long, confusing, not very important message, taking up space and attention on every page.
This could be shrunk to one line w/o a border, including the icon/characters used for the real menu (文⧸A). Challenges:

This is fixed for logged-in users but still broken for logged-out users. It is disorienting and pushes the whole page down roughly one screen-length.

Hello @alexhollender_WMF , thanks for all of these replies and details.
I'm not sure where else to put a reply so I'll leave this here for now:

@HirnSpuk : agreed. Do you think we need separate magic words to specify showing or not showing the sidebar TOC?

Given the title: is this the right place to discuss NOTOC / FORCETOC magic words?

Thanks for the links Alex. Appreciated; I realize phab works best with compact issues and isn't a great place for umbrella topics.

From T328088#8573021 it looks like 15% of editors who made 1 edit since 1/18, and 23% of editors making 5+ edits since 1/18, have opted out.

Other menu-style issues that may fit here (lmk if there's a better place for some of this)

Moss is looking excellent! Thanks for this update, @ovasileva and all. The font size, line height, inter-section spacing, and background color/border all improve readability for me.

I would find it helpful to see, using the same user_id hash function so that you can get the breakdown:

• # of accounts with 1 edit in the past year / with 1+/5+/100+ edits/month in the last 3 months
• # of these accounts which have made an edit, logged in, or changed any preference since the launch (or: is there a better way to confirm if they have been online/reading this week?)
• # of new accounts created since the launch
• # of accounts in each of the above categories which have opted out

This seems a different definition of 'active editor' than stats.w.o uses. Could someone calculate the % for the traditional definition of active & very active editors? (5 & 100 edits/month)

A lot of discussions about how this impacts readers, on en:wp at least, has assumed that logged-out readers will understand they can customize the skin by logging in. That was my assumption as well in past weeks, because in skin tests there was no way to test the "anon experience" -- the only way to choose the beta Vector 2022 skin was to be logged in, in the first place.

When compiling toy models to support, please include a page that consistently has ~100 sections (like an active noticeboard or talk page). For these a common way to browse is by skimming across section titles in the TOC. Being able to do that without locating and scrolling inside a tiny TOC (e.g., by paging down the central page content instead) is useful.