With "rough consensus to make unlimited width the default" being found, someone will need to open feature requests to (a) make this be something that is configurable in the software, and (b) set that configuration to wide for enwiki. — xaosflux ^Talk 14:42, 16 March 2023 (UTC)

Ping to RFC initiator: @HAL333:. Please provide your phab ticket numbers here for reference when created. — xaosflux ^Talk 14:44, 16 March 2023 (UTC)

I've opened T332426; comments + edits welcome. – SJ + 18:57, 17 March 2023 (UTC)

@Sj: looks like you only did half of that. Completed with phab:T332505, which is now a blocker. — xaosflux ^Talk 14:06, 19 March 2023 (UTC)

Thanks. Not necessarily a blocker, but the right approach. Appropriate for that to be its own ticket. – SJ + 15:01, 21 March 2023 (UTC)

@Sj it is a blocker because that software capability doesn't exist yet. Building that capability requires someone to code it, which anyone can work on - but until it gets built there is nowhere to specify that option here (as opposed to if that was just going to be a skin-wide change on every project using vector-2022). — xaosflux ^Talk 09:50, 22 March 2023 (UTC)

• Please note, a developer has refused the underlying ticket to enable this to be selectable. — xaosflux ^Talk 16:22, 24 March 2023 (UTC)

Someone has requested a closure review of this RFC at Wikipedia:Administrators' noticeboard#Closure review of RFC on Vector 2022. Pizzaplayer219^Talk_Contribs 19:05, 20 March 2023 (UTC)

Facepalm This is never going to end, is it? — The Hand That Feeds You:^Bite 20:16, 20 March 2023 (UTC)

I've boldly closed that review. While a review is needed, that review is not it. BilledMammal (talk) 20:58, 20 March 2023 (UTC)

I agree with BilledMammal's procedural close. The request for review opened by Tvx1 was hasty and not well-thought-out. Æo (talk) 21:27, 20 March 2023 (UTC)

And are you going to present you're "well-though-out" alternative now then? Tvx1 20:41, 22 March 2023 (UTC)

So a couple of admins can overrule the majority of users, and an appeal is shot down as too hasty. How long do we need to wait, exactly? Ann Teak (talk) 22:54, 20 March 2023 (UTC)

@Ann Teak: I also support an appeal for review, but Tvx1's one was really badly worded. Æo (talk) 23:00, 20 March 2023 (UTC)

So how would we word it better? Ann Teak (talk) 23:03, 20 March 2023 (UTC)

I'm waiting for some additional information from the closer; when the closer has provided it I'll ping you and any other interested editors to help draft a review? BilledMammal (talk) 23:11, 20 March 2023 (UTC)

I've not decided on whether I would support overturning the closure, but I wouldn't mind having some input on how the issues are framed. —Compassionate727 ^(T·C) 02:30, 21 March 2023 (UTC)

Who more do you want from the closer other than “I’m not going to change my mind”?? You’ve declared yourself the sole authority on whether an when a review can take place, well then take your responsibility and start the draft for the wording! Tvx1 18:59, 22 March 2023 (UTC)

Six months, apparently, Ann Teak. Good luck getting anything to happen until then. Toa Nidhiki05 02:34, 21 March 2023 (UTC)

The review will happen. We should all have a chance to discuss the best wording and the best way to bring it to WP:AN. Tvx1's review was poorly-worded and would've inevitably (look at the votes) ended with the close standing. Cessaune [talk] 20:03, 21 March 2023 (UTC)

I agree that review was malformed. I'm of the frame of mind that the WMF should be given an opportunity to comply with the RFC's result. If they don't, it should be reviewed immediately. Toa Nidhiki05 23:09, 21 March 2023 (UTC)

Why should we wait for them to comply with an incorrectly interpreted result that we all want to challenge? Tvx1 19:02, 22 March 2023 (UTC)

So you’re all saying it should be challenged, but no-one has the backbone to actually take the step. And when someone finally does, you all collectively shoot down that person??? What on earth is going on here?? Days and days pass and nothing is undertaken against that ridiculous close.Tvx1 19:07, 22 March 2023 (UTC)

I’ll draft something tonight; the delay is caused due to waiting for a response from the closer. In particular, there is one yes/no question that I want an answer for. BilledMammal (talk) 22:30, 22 March 2023 (UTC)

Still waiting… Tvx1 01:46, 24 March 2023 (UTC)

How long must we let the closers stonewall us? Ann Teak (talk) 00:20, 25 March 2023 (UTC)

You were pinged in the draft discussion. You should head there. Cessaune [talk] 03:13, 25 March 2023 (UTC)

The discussion can be found at Wikipedia:Village pump (technical)#Implementing the consensus to set Vector 2022 to full width by default. BilledMammal (talk) 20:22, 29 March 2023 (UTC)

Please see the discussion at Wikipedia:Village pump (idea lab)#Modifications to the default settings of Vector 2022 BilledMammal (talk) 20:31, 29 March 2023 (UTC)

A second request for a closure review has been opened here: Wikipedia:Administrators'_noticeboard#Close_review_of_Requests_for_comment/Rollback_of_Vector_2022. Æo (talk) 11:54, 28 March 2023 (UTC)

To clarify, the first was closed procedurally, not on the merits. BilledMammal (talk) 11:57, 28 March 2023 (UTC)

The closure review has been closed with little to no explanation. That's the end of that, I suppose. Toa Nidhiki05 19:42, 29 March 2023 (UTC)

@Toa Nidhiki05: BilledMammal is now proceeding with discussions/RfCs about forcing the implementation of full width and deciding about other single characteristics of V22. These are probably the only ways forward now. See below. Æo (talk) 13:10, 30 March 2023 (UTC)

The closure statement has 296 words, I wouldn't call that little to none. Aaron Liu (talk) 19:07, 8 April 2023 (UTC)

The RfC is closed, but... There is no mention of the result. WTF? 155.4.221.27 (talk) 15:34, 26 March 2023 (UTC)

I'm not sure what you mean by "mention of the result". Snowmanonahoe (talk) 16:04, 26 March 2023 (UTC)

The result is the first thing that's mentioned. It's everything above the horizontal line. —Tenryuu 🐲 ( 💬 • 📝 ) 22:29, 26 March 2023 (UTC)

...

That was extremely unclear. There was no way of telling, that the result-bit wasn't just part of the RfC. 155.4.221.27 (talk) 19:26, 8 April 2023 (UTC)

I'm not sure how much clearer they could have made it when the template literally says A summary of the conclusions reached follows. —Tenryuu 🐲 ( 💬 • 📝 ) 16:15, 9 April 2023 (UTC)

Hi everyone,

Thank you again for your participation in this conversation. I am Selena Deckelmann, Chief Product and Technical Officer for the Wikimedia Foundation, and I am providing an update on behalf of the teams who work on Vector 2022. We appreciate all of the time you took to help us make the skin better together. We wanted to share a draft of the next steps we are thinking of as a result of the RfC close and get your thoughts on some of the open considerations before proceeding.

Respecting the consensus of the RfC with respect to logged-in users is, as I mentioned before, our recommended approach. We know that rolling back the fixed width (as per the summary statement) will be a surprise to many logged-in users, so we have ideas below on how to make that transition smoothly, and want to hear what you all think.

Based on the data that we have, the research and accessibility recommendations for page width, and the new ability of logged-out users (vast majority are readers) to persistently select their preferred width, we don’t think we have the evidence to support rollback for the width for logged-out users. We believe this evidence suggests that readers are receiving the benefits from the width that we hoped they would. We believe that this path forward is aligned with the policy at WP:CONEXCEPT on behalf of readers.

That said, the perspectives of the editor community are an important input to making decisions about readers. Thus, we also want to take further steps to address width for readers and other logged-out users by making it clearer that they have the option to change the width of the page, and add more measurements to determine what the usage of the feature is.

An important technical challenge with all preference changes is that our system does not make it possible to keep choices users have made before a default is changed. This means that logged-in users who have explicitly chosen the limited width may see their preference reverted, and would be surprised or confused by the change. To account for this, we’d like to offer as smooth a transition from a user experience standpoint as we can. With that in mind here is what we propose:

Fixed width vs full width Current state: The fixed width is default for logged-in and logged-out users. Both logged-in and logged-out users can change their preference to full width, persistently.

1. Logged-in users: Roll back to full width, but consider how to allow people to keep their preferred width or to reduce confusion.
   The skin has now been default on English Wikipedia for more than two months. As logged-in users can currently switch to the previous skin or change their width preference in the Vector 2022 skin, we believe that many of the users who are logged-in and still use the limited width do so because of their personal preference. In addition, as many of you have mentioned before, layout decisions made on a specific width might negatively affect readers who are using limited width, as well as mobile users. More consistency across interfaces ensures that layout decisions will work for larger groups of readers and editors. Thus, rolling back might be an unpleasant surprise to many. The risk of making a disruptive change is high in my view based on the low use of the current toggle. With this knowledge, I would like to discuss different options before making a change.

   

   • Option 1: Our proposal is to display a modal for all logged-in users, asking them whether they would like to keep the limited width, or revert to the full width. This modal might take a few weeks to build. The image above shows an early draft of what this could look like. We can have a further discussion about exact wording and behavior of the modal.
   • Option 2: We roll back to full width for all logged-in users. This change can be made next week.
   • Option 3: Do you all have other suggestions and ideas on how best to do this?
2. Logged-out users: Do not roll back fixed width, but prompt readers to decide the width they prefer.
   • Process: Instead of suddenly changing the width for millions of readers, we suggest displaying a tooltip (ticket that contains an example of what this could look like) for all logged-out users which clearly points to the location of the toggle for the fixed width and explains its purpose. This tooltip will be shown by default for all logged-out users, to ensure that they are aware of the ability to switch width if they want to.

White space concerns

1. Continuing with page layout work: We know that many of you raised the issue of white space as separate from the issue of the width of the page. Specifically, folks have reported that the current amount of white space makes it more difficult to focus on the content, and can potentially cause eye strain for those sensitive to light. To address these issues, we have developed this prototype, and the discussion with community members about how to evaluate it has already begun. We invite you to join it here.
2. Ongoing improvements: In addition to the concrete changes laid out above, we are exploring other ways to address white space concerns. For example, by adding a font size preference, which should make it easier to read overall and increase the overall width of the content (as recommended width is determined by the number of characters per line, not the absolute width of a line), or by adding dark mode to further help those who experience eye strain. Currently, we’re evaluating the possibility of these features in the future, but hope to come back with concrete next steps over the next couple of months.

Reviewing the impact of Vector 2022 in the future

For all of the options above, we will be measuring how many users choose the different options so that we can all look at the numbers together, learn more about peoples’ preferences around the skin, and determine any future actions based on what we learn about default states.

What do you think of the above options? We can begin implementation of either the modal, the tooltip, or both, and start making the switch.

It’s also important for us to continue the conversation on the nature of RfCs for making software decisions. A specific thank you to those who began the discussions on this with us and your thoughts and ideas so far. We would like to continue discussing how we make software decisions together in the future, in processes that promote further representation and earlier community involvement in decision-making than RfCs have so far. We will be beginning a larger conversation on this on the Village Pump over the next few weeks, including specific discussions on some of the ideas you all put forth, such as participation on a committee and explicit community agreement on project metrics.

Thank you,

SDeckelmann-WMF (talk) 18:33, 23 March 2023 (UTC)

As I said before, you’re jumping the gun. The RFC’s consensus is not certain yet and the current close is incorrect and very controversial. It’s going to subject of a full review. Secondly, why not rollback limited-width for everyone. Logged-in users are the least affected as they prefer to use VLegacy instead and the logged-out readers were actually the most vocal about wanting that seen rolled back. Tvx1 19:32, 23 March 2023 (UTC)

"Logged-in users are the least affected as they prefer to use VLegacy instead" — this is blatantly factually incorrect. Please provide any statistics to back up the assertion that logged-in users prefer the legacy skin. 2600:1700:87D3:3460:F106:5B2F:9D72:B3A5 (talk) 20:58, 23 March 2023 (UTC)

Option 3 Why not use the same tooltip for all users, with or without an account? Nonetheless I like this idea. The only thing better than choosing the option most people will like is letting people choose their personal preference. One potential issue that comes to mind is that users won't really understand why the text width would make that much of a difference, pick the option they don't prefer, and then never remember to try changing it. The differences line width makes with reading are quite subtle. Snowmanonahoe (talk) 19:17, 23 March 2023 (UTC)

I like the option of a modal, as this would allow us to gather data. Current data leaves more questions than answers. If we want to gain info from it, the modal should be worded as an equal choice without a default.

I do worry that creating a different experience for logged in users and logged out users will make V22's accessibility issues worse. Many layout problems in V22 fixed width are not evident for those with full width. These issues are now being fixed, which is also great for people with smaller screens. By creating a dual experience, that work will show down. —Femke 🐦 (talk) 19:18, 23 March 2023 (UTC)

Option 2, full width for logged-in users. PC users can change the window size. Mobile users can switch from landscape to portrait. Option 1, a modal, would be an unnecessary slow down for all logged-in users, including those who are happy with the current setting or just do not care. Other, bold suggestion: full width, text columns per paragraph, see User:Uwappa/common.css. Same story for logged out users, no distracting tooltip, simply use full window width and let users decrease window size or switch to portrait. Uwappa (talk) 19:30, 23 March 2023 (UTC)

@Uwappa, as an editor who uses both mobile and desktop devices, I don't think either of your suggestions for dealing with fixed-width help. For turning landscape to portrait, I (personally) would find that very awkward to do.

As for resizing windows, that is something I've seen a lot as an argument. Can you explain how this works? Does this mean that if you were on Wikipedia and found the width too much, you would decrease the width of the window you're on?

Also, please can your reason for being opposed to a modal - how would it slow down users, and how is it unnecessary? — Qwerfjkltalk 21:40, 23 March 2023 (UTC)

Yes, I would resize a window if text was too wide. On my computer it is super + left to get a half-size window on the left side of the screen. Super + right for right half of screen. Super + up to restore full width. Most of the time I use full width. On a mobile, simply turn the phone 90 degrees to switch from landscape to portrait.

Yes, a modal window slows down as it prevents interaction with the main window. NN Group: A model dialog interrupts the workflow. Alan_Cooper calls it "stopping the proceedings with idiocy" in his UI design book 'About Face'.

Proposed alternative: Let designers design something that uses available width. Let users control window width (and font, font size, etc, etc). That is existing, standard functionality, should not be a worry. Uwappa (talk) 22:35, 23 March 2023 (UTC)

Thank you SDeckelmann for taking the time to explain your team's thoughts and progress. The modal and tooltip seem perfectly fine options to me. As Femke notes above, seeing folks' preferences as they interact with the modal will be interesting, as will seeing if more folks use the new text-width-expander button after the tooltip launches (is that something we're able to track?). I'm glad to hear about ongoing improvements to the reading experience. These have been long needed. Ajpolino (talk) 19:51, 23 March 2023 (UTC)

SDeckelmann-WMF, I appreciate your thoughtful engagement with this issue. It bodes well for the future of the relationship between the WMF and the en.WP community. I understand that there is angst among the developers about suddenly changing the width for readers and editors alike, but with respect, we told you in significant numbers that the limited width was a bad idea, or at least poorly implemented, in our first RFC, and the WMF went ahead with it anyway. The WMF sowed the wind, and now it is time to reap. Just bite the bullet and change the default. I hope that the WMF carefully considers what it can learn from this whole experience. I look forward to continued improvements in the Vector 2022 skin, and I will continue to engage on Phabricator and elsewhere with WMF developers who want to make Wikimedia sites better for everyone. Forward together! – Jonesey95 (talk) 20:22, 23 March 2023 (UTC)

Thank you for the words of encouragement, Jonesey95. Our team and I really appreciates all the time you’ve put into collaborating on this project with the team both here and on Phabricator. I’m also optimistic about the future of how we all work together. We will soon be starting a series of conversations on how to improve our decision-making processes and collaboration as a whole - I hope you’ll be able to join us in those conversations, we would value your opinion. I know that introducing limited width did create a significant amount of work for both the developers and our community and I want to extend a thank you to all the volunteer developers and editors who have worked hard to update templates, gadgets, and tools to make sure the content looks great in this new presentation form. This work made reading the site easier for millions of users.

As I mentioned before, I believe that we made the right choice in the introduction of the limited width and that, for readers, we are continuing to make the right choice in the decision to keep it as the default, based on the data that we have, the research and clear recommendations for page width, and the new ability of logged-out users to persistently select their preferred width. For this reason, I cannot recommend that we follow the RfC’s rough consensus for all logged-out users on this point.

That said, the feedback from the community on this issue has also helped us in being able to serve even more users by making the site more customizable to individual preferences. As a direct result of this feedback, right now, all users on the site, logged-in or logged-out, are able to choose and stick with the width they prefer - fixed or limited. And going forward, we’ll now take steps to ensure that all users are aware of their ability to make this choice. We think this approach will allow us to continue serving the majority of users with a default that improves their experience, while allowing those with different needs and preferences to make a choice to change that default for themselves. SDeckelmann-WMF (talk) 21:22, 24 March 2023 (UTC)

@SDeckelmann-WMF: To be clear, we have the ability to implement full width by default ourselves, and while I would prefer you did it as the solution would be cleaner, I have no doubt that we will do it if you continue to refuse. Do you plan to continue to refuse to do so? BilledMammal (talk) 03:30, 25 March 2023 (UTC)

I don't understand the usefulness of the default if everyone using Wikipedia is made known of the option to change. What's the rationale? Cessaune [talk] 03:34, 25 March 2023 (UTC)

Logged out users will only get a tooltip and won't be forced to choose an option; for them, the default is relevant. BilledMammal (talk) 03:54, 25 March 2023 (UTC)

Option 3 - Full width for all users, logged in or otherwise. Assuming this is debatable is ludicrous. —Jéské Couriano (No further replies will be forthcoming.) 20:36, 23 March 2023 (UTC)

Option 3, Unlimited width for everyone as default. This is the most requested thing, even by unregistered readers. The proposed tooltips don’t give an option to select a default, but merely a choice that needs to be remade on every visit. That’s unacceptable. In any case, this survey is taking place to soon. The consensus of the RFC has not been established. The current close is very controversial, so please let the community deal with that first!Tvx1 20:39, 23 March 2023 (UTC)

@Tvx1, The proposed tooltips don’t give an option to select a default, but merely a choice that needs to be remade on every visit. I believe the preference is persistent, as the comment above mentions the new ability of logged-out users (vast majority are readers) to persistently select their preferred width. — Qwerfjkltalk 21:44, 23 March 2023 (UTC)

Still, it remains an unnecessary complication. Just make width unlimited by default and let everyone scale their browser windows to their preferred size.Tvx1 22:07, 23 March 2023 (UTC)

Let everyone do it the way I prefer, which is obviously the right way. ScottishFinnishRadish (talk) 22:13, 23 March 2023 (UTC)

Which is exactly what I said. Let everyonr scale their view of Wikipedia as desired. Don’t enforce any fixed width for anyone. Tvx1 01:42, 24 March 2023 (UTC)

Hi @Tvx1 - thank you for your feedback. I just wanted to jump in and confirm that the options for selecting a user's preferred width (whether that is full or fixed width) will continue to be available for all logged-out and logged-in users and will persist across pages for both logged-in and logged-out users. OVasileva (WMF) (talk) 14:55, 24 March 2023 (UTC)

Option 3 - I think the page width should still be capped, but the cap should be very very large. Somewhere along the lines of the span of a 16:9 or 3:2 monitor. Any wider should automatically limit the width. Also, I would propose replacing the toggle with the option to drag and resize the content of the window to set their preference as needbe. Wikipedia should certainly experiment with different configurations to provide the right amount of information density while not wasting any usable space. That is not what I am seeing though. Aasim - Herrscher of Wikis ❄️ 22:16, 23 March 2023 (UTC)

@SDeckelmann-WMF: why are we having these discussions in such an obscure place as the talk page of a closed RFC? I'm not sure but I feel like WP:VP/PR would be better. small jars tc 22:22, 23 March 2023 (UTC)

Agreed. I've added a link to this section to Village pump (WMF). Maybe we should consider adding it to centralized discussion too? Actually, I just noticed the WMF plans on making a larger discussion on VP later, so hold off on that for now. Snowmanonahoe (talk) 22:39, 23 March 2023 (UTC); edited 22:54, 23 March 2023 (UTC)

Ah, yeah, thank you. I wasn't trying to obscure the conversation, but more attempting to keep the conversation in the most logical place associated with the RfC. I'm going to be out of office next week, but when I return, I'll spend some time thinking about how best to approach these conversations. Something I could do is whenever I post something I think is worth discussion, I could also post to a page hanging off my user page, for example. I welcome advice on what would be helpful to those who are interested. SDeckelmann-WMF (talk) 21:18, 24 March 2023 (UTC)

Option 3, Unlimited width for everyone as default. This is the consensus, and if you don't implement it we can and will. BilledMammal (talk) 23:02, 23 March 2023 (UTC)

Do you have a reason beyond it simply being "the consensus"? The RfC was about which width is most likely to be preferred by the most users. If we allow users to pick, this isn't an issue. Snowmanonahoe (talk) 23:17, 23 March 2023 (UTC)

I don't have an issue with allowing users to pick. The issue is the WMF is telling us that they want to keep limited width as default for logged out users, and instead make the toggle-width button slightly more accessible.

I fully support them making the toggle width button more accessible (although I do have some concerns that a prompt that shows up every time a user is unrecognized might disrupt the reading experience, and believe there are likely better ways to explain what the button is - perhaps by getting rid of mystery meat navigation), but with full width as the default. BilledMammal (talk) 23:46, 23 March 2023 (UTC)

I also have two issues with the option one popup. The first is that it is not neutrally worded, and the second is that it will delay the implementation of consensus by at least a few weeks. If it is worded neutrally, and if the WMF can have it ready within a week, then I have no objection to it - if it is not ready, then editors will still have a choice through the current toggle width button, which I note they considered sufficient when the default was their preferred option. BilledMammal (talk) 00:15, 24 March 2023 (UTC)

No it wasn’t. Tvx1 01:43, 24 March 2023 (UTC)

Then what was it about? Snowmanonahoe (talk) 01:45, 24 March 2023 (UTC)

The first was about gouging support to deploying V2022, the second one about rolling back its deployment. Tvx1 04:32, 24 March 2023 (UTC)

@Tvx1 Please see Make unlimited width the default Aaron Liu (talk) 19:06, 24 March 2023 (UTC)

Support Snowmanonahoe's Option 3, with option 1 as a second choice. Giving all users this choice is a good idea. I imagine there will be a good subset of users who would prefer having a set width for accessibility/readability reasons. Wikipedia's own article on line width cites a study that indicates that some users prefer longer text lines while other users prefer shorter text lines. Aoi (青い) (talk) 23:30, 23 March 2023 (UTC)

Giving all users this choice is a good idea. – I need to stop repeating this, but default fullwidth (i.e., the consensus established in this already-closed, month-long RfC) is the easiest, least bug-prone, and most familiar way of providing this choice to users. Window resizing is about the second thing anyone ever learns about how to use a window manager, which has been the form of almost all desktop operating systems for several decades (with a few much hated exceptions). On the other hand, a modal will inevitably be clicked through at high rate with little thought,^[1] and the WMF's design will inevitably lead the eye towards the button that enables their faddy pseudo-technocratic line width constriction. small jars tc 00:44, 24 March 2023 (UTC)

I don't think there are many people who bother with the effort of resizing windows to desired width for every website they visit, not to mention it's something you'd have to do every time you visit the site. I also feel faddy pseudo-technocratic line width constriction is an excessive description considering there is actual research that backs it up, and most of the internet at least somewhat abides by these guidelines. I agree that the proof of concept of the modal isn't quite neutral, but keep in mind that because of the amount of editors already noting this fact it probably won't actually look like that if it is implemented. Snowmanonahoe (talk) 00:57, 24 March 2023 (UTC)

Why would you need to change it for every site? You can, which is nice, but it's unlikely that someone's comfortable reading width would be dependent on what site they're on, unless they visit a site with excessive and constrictive styling that messes up the connection between their setup and their experience... which is currently what Wikipedia is. small jars tc 01:13, 24 March 2023 (UTC)

@small jars, just personally, whilst I know how to resize a window, it has never occurred to me to do that because I don't like the width of a website. — Qwerfjkltalk 07:14, 24 March 2023 (UTC)

That suggests to me that too much line width is not a problem for you, at least bounded by your screen width. This is anecdotal evidence, but I help out in a IT class in my school, using medium-sized monitors: for most students I see there, it seems like wider is always treated as better, so they only resize when they want multiple things on screen at a time, and then stretch one thing back out when they're done with that. Personally, I do often want a narrower width, and get that by resizing, but I've always assumed that needing that was something to do with my dyslexia (of course it could become more general if you’re using a massive monitor or something). small jars tc 09:51, 24 March 2023 (UTC)

@SmallJarsWithGreenLabels, I personally don't think wider is always better, but I would still never resize my window unless I wanted multiple windows on screen at one time. — Qwerfjkltalk 07:50, 25 March 2023 (UTC)

This is just making me giggle at this point. So you wanted a shorter line width, but you thought the only way to have that was if the page had CSS that puts big blank columns on either side of your window?? And once those columns are there, would you realise that you could resize your window to match them, freeing up wasted space and revealing your backdrop? small jars tc 11:02, 25 March 2023 (UTC)

@SmallJarsWithGreenLabels, no, I wanted a shoter line width, but I just put up with having a wider width than I want. — Qwerfjkltalk 12:01, 25 March 2023 (UTC)

Having the site do it for you is just easier than changing it for every site that isn't text based. Aaron Liu (talk) 13:21, 25 March 2023 (UTC)

It's not "having the site do it for you" (as if one click+drag was something worth automating), but having it done to you whether you want it or not, and, if you don't want it, then being made to search for the site's unique control method, assuming that exists. Again, I don’t understand why you would need to resize for every site that isn’t text-based. small jars tc 19:04, 25 March 2023 (UTC)

one click+drag was something worth automating a pretty precise click and drag, yes. Resizing is more frustrating than drag 'n drops.

There are more websites than text-based ones. When you're searching for images, creating a powerpoint, viewing a PDF, using a multi-page word processor, etc. you probably want to resize the window. Aaron Liu (talk) 21:44, 25 March 2023 (UTC)

a pretty precise click and drag, yes. Resizing is more frustrating than drag 'n drops. – Most operating systems do have short cuts to toggle between window sizes much more quickly, e.g. by double clicking the menu bar on macs. If these methods can be dismissed as hard to learn, then can we please stop pretending that solutions that aren't even native, like the resize button with the mystery-meat icon, or "if you don't like it, create an account", are anywhere near viable by comparison. small jars tc 11:15, 26 March 2023 (UTC)

Remember that enwiki’s demographics are very far reaching. We need to consider not only the typically at least mildly tech savvy editor demographic, but also 80 year old grandmas that need their grandson to open Facebook for them. Snowmanonahoe (talk) 12:06, 26 March 2023 (UTC)

Those 80 year old grandmas will not be able to figure out that a broken square is what will let them read at full width, but, again, almost all of them will know how to resize a window. I wouldn't see this conversation as worth having if I wasn't thinking about the less tech-savvy users. small jars tc 12:23, 26 March 2023 (UTC)

…almost all of them will know how to resize a window. I think the oldest person I know who knows how to resize a window (let alone does it regularly) is like 40. I don’t know what 80 year old grandmas you know but I assume you the majority of them definitely cannot resize a window, or even like, know what a window is. Snowmanonahoe (talk) 13:25, 26 March 2023 (UTC)

Because desktop Wikipedia is almost always accessed via a window, people who do not know what a window is cannot be part of desktop Wikipedia's demographics, no matter how "far reaching" they are. The number of people who know what a window is, and how to open it, and know how to use v22's unique line-width control system, but are somehow still unaware of the ability to resize windows, has got to be so tiny that brining them into consideration is sophistical. small jars tc 13:50, 26 March 2023 (UTC)

Touché. Snowmanonahoe (talk) 14:36, 26 March 2023 (UTC)

I have experience with elderly people who don't understand the window model (to them, they just learn you click here, and X happens) but still read Wikipedia regularly. Regarding having to set up a different width than the default, since it only has to be done once, someone can set it up for them to their liking, and then they can browse as normal. Having someone set up your settings to your liking is a very common mode of operation for many of those who are personally less tech-savvy. isaacl (talk) 16:37, 26 March 2023 (UTC)

Good point. I hadn't thought of the possibility that they could have learned the bare instructions for reaching a Wikipedia article from someone who understands the operating system, without much of that understanding actually being conferred. small jars tc 19:28, 26 March 2023 (UTC)

Another note regarding resizing windows: I think before browsers commonly started supporting tabs for different pages, it wouldn't be that much of a change to one's browsing flow to resize a window. With tabs, users don't typically want to affect all the other tabs in the same window, so they'd have to pull the tab in question out into a separate window. Assuming they still wanted to keep down the number of open windows on their desktop, they'd have to further group together tabs from that site into one (or a small number) of windows. It's all doable, but extra work that adds up for a frequently used site. isaacl (talk) 21:30, 26 March 2023 (UTC)

I've said before that these people can be treated as air friction. That said, I'm pretty sure such a window-resizing feature doesn't exist on Windows. (yet another example of why macs are better than Windows) Aaron Liu (talk) — Preceding undated comment added 19:34, 26 March 2023 (UTC)

I'm not sure what you mean by "air friction". Snowmanonahoe (talk) 19:45, 26 March 2023 (UTC)

I disagree with minimizing the problems faced by less tech-savvy users. Even leaving aside that everyone is on a shifting continuum, I think those more tech-savvy, who are able to change their setup to their liking, ought to be kind towards those who cannot and are reliant on others to help them out.

On a side note: double-clicking on the title bar in Windows will toggle between full-screen mode and regular mode. Windows key+arrow key will snap a window to an edge of the screen and reduce the size, to help you tile application windows. isaacl (talk) 21:17, 26 March 2023 (UTC)

We might have forgotten during this discussion that the question is about what width should be the default, not whether the non-native width control should be removed. So there's no case where switching widths between wp and other sites will become necessary for people who are savvy enough to know what the button does. The difference is that with full-width as a default, those who don't know what means (I'd guess about half of readers) will be able to use their knowledge of native methods to get their preferred width, where they would be completely stuck otherwise. And "preferred width" doesn't just mean something to do with reading speed/comfort. On desktop, with the messiness of most wp articles, it can determine whether someone can read at all, with wide tables, MOS:SANDWICH issues, etc. small jars tc 00:22, 27 March 2023 (UTC)

That’s only maximized and regular, not different custom configurations. Aaron Liu (talk) 13:54, 27 March 2023 (UTC)

As far as I can tell, without any additional extensions, MacOS lets you configure doubleclicking on the title bar to either minimize the window, or to maximize it to full screen, and doesn't offer custom configurations. Windows offers maximizing through doubleclicking on the title bar, as well as snap to side through shortcuts. isaacl (talk) 16:26, 28 March 2023 (UTC)

ah, then none of the resizing things are solved with this. Aaron Liu (talk) 17:21, 28 March 2023 (UTC)

• Option 3, but Option 1 is better than 2. I still prefer limited width as the default for everyone, but failing that, showing a modal is better instead of a sudden change. EpicPupper (talk) 23:35, 23 March 2023 (UTC)

  Don’t you mean unlimited width? Tvx1 01:44, 24 March 2023 (UTC)

  There are improvements with limited width, and but failing that clearly indicates that they meant limited. Aaron Liu (talk) 19:07, 24 March 2023 (UTC)

• Follow Consensus as established in Isabelle Belato's close. If it gets reclosed, changes can easily be reversed. With regards to the second question presented in this RfC, arguments presented by both sides were very similar to the first question, in that some like the new limited width and others do not. Some of those supporting an unlimited width noted that many articles contain galleries, tables, etc., and were negatively affected by the new width. There was a lot of discussion on whether scientific papers reached any form of consensus on the best width, with both sides presenting studies with opposing views on the issue. The large amount of whitespace was one of the main concerns of those who supported the rollback of Vector 2022. Since the arguments are equal in strength, there is rough consensus to make unlimited width the default. Also per this close, Another point of contention was the fact that, while it is trivial for registered users to change back to the old skin if they dislike the changes, unregistered users do not enjoy that option. Many of those supporting the rollback were sympathetic editors who saw this as problematic. The only refutation offered to this was that the new skin was shown to be, according to the aforementioned studies and surveys, an improvement for readers, especially due to the reduced text width, implying that any change that only applies to registered users is missing the point. I feel that we are being dragged through the same time-wasting discussion again in the hope that chance (and manipulative framing, where the actual consensus is only implicitly a choice via option 3) might push consensus a different way. small jars tc 23:59, 23 March 2023 (UTC)
• Anything short of following community consensus is unacceptable Unlimited width should be default. If the WMF is unwilling to make this good-faith measure, the RfC should be overturned and the result changed to Consensus to roll back default. Toa Nidhiki05 00:23, 24 March 2023 (UTC)

  This doesn't make sense. Why should consensus be changed on the basis of someone not following it? Retribution? there might be other reasons that the RfC needs reclosing, but not this. small jars tc 00:29, 24 March 2023 (UTC)

  Given that fixed width is the number-one complaint people have, the idea that there's no consensus to rollback even if it says seems extremely tenuous. Tying both aspects of the RfC together seems reasonable. Toa Nidhiki05 00:36, 24 March 2023 (UTC)

  Yeah, but WMF doesn't have to do that. They could literally pick anything they wanted to keep and ignore the rest per CONEXEMPT. Cessaune [talk] 03:15, 25 March 2023 (UTC)

• Strongly oppose creating two different experiences for logged-in user and logged-out users by default, per Femke and the previous discussion on this idea which does not seem to be reflected in this new proposal. This idea did not receive support after it was last proposed, is not what the RfC suggested, and is simply a very poor idea. Editors edit based on what they see as readers, if there is a different default experience then editors won't be editing for what the majority of people see. (As a side-note, amused by the argument "Instead of suddenly changing the width for millions of readers" given the context.) CMD (talk) 01:10, 24 March 2023 (UTC)

Didn’t we already have a consensus at the RFD? Why are we discussing this again? Did I miss something? The close in the RFD literally says there is rough consensus to make unlimited width the default. Pizzaplayer219^Talk_Contribs 02:21, 24 March 2023 (UTC)

The WMF has deemed that a stupid-ass decision and elected to ignore it. Toa Nidhiki05 03:18, 24 March 2023 (UTC)

• I don't think we should do Option 2 - existing logged in users may have set/unset/set again this and got it working just as they like it already, so don't force a change on them. phab:T332505 has already been created to request functionality to be created to allow this to be a project setting, and how the default should apply to new registered users — xaosflux ^Talk 12:34, 24 March 2023 (UTC)

  @Xaosflux: unbolding to prevent misread as "support option 2" Aaron Liu (talk) 19:21, 24 March 2023 (UTC)

• I think we should randomize the width and then you only get the page if you guess the correct value. (yes, sarcasm) —TheDJ (talk • contribs) 14:21, 24 March 2023 (UTC)

  More seriously. I think this is VERY unwise. This is the moving of goal posts just because some people want to be uncooperative. This makes WMF very vulnerable, all because we want to keep it moving forward. I have said this many times in the past, it is unwise to give this much freedom and options to the community. People will NEVER be satisfied and they will always be the ones who turn up. en.wp doesn't get a say in this other than take it or leave it. Switch everyone BUT en.wp over and then degrade their experience like EVERY other site in the world does. —TheDJ (talk • contribs) 14:43, 24 March 2023 (UTC)

  Many sites degrade the experience to fit in ad sidebars. Wikipedia doesn't need to do that, even if the change necessary for those other sites is given a positive spin. Certes (talk) 15:12, 24 March 2023 (UTC)

  Yup and you don't have to use those sites either. —TheDJ (talk • contribs) 15:41, 24 March 2023 (UTC)

• Note: as phab:T332505 (allow a setting for default state of vector 2022-width) has been declined the request to set it for enwiki (phab:T332426) is now impossible. Someone would need to challenge that decline and reopen the ticket to get those requests moving again. — xaosflux ^Talk 16:26, 24 March 2023 (UTC)

  Note: These are now back to blocked on development / Stalled on blocked. — xaosflux ^Talk 17:30, 24 March 2023 (UTC)

  Perhaps we should just decline Vector 2022, just temporarily while the promised changes are stalled or blocked. Certes (talk) 18:08, 24 March 2023 (UTC)

  @Certes: We can't just "decline" V22, this is a server-side config change that we can't make through editing due to the JS/PHP/Mustache/HTML/IDK nature of skins.Aaron Liu (talk) 19:21, 24 March 2023 (UTC)

  Note: It was closed by TheDJ who is not with WMF.Aaron Liu (talk) 19:21, 24 March 2023 (UTC)

  But is a MediaWiki developer. —TheDJ (talk • contribs) 22:07, 24 March 2023 (UTC)

  Yeah but only WMF has the authority to override consensus and invoke CONEXCEPT. Aaron Liu (talk) 13:20, 25 March 2023 (UTC)

• Option 4: As Xaosflux proposed, make unlimited width the default for new editors and don't touch existing editors' settings. I'm still mixed on IP editors as WMF has a valid point on this and I've been mixed on this throughout the RfC, and it was closed 92 to 64. Aaron Liu (talk) 19:21, 24 March 2023 (UTC)

  TBF, I documented the second part of that, but didn't propose it. But agree that existing end users should be left alone. — xaosflux ^Talk 20:03, 24 March 2023 (UTC)

• Comment A formal challenge of the RFC's closure has been initiated. I think this discussion should be suspended until such time that controversial close has been properly dealt with.Tvx1 17:50, 28 March 2023 (UTC)

  @Tvx1 They can continue in parallel. I don't see anything suggesting that people disagree that there was consensus to make unlimited width the default. Aaron Liu (talk) 18:55, 28 March 2023 (UTC)

• Thanks for this thoughtful reply. Whatever the outcome, please don't create a different default experience for logged-in and logged-out users. A premise of the RFC is that editors want to be using the same layout as readers, and care about the reading experience. They want to see concerns about the reading experience resolved before the default changes.

For logged-in users, Option 4: don't force a change, but make the default for new users wide. A modal is great, you could offer that to everyone, and on first log-in for new users. For next time: you might change prefs so that "default" is always distinguished from actively choosing that setting by hand.

For logged-out users: simpler to offer the same modal that logged-in users get, not just a tooltip. That reduces confusion for people who switch between logged-in and logged-out states. Don't force a change for logged-out users who have set their width pref by hand. – SJ + 21:06, 28 March 2023 (UTC)

This can be a joyful message about a new feature, not a bureaucratic one:

"Now you can switch between narrow and wide reading modes, depending on the page!"   (image highlighting where the toggle is).

"Choose a default width for browsing."   (modal option w/ illustrative images)"

Discovering this option should be a quality-of-life improvement for basically everyone: some pages want to be wide, and readers already manually expand their browser window to read them. In keeping with the RfC, when the initial choice is provided to readers, the default selection should be wide. – SJ + 13:00, 30 March 2023 (UTC)

Given the review was abruptly closed with little explanation, I want to reiterate my stance I gave in my vote: the only acceptable outcome here is that unlimited width is made the default. This can be done with or without the WMF. It has been months now, and the backlash hasn't gone away; the strategy of running out the clock simply isn't working. Toa Nidhiki05 19:39, 29 March 2023 (UTC)

• Why not do File:Mockup of modal for Vector 2022 width selection.png but do it for logged-out users? They've had a couple months to experience limited width, now you ask them to make a choice. This way, we know for sure what readers want (and aren't relying on samples and surveys), and I'm sure the community will be satisfied (notwithstanding the RfC result), and everyone will be using the width of their preferences so people will be happy too. ProcrastinatingReader (talk) 07:52, 31 March 2023 (UTC)

  If I had to guess, such a modal would be annoying to logged out users, who would see it every time their cookies were lost. Snowmanonahoe (talk) 11:24, 31 March 2023 (UTC)

  Fair, though I wouldn't suggest retaining the option indefinitely. After a couple weeks I'd imagine the results are clear enough, and then we could use the majority result as the default, of course retaining the preferences of anyone who has explicitly set one. (I suspect even this would need refinement for good UX, but just roughly sketching out an idea.) ProcrastinatingReader (talk) 13:29, 1 April 2023 (UTC)

April 6th Response

Hi everyone.  Thank you again for all your feedback and for taking the time to be a part of this conversation.  We see that many of you have a wide range of opinions.  We collected these and  made this quick summary on the main points we’ve heard from the discussion so far:

1. There is the concern that having a different default width for readers and editors would affect the quality of the layout for all users.  This concern is present in the cases where two separate defaults are present, as it also was in the past, when the width was unlimited (as it was then restricted by the size of a user’s monitor)
2. Some of you suggested that the presentation of the option to select full or limited width should be the same for both logged-out and logged-in users.
3. Some of you expressed concern at whether a modal is too intrusive for logged-in users, and whether we can explore a more subtle option.
4. Some folks are happy with our proposal to allow for both logged-in and logged-out users to select the width they are comfortable using.
5. Some folks are disappointed with our decision to not proceed with full width for logged-out users.

Overall, we see that there is agreement that we should keep the logged-out and logged-in experiences as similar as possible, and that introducing two different defaults would set a precedent that will force many articles to appear worse.  We agree with this concern - it’s important that layout choices are made when similar widths are used across all users.  This was one of our original motivations behind introducing a fixed width across all users.   Additionally, we see that the idea of providing users with the choice to select their experience was received well, with many also sharing the concern that changing settings which logged-out or logged-in users have already selected would be disruptive for them.   There is also interest in continuing to measure the usage of width preferences and iterating based on what we learn, specifically after increasing the prominence of these preferences.   Based on this feedback, we would like to suggest the following:

1. Begin with displaying a tooltip informing users of the location of the toggle for full width, with the objective of making it clearer that users have this choice.  Display this tooltip for both logged-in and logged-out users.  As some of you mentioned, the copy/language of this tooltip will be very important.  We will draft a couple of versions of this copy and can share here for feedback on accuracy and neutrality.
2. Display the tooltip and collect data on usage of the toggle for two weeks.
3. After two weeks, share the data with the community and propose next steps.  If full-width usage increases markedly, then we’ll learn that there are people who do prefer full-width who need the option to be clearer.  Here are some ideas for what we might want to do if we see high usage:
   1. Logged-in users: Continue displaying the tooltip upon account creation.  This way, all new logged-in users will be aware of their ability to change the width.
   2. Logged-out users: As some of you pointed out, displaying a tooltip on every session is most likely not a sustainable long-term solution.  If tooltip usage indicates that future users would also benefit from clearer information on changing the width, we can begin to explore different options.  For example - collecting all current and future settings for logged-out users (such as width, page previews state, as well as future settings such as dark mode or font size) in a single easy-to-find menu.  We can discuss these options together once we have collected, analyzed, and shared the data from the tooltip experiment.  

If you’re interested in tracking our work, please take a look at these two Phabricator tickets: T333601, T333600. What do you think of the plan presented above?  We know this proposal may be disappointing to some of you and would like to talk to you further, for those who are interested. We would like to propose a session with Selena, our CPTO, and some of our staff to talk together about how the Vector process has gone, hear thoughts from the community on the current plan, and plan the future of software decision-making together.  We can also take some time to go over our current prototype and other plans for improvements to the skin in the future. This session will take place on Thursday, April 13th at 18:30 UTC on Zoom (click here to join / dial by your location).  We look forward to hearing your thoughts and comments.  Thank you! OVasileva (WMF) (talk) 21:45, 6 April 2023 (UTC)

I think that a tooltip would be insufficient to gather unbiased data, as the data would likely be skewed towards the default setting since inaction (ignoring the tooltip, closing the tooltip) is easier than action (reading the tooltip, using brainpower to figure out what the tooltip is talking about, clicking the button). Perhaps a random subset of users should receive the modal at the beginning of their session that forces a choice.

The modal should have extremely neutral wording, such as "Wide width / Narrow width" instead of "Unlimited width / Existing width" ("existing" is biased). And "Select wide width / Select narrow width" instead of "Revert to unlimited text width / Keep existing width" ("revert" and "existing" are biased). Then this unbiased data can be used to figure out what width readers prefer. Hope this helps. –Novem Linguae (talk) 22:56, 6 April 2023 (UTC)

"Existing" is not just biased but also confusing, as a wide column is the status quo ante. Certes (talk) 16:50, 7 April 2023 (UTC)

Finding that no one switches could be consistent with at least two hypotheses. One is that everyone loves a narrow column of text and is delighted with the blank space beside it. Another is that no one hovered over the tool tip long enough to discover the right sequence to switch widths or even to guess that such a facility exists. How do you propose to distinguish between those two hypotheses? Certes (talk) 16:48, 7 April 2023 (UTC)

A tooltip is something that points you to the button, not the button itself. Aaron Liu (talk) 17:01, 7 April 2023 (UTC)

@Certes - thanks for the question! I admit that "tooltip" is a bit of misnomer here. Technically what we are proposing is an indicator that will show by default upon loading the page, pointing to the button itself (would not require hover). Something similar to the tooltip we use for when the table of contents is collapsed

. We're still figuring out the exact logic here, but what we would hope for is to show it on page load for the first page of a session for all users. When used, a confirmation indicator would also appear. Hope that clarifies things. OVasileva (WMF) (talk) 17:16, 7 April 2023 (UTC)

That's better, but I think the logic still applies. Not everyone knows that the ⋮☰ symbol beside "Beaver" means "click here to show a table of contents". Similarly, they may not guess the meaning of the new icon or even find it, however apt and clearly designed. Certes (talk) 17:21, 7 April 2023 (UTC)

I guess you could make a tour around new skin. But... I'm not sure if it is worth the time to develop such a tour as it might be hard to do with i18n and l10n in mind. To show what I mean here is an example OPAC that has a tour (start the tour with a question mark button). The software library used for that is bootstraptour.com, but there were no i18n features built into it (from what I recall) and it does need Bootstrap, which Mediawiki doesn't use, so you would probably need to find something else. I don't have figures on this feature of our OPAC because we can't track underage users... but librarians are happy with the software (98% recommend it in a recent survey). Nux (talk) 10:45, 8 April 2023 (UTC)

If we're confident that readers prefer a narrow column, let's run the experiment the other way round. Restore the pre-2022 default of full width, have an option to reduce the width accessed via a suitable icon, and see how many readers select it. If it's a majority, then let's make life easier for them by changing to narrow width. Certes (talk) 18:23, 8 April 2023 (UTC)

Or run an AB test; give some users full width, others limited. The test as proposed by the WMF will not tell us anything as users who don't know how to switch, and users who don't care enough to switch, will be registered as preferring limited width. BilledMammal (talk) 18:27, 8 April 2023 (UTC)

I agree with an actual AB test. Either way we still need actual data instead of that very suspicious survey, for which the raw responses still haven't been released. Aaron Liu (talk) 19:03, 8 April 2023 (UTC)

I Think you need a better description than fixed width. Go open a usepage in 1080p then click move tools to sidebar. It ceases to be fixed width. Beyond that just save everyone time and effort and go with the RFC result. Then if it is thought desirable we can plan a proper AB test (all you're proposing is a flawed test of tooltips).©Geni (talk) 16:20, 9 April 2023 (UTC)

It's still fixed width though? The fixed width is a cap, it's not like it can't be responsive. Aaron Liu (talk) 18:41, 9 April 2023 (UTC)

• Please run a proper A/B test, with controls for the confounds noted above. Skin usage studies so far do not have enough power to infer much about user preferences. – SJ + 20:31, 9 April 2023 (UTC)

  Ex: A test of {modal, tooltip} + {default wide, default narrow} + {logged-in, logged-out}, run on a modest set of readers (1% of sessions for a few days, at most once per session & once per IP). – SJ + 20:31, 9 April 2023 (UTC)

Copy options for indicator/tooltip

Hey everyone,

Thank you for participating in the conversation so far.  As we mentioned before, we wanted to show you all a couple of options on the copy for the indicator which will be displayed alongside the toggle.  We would appreciate your thoughts and comments, as well as other suggestions for the copy.  Once we have the copy finalized, we can begin the test as early as next Monday (April 24).  

Proposed copy:

• Neutral state: You can toggle between limited width and unlimited width by clicking this button.
• If going from limited width to unlimited: You have switched your layout to unlimited width. To go back to limited width, press this button.
• If going from full width to limited width: You have switched your layout to limited width.  To go back to unlimited width, press this button.

Variations on the copy 1:

• Neutral state: You can toggle between a fixed width and full width by clicking this button.
• If going from fixed width to full: You have switched your layout to full width. To go back to fixed width, press this button.
• If going from full width to fixed width: You have switched your layout to fixed width.  To go back to full width, press this button.

Variations on the copy 2:

• Neutral state: You can toggle between a limited width and full width by clicking this button.
• If going from limited width to full: You have switched your layout to full width. To go back to limited width, press this button.
• If going from full width to limited width: You have switched your layout to limited width.  To go back to full width, press this button.

Thank you! OVasileva (WMF) (talk) 23:25, 19 April 2023 (UTC)

To clarify, is the "unlimited width" you speak of the 'limited' unlimited width we have currently, or an actual border-to-border unlimited width? Thanks for the clarification. Cessaune [talk] 01:17, 20 April 2023 (UTC)

I think it’s the one we have currently (not sure what you mean by ‘limited’) and that this section is only about wording Aaron Liu (talk) 11:59, 20 April 2023 (UTC)

Yeah, should be obvious that unlimited doesn't mean flowing off screen or something like that. Or maybe not obvious? Maybe full width is better? The icon for the layout switch is kind of like full-screen icon, so that would fit nicely I think. Nux (talk) 12:52, 20 April 2023 (UTC)

Yeah, I support copy 2. Aaron Liu (talk) 13:13, 20 April 2023 (UTC)

I haven't been following this closely, but I thought the original plan was to make a modal and not a tooltip. Why was this changed? InfiniteNexus (talk) 16:16, 20 April 2023 (UTC)

I don’t know if this has changed or not, but the original plan included a tooltip for logged-out users. Aaron Liu (talk) 16:41, 20 April 2023 (UTC)

Why not display a modal for both logged-in and logged-out users? InfiniteNexus (talk) 16:45, 20 April 2023 (UTC)

Because you’d need to dismiss the modal every time you didn’t have the cookie. Aaron Liu (talk) 18:26, 20 April 2023 (UTC)

The same thing would happen with a tooltip. That is, a tooltip would also show up every time if a user doesn't have cookies enabled. InfiniteNexus (talk) 20:50, 23 April 2023 (UTC)

Yes, but it's way less intrusive than having to dismiss a modal. Aaron Liu (talk) 22:41, 23 April 2023 (UTC)

Tooltip

Is it just me, or was a tooltip "You can toggle between a limited width and full width by clicking this button." just deployed for all users? Aaron Liu (talk) 21:06, 8 May 2023 (UTC)

I got it too. Snowmanonahoe (talk) 21:14, 8 May 2023 (UTC)

Same. Cessaune [talk] 00:43, 9 May 2023 (UTC)

Tooltip bias

So, did anyone else notice that since Day 1 of the addition of the tooltip back in May, it has been implemented in a one-sided way? It only shows the message when switching away from fixed width, and shows nothing when switching away from unlimited width. The only tooltip visible reads "You have switched your layout to full width. To go back to fixed width, press this button." This seems like the kind of thing that might bias the results of the experiment. (If I'm just an unlucky recipient of some weird meta-A/B test on both my devices, and it shows up correctly for others, please let me know!)

I know I'm beating a more-than-dead horse at this point, but I thought it should at least be mentioned somewhere. 2607:FB91:1308:2422:9177:61FD:80D7:650F (talk) 13:11, 17 June 2023 (UTC)

2607:FB91:1308:2422:9177:61FD:80D7:650F, I believe this is because the default is fixed width, and so anyone switching to fixed width must have switched to unlimited width previously.
I'm curious what experiment you're referring to. — Qwerfjkltalk 13:40, 17 June 2023 (UTC)

This is my experience when I repeatedly toggle it on and off ... the tooltip continues to reappear every time I switch away from unlimited width (which itself is bizarre behavior).

Actually, that's what makes it an issue to me, I suppose. If it is going to show up every time I click the button in one direction, it should also show up every time I click the button in the other direction.

EDIT: Oh, and re: experiment, I thought maybe the tooltip was going to be part of an experiment collecting metrics on how often logged-out users choose each option. Maybe I misconstrued that. 2607:FB91:1308:2422:9177:61FD:80D7:650F (talk) 13:46, 17 June 2023 (UTC)

2607:FB91:1308:2422:9177:61FD:80D7:650F, I'd ask any questions at Wikipedia talk:Vector 2022 or WIkipedia:Village pump (technical). — Qwerfjkltalk 16:25, 17 June 2023 (UTC)