Thanks for making a ticket. For me 2+ bits of essential information would be

.1. the # of users whose screens are wide enough to ever see the option;
.2a. the % of [such] users who ever interact with the toggle; and
.2b. the % of [such] users in a user survey who report knowing that the toggle exists

I believe that on the browsers I've used there's still no pop-up message and no hovertext for the toggle [unless you've already used it; hovertext only invites you to return to fixed-width], so there's no way to know what it does without using at least once. As a result 2a. and 2b. should be comparable, but it's a quick sanity check that could also provide some long-form detail.

I'm wondering if T346979#9376514 helps answer these questions?

Thanks for the link! That's presented in a rather confusing way, I'm not quite sure. (A little data-journalism would go a long way. :)

It looks like 50% of account-sessions and 9% of anon-sessions customize something, perhaps that's mostly width? You'd have to see the breakdown to know.

• That doesn't give us stats per user, since there's a power law of sessions-per-user
• That doesn't tell us 2b : how many people report knowing the toggle exists?
• That doesn't tell us 2a: everyone in 2b interacts with the toggle at least once to see what it does, some may choose to set it back to the default. (so most of their sessions may be the default, but they tried the non-default at least once; or vice versa.)

2a and 2b are the key stats for understanding whether the toggle meaningfully provides an option to those who would want it; and understanding how many people after trying both decide on one vs the other.

Hi @Sj, we have discussed your questions within the team. The request requires recording the reader's user_id along with the timestamps of their visits and clicks. We don't track such detailed info for readers. The session based stats are the closest approximation we have for readers.

The breakdown percentage of full width was posted at T346979#9285473. I am reposting it below for better visibility.

% of pageview sessions which do not use the default width option (and view the site at full width)

Metric: Number of unique sessions with full_width on (non_default)/ total number of unique initialized sessions
The following statistics are based on the data collected from all wikis between Oct. 20, 2023 and Oct. 25, 2023,

I see, many thanks @jwang.

• On getting data per user, or bucketing groups of users: I hope this is developed as an option. There are many privacy-preserving ways to do this, some I know have been implemented by other teams in the past, and it can complement per-session statistics especially when exploring what works for new accounts that may only stay briefly.
• From the breakdown, I see that 90% of logged-in users who customize their experience do so to turn off page previews. That is not so surprising: it actively impedes reading if you aren't used to it / are not careful, and the toggle to set a preview preference is right in the middle of the preview pane, taking up 1-2% of the total pane in the center of a reader's gaze.

Coming back to this ticket,

• The data on page width looks at all sessions with viewports wider than 1000px. The toggle only appears for windows wider than 1400px. Do you have width data for only those viewports that show the toggle?
• Under the default for logged-in users (both menus pinned), the toggle has no effect at all for windows narrower than 1600px. That probably crosses the line into a minor bug: it's quite confusing what's happening within that width range (which covers anything but a full-screen browser window on a standard macbook). Do you have width data only for users whose toggle would do something when toggled? (viewport > 1600px, or viewport <1600px but among the 7% who have at least one menu unpinned)?

Comment for @Jdlrobson : There are better ways to identify which users have discovered various settings, w/ a little instrumentation. E.g.

• Adding a flag-dictionary for "tried the non-default setting at least once" for each customizable setting. That could also useful for customizing any future tutorials, or distinguishing in the future b/t people who actively chose the default setting [and don't want to be auto-migrated] or just always kept the default.
• You could run a quick user survey to see who knows that width can be customized + reports ever trying a different width setting. (in contrast to Preview, the width toggle is under 0.1% of the total screensize, in a corner where gaze doesn't usually go, &c :)
• You could run a controlled test where readers are shown a known browser config and you see how long it takes them to discover each option.

I'd very much hope for some combination of these tests, compiled w/ love and not pulling teeth, given how much time has been spent discussing + developing width options, the decision to finesse consensus, &c. It may also highlight how much of an improvement the theme menu is ^____v

Happy holidays, all! 💫 ✨