Wikipedia:Village pump (proposals)/Archive 192

This proposal in a nutshell: In one to two weeks, we would like to begin the conversation to update the default desktop design of Wikipedia to the Vector 2022. We are interested in deciding on the process we want for the conversation before discussing the change itself. This is because we want to have a good decision-making process that allows for a way to identify the needs of the community from the new skin.

Hi everyone,

We would love to see the Vector 2022 skin (see what it looks like) become the new default on desktop across all wikis, including English Wikipedia. The skin would be turned on for all anonymous users, and also all logged-in users who now use Vector (the current default). Logged-in users are and will be able to switch to any of our other available skins, including the current Vector. We will be ready to begin making the change at the end of August (and not in July, as previously announced), when the visual refinements and other deployment blockers are ready.

The goal of the project is to make the interface more welcoming and comfortable for readers and useful for advanced users. The project consists of a series of feature improvements which make it easier to read and learn, navigate within the page, search, switch between languages, use page and user tools, and more. The team has been working on this change for the past 3 years, ensuring that every change is thoroughly tested and proven to work.

Making this change is important for both readers and contributors.

We need your help and feedback on how to proceed. We have two requests:

1. We need to talk in a way that works well for the English Wikipedia community. What would be the best format and timeline to discuss the change? We have included a proposed format below, and are interested in what you think about it. If you agree, we can begin the deployment conversation in one week. Here is our suggestion:
   1. Have the deployment conversation that would take 2 weeks. The goal for that discussion will be to identify breaking issues or opportunities for improvement for the new skin. It will be important for us to reduce the risk of bugs or imperfections that would be particularly troublesome on English Wikipedia
   2. After the deployment conversation, we get back to you with a prioritized list of remaining work/fixes necessary prior to deployment
   3. Before the deployment,
      1. Banners announcing the change will be displayed for logged-out and logged-in users
      2. The announcement will be made both on the Village Pump as well as in the Tech News.
   4. We proceed with deployment once the agreed upon fixes are ready.
2. We need to understand the perspectives of different parts of the English Wikipedia community. What forms of communication would help to gather feedback and further raise awareness for the English Wikipedia community? We would like to have an open discussion, but are open to other forms such as requests for comments, office hours dedicated specifically for the English Wikipedia community, or guest presentations at community meetings. If necessary, we can also adjust the timeline of conversations based on your needs.

We welcome your replies here, or via email ([email protected], [email protected]), as well as during our next office hours (26 July).

Thank you for your time and help. OVasileva (WMF), SGrabarczuk (WMF) (talk) 12:05, 13 July 2022 (UTC)

The comments from jawp above suggest that this change may not be entirely uncontroversial, with some editors feeling that it is not an improvement. Will enwp be allowed any say in whether the change is rolled out at all, or is it being imposed with our only input being into the details? Certes (talk) 12:48, 13 July 2022 (UTC)

No matter what change, there is a guarantee that a certain amount of people will not feel like it is an improvement. That in itself is a very bad metric for decision making. Are the points being made valid, is there an opt out, what other problems are we solving and are the people responding an accurate representation of the larger group of users. Those seem like much more critical questions to me. —TheDJ (talk • contribs) 13:08, 13 July 2022 (UTC)

I didn’t like it at all when I tried it, but I’ve been won over after spending some time with it. Doug Weller talk 13:14, 13 July 2022 (UTC)

Is there a list of blockers that are being accepted as blocking tasks right now?

• I think the table of contents handling parts are the biggest problem right now. We currently have a lot of control over the TOC placement and display, which seems much harder or impossible with vector-2022.
• Personally, I think with our "wide vector-2022" gadget option being an option for editors, general editors may be OK -- if we can ever get control over what is going on with the left sidebar - it comes, it goes, it is hard to control.

— xaosflux ^Talk 13:08, 13 July 2022 (UTC)

Here are 2 examples of the sidebar with the wide gadget: an article that doesn't for a TOC, and article that has a displayed TOC. In the later, the entire sidebar will collapse, but only at certain display sizes, there is a task out there about being able to collapse the TOC - but very notably, even when collapsed that sidebar stays open an empty. Is the "grid" work going to address that at all? The sidebar element seems to be part of the content container. — xaosflux ^Talk 13:11, 13 July 2022 (UTC)

I quite like the wide-vector-2022 layout and I'm sure I could be won over after a few weeks of it being the default. I think I'm in the minority when I say I like the ToC positioning on the left (but only on wide-vector). I strongly dislike the normal (non wide) version of Vector 2022, and I've left comments here on why this is. As for the OP's question: I don't think enwp will take kindly to a discussion about setting Vector as the default while these issues of narrowness, ToC placement, and unnecessary top banner whitespace exist. Anarchyte (talk) 13:31, 13 July 2022 (UTC)

I don't hate the side-bar based TOC in vector-2022 (even with wide mode) - I mostly hate that when all the sidebar elements (toolbar, and hopefully soon to be TOC) are collapsed or docked, that the sidebar can't be collapsed without also adding in javascript hacks - I'd think this should be possible with css and a layout that allows it to widen if there are contained elements pushing the margin. — xaosflux ^Talk 13:38, 13 July 2022 (UTC)

Hiding the TOC and then regenerating a custom TOC (as in this article does achieve what I'm looking for I suppose - not sure why that is so hard? — xaosflux ^Talk 13:42, 13 July 2022 (UTC)

Perhaps something the team could look into could be having the __TOC__ magic word forcing the TOC to exist within the page instead of in the sidebar. Anarchyte (talk) 14:38, 13 July 2022 (UTC)

Hey @Xaosflux - thanks for the feedback, and quick answer to the sidebar question (I'll follow up on your other points around magic words a bit later). Once the new ToC collapsing behavior is ready (phab:T306660), the gadget should work again to stretch the full width if both the sidebar and the ToC are collapsed OVasileva (WMF) (talk) 13:37, 15 July 2022 (UTC)

@OVasileva (WMF) thanks, looking forward to trying that out - I think it will at least alleviate some worry for logged-in-editors that have concerns about "too narrow" - likely some of the more heavy power editors that are using wide desktop monitors, I don't think it is a big deal for casual readers. From initial notes below, seems like the loosing control of Table of Contents styling in general is at least an emerging concern among editors - I'd hate to see ugly hacks get pushed by the community if there is an impasse (like the continuing problems going on in Wikipedia:Village pump (proposals)#RfC: Showing Editnotices to mobile editors below with Mobile Front End and developers preventing certain elements from being controllable). — xaosflux ^Talk 13:52, 15 July 2022 (UTC)

• Regarding TOC handling in general, for example in these articles editors have specified a custom right-sided TOC, which vector-2022 overrides. — xaosflux ^Talk 13:34, 13 July 2022 (UTC)

  It seems quite inconsistent though, see this article in vector where editors have determined the best TOC layout type, compared to it vector-2022. — xaosflux ^Talk 13:46, 13 July 2022 (UTC)

  I think the primary reason we have customized TOCs is when they are very long. Of the most common variants, the floating variants ({{

  horizontal toc

  }} all exist to deal with a long table of contents. General point: except for people who customize their skin selection away from Vector22, I don't think we need to support these at all in the new skin. We can leave the templates alone right now for those people who do use the other skins, if we want. Specific points:

  1. Floating variants: simply don't care
  2. Toc limit: With a per-level collapsible table, totally obsolete.
  3. Horizontal toc: Maybe the only interesting one, since its major use cases are 'letter/number-driven' lists and large categories, and I expect that a TOC that long will be rough on the sidebar version (I haven't checked yet). I think there's probably a feasible feature request somewhere regarding category tables of contents.

  I think forcing the TOC to appear in page besides maybe that last one isn't needed at all (and I don't think that needs anything more than the customization we can already build with a template). Izno (talk) 19:59, 13 July 2022 (UTC)

phab:T306246 was mentioned above in #Consultation on Search improvements by CX Zoom and Ahecht and myself. That must be solved, and not by updating documentation, declaring it not a bug or closing it as a duplicate of $random other task. (I occasionally see tasks getting closed without a real solution so I'm just saying) I see plenty of open tasks on phab:T309972 so there's plenty to do. From a UI perspective, I suggested some improvements on phab:T302641, that alone is a hard deal breaker to switch for me personally. — Alexis Jazz (talk or ping me) 20:31, 15 July 2022 (UTC)

@OVasileva (WMF) / @SGrabarczuk (WMF) - I think the entire design/implementation/documentation/testing about page meta-content and collisions with content things like our "coordinates" templates (see also -Wikipedia:Village_pump_(technical)#Coordinates_in_Vector_2022, phab:T292617, and phab:T281974) may be a bit of a blocking issue here - seeing as we make use of these features on literally millions of pages. I fear there seems to be a bit of tension in layout/design goals between skin developers and community use. What are your thoughts on the best way to reconcile these sort of things? — xaosflux ^Talk 12:41, 22 July 2022 (UTC)

SGrabarczuk (WMF), if you choose to make this change, it will be important to the success of the change to have a team of developers available to monitor forums where bugs and feature requests are reported, create phab tickets actively, and resolve those tickets quickly. Too often, new features are rolled out in beta form (I'm thinking especially of the Visual Editor) and then the development team appears to move on to new projects, leading to bug reports that linger for years (I'm thinking especially of the Visual Editor). I encourage you to designate a place local to en.WP, de.WP, Commons, and other large MediaWiki installations, where editors can report problems without having to travel to unfamiliar sites with different interfaces and watchlists, like mediawiki.org. – Jonesey95 (talk) 14:38, 13 July 2022 (UTC)

Hi @Jonesey95. Oh, that's a very fair comment. I'm giving a bunch of quick replies to different parts of your comment. I hope these bits make sense together:

1. VE was launched, correct me if I'm wrong, like... 9 years ago? we've learned a lot since that. For example, earlier this year, when planning the current Californian fiscal year, we decided that we would dedicate some time this summer and fall (the first months of the fiscal year) just to further improve Desktop Improvements if needed. So that part's safe, not only in our hearts, but on the governance level, too.
2. As a result, some bugs and feature requests will definitely be handled. Depending on how much related to Desktop Improvements, these will either be just done or considered as part of future projects.
3. Vector 2022 is the default on ~30 wikis. On a few of these, incl. French Wikipedia, it has been the default for almost two years! So they've done a great deal of bug-reporting/feature-requesting already. I think both our team and other communities may be truly grateful for that.

SGrabarczuk (WMF) (talk) 15:04, 13 July 2022 (UTC)

Thanks. I wish you luck. If all goes well with desktop improvements and the developers find that the set-aside time is available for other work, maybe some of the team can work on the VE backlog and officially get it out of beta status. A bunch of us gnomes who clean up errors that it generates would be very grateful. – Jonesey95 (talk) 15:52, 13 July 2022 (UTC)

?? "Vector 2022" has been the default on frwiki since 2020? Does it have time traveling properties? — xaosflux ^Talk 18:22, 13 July 2022 (UTC)

@Xaosflux, you are kidding, right? Let's make it clear for everyone around: back then, it wasn't labelled as "Vector 2022", but it was there. We've been adding more and more features and changes, but the first ones (different logo, collapsible sidebar, limited width) have been the default on some wikis since July 2020. SGrabarczuk (WMF) (talk) 19:11, 13 July 2022 (UTC)

@SGrabarczuk (WMF) Yes, that was mostly humorous, just contrasting that the entire current incarnation it hasn't had 2 years of bake-in. — xaosflux ^Talk 19:17, 13 July 2022 (UTC)

Yeah, right. It's a good opportunity to make it clear that this interface isn't static, really. These incarnations are like ogres - both have layers. Some are two years old, and some (like the sticky ToC) are two months old. The older a layer is, the more people have actually used it, noticed bugs, advocated for improvements, everything. It's not like we're pulling Vector 2022 with everything about it out of a hat. I hope it's reassuring. SGrabarczuk (WMF) (talk) 19:29, 13 July 2022 (UTC)

WP:Thanks, WP:Nuke, WP:Page Curation, Special:RecentChanges. Not anything people really use, you know. — Alexis Jazz (talk

or ping me) 21:03, 15 July 2022 (UTC)

I suggest having a page somewhere that essentially functions as a press release and/or a list of FAQs. At the miminum, link this page in the banners (i.e. with a CTA: 'Read more about the upcoming change!') so that 1. non-registered visitors can read more about the impending changes (and possibly encourage them to register as editor even if it is just to revert back to the previous skin); 2. interested publications may organically pick it up as a story for their audience. – robertsky (talk) 18:08, 13 July 2022 (UTC)

Great idea, @Robertsky! We're working on a page on wikimediafoundation.org (for readers, media, the "general public"), and we'll definitely have a more detailed FAQ for editors. SGrabarczuk (WMF) (talk) 18:18, 13 July 2022 (UTC)

I'd recommend that said press release/FAQ page should also include instructions on how to revert back to the older vector skin. I imagine that there will be a fair few (including myself) using the current vector who would like revert back to the older form, and while I know how to switch skins, there are some who may not be familiar. Hog Farm _Talk 19:58, 13 July 2022 (UTC)

For this change to be a success you can't just impose this on enwiki; you need consensus from the community. Are you willing to open an RfC that seeks to obtain consensus to implement this change? BilledMammal (talk) 21:25, 13 July 2022 (UTC)

@BilledMammal, I think the proposal pretty much answers your question. Let me rephrase a part of the first message: in the next conversation, we'd like to talk what remains to be done instead of having a yes/no situation. And we do mention RfC there, too. SGrabarczuk (WMF) (talk) 22:36, 13 July 2022 (UTC)

Your comment comes across as if this is a done deal, with only small details (what remains to be done) to be worked out, but the community needs to be able to reject this. It needs to be able to say that it is not satisfied with the current version of Vector 2022, and instead ask you to come back and see if

consensus has changed

when you believe you have addressed the objections raised in the discussion.

To rephrase my question; are you willing to open an RfC that seeks to obtain consensus to implement this change, with an option that will permit the community to reject the change? BilledMammal (talk) 22:53, 13 July 2022 (UTC)

+1 to User:BilledMammal's comment. In that vein: Consider me an Oppose to switching the default. On my screen at least, V2022 has a very poor layout that looks unclean and would create a poor impression of Wikipedia, forced upon us by the WMF. I want to see a finished product before everyone without an account (that is the majority of users) are suddenly switched to a new (worse) look. Happy Editing--IAmChaos 21:44, 13 July 2022 (UTC) edited 01:50, 14 July 2022 (UTC)

We believe this change is extremely important for readers, and have a lot of data and research that can help us prove this.  That said, we understand that that community might need more from the skin than what is currently developed. That’s why we hope to get into the details so we can identify what needs to be changed before the conversation on whether and when that change will happen begins. That said, to be clear, we will not be rolling out the new skin prior to coming to such an agreement with the community. SGrabarczuk (WMF) (talk) 16:46, 15 July 2022 (UTC)

@SGrabarczuk (WMF): Thank you, I am glad to hear that. Are you able to provide us with the data and research reports so that we can consider this change in that context? BilledMammal (talk) 22:35, 16 July 2022 (UTC)

@BilledMammal see § UX research and usability testing below. There's a great deal available there and at other pages, so please specify what else you're seeking if you'd like additional research. {{u|Sdkb}} ^talk 22:40, 16 July 2022 (UTC)

Thank you, I missed that. BilledMammal (talk) 02:13, 17 July 2022 (UTC)

@IAmChaos Olga and Szymon explicitly structured this conversation as a meta-conversation about process, not a !vote on implementation. Let's respect that by avoiding bolded !votes, just as we do at VPI. {{u|Sdkb}} ^talk 23:02, 13 July 2022 (UTC)

I appreciate that. I will unbold. Happy Editing--IAmChaos 01:50, 14 July 2022 (UTC)

I think just waiting until the "final" release version is ready and usable before starting any discussions on adding it is best. While prototypes are still ongoing it isn't great to start any discussion on a non "final" version when signficant changes can still occur and the outcomes on changes are not released. Using the latest prototypes: Color schemes, borders, toc highlighting & logo choices should be able to be viewed at the point the discussion starts rather than lumped in at the end and not allowing anyone to voice their opinions on these choices specifically isn't a good idea. Terasail^[✉️] 22:02, 13 July 2022 (UTC)

@IAmChaos, @Terasail, we're not there yet. Please take a look at the proposal. You'll find the replies there. We don't have a definition of a "good enough" product. (In a way, it will never be quite "finished", just as most Wikipedia articles never are.) We'd like to make it together with the community, and now, we're asking how do you think we should do that. SGrabarczuk (WMF) (talk) 22:34, 13 July 2022 (UTC)

It sounds like this product, if approved, will see regular releases. Will these releases also be discussed with the community or will they be

boldly implemented? BilledMammal (talk

) 22:58, 13 July 2022 (UTC)

@BilledMammal, I'm not sure I understand your question. What do you mean? Could you elaborate on that? SGrabarczuk (WMF) (talk) 23:26, 13 July 2022 (UTC)

@SGrabarczuk (WMF): If I have understood you correctly this version of Vector 2022 is not the final version; instead, it will see regular significant updates. My question is what your process for implementing these updates will be; will you do them boldly or will you discuss them with the community first?

In some ways, this question is related to my question above from 22:53, 13 July 2022, which I believe you may have missed. BilledMammal (talk) 00:58, 14 July 2022 (UTC)

Thanks for clarifying your question! What we mean when we say that this is not the final version is:

• We still have some identified issues (documented as tasks) that are not resolved. This is the list that is under this task.
• The two-week conversation we're proposing would be meant to help us define the version upon deployment. We need agreement between our team, the needs of readers, and the community in the identification of what their needs from the skin are. What are the blockers to changing the default? That is the conversation we are currently trying to set up.
• Once deployed, we plan on continuing to work on the desktop experience. Our next focus will be on improving some of the features we’ve built here, but also using some of the things within the new interface to begin exploring goals that are even further-reaching, such as encouraging more interested readers to begin editing.  With Vector on most Wikipedias, we didn’t change the skin for 12 years. This project, while improving usability for existing tools, did not add or remove any current tools from the interface. Once it’s done, it gives us the opportunity to work with communities to provide new and necessary tools both for readers and editors. This is a process that is ongoing and will be done with the feedback and collaboration of the community here and across other projects.

SGrabarczuk (WMF) (talk) 17:18, 15 July 2022 (UTC)

Thank you for clarifying this as well. I am glad to hear that you will seek input and hopefully consensus from the community before implementing any significant updates. BilledMammal (talk) 22:35, 16 July 2022 (UTC)

@SGrabarczuk (WMF) Firstly, thanks for your reply, I appreciate you being willing to answer so please don't feel like I'm jumping on you specifically, its just that you brought this here and I figured I should voice my concerns with a switch to V22. @Sdkb replied to my earlier comment, and I agreed so I modified it with their suggestion. I strongly believe though, even in this so called "meta" conversation about process, we shouldn't be ignoring the issues. Logged out editors are the most populous user, even though they have practically no voice in ProjectSpace discussions. If we are to implement a change to what they see (ie default settings), we need to address this more than other things, because those affected won't discuss it. Here's a quick list of what I've found.

1. The TOC issues. They are being overriden against specific decisions by editors who chose to design a page a certain way. for example, see Alien, which is the first page alphabetically that uses {{TOC right}}, why should V22 override, there is no precedence in monobook, timeless, minerva which are the other skins installed on enwiki. I think overrides like that (and there may be others, this is just what I have seen conversation about above) should fall to editors, not to software.
2. The look of it. Not to be mean to the team who worked very hard on it, and I appreciate what you've done for the MediaWiki community, but I feel that there are (in the current state) some things objectively worse. Why is there just blank space to the right of articles when V(legacy) reaches the edge of my screen? Why is there space blank to the left of the sidebar that is just white? The sidebar is highlighted in gray which only makes the large blank more obvious.
3. In a similar vein to the blank space - the bar across the top is unbalanced - The user icon is all the way to the right over the blank space, but the arrow on the left is indented like the sidebar, it looks unbalanced.
4. This one is a much more niche issue - and probably one that you will never work on (and don't need to at least for enwiki), but for a user such as myself who has a long sidebar - multiple scripts add links to mine, the TOC is impossible to find for multiple sections - for example on Butetown - I have scrolled down to section 4 (#Welsh language) before the TOC is caught up with me. This may be a concern though for other projects that have added links to their sidebar, such as my private mediawiki site, which has many sidebar links for my convenience.

On the note that I have now spoken about your hard work in a less than stellar light, I again apologize if I came across as harsh, but these are things that I feel need to be addressed before such a big switch for such a prominent website in today's world. Again, I don't want to come across as rude, but I feel we shouldn't rush into this, and that as sdkb called it, the 'meta-process' should include the community's voice on the actual skin itself, and how it could work for enwiki, instead of just how it will be rolled out. (full disclosure: I havent looked at the deployment blockers you linked, because that's a long phab list, and I still don't quite understand all the lines on it, but I will and am open to the possibility that there are other concerns that are more pressing or maybe I'm a complete minority opinion.) Happy Editing--IAmChaos 02:20, 14 July 2022 (UTC)

I find myself agreeing with you here, particularly on aesthetic grounds, where it looks almost amateurish to me. I have not yet had the time to introspect on why I’m receiving that impression (perhaps I’ll update this later though), so take my take with a grain of salt. I definitely think it’s important not to rush this, considering the extreme outsized effect UX design seems to have on people. Yitz (talk) 03:29, 17 July 2022 (UTC)

@Yitzilitt, thanks for mentioning the aesthetic aspect. Look at this page. We simply haven't built that part yet, because we've been focused on changing the features. We'll implement the visual changes in the next couple of weeks. SGrabarczuk (WMF) (talk) 15:48, 18 July 2022 (UTC)

Hey @IAmChaos — thank you for your feedback, and apologies for my delayed response. We appreciate your honesty here.

Regarding your comments about whitespace and the look of Vector 2022: I’m curious if you have been able to take a bit of time to sit with the new skin, and if so, if that has changed any of your opinions so far? The reason why I ask is: several editors who have given feedback and collaborated with us over the past two years have initially disliked Vector 2022 (often for similar reasons), and then after a few weeks of using it they have come to appreciate the changes that have been made, and even ended up liking it more than legacy Vector.

Some design-specific notes regarding the whitespace: the majority of research on readability and reading comfort over the past ten years have concluded that limited line-length, and whitespace surrounding the text, are critical to a good reading experience (more info here). So we started by limiting the line-length, which ultimately leads to limiting the width of the entire interface (otherwise we would end up with even more whitespace). I know it’s a big adjustment, and it feels like there is a lot of “wasted” space. Fortunately there are several community members who have already begun to develop scripts and gadgets to address this, resulting in a more dense version of Vector 2022 (we were joking that it’s kind of like Monobook version of Vector 2022). You can find those gadgets and scripts here. From a process standpoint: the layout has been worked on and reviewed extensively by the entire WMF design team, supported by the majority of community members who have given feedback over the two year development process, and proven via testing to work better for both logged-in and logged-out people in various ways. So while it may not look aesthetically pleasing to you at this time, we wonder if you can go more in depth in terms of what makes it objectively worse. I am of course happy to discuss these topics further with you.

Regarding your comment about the long sidebar pushing the table of contents down the page: fortunately this is a functional issue so it is easier for us to discuss and agree on. In case you have not yet seen it I invite you to first look at our latest prototype here: https://vector-2022.web.app/Flamingo. You will find that with the tools menu moved to the article toolbar the sidebar becomes much shorter (and please note that the tools menu is able to be pinned to the right side of the article for immediate access upon page load). Secondly, due to the infrequent use of the remaining items in the main menu, we expect that over time most logged-in people will discover their experience is improved by collapsing the main menu (allowing for immediate access to the table of contents upon page load), and then opening the main menu when needed.

Thanks, AHollender (WMF) (talk) 23:27, 28 July 2022 (UTC)

Thanks for the reply @AHollender (WMF). I have looked a bit more, and noticed that I hadn't collapsed teh sidebar which addressed part of my issues mentioned above - particularly the long sidebar hiding the TOC. I will definitely look into the research on readability, I personally find it disconcerting as the software used at my day job is chock full of information too all four corners of my work desktop, all of which I need access to, so maybe it's a bit of Status quo bias in my comfortability with a crowded workspace, but I feel like after looking around there are a few places I don't quite feel fit together right. As for an example where it doesnt match up well: Clicking on Special:Random today brings me to an article in V22. The Categories box is the width of the article, followed immediately by a horizontal line the width of the screen and the footer info is full width across the bottom. I will definitely be looking into the community scripts with density, thanks for the link. Happy Editing--IAmChaos 03:46, 29 July 2022 (UTC)

Hey @IAmChaos — ok right, so this is related to your earlier comment about the width of the header. So how we've currently setup the page layout is:

- there's a max-width for the entire interface, which is currently 1514px. This is the max-width that the site-header, sticky header, and footer all have

- there is a max-width for the content, which is currently 1244px for pages that have a table of contents, or 960px for pages that do not. Again, this max-width is the result of first establishing a comfortable line-length for the article text, then finding a reasonable width for the table of contents. Once we move the tools menu to the other side of the page, if you decide to pin the tools menu this max-width will then be 1514px and everything will be balanced. To explain visually:

Currently this is the situation, with the blank space you're noticing called out in red:

However if your screen is less than 1325px wide (which most laptops are), there is no longer a blank space:

Once we move the tools menu to the other side of the page, if you decide to pin the tools menu this max-width will then be 1514px and everything will be balanced:

Unfortunately, aside from having the tools menu pinned, there's not really an easy way to make these max-widths match. The easiest thing to explore would be limiting the max-width of the site header to 1244px. However if we did this, and then you decided to pin the page tools, the max-width of the site header would have to change in order to stay aligned.

I hope this is helpful. I can promise you that we are also concerned about possible imbalances in the page layout, are keeping a close eye on this, and are on the lookout for opportunities to achieve better harmony. Your comments are super helpful to us as we continue to explore our options here. AHollender (WMF) (talk) 16:39, 29 July 2022 (UTC)

A request for comment is an open discussion. It's just an open discussion that is geared towards assessing consensus rather than discussing something in the abstract, or as in this topic, having a discussion where you create a plan. So a request for comment, which often runs for 30 days but can go shorter if consensus is clear or longer if discussion remains active, advertised on

WP:CENT feels like the right way of having this open discussion with the enwiki community. Best, Barkeep49 (talk

) 01:34, 14 July 2022 (UTC)

One extra thought. If there's a sense that consensus might be initially hard but there's a courage of conviction that the skin will genuinely help, some sort of testing, whether through a trial period (owing to enwiki's massive reach lots of data can be collected in shorts period of time), or through A/B testing, with clearly defined metrics could lead to a consensus that wouldn't be there without that data. This is something the Growth Team has done to large success. Best, Barkeep49 (talk) 01:39, 14 July 2022 (UTC)

I like a lot of what Skdb has said below, particularily that it will be an uphill battle for it to gain acceptance. Another factor is that the enwiki users being asked what they think about the change would generally be the heaviest users; casual readers won't see any future RfC's. These users are probably most accustomed to Wikipedia's current look and would most likely be relatively quick to oppose in my opinion. I also think that starting an RfC about 'Should Vector 2022 become the default after it is modified' (so that the RfCs aren't forcing the community to do things and don't have that appearance, also forestalling complete skin opposition in other RfCs) and then following up with one about 'what should those modifications be' could be a good idea. That assumes the community would reject the skin in its current form. —Danre98^{(talk^contribs)} 00:05, 15 July 2022 (UTC)

I would second both thoughts by Barkeep. Specifically, (1) a full 30-day policy RfC, listed on CENT and following the requirements of

WP:PROPOSAL, is the gold standard and the only realistic path to legitimacy for such a large change. (2) The change is much more likely to gain consensus with solid supporting data from A/B testing. Best, KevinL (aka L235 · t · c

) 00:39, 15 July 2022 (UTC)

FWIW, I am a moderate user (just under 10 edits per day average over the past year, but with over 5,000 pages on my watchlist). After using Monobook for many years, I switched to Vector 2022 a few months ago. It felt a bit wierd at first, but I am now quite comfortable with it. Of course, you are much more likely to hear from users that don't like it than from the rest of the spectrum of user reactions. - Donald Albury 15:56, 15 July 2022 (UTC)

Agreed. Doug Weller talk 17:24, 15 July 2022 (UTC)

Re BilledMammal, Barkeep49, IAmChaos, Sdkb comments on this page about consensus...YES. Changing the editing experience by default for Vector 2010 users without an Opt in....not my favorite and would probably guarantee a strong blowback. Changing the editing experience around here is always fraught with challenges and difficulties (Yeah, VisualEditor...), the chief among them, for me at least, is that I am an editor. I am not someone who approached Wikipedia editing from a developer/programmer/coding/data point of view, I'm just an editing/researching/writing fool and I think there are many of my kind amongst named Wikipedia accounts. I just stumbled upon this discussion by accident and probably wouldn't have known that a change was coming/had been instituted until it happened...
And a plea for the future... If the Vector 2022 skin comes online can we please have clear/easy-to-understand Opt-Out instructions? Maybe have them come up for six months afterwards for Vector 2010? Maybe have an Easy-to-find/Clearly-labeled FAQ for the changes and for Opting-Out? When the "Section edit/Reply to individual posts" change came online recently (I'm sorry but I can't quite remember what the name actually is/was) it was Not Easy to find how to disable/Opt-out from the change. Heh, at least it was not easy for me and I have over 35K posts... That's about all, I'll try to keep up and follow this discussion so it won't be another Big Surprise to me. Shearonink (talk) 17:01, 15 July 2022 (UTC)

Hey @Shearonink, first of all, I understand you. I became a Wikipedian years before I was hired by the Foundation. I personally, as well as other staffers at the Foundation, know that there are thousands of people not editing every day, not engaging in the Village Pump discussions, and finding it difficult to adjust to technical changes impacting the editing experience. So the link to opt-out is and will be available in the Vector 2022 version of the sidebar (left menu). As we wrote, we are also thinking about putting up banners before the launch. SGrabarczuk (WMF) (talk) 17:46, 15 July 2022 (UTC)

It is unfortunate that the en.wiki editor community has been determined through all obstacle to keep this embarrassment of a UI stuck in the year 2001. Despite many excellent proposals for reform of the Main Page, it remains a dull and outmoded layout; the left sidebar is cluttered and unusable by all who have not become accustomed through years of use to its contradictions. Here we have a vector that is far more modern, far more intuitive and far more pleasant for readers—the only problem is that editors who have been here for many years can't possibly approve of it because they've optimised their workflow within the current janky hackjob we have, and the slightest change threatens that.

There are suggestions for changes to the skin that would be useful, but the website's design should not be motivated by the navel-gazing within the editor community. It is apparent in many editor discussions on design that articles are overly focused on how it looks on the editor's desktop view, when most readers will be on mobile. There are discussions for us to have on what the new layout will mean for ToC placement, but we cannot hash out every small detail before first agreeing the adoption of the new layout. There are complaints here about interaction with gadgets and Javascript: this means that those bits of code need to be changed, not the website layout. Many of these gadgets are operating under UI assumptions that are not some functional specification guarantee.

We should not hold back on improvements due to complaints of a vocal minority, but go forwards with the quantitative testing-approved solutions to the problems identified by readers and editors (see below for the WMF's explanation of each stage of this project). — Bilorv (talk) 20:46, 16 July 2022 (UTC)

discussions on design that articles are overly focused on how it looks on the editor's desktop view, when most readers will be on mobile - It's possible to give different views for mobile and desktop readers; I don't think we should be catering for mobile to the exception of desktop. I also note that even the current mobile view is less than ideal; I switch to desktop view when reading from mobile because even there it is easier to read the article in that format. BilledMammal (talk) 22:40, 16 July 2022 (UTC)

I think you've missed my point, BilledMammal, perhaps because I didn't make it clear enough. The issue is not that desktop layout doesn't matter, or that making a good desktop layout contradicts making a good mobile layout. It's that editors generally consider their own layout only (often a desktop layout and specific browser and specific skin) and give no thought to other layouts. As editors, we should be thinking as much about mobile (or more!) as about desktop. But we don't, and that is one example of how editors are not the best people to consult about UI changes. — Bilorv (talk) 08:03, 17 July 2022 (UTC)

Ah, I see what you are saying now - I fully agree, we do need to consider this on a variety of platforms, and even if it isn't currently suitable for all platforms it may be suitable for some. Below, I have actually asked for some data to be presented separately for desktop and mobile users. BilledMammal (talk) 02:53, 18 July 2022 (UTC) Struck following clarification that this is only proposed for desktop. BilledMammal (talk) 04:43, 23 July 2022 (UTC)

Agree with this. I find Vector 2022 much more modern and have been using it for a couple of months now. The only hitch was getting used to all the links being under a dropdown menu instead of listed at the top. Sungodtemple (talk) 03:18, 4 September 2022 (UTC)

Sdkb comments

I've been following/commenting on New Vector throughout the development process and have a lot to say here, so with apologies in advance for the length, I'm creating a subsection.

@SGrabarczuk (WMF) and @OVasileva (WMF): In some other circumstances, I've encouraged the WMF to plunge forward with seeking consensus for deployment, even though development isn't yet complete. My advice here is the opposite: we're not ready for that conversation yet. Users of any site are inherently biased against redesigns, and with Wikipedia's community consensus model, that gives you an unenviable uphill climb if you wish to succeed where past efforts have failed. Because of this, there will be a certain level of guaranteed opposition, and to overcome it, you'll need the design refined enough to get every winnable editor on your side. New Vector has improved a lot over legacy Vector, but I don't think it's at that point yet.

Some of the changes are fairly simple things. For instance, looking at the ToC to the left right now, it ends a ways before the bottom of the page, resulting in an ugly scrollbar that likely could've been avoided if it just extended the full vertical length of the page. Making refinements like that will help avert a gut "this is ugly" reaction and could making the difference between consensus and no consensus.

Other changes are more fundamental. The reduced screen width is something I'm fairly used to at this point, but it seems to be a sticking point with many others. Given that, I think you need to decide how many of the New Vector changes are segmentable. I.e. if the community says "we're okay with everything in New Vector except the screen width" or "we're okay with everything except the ToC", will you be able to implement that? I know you'd prefer to be able to implement everything, but if it has to be an all-or-nothing decision it'll make your task all the harder, because opposition to any one element could foil the entire proposal. So I'd put some thought into what can be segmented out vs. what has to be bundled.

On the ToC, getting it to display so that it doesn't require scrolling in normal cases, even when the main menu is uncollapsed, is something that I predict will be crucial for getting community buy-in. We've been discussing it on MediaWiki, so let's continue the conversation centralized there.

Lastly, I'll reiterate that I think that the upper right corner is going to be a sticking point. We've previously discussed (with Izno and others) how the decision to commandeer that spot for the language switcher appears to have been made based on user research that began with the baseline assumption that making it more prominent was an inherent good, ignoring the other elements that currently occupy that space and that are also important. In your most recent newsletter, you write that the page tabs/title switch moved the language button into an even more prominent position at the top of the page, once again making this assumption, and once again ignoring that you're pushing the other elements down yet another row. When we've brought up those elements, namely coordinates and good/featured article icons, you've declared them out of scope for your project. I don't understand that — you consider it in scope to push them out but not to care about where they're pushed to? Helping readers understand through the site design which articles have undergone a peer review is absolutely crucial for information literacy, and I really wish you'd convene one of your focus groups to understand whether they have any clue about GA/FA currently (my guess is no) and, if not, what can be done through design to fix that (my suggestion is moving them left next to the article name).

If you manage to address these sorts of things, I think it'd be possible to start a productive conversation on making New Vector a default few months from now. That conversation could incorporate multiple steps as you suggest, and it'd probably best take the form of a CENT-listed and watchlist-advertised RfC. If you start it prematurely, though, I think the combination of reasonable and knee-jerk concerns will result in failure to reach consensus, which would set you back. (And I hope it goes without saying that attempting to push through the changes without community consensus would result in a

@Sdkb Thank you for your thoughtful reply and thoughts here, and for being super helpful and giving us feedback throughout the process! Apologies for the long response time - we’ve been monitoring this conversation and replying to quick questions, but wanted to sit with your comment for a little bit to make sure we can address all the points you raised. Here are some of our thoughts and answers - curious what you think as well:

1. Thank you for flagging that you think the conversation feels a bit premature. We're very excited to begin bringing the changes to readers as well as to flag where the issues are early on, but agree that the next step would be to continue at a longer timeline than the three weeks we had originally suggested. We would like to continue the conversation by identifying which blockers we have for deployment, making sure that our understanding of “finalized” matches that of the community here. In future iterations of this conversation, we’ll also make sure to highlight this point so as to avoid confusion.
2. ToC issues. Just adding note here, but also agree we can continue discussing in the other thread - sorry for the repetition! We’re currently working on some improvements to the ToC for narrow screens, tracked in phab:T306660 which we hope to have live next week. In these, we have improved the styling of the ToC so that the scrollbar does not appear unless actively scrolling - I agree it’s pretty unsightly. Does that alleviate your concerns somewhat? In the future, after the deployment, we plan on separating more tools out from the main menu, such as the page specific tools. These changes will also allow all menus to be individually collapsible and can also serve as the first step to a more highly customizable system. They will also shorten the main menu significantly. That said, as these changes are pretty technically significant, we would like to confirm the plans for the new default before beginning this next part of our desktop development.
3. On the reduced width - I agree this is tricky. We do have some capability to offer customization, but this becomes more difficult to maintain and test with every option we add. To us, the best case scenario would be to continue to promote the use of individual gadgets and scripts among editors, but if this is deemed insufficient, we can begin scoping out a potential setting for logged-in users. That said, it’s probably not something we’d be able to offer for every feature - it would depend on the request, how difficult it would be to maintain, and how independent it is of the other changes we’ve introduced.
4. Coordinates and upper-right corner issues. This is a priority for us right now as well. In terms of the prominence of language switching - getting higher priority for languages is an important aspect of the project’s goals which are to focus on growing our readership and communities globally. This includes an enormous audience for whom language switching is crucial, and who tend to use a global language, such as English or French, in addition to their local language, for learning on a daily basis. We want to make sure we’re taking their needs into account as much as those who are native speakers. That said, we need to make sure the other elements like indicators and coordinates work well with the new location. This has been tricky as the location of these has traditionally been in the hands of the community. Our view on this is that the order should be as follows (vertically): language button, tabs, indicators and coordinates. Indicators and coordinates should appear on the same line and preferably, coordinates would be treated as indicators. We'll be adding some more thoughts and hopefully some ideas for next steps on the current conversation in VPT.

Hope this is helpful! We’ll continue getting into the details on the individual threads as well, but can also definitely keep talking here too. Also we hope to post a longer response to everyone that’s been involved in the conversation here later today on the next steps in the process. OVasileva (WMF) (talk) 12:27, 27 July 2022 (UTC)

@OVasileva (WMF), thanks for the reply! On the ToC scrollbar, it's not the scrollbar itself that's ugly so much as the fact that you have to scroll to see the full ToC. The entire point of a ToC is to let you see a summary of a page without having to scroll through it all, so if you can't do that, why have a ToC at all? This is certainly an issue for larger articles or talk pages. One possible solution to explore is having the ToC width double when you hover the cursor over it so that less needs to go onto two lines; does that make sense as a concept? {{u|Sdkb}} ^talk 04:12, 29 July 2022 (UTC)

I think that spacing the TOC entries out less would be a good idea as well. The current TOC is just a bit too "fluffy" in my opinion. CactiStaccingCrane (talk) 04:14, 29 July 2022 (UTC)

Hey @Sdkb - thanks for replying to the reply! You bring up a good point. Hovering on the ToC is something that we had initially explored in our first prototypes which we tested with groups of readers and editors in English, Spanish, and Indonesian (more details on the report page). However, we saw that across all groups, people preferred having the ToC shown in full without having to take an action (such as hover or collapse) to view it. So we decided against it and opted for maximizing the space within the sidebar instead to show as much of the ToC as possible. It's possible that later on, we can explore a more specialized solution for cases where line wrapping is particularly prominent (such as talk pages like you mentioned). For now though, I think the tradeoff of having the ToC available persistently is worth the introduction of scrolling in some cases. Our A/B test data came in recently and we're seeing a 50% increase in clicks to the ToC. We'll be monitoring this over time, but are really happy to see that it's helping people navigate back and forth across the page more. Next we'll be looking at the scrolling data - we hope to see a similar decrease in scrolling that we saw with the sticky header. OVasileva (WMF) (talk) 08:51, 2 August 2022 (UTC)

I am just an editor/reader that uses one language (as well as "many" others I suspect) so please consider this when "prioritizing". If it is rushed there will be more negativity than imagined.

A consideration has to be given to those that write before it can be read. From what I read, in a search, it seems that "a reader could be forwarded to the English Wikipedia without any reference to a page in their native language, especially when the page does not exist in the Wikipedia of the redirect's language". This would mean that ease of language change would be helpful.

Otr500 (talk) 02:04, 5 September 2022 (UTC)

UX research and usability testing

Note, I am an engineer that uses terminals a lot and I still use the MonoBook skin. But, here's a question. If moving to the new Vector skin is controversial, why not commission and publish an extensive user-centered design case study to prove that the Vector 2022 is actually better. Then the community will have to see reason. (Maybe) Andrevan@ 03:23, 15 July 2022 (UTC)

Hey all,

A number of you have asked us about our research and testing (both Qualitative and Quantitative), so we wanted to write a pretty detailed and long comment to address this. We wanted to confirm that not only the Growth team conducts complex testing :) This is more like the standard for big projects now. Each feature change has gone through the process below (which we also described in the Signpost in April). This is what gives us the confidence that everything we have built so far is, in principle, an improvement. At the same time, we acknowledge that there's room for more adjustments.

1. Problem identification research with both readers and editors - during this phase, in 2019, we studied the way people used the site and identified the largest usability issues as well as issues to exploring the site further, becoming more engaged with reading or editing. We did this by interviewing readers and editors across multiple countries and locations. (See the links: Research and design: Phase 1, Research and design: Phase 2.)
2. Prototype development and testing - this is when we build out the ideas of a feature and begin showing solutions to our audiences. Each feature was tested with readers and editors through interviews and wider rounds of prototype testing. Generally, for testing with editors we used central notice across multiple language Wikipedias, including English Wikipedia, so that we can get the widest audience possible. Each prototype was tested by approximately 200 editors on average. (Example)
3. Refining and building - we then take the feedback from the prototype testing and refine or change the prototype based on what needs were identified in the prototype testing. In some cases, we ask for additional feedback during this process so that we’re sure we’re making the right decisions.
4. A/B testing and other quantitative testing on pilot (early adopter) wikis - we perform a quantitative test for whether the feature works as expected based on the criteria of success we have previously defined. For example, the sticky header was designed to decrease scrolling to the top of the page. We gave the sticky header to 50% of users and compared them to the other 50% for two weeks. After two weeks we compared the results and identified that people who had the sticky header were indeed scrolling less to the top of the page in order to select any of the tools available there. If we get negative results from our test, we change the feature and test again. This is the "beta" phase. During this phase, we also monitor usage across all wikis, including English Wikipedia, where many account holders are already using the new skin.
5. Finally, we deploy Vector 2022 on more wikis and continue monitoring the way people are using it so that we can flag any issues. In this phase, Vector 2022 isn't "beta" anymore. It's more like a B-class article. Different wikis have different thresholds for B-class, and we believe that in the case of English Wikipedia, we'll be there when the visual refinements and other deployment blockers are ready.

We are currently working on an easy way to explore all of the above data and research (and are welcome to suggestions on the best format). For now, the best way to learn more about the testing is:

• From Reading/Web/Desktop Improvements/Features, select the feature you are most interested in
• Within that feature page, refer to the Qualitative or Quantitative testing section to see the results and our conclusions

Just so we can have a short version of this as a part of this conversation, we're posting a quick list of our learnings:

OVasileva (WMF), SGrabarczuk (WMF) (talk) 16:14, 15 July 2022 (UTC)

Thank you for posting this; there is a lot to read through so I have only reviewed two features so far, sticky header and persistent table of contents. For the latter, it appears you have yet to conduct A/B testing but when you do I would be interested in seeing data on the percentage of page views that involve at least one click on the table of contents, and the percentage of page views that involve at least two clicks on the table of contents. In addition, I would be interested in seeing separate data for mobile users and desktop users. Struck following clarification that this is only proposed for desktop. BilledMammal (talk) 04:43, 23 July 2022 (UTC)

For the former, I see you have already conducted A/B testing but there is some additional data that I would like to see:

1. Currently, you show the clicks per session and clicks per page only when skinversion=2; I would be interested in comparing this to the clicks per session and clicks per page for skinversion=1. My hypothesis would be that the sticky_header makes it more convenient for readers to access these links, and thus increases the number of readers using them.
2. The rate of accidental clicks. Assessing this would vary by link, but I have a few ideas and am happy to discuss further if required. My hypothesis would be that the sticky_header increases the number of accidental clicks, and we would need to consider whether this increase offsets the benefits of the sticky_header.
3. Time on page, time on page when limited to pageviews that do not involve following a header link, and time on page when limited to pageviews that involve following a header link. Clicks on pages with stickyHeaderDisabled would need to be split between those that involve a scroll back and those that do not. My hypothesis would be that it does not affect time on page for readers who do not click on a header link, and that it has a small but relatively constant absolute decrease in time on page for readers who follow links on the sticky_header compared to those who scroll back to click on a header link. The former would suggest that this does not negatively affect the reading experience, the latter would suggest that that this has a positive effect on the reading experience for readers who are wanting to navigate to one of those pages.

Alternatively, is there raw data that we can look at from the A/B testing for the sticky header? I suspect it won't answer #2, but it may contain information on #1 and #3.

BilledMammal (talk) 03:33, 17 July 2022 (UTC)

@BilledMammal - thanks for your questions! You bring up some really good points that we considered during the design phase of the experiment. The full data analysis is available here: https://jenniferwang-wmf.github.io/Web_sticky_header/. In terms of your questions:

1. Comparing overall clicks. This is something we can look into and report back. The reason it wasn't a main goal for the A/B test is because we wanted to focus on decreasing scrolling (i.e. making the site easier to navigate by requiring less of the user) rather than setting a goal for increased interactions. As in, we would still consider the feature a success if people used the tools as frequently as they did before but had to scroll significantly less in order to do so. That said, I agree with your hypothesis that we most likely would see a significant increase in clicks as well.

2. Accidental clicks are a bit trickier to measure. Generally, with new features, we get a lot of clicks in the first day or so after deployment (which are generally more based on curiosity than accident). This is why we run our tests for an extended period of time - 2 weeks, to make sure it's sufficient time for people to get used to the new functionality and begin using it as they would naturally

3. We discussed looking at time on page at the beginning of the test but decided to look at scrolling specifically instead. While I personally believe that your hypothesis is correct, we've had some issues in the past with looking at the time on page metric and receiving conflicting data. For example - time on page may actually increase over time with the sticky header available because people would be less frustrated with not being able to access specific tasks and thus more open to spending longer on our sites overall. The same is true of scrolling - people might scroll more overall because the site is easier to use. This is why we specifically looked at scrolling to the top of the page as we thought it was the clearest signal that people are going there specifically to find one of the tools available in the sticky header. OVasileva (WMF) (talk) 09:06, 2 August 2022 (UTC)

@OVasileva (WMF):, thank you for your reply, both here and below.

To summarize my position; I see the tests you have done as testing whether the feature is used, but not anything beyond this. With this, it is only possible to come to the conclusion that this proves that each feature is an improvement if the pre-existing assumption is that the feature is an improvement, and thus the user experience is improved so long as the feature is used; I understand how you can see this differently, but I disagree.

I do agree that time on page isn't a perfect metric, but I believe it is a better metric than what is currently being used, and I also believe that those concerns can be partially addressed. For example, looking at the various options on the header bar the only one that I can see plausibly altering behaviour is the search bar, with readers using it more and doing a shallow dive into multiple articles rather than a deep dive into one; to address this we could separate the data into sessions that use the search bar and sessions that don't.

Regarding accidental clicks, that is a good point regarding the curiosity clicks; most methods to identify accidental clicks that I am aware of would likely see those as false positives. Are you able to identify which sessions belong to same logged-in user, as that might offer a way to exclude most curiosity clicks? BilledMammal (talk) 16:46, 7 August 2022 (UTC)

Has anyone actually used the link given at the very top as "see what it looks like" on a smartphone? For me, instead of getting an encyclopedia article, I get a full screen with the sidebar and no encyclopedic content until I scroll down. Can other people please test this? Because this seems like a quite major bug or worse experience than the current mobile version.

Same bug here but only if I'm using the mobile view in a browser. If I'm using the desktop view on mobile it works fine (and actually looks quite nice). With this said, it may be a non-issue as I've not read anything about mobile transitioning away from MinervaNeue. Anarchyte (talk) 09:01, 17 July 2022 (UTC)

FWIW, I see the same bug as Fram does, on both a Macbook laptop (not mobile) running Safari 14.1.2, and on an Android phone running Opera 69.3.3606.65458 in desktop mode. I just see a banner at the top, a sidebar on the left, and a big blank space on the rest of the page. I have to scroll way down past the sidebar before I see any content, and the content fills the full window width (that is, the sidebar is not to the left of the content, it's above it). There's also no visible TOC on the left side or anywhere, just a hamburger icon that I have to click on to open a TOC. I do not see this bug on Firefox 102.0.1 on a Windows machine. It seems there is still some browser dependency that makes this skin very unpleasant to use in some environments, and not only mobile ones. CodeTalker (talk) 00:51, 18 July 2022 (UTC)

Confirming I see the same thing as Fram in mobile view on Firefox 101.2.0 on Android 11. Desktop view looks intentional. Folly Mox (talk) 18:01, 18 July 2022 (UTC)

It looks great to me (tablet, mobile & desktop) if the sidebar's collapsed. ― Qwerfjkltalk 21:29, 18 July 2022 (UTC)

This is indeed what you see if you force the mobile website to the desktop website/skin (not something anyone but a few realistically is doing) and you open the menu (for me the menu is collapsed by default on that size). While this desktop skin is more compatible with mobile and will eventually probably be fully suitable for mobile, that has not been the primary target of these changes. I believe there is an invite on its talk page asking people for feedback and ideas on what the menu SHOULD look like on mobile. But don't forget that lots of the content is not mobile compatible (minerva on the mobile site has all kinds of hacks to make content not break out of the mobile constraints) and Vector 2022 doesn't have those hacks. So for the immediate future it is still better to use the mobile website on mobile. —TheDJ (talk • contribs) 08:49, 19 July 2022 (UTC)

Apparently you get the same bad results on a Macbook laptop though, see above...

Fram (talk

) 09:21, 19 July 2022 (UTC)

I've just tested this on a Macbook in Safari and can't reproduce the issue - the link destination looks exactly as intended. Sam Walton (talk) 10:39, 19 July 2022 (UTC)

And of course, nothing in the opening statement of this section said anything about this not being for mobile and only for desktop, it just said that this would become the default, full stop.

Fram (talk

) 09:23, 19 July 2022 (UTC)

Just to confirm, this conversation concerns changing the skin on desktop only. This will affect the desktop view on mobile as well, but not the current default mobile view. OVasileva (WMF) (talk) 13:27, 20 July 2022 (UTC)

On desktop (not mobile), using Firefox on a MacBook Pro, if I click on the suggested Galaxy link and narrow my window to about half my screen width, I get a view in which only the left toolbar is visible. The rest of the window is blank. The article itself is off-screen below the toolbar. This is a normal width to narrow the window for when I want to see two apps at once, and much wider than its minimum width (which I sometimes use as a quick test of mobile views). On the other hand, when I view it in full screen width, only maybe 60% of the window width is dedicated to content, with maybe 10% sidebar and 30% unused blank space. This extreme sensitivity to window width, unusability on too-narrow windows, prioritization of sidebar over content, and inability to use much of the real estate on too-wide windows, makes this seem like a non-starter to me, but maybe these are things that are still subject to improved design before the push to roll this out to the world? —David Eppstein (talk) 01:29, 8 August 2022 (UTC)

@OVasileva (WMF): Backing up here, can you clarify whether the team has tested the new skin altogether for readers yet (as opposed to the individual feature changes like sidebar and header)? Sorry if you or someone else said that already and I missed it. It's cool you tested the independent impact of each change, but to help make final decision on the default, it's also important to see whether all the changes holistically had impact on basic readership metrics (unique visitors, bounce rate, time spent on page, etc.) Thanks, Steven Walling • talk 03:06, 31 August 2022 (UTC)

Hi @Steven Walling, thank you for your question! Here is a quick overview to the approach to monitoring:

To ensure the success of the skin as a whole, health metrics are defined with the purpose of monitoring across the usage of the skin as a whole. This monitoring happens across all the partner projects where the skin is already default (thus, it is possible to monitor the different stages and states of the skin over time, so that we can quickly identify if any given feature was affecting the health metrics negatively). This allows monitoring of large projects (such as French Wikipedia or Japanese Wikipedia) as well as smaller projects across a number of languages. These metrics include pageviews, unique devices, edit rates, account creation, and more.

Because it is difficult to run A/B tests on logged-out users for long periods of time, the focus is on monitoring significant fluctuations in the short term, and also on reviewing on a quarterly basis to establish any long-term trends (which are compared to the long-term trends of similar wikis where the skin is not default). So far, we have found slight increases in account creation on initial pilot wikis, no decreases in pageviews attributed to the new skin, and no decreases in active editors or overall editings attributed to the new skin.

As mentioned above, time on page is not used as a key metric since fluctuations in time spent on the page can be quite misleading without having more detailed data on precisely what people are doing during this time (which generally would require tracking that is complicated and potentially not privacy-friendly). For example, an increase in time on page could be seen as negative - many of the our new features (such as a persistent ToC and sticky header) are designed to save people time in scrolling. But it could also be positive - the new experience makes a wiki so much easier to use that people are spending more time reading and interacting with the content. OVasileva (WMF) (talk) 13:03, 5 September 2022 (UTC)

Thanks for reply! This all makes sense. I'd just suggest during the RFC that you link to / summarize the health monitoring metrics for the Wikipedias where the new skin is the default, in order to show the community that in addition to the A/B test results, the rollout of the skin has either improved or not regressed key metrics. People will continue to have feedback based on what their individual preference is, but these data really help prove that the skin is worth changing the default to for readers. Steven Walling • talk 16:31, 5 September 2022 (UTC)

Easy switching skins

After I switched to the 2022 skin, I noticed a new link "Switch to old look" in the left margin, right below the "donate" link. But in the legacy (current) skin there is no corresponding "Switch to new look" link. Why not? wbm1058 (talk) 05:21, 23 July 2022 (UTC)

@Wbm1058 that is a temporary link designed to help anyone that is all of a sudden lost in the change to get back to being able to get around again. — xaosflux ^Talk 11:40, 23 July 2022 (UTC)

I understand that, but the purpose of the "Switch to new look" link is to give readers a heads up that the change is coming so that they can check it out if they opt to. Then hopefully feedback on the changes is given in a manageable trickle so that things can be fixed before a hard change is made that causes an angry mob reaction. Not everyone is as tuned into this as you are; the only way I've become aware of this is from seeing the change in the French and other foreign-language versions. Not everyone is a power-user like me who reads foreign language wikis using Google Translate.

Will the French 2022 skin and the English 2022 skin be the same width, or is the English 2022 skin wider than the French 2022 skin? – wbm1058 (talk) 15:05, 23 July 2022 (UTC)

@Wbm1058 by default all of the vector-2022 skinned sites will have a similar look and feel. We have a opt-in gadget available if you want vector-2022 but in wide mode (mostly for wide screen desktop monitor users); it is still getting some improvements. — xaosflux ^Talk 16:01, 23 July 2022 (UTC)

It looks like this. — xaosflux ^Talk 16:04, 23 July 2022 (UTC)

Wide vector-2022 on a page with a TOC , there is work pending on a collapsible TOC for vector-2022 overall still. — xaosflux ^Talk 16:06, 23 July 2022 (UTC)

And for users like me, will it be easy to use the version suitable for a large monitor on my PC and the other on my iPad. Doug Weller talk 17:20, 23 July 2022 (UTC)

If it became popular, a toggle such as "dark mode" toggle could possibly be built. — xaosflux ^Talk 17:02, 25 July 2022 (UTC)

Tracked in Phabricator
Task T313747

This is a great question, @Wbm1058. When we made the decision to put this link into the sidebar, the project was on an early stage. Now I think we could revisit this and put an equivalent link into the legacy Vector sidebar. SGrabarczuk (WMF) (talk) 16:48, 25 July 2022 (UTC)

+1 this both for easy toggling as expressed in the Phab task, but more importantly as a pre-release promotion per Wbm1058. This should also be available as a cookie-backed pref for non-account/not-logged-in readers, SGrabarczuk. ⁓ Pelagic ( messages ) 14:25, 9 August 2022 (UTC)

Thanks, @Pelagic. Regarding the last sentence, this is unfortunately off the table. It's beyond our power to make it possible. I'm sorry. SGrabarczuk (WMF) (talk) 23:00, 24 August 2022 (UTC)

@Pelagic: Just so. SGrabarczuk, who has the power to make it possible? It seems like a natural step. – SJ + 15:22, 1 September 2022 (UTC)

@Pelagic and @Sj, I'll try to explain this based on what I managed to figure out myself (thanks to @Jdlrobson for review and input). For more details, read blog posts: How a new data center in Singapore is helping people access Wikipedia around the globe, Building DReaMeRS: How and why we opened a datacenter in France, and Why performance matters.

The priority has been to make our sites load quickly. Most traffic comes from logged-out users. Put everything below in the context of these two factors.

To handle the vast majority of traffic, we have a few "caching servers" which only save and send "snapshots" of web pages to the logged-out users (instead of generating actual web pages). This allows us to serve these pages significantly faster in a way that doesn't overload the other servers.

These "snapshots" are the same for all logged-out users. Dark mode and any other preferences for logged-out users would require generating different versions of actual web pages. This would overload our servers. But we don't want to do that because we need to reduce cache fragmentation.

The only reason we have preferences for logged-in users is we don't serve these "snapshots" to logged-in users. We can do that only because the group of logged in users is tiny compared to the total page views.

The only possible way of providing preferences for logged-out users now is making the settings (whether any custom ones are enabled by an individual user or not!) load always after the page. This takes much more time to load and looks odd. For example, if a logged-out user was to see the dark mode in action, then immediately after loading each page, they would first see the light interface for a short moment, and then the interface would become dark.

If you disagree with any of the above, or have ideas on how to change that, please discuss this on wikitech-l.

The decisions on making changes to the architecture mentioned above would require work and input from multiple teams in both the Product and Technology departments, and are quite outside of the scope and capabilities of the Web team. Which is why this is way beyond the project of Desktop Improvements and the Vector 2022 skin.

Is this all clear? Thanks, SGrabarczuk (WMF) (talk) 13:33, 20 September 2022 (UTC)

As a semi-technical follow up: the front end caches that we serve logged out ("anon") content from are a signficant chunk of our server hardware and have a huge effect on perceived experience. We try to avoid splitting that cache at all costs. (There have been experimental efforts on "Edge Composition" or "Client-side composition" as a means to efficiently customize content post-cache, but these have never made it to production.)

Splitting the anon cache to serve a light mode and a dark mode would halve the space available for that cache. That wouldn't halve our hit rate, exactly, but it would have a significant performance impact on all users (or a significant financial impact on the foundation, if we doubled our hardware budget for that cache).

We do have mechanisms to do (for example) A/B testing, but those are based around bypassing a small fraction of the incoming traffic to a small dedicated cluster serving the test. That sort of traffic splitting /does/ scale: add another small dedicated cluster and you can either double the participation in the A/B test or add a "C" option. The difference with dark mode (or vector-2022) is that the proposal is to make it available on 100% of the traffic. In theory you could send everyone with a "dark mode" cookie over to a separate cluster, but that only works if hardly anyone ever uses dark mode. C. Scott Ananian (talk) 21:29, 21 September 2022 (UTC)

Thanks SGrabarczuk and Cscott -- that makes sense. Flickering-dark-mode sounds fun for about two seconds. I suppose one could still offer logged-out users the same sort of option, but have it take them to a login page that after login redirects them back to the page they were viewing, with the preference set...

How large are current A/B test fractions -- 0.1% of sessions, less? Is the new skin getting such a test w/ logged-out readers? – SJ + 23:23, 21 September 2022 (UTC)

Vector 2022 office hours

Join an online meeting with the team working on the Desktop Improvements! It will take place on 26 July 2022 at 12:00 UTC and 19:00 UTC on Zoom. Click here to join. Meeting ID: 5304280674. Dial by your location.

Read more. See you! SGrabarczuk (WMF) (talk) 16:49, 25 July 2022 (UTC)

Hey all, wanted to ping @Sdkb, @Xaosflux, @Bilorv, @TheDJ, @BilledMammal, @IAmChaos, @Jonesey95 and anyone else who is curious - we're hosting office hours later today - if you're interested and have the time, you're welcome to join to talk through questions, comments, and the plan overall. In terms of the conversation here, we plan on answering open questions (we know there's still a few), summarizing the discussion, and identifying some next steps over the next couple of days. OVasileva (WMF) (talk) 08:07, 26 July 2022 (UTC)

Just want to say it's great that you are offering this and I hope people take you up on it! Andrevan@ 21:34, 30 July 2022 (UTC)

An update after two weeks of discussion

1. What should the process look like?

Hey all,

Thank you for your feedback. We recognize that this is a large and important change to our interfaces that will affect the default experience for millions of people. We appreciate your patience in this discussion on how to proceed in the best way possible for our readers, contributors, and communities.

We will try to summarize the feedback we have gotten so far, and continue with identifying next steps. Based on your feedback, we would like to propose the following process:

1. Agree on what changes need to be made to the interface before the final deployment conversation
2. Continue with a conversation focused on building consensus around deployment
3. Deploy and continue with other improvements and requests that were agreed to be non-crucial for deployment

Does this seem in-line with your expectations? Do you have any concerns?

2. Why are these changes improvements?

Many of you were curios about the changes, and especially expressed interest in getting more details on our data and process. Below, we are outlining a bit about our process, as well as the data we have collected that proves that each feature is an improvement. Ping: @

You will find more details in the section #UX research and usability testing. We have tweaked the existing comment a bit. — OVasileva (WMF), SGrabarczuk (WMF) 01:53, 28 July 2022 (UTC) — continues after insertion below

Thank you for spending the time to write this out. My concern is that you are focused too much on testing for the change you intended to make and in doing so miss the broader impact. Because of this I feel your analysis only proves that you brought about your intended change, rather than proving that each feature is an improvement.

For example, consider the sticky header. Here, the goal is to (1) improve the user experience, by (2) saving reader time, by (3) reducing the amount of scrolling to the top that they need to do.

However, you only test for (3); you then infer (2) from the positive result for (3), and infer (1) from the positive result for (2). Testing directly for user experience is difficult, but to reduce the risk of errors the goal should be to get as close to that level as possible, and in this case it means testing for (2) rather than (3); if you look at #3 in my previous comment you will see that I am requesting data that should give us an answer to (2).

In addition, you assume there are no negative impacts from the change. This isn't a safe assumption, and with #2 and #3 of my previous comment I request data that will allow us to consider this possibility. BilledMammal (talk) 06:56, 28 July 2022 (UTC)

Hey @BilledMammal - sorry for the delay in response! I replied briefly to your initial comment above. TLDR is that we try to design experiments using more precise metrics because more open-ended metrics (such as time spent on page) could be interpreted in multiple ways. More time on page could be an improvement (people have a better experience and thus spend more time on the site overall). Less time on page could also be seen as an improvement (we're saving people time in scrolling so they get to what they need to do quicker). We can keep discussing there or under this thread - whatever is easier! OVasileva (WMF) (talk) 09:11, 2 August 2022 (UTC)

Thank you; no worries about the delay in response, and apologies for my own delay in response. I've replied above. BilledMammal (talk) 16:46, 7 August 2022 (UTC)

3. Why are we having this conversation while development is still happening?

We are eager to bring the improvements mentioned above to our readers. Currently, many new readers do not feel welcome by the interface as it is, and this is something we hope to solve as soon as possible. We recognize that no feature or skin will ever be perfect, and there will always be room for improvement. As we mentioned above, the skin, in its current form, is already a significant improvement over the current state.

The final state of the skin also depends on the conversation we’re having right now. There are many possible improvements or ideas for changes we can build and focus on. We’d like to discuss which of these are most important to the community as we proceed to implement and put the last touches on this version of the skin.

Finally, as we mentioned in a previous post, once deployed, we plan on continuing to work on the desktop experience. This project opens more possibilities for the future and gives us the opportunity to work with communities to provide new and necessary tools both for readers and editors. This is an ongoing process and it will be done with the feedback and collaboration of the community here and across other projects.

4. What changes will be made before deployment?

Our request for you is to review the list below and let us know if it looks correct in your opinion. What should be added? What should be removed? Do you have any questions on what each of these items will and will not include?

As a part of these conversations, we plan on placing requests into three categories. This categorization is based on our research, previous conversations with communities and prototype testing, as well as the feedback we received from all of you last week. These categories are flexible. We need your feedback to move something from one category to another, as well as to add items to each category.

1. Issues we would like to address prior to the deployment
   1. Table of Contents collapsing and narrow screens behavior (@xaosflux, @sdkb). We are working on this and hope to have it ready within the next few weeks (more details in T306660)
   2. Visual refinements (@IAmChaos, @Terasail). We are working on this and we will finish before deployment, with the first part landing next week (week of August 1). To see more details on what visual refinements we are and how we worked with communities to define these, please see this page
   3. Making a decision on ToC handling and magic words (ping @
      horizontal toc
      }}
   4. Coordinates display and other indicator issues. We would like to ensure that coordinates do not overlap with any existing indicators and that the area in the top right corner of the article is well-organized (T281974). Special thanks to Xaosflux, Izno, theDJ, Sdkb, AlexisJazz for participating in the discussion and helping us identify next steps. The conversation around coordinates continues in VPT#Coordinates in Vector 2022
   5. Making it easy to opt-in and opt-out ​​(@Shearonink, @wbm1058) - we have a button in the sidebar, which allows for easy recognition of opting out. Opting in is, however, only available through the preferences page. We’d like to explore the possibility of running banners that explain that the change was made and provide opt-out instructions as well. Similarly, prior to the change, we’d like to run more banners that encourage people to opt in and give us feedback
2. Issues we would like to address after the deployment
   1. ToC/sidebar length and the separation of page tools from wiki-wide tools (@sdkb). This is a significant change that we would like to move forward with once we have everyone using the new default. This will be the best way to study and build out customizations for the various use cases (example: the ability to add admin tools or gadgets like Twinkle to the menu)
3. Issues that will not be addressed at this time (issues that are not part of the Desktop Improvements project, belonging to other teams, etc.)
   1. A preference which allows the fixed width of the page to be turned off. — OVasileva (WMF), SGrabarczuk (WMF) 01:53, 28 July 2022 (UTC) — continues after insertion below

      A local gadget (currently experimental) or personal userscripts may address this at an individual editor level. — xaosflux ^Talk 10:10, 28 July 2022 (UTC)

A quick note here that we've started collecting a list of different gadgets and customizations that folks have built over the course of the project in our repository. We hope to expand this as we hear of more gadgets and scripts and encourage whoever is interested to use what's there or add their own to the list. OVasileva (WMF) (talk) 13:12, 22 August 2022 (UTC)

5. What should the deployment conversation look like?

Some of you said that an RfC would be the best approach for the conversation around deployment. Does that sound like the right course of action? One thing that we have been thinking about is ways to include the voices of readers into the decision making process. We are planning to run surveys asking readers what they think about the new skin compared to the old one. How can we incorporate their thoughts into the conversation?

OVasileva (WMF), SGrabarczuk (WMF) (talk) 01:53, 28 July 2022 (UTC)

Amazing work! CactiStaccingCrane (talk) 05:31, 28 July 2022 (UTC)

You could run a banner that provides an opt-in button for the new skin only visible for unregistered users, but then I'm not sure how they'd be able to leave feedback anonymously. The RfC could then be run in parallel with this campaign, with the ultimate decision relying on the inputs from both. Anarchyte (talk) 06:03, 28 July 2022 (UTC)

with the ultimate decision relying on the inputs from both How would this work? Who gets to decide how much to weight each if they conflict? I don't foresee the community willingly relinquishing control, so as much as I'm concerned that the community isn't going to follow

WP:READER and is going to overprivilege editor needs, I think BilledMammal's suggestion is the only practical way to take reader input into account. {{u|Sdkb}} ^talk

04:27, 29 July 2022 (UTC)

I echo

talk

) 23:41, 29 July 2022 (UTC)

To incorporate their thoughts I would suggest running the surveys prior to the RfC, and allowing editors to assess the results of the survey when making their decision. In the end, this needs to be based on the consensus of the community, as assessed by the community. For this assessment I would suggest one thing;

asking for a panel close, such as was done for the 2021 review of RfA. BilledMammal (talk

) 07:23, 28 July 2022 (UTC)

I think it's premature to decide in advance that multiple closers are needed. Most discussions can be evaluated adequately by a single closer. The 2021 RfA review was by design open-ended in the number of proposals that could be made, and thus unconstrained in the variety of rationales, which were primarily opinion-based, since often there's no way to collect data without actually trying a change to the process. It remains to be seen if an RfC on a new skin will have these or other characteristics such that more than one closer might be desirable. Ideally, if the development process goes as planned, there won't be an RfC unless there is already widespread support for the changes in question, much like the default deployment of the reply tool feature. isaacl (talk) 07:45, 28 July 2022 (UTC)

My suggestion was mainly to reduce the chance of the close being appealed at AN; I don't want us to have a situation where the discussion is closed with a consensus to implement the change, only to have the AN overturn the close. Normally such a situation would not be problematic but in this case I believe it would be due to the scale, prominence, and technical nature of the change. BilledMammal (talk) 08:04, 28 July 2022 (UTC)

I think I agree with BilledMammal that the best way is to present the results of the surveys at the RfC. Olga, you really don't want to end up in the scenario where the enwiki community reaches a consensus against the change while readers say they like the change – I think the community will feel betrayed if you don't respect its decision. If you don't think you can commit to abiding by the outcome of an RfC, you shouldn't hold an RfC; I would be quite upset but less than if you ran an RfC and then overruled its outcome. Best, KevinL (aka L235 · t · c) 17:55, 2 August 2022 (UTC)

Two pretty glaring issues

Ok, so, first, the collapsable toc. if you say readers find it easy, cool, but to me it seems like we're burying our navigational tools. Which to me seems like a really really bad idea. This feels more like something done for phones to save screen real estate, than what would need to be done on a computer monitor, but whatever. If that's a fail, we'll probably find out soon enough by analyzing number of clicks on toc/side menu links.

That aside, not having the user talk page right next to the user's name is also a really bad idea.

We've already had issues with the mobile interface where it was difficult for new editors to know they were receiving warnings, because they didn't see they had a user talk page.

I realize we have our alerts system, but a direct link to the user talk page seems paramount.

if space is an issue, move the watchlist to the drop down, next to contributions (they both should be at the top of the drop down)..

But "talk" should be right next to the user name, before the notice icons. to make it clear that it's the user's talk page. - jc37 11:51, 28 July 2022 (UTC)

If that's a fail, we'll probably find out soon enough by analyzing number of clicks on toc/side menu links. That is a good point, and A/B testing should include data on this. Hopefully the WMF will be willing to engage with this and the other requests for data I made above. BilledMammal (talk) 00:09, 30 July 2022 (UTC)

Can u explain ur thoughts further? Because talk page is a concept completely unique to us, id think. So why would that be more recognizable to ppl than a notice in the notice menu? More recognizable outside of a user’s menu than within the menu ? Isn’t it just that ppl simply need to learn these things no matter where they are ? —TheDJ (talk • contribs) 08:58, 31 July 2022 (UTC)

It's simply a matter of understandability and use-ability. If you look at the various icons that are intended for the user, both displayed and those in the drop-down, I think it's fair to say that the most important ones would be the user page, the user talk page, and alerts/notices. Contributions/watchlist next, then misc "other stuff", and then preferences and logout at the end/bottom.

Wikipedia is a learning curve, to be sure. But as our user model is based upon

consensus

, and discussing things is often the way of things here, putting the user talk page readily viewable would seem rather obvious.

My return question might be: Why shouldn't it be there? What is the logic here?

And with that in mind, pinging @User:OVasileva (WMF) and @User:SGrabarczuk (WMF). - jc37 08:00, 1 August 2022 (UTC)

@Jc37 - sorry for the late reply here! I had missed the question around the user menu here and focused on the ToC (data for which is available in our latest update below). In terms of the user menu - what we were seeing in our research is that newcomers were having difficulty identifying that the links on the top of the page were related to their accounts at all. The standard across the web is for these links to be collected in a single visual container, such as a menu. For example, people didn't understand what the difference was between the talk link for the article and their personal talk page link, since both said just "talk". By collecting these in a menu, we're sending the signal that they are items related to the user account. That said, we did also look at the data to make sure that access to the most commonly used links are still available (https://phabricator.wikimedia.org/T289574#7462391). We saw that the watchlist, which was also initially within the user menu, was getting more than 52% of the clicks within the entire user menu on Wikipedias, and thus moved it out of the menu for easier access. OVasileva (WMF) (talk) 13:08, 22 August 2022 (UTC)

• Comment I'm ok with the "two weeks to discuss it" idea. Best way to gather discussion points is to have an unobtrusive banner ad at the top of every page explaining what is going on. Oaktree b (talk) 23:02, 2 August 2022 (UTC)

Another TOC thing "Beginning"

Vector-2022 inserts a section-0 link on the TOC, and it is labeled "Beginning". Anyone else think this is odd? See this page as an example. When I first saw that in the TOC, I didn't think "this is the beginning of the article", but "this is a section about the early days of this subject". Luckily we can localize this via Mediawiki:vector-toc-beginning. Anyone think we should? Perhaps something like "(Top)" or "(Return to top)".? — xaosflux ^Talk 00:38, 3 August 2022 (UTC)

@Xaosflux, we've absolutely raised this already. In the latest mockups, it's bolded, which helps a bit to distinguish it. Still, I think we'd want to consider localizing it, perhaps to "Introduction," which aligns with what we actually call the section (making the entry ramp for newcomers shallower). {{u|Sdkb}} ^talk 01:36, 3 August 2022 (UTC)

@Sdkb that label is on all pages, not just articles (e.g. https://en.wikipedia.org/wiki/Talk:Ireland?useskin=vector-2022 ) so "Introduction" seems even worse to me. — xaosflux ^Talk 09:18, 3 August 2022 (UTC)

Hmm, we could use different labels for different namespaces. Or go with something like "Top" everywhere. As I mentioned at the other conversation, I think the key will be differentiating it somehow through design rather than finding an unambiguous word (which may be impossible). {{u|Sdkb}} ^talk 17:16, 3 August 2022 (UTC)

Some kind of icon, such as a stylized caret ^ , seems to be the best option to me. Daß Wölf 15:40, 7 August 2022 (UTC)

Use italics (not bold) or put (Beginning) in brackets or (Top) in brackets. Definitely not (Return to top) since we are already at the top when the page loads — GhostInTheMachine ^{talk to me} 16:10, 7 August 2022 (UTC)

I've loaded in (Top) as a try; any feedback? — xaosflux ^Talk 16:13, 7 August 2022 (UTC)

@Xaosflux - thanks for starting this as an experiment! A few weeks in, I think "(Top)" works quite well. We discussed a little bit internally and think that leaving this up to the wikis with the default remaining as "Beginning" might be the best way forward. We explored some other options for a visual solution by adding an arrow or icon, but it felt a bit heavy on the page and potentially confusing with the carets that open/close the sections. @Daß Wölf, @Sdkb, @GhostInTheMachine - any thoughts on this approach? This also allows us to change the copy of the default, if necessary as well. OVasileva (WMF) (talk) 10:52, 24 August 2022 (UTC)

If ... "(Top)" works quite well then it is probably best to use it as the default. If "Beginning" is seen to be easier to translate, then the default should still include the brackets — GhostInTheMachine ^{talk to me} 11:07, 24 August 2022 (UTC)

@OVasileva (WMF) I agree with GITM above, that some sort of styling is beneficial there. Perhaps wrap it in Mediawiki:Parentheses-start / Mediawiki:Parentheses-end. Such styling helps to indicate to the reader that it is not a specific content label.

I think that "top" is better than "beginning" for English encyclopedia articles, but that is something the community will eventually decide. Here's an example of an english wikitionary page [1] - Just plan styled "beginning" seems out of place there as well. — xaosflux ^Talk 13:21, 24 August 2022 (UTC)

Maybe a thin line between (Top) and the rest of the sections would help more in making them distinct. --NGC 54 (talk｜contribs) 14:06, 24 August 2022 (UTC)

Note, I tried to demo that with the label, via a <span style="text-decoration:underline; text-underline-position:under;">(Top)</span> udpate, however the vctor-2022 TOC does not process spans, instead outputting them literally. — xaosflux ^Talk 14:23, 24 August 2022 (UTC)

Hide/Show

(split from prior section — xaosflux ^Talk 13:10, 19 August 2022 (UTC))

Better. Can Contents [hide] be altered as well? In this case, the opposite of "hide" seems to be "move to sidebar" which is just a bit evil — GhostInTheMachine ^{talk to me} 16:25, 7 August 2022 (UTC)

@GhostInTheMachine I'm not sure if that one is as confusing? To answer your question, it can be localized at MediaWiki:Vector-toc-toggle-position-title. Clicking on "hide" does result in the TOC being completing removed from view (hidden), I don't think (collapse in to the page menu) or something like that would be better? — xaosflux ^Talk 15:34, 15 August 2022 (UTC)

If two buttons act as the inverse to each other, then their names should reflect that inverse nature. The oppose of "Hide" is "Show". If clicking "Hide" does hide something, then the inverse should be clicking "Show" to show something. If clicking "Hide" moves something elsewhere, then it should instead be named "Move to ABC" and the inverse should be "Move to XYZ" or maybe "Move out of ABC". I don't think that the current TOC hide / slide across action is at all pleasant, and the confusion of labels is just a symptom of the confusion of function — GhostInTheMachine ^{talk to me} 17:59, 18 August 2022 (UTC)

@Xaosflux: Better still, a "Hide" button should be the "Show" button — it should toggle like a light switch, without moving. Just the label changes. In practice, this could be implemented so that the TOC "rolls up" while leaving the toggle button in exactly the same place, and then a second click "unrolls" the TOC back to where it was before. We already use that form of toggle button to "Collapse" and "Expand" navboxes and tables, so it would be kinder to the users to stay with the same mechanism for interface components. — GhostInTheMachine ^{talk to me} 18:25, 18 August 2022 (UTC)

@GhostInTheMachine: functionally, the UX on this is not just a boolean condition:

• STATE 1: (DEFAULT STATE): Docked on the left sidebar, has a label, "Hide" (from Mediawiki:vector-toc-toggle-position-title)
• STATE 2: The TOC is removed from the sidebar, and is hidden next to the article title in a collapsed menu
• STATE 3: The TOC is unhidden, opened in to a popup box, has a label "move to sidebar" (from Mediawiki:vector-toc-toggle-position-sidebar)

The the transition options are:

• STATE 1 to STATE 2 (This is a MOVE and HIDE effect)
• STATE 2 to STATE 3 (This is an UNHIDE effect)
• STATE 3 to STATE 2 (This is a HIDE effect)
• STATE 2 to STATE 1 (This is a MOVE effect)

So I'm not really sure what the best label is, just calling out that it is not just an ON/OFF effect. — xaosflux ^Talk 13:10, 19 August 2022 (UTC)

Just wanted to note that we're reading along and keeping track of the new ideas on verbiage for both this as well as the "top/beginning/introduction" link. In terms of the decision on the current copy, I can confirm that @Xaosflux correctly identified the reason for why the call to action is not a binary hide/show. Potentially another approach would be to clarify the "hide" action further since the ToC is hidden but still accessible via the button - something like "collapse into title" or similar. OVasileva (WMF) (talk) 12:55, 22 August 2022 (UTC)

Mockups for first TOC link

Hey, regarding the first link in the TOC: I'm going to try and summarize the ideas in this conversation (and other conversations about this topic that have happened elsewhere), articulate the design goals, and provide mockups to (hopefully) help us evaluate our options.

Ideas

• Ideas for labels:
  • Top
  • Beginning
  • Introduction
  • Article title
  • (remove label and instead make "Contents" itself a link)
• Ideas for styling:
  • Add ↑ before label
  • Add ( ) around label
  • Add border underneath label

Design goals

• (Primary) Provide people with an easy way to get back to the top of the page
• Find a solution that works across various namespaces
• Ensure that the link doesn't conflict with other links within the TOC (e.g. having two links labeled "Introduction")

Mockups

• the mockups assume that this change, which bolds the active section link in the TOC, has been deployed.
• because I think it's helpful to see how this link looks when you are both at the top of the page, and scrolled down (so that this link is no longer selected), an interactive prototype seemed more appropriate than static mockups.
• link to prototype: https://di-toc-first-link.web.app/Education
• use the options panel in the bottom-right to explore the various options
• be sure to view several different articles (for example articles where the second TOC link have an expand/collapse arrow, seem to change the feel of things, especially the option where there's an arrow before the first TOC link — e.g. https://di-toc-first-link.web.app/Moss)
• since people might have other ideas for the text of the first TOC link there is an input box that allows you to customize it

What do people think?

Some of my thoughts so far:

• Using "Contents" as the back to top link doesn't seem as discoverable or intuitive to me as the other options
• Adding an arrow next to the first TOC link makes the TOC feel more cluttered, and I'm not sure it makes a significant difference in terms of discoverability
• Adding a border below the first TOC link makes the TOC feel more cluttered, and I'm not sure it's particularly helpful in clarifying things
• Using the article title as a label results in the article title appearing twice, pretty close together (the main article title, then just below and to the left of it the article title again in the TOC). It also doesn't seem quite right when scrolled down on the page that the first link in the TOC is the article title and that clicking it will take you back to the top, though I can't quite figure out why.
• Using "Introduction" as a label (at least in the main namespace) seems clear to me, and I don't think requires any additional styling
• Using "Top" as a label seems clear, and seems like it works well across various namespaces, though I think it requires some kind of additional styling to help people make sense of it because it doesn't really fit in with the other TOC links.
  • Adding parenthesis around it feels like a simple and effective way of differentiating it from the other TOC links (which map directly to section names)

I think my favorite option so far is using "Introduction" with no additional styling (with the assumption that we would make it customizable by namespace), or using "(Top)". AHollender (WMF) (talk) 21:32, 2 September 2022 (UTC)

Daß Wölf's comments

• Changing skins is unworkable for non-logged-in users since ?useskin= switches are reset every time you click on a link. They should be made more permanent, through cookies for instance. You can see this for yourself by logging out and visiting a Wikipedia that uses the new interface, e.g. the French Wikipedia. The option to return to the old skin also isn't shown to unregistered and logged-out users, who are the ones who need it the most (since they're much less likely to know about our query string tricks). IMO it would be best to follow Reddit's practice (see [2][3][4]) and let users switch between skins in an easy an obvious way with something like https://en.new.wikipedia.org and https://en.old.wikipedia.org. Daß Wölf 15:56, 7 August 2022 (UTC)

  I wish this idea would garner some interest. We're one of the most viewed sites on the internet and obviously we'd be alienating many readers, just as we'd be accommodating many. This small step for a $150 million organisation would easily avoid moving an (in absolute numbers) large amount of our readers to Wikipedia mirrors. We're really focused on trying to create the perfect skin, when any single design will always drive away somebody. We have to be more flexible here. Daß Wölf 05:06, 12 August 2022 (UTC)

  @Daß Wölf, what is your claim based on? My understanding of the research around site appearance changes (which is mostly not Wikipedia-specific) is that most frequent users dislike noticeable changes, some complain, and a few weeks later, even the people who complained about it usually can't tell you how the old site differs from the new one.

  I also understand that the last time the English Wikipedia's default skin was changed, it had no significant effect on page view traffic to the desktop site. If you have found any good research showing that changing the site appearance alone (and not, e.g., removing tools people needed – an incompatible gadget delayed my own transition from MonoBook to Vector 2010 by months) drives away an appreciable number of readers, then I'd be very interested in reading it.

  P.S. You might be interested in https://nostalgia.wikipedia.org/wiki/HomePage This is the real "en.old.wikipedia". Whatamidoing (WMF) (talk) 04:44, 13 August 2022 (UTC)

  @Whatamidoing (WMF): If that's true, then why is https://old.reddit.com still so popular (~1/6 of desktop views 3 years since the switch)? [5] Daß Wölf 20:29, 13 August 2022 (UTC)

  The fact that some people use an old version doesn't prove that they would leave the site if the old version stopped working. Many admins and other high-volume editors here use non-default skins. Common reasons for this include liking what I'm used to and because it makes it really obvious if I've accidentally gotten logged out. But: "I prefer _____ and will go to some extra trouble to use it" doesn't actually mean that "I'll quit unless I can use _____". Whatamidoing (WMF) (talk) 19:42, 15 August 2022 (UTC)

  Does that make it fine if the ordinary reader's experience gets worse and worse, just as long as they don't leave? Daß Wölf 18:22, 16 August 2022 (UTC)

  That’s a really big if. Doug Weller talk 19:46, 16 August 2022 (UTC)

  @Doug Weller and Whatamidoing (WMF): Please excuse my POINTy wording. I'll try to rephrase my argument in a more neutral manner:

  Clearly, a significant minority of people, for different reasons, prefer website skins using older design language. Many people are simply afraid of the new, others simply like a more verbose design language, still others (maybe relatively few) actually make better use of that language. For example, I use a workaround that removes the interactive date picker in page history, because the old date picker loads instantly and takes fewer clicks to get things done. I won't quit if this workaround is removed, and I will come to terms with it, and maybe even completely forget that the old style ever worked faster, but nevertheless that would be another several seconds lost time and time again -- that would not an improvement. But maybe these cases are relatively few in number.

  Now, Reddit is a commercial website that can impede and/or sue mirrors as they see fit. Despite this, they see it worth their money to maintain their old design. OTOH, we're a GPL/CC-licenced website running on FOSS technology. If I remember correctly, one of the reasons cited for this redesign on mw: was that we are losing traffic to commercial mirrors like WikiMili and there's nothing we can legally do other than compete with them. Yet if we now cease offering a full-width option publicly, somebody else will start, etc. Likely we'll be losing fewer readers this way, but why not try and keep them all? Daß Wölf 19:42, 17 August 2022 (UTC)

  I was reading Wikipedia when the main page looked like that. I miss it. But then, I still use a frankensteinian emulation of the Standard skin without side column, shoehorned into the now-also-obsolescent-and-soon-to-be-discarded Cologne Blue, so what do users like me matter. Some day, they'll come for your Monobook, too. —

  Cryptic

  00:08, 14 August 2022 (UTC)

  I suspect that Cologne Blue and Modern will not be de-installed until they actually break. It's not much work to remove them, but it's no work at all to leave them alone (in the absence of security problems, etc.), so I suspect that the removal, if it is ever planned in the first place, will be postponed repeatedly. Whatamidoing (WMF) (talk) 18:38, 18 August 2022 (UTC)

  I don't remember hearing any overall reasons for updating the skin this round. I'm aware that there are always some editors asking for a more modern appearance, and I have heard reasons for some of the individual changes, but I don't know happen to know what motivated the overall project. To give an example of an individual change relevant to your comments, there is external/non-Wikipedia-focused research showing that most people have trouble reading very long lines of small text. If you have an extremely large screen, it is not helpful to have 14 pt text run across the full width of that screen. It's hard to keep your eyes on the same line when you have to physically move your head (or your whole body) so you can see the words at the far end of the screen. These people are not helped by a full-width skin.

  The idea that people might struggle to chase a single line of small text across a meter-wide screen makes intuitive sense, but to get further than speculations about whether the normal width of a piece of standard paper has something to do with the width that people are comfortable reading, then you have to look into the research. If memory serves, the research indicates that – for the average reader – the "best" screen width in terms of Reading comprehension (which would be a very natural goal for an educational website like this one, right?) is about 15 words wide. I personally prefer something closer to 25 words, and I get annoyed when the size is reduced to 10 words (typical for The New York Times website, and supposedly faster for skimming), but something around 15 words is supposedly better for the average person.

  As for whether the movement should try to be all things to all people: I'm not aware of any websites except Reddit doing this, and I don't expect Reddit to do this forever. If almost no website thinks this is a good idea, then why would it be a good idea for us? Whatamidoing (WMF) (talk) 18:35, 18 August 2022 (UTC)

  @Daß Wölf I agree. i don't understand why the UI and the content aren't, or at least modifiable.

  Actually, how difficult is it for a volunteer developer to contribute?~~~ Wakelamp d[@-@]b (talk) 05:24, 16 September 2022 (UTC)

  @Wakelamp, you might start looking around at https://developer.wikimedia.org There are even ways for people to contribute if they don't already know how to code. Whatamidoing (WMF) (talk) 17:07, 19 September 2022 (UTC)

  ooooh I used to program (

  hollereith cards I miss you not at all) I work as a Business/process Analyst now - and volunteer BAs are never a good idea . Are there many volunteer developers? Wakelamp d[@-@]b (talk

  ) 13:25, 20 September 2022 (UTC)

  I don't know that we can assume that the average Redditor – a nerdy, tech-savvy 13–35-year-old man – is representative of the average Wikipedia reader. Graham (talk) 05:44, 1 September 2022 (UTC)

• Regarding the skin itself, I see nothing has been done to make the skin look better on wide screens. How about letting the user set the page width (ideally in a noJS-accessible way) and/or a picture-in-picture sort of preview in the right !ad-banner space for
  WP:NAVPOPS? Daß Wölf
  15:56, 7 August 2022 (UTC)

  @Daß Wölf while it only applies to logged-in users, we have an experimental gadget to widen the view you could try. — xaosflux ^Talk 16:11, 7 August 2022 (UTC)

  There any several (many?) user scripts to fix the width issue. It really would be better if full width was just a standard Skin preference — GhostInTheMachine ^{talk to me} 16:19, 7 August 2022 (UTC)

  I agree completely, but it would be even better to have this setting somewhere on the page, perhaps more prominently than the way the "Desktop view"/"Mobile view" link is buried right now. User scripts and Special:Preferences are well and good, but they do nothing for the vast majority of Wikipedia's users, who do not edit nor have accounts. Daß Wölf 05:00, 12 August 2022 (UTC)

Update on Vector 2022

What changes will be made before deployment

Hey everyone! Thank you for your continued feedback. Wanted to send out an update on the project and next steps, and get your thoughts:

In our last message, we posted a list of tasks that we had placed in three categories based on our research, previous conversations with communities and prototype testing, as well as incoming feedback. Below is an update for the tasks within each category. For this updated version, we would like to ask the same questions - What should be added? What should be removed? Do you have any questions on what each of these items will and will not include?

1. Issues from this conversation that we would like to address prior to the deployment
   1. Table of Contents collapsing and narrow screens behavior - The ToC is now collapsible at narrow screen sizes as well as for all screen sizes. During the next week we will be making changes to the width and centering of content with collapsed ToC's (T314579). We will also be adding the ability to access a collapsed ToC from the sticky header (T311103).
   2. Visual refinements - We're working on this part now. We have made the first changes based on the feedback we have received. The styles for menus and buttons are now back to their default blue state. We have also made some changes to the styles of the ToC. To see more details on the remainder of visual refinements please see the page on MediaWiki.org.
   3. Making a decision on ToC handling and magic words - We will be updating on the state of magic words early next week.
   4. Revisiting the naming of the ToC “beginning” section - @Sdkb, Xaosflux, and GhostInTheMachine: thank you for your continued participation in this conversation and your ideas here. We're monitoring the conversation and are evaluating the idea of the new “(Top)” link as well as other previous suggestions from the conversation on the project talk page. This work will be tracked in this phabricator ticket. We commit to finalizing the name of this section prior to deployment.
   5. Coordinates display and other indicator issues - We are continuing the conversation around coordinates in WP:VPT#Coordinates in Vector 2022 and will post a specific update soon.
2. Issues we would like to address after the deployment
   1. ToC/sidebar length and the separation of page tools from wiki-wide tools - This is a significant change that we would like to move forward with once we have everyone using the new default. This will be the best way to optimize for studying and building out customizations for the various use cases for the page menu (example: the ability to add admin tools or gadgets like Twinkle to the menu).
3. Issues that are not part of the Desktop Improvements project, issues that belong to other teams, and other requests that will not be prioritized at this time
   1. Introducing a setting in preferences which allows the fixed width of the article to be turned off - as some of you mentioned, there are a number of gadgets and scripts that allow for increasing the width or using the space for other tools for people that have larger screens. We have published a list of these on our repository page. Feel free to add any scripts/gadgets that you have created or use the ones available there.

Why are these changes improvements: Update on ToC A/B test results

We have received the results of our ToC A/B test.

• We see that among the sessions with at least 1 click on ToC, the treatment group (the group that is exposed to the new ToC) has more clicks on ToC than the control group (the group exposed to the old ToC). Our data model predicts 53% more clicks on new ToC with logged-in users and 45.5% more clicks on new ToC with anonymous users.
• We saw that this trend is consistent across all edit count buckets: i.e. we saw that logged-in users clicked on the ToC at roughly the same frequency regardless of how many edits they had previously made.

Update on survey results

@

We will be hosting an introductory session to the project at Wikimania on Saturday, August 13, at 8:05 UTC in tent 2 (join on Pheedloop; see the details). We welcome anyone to join the session. We also welcome anyone with questions or comments to the Q&A afterwards (join on Zoom, dial by your location).

And that's all for now - thank you all again, as usual, for your continued interest, feedback, and help! OVasileva (WMF), SGrabarczuk (WMF) (talk) 15:32, 9 August 2022 (UTC)

It would be great to get a quick fix for T311277, short descriptions being cut off in Vector 2022 instead of being displayed on two lines. There is available space, so there does not seem to be a reason for the truncation of this useful information. The bug was generated by this discussion. – Jonesey95 (talk) 11:38, 29 August 2022 (UTC)

Reinstate link to our sister projects on the sidebar

@OVasileva (WMF) and SGrabarczuk (WMF): Please revisit the decision to hide by default the links to sister projects to non-logged users (phab:T287609).

This decision directly contravene our Strategic Direction ("we will become a platform that serves open knowledge to the world across interfaces and communities"), the Improve User Experience recommendation of Movement Strategy ("tools to connect cross-project and cross-language functionalities to provide an enhanced experience of the knowledge contained in the Wikimedia ecosystem for a particular interest, informational need, or inquiry"), and the long-established convention of cross-wiki co-operation among Wikimedia projects of different languages.

As I've pointed out in the MW talkpage, "no one's clicking this so we should remove it" is not a very good argument, and the data presented to back it up is not very convincing. As Theklan pointed out: you're going against a pretty clear Strategy recommendation; if you think that this doesn't go against it, please show how this is helping it. dwadieff ✉ 04:44, 13 August 2022 (UTC)

Thanks dwadieff for bringing this here. Let's see if we have some luck and the problem is solved. Theklan (talk) 09:53, 13 August 2022 (UTC)

Skin is deployed

A/B testing is now in progress for logged-out users. CactiStaccingCrane (talk) 11:24, 19 August 2022 (UTC)

@CactiStaccingCrane - thank you for pointing this out. Just to clarify, we are not A/B testing or deploying the skin at this stage. We have switched a small group of pages (<10 pages) to the new skin in order to qualitatively survey readers for their opinions on the new experience, as discussed in our message above. We hope to get about 500 - 1000 replies to the survey, the results of which we will publish here prior to continuing the deployment conversations. Our goal here is to include the opinions of readers into the conversation around the deployment of the skin and potential improvements. Please see Wikipedia:Village_pump_(proposals)#Update_on_survey_results above for more details. OVasileva (WMF) (talk) 12:47, 22 August 2022 (UTC)

Oh, sorry, thanks for the clarification OVasileva (WMF)! CactiStaccingCrane (talk) 12:52, 22 August 2022 (UTC)

Hi, is there a list of those pages as I'd like to test them too (as a logged out user). —CX Zoom[he/him] ^{(let's talk • {C•X})} 10:28, 24 August 2022 (UTC)

@CX Zoom - sure! The list is available in phab:T314286. OVasileva (WMF) (talk) 11:47, 24 August 2022 (UTC)

Thank you very much! —CX Zoom[he/him] ^{(let's talk • {C•X})} 12:32, 24 August 2022 (UTC)

I find it ironic that the banner uses more screen width than the article content. I really hope that the WMF will come around on making it as easy as possible, even for logged-out readers, to use the whole window to view the content that volunteers have created. – Jonesey95 (talk) 13:07, 25 August 2022 (UTC)

Hey @Jonesey95. I appreciate your previous comments and I think I understand the irony :> But for the sake of anyone reading this who hasn't read our documentation yet, just wanted to give the context again on why the banners are appearing at full width.

• The limited width is intended for long-form text. For more information on that, check out the Goals and Motivations section on our project page or the relevant section within the FAQ or the Wikipedia article on line length.
• Through the development process, we have made decisions on displaying content meant to be scanned or read quickly at full width. You can see an example of this within banners, as well as on pages that are table-based, such as diffs, History, or Recent Changes.

SGrabarczuk (WMF) (talk) 16:00, 25 August 2022 (UTC)

Update of August 24

Hey everyone, thank you all for your continued feedback. We wanted to give a quick update on the status from our side and what to expect over the next couple of weeks. Please give us your thoughts, questions, and concerns on any of this:

1. Table of Contents collapsing and narrow screens behavior - This work is now completed. The table of contents is collapsible, and can be accessed from both the title of the page as well as from the sticky header. Please let us know if you have any concerns around the implementation here or additional requests around the ToC.
2. Surveys with readers - We are currently running surveys for logged-out users here on English Wikipedia. We hope to wrap up the surveys and have the results ready for you prior to beginning the RfC.
3. Visual refinements - We are currently wrapping up the core parts of our visual refinements work. Please see the Qualitative Testing section on our page dedicated to this part of the project for a full list of the changes we plan on making. We appreciate your feedback on any and all of these.
4. Coordinates - We are continuing to explore different solutions for coordinate alignment, including potentially adding coordinates directly into the styles of the skin in the future. Do you have any thoughts on this idea? Any immediate concerns? Let us know within the Phabricator ticket.
5. New blog post published - We have published a new blog post on equitable product development within the Desktop Improvements project. We encourage you to check it out, especially for those of you that are interested in reading a little deeper about the motivations for our changes, and the ways we have tried to change our process and approach in order to build equitably for diverse and global audiences and communities.
6. RfC Preparation - Finally (and most importantly), this week, we are focusing on preparing for the deployment RfC on enwiki. We hope to have a specific update on the process here soon, but would appreciate any ideas and feedback that have not yet been discussed. We might come back throughout the week with some questions for you all as well as we build out our plan.

Thank you all, again, for your thoughts and help throughout this process! OVasileva (WMF), SGrabarczuk (WMF) (talk) 10:11, 24 August 2022 (UTC)

Thank you for the update! Sounds like sensible progress in all areas. Will the RfC be in this forum? If so, I recommend creating a new section and linking back to this one as needed to keep things clean. —Ganesha811 (talk) 18:56, 24 August 2022 (UTC)

I'm using the new skin as is except that I have the wide-vector-2022 gadget enabled to remove the added whitespace on my laptop. For the reader I think having the whitespace is probably a nicer thing, but it makes doing admin tasks harder. For example, currently viewing diffs has the extra whitespace content which means there is less width and to therefore still fit things more height which increases scrolling. Ideally it would be good to make an option that's opt in to remove the added whitespace. Dreamy Jazz ^{talk to me | my contributions} 12:55, 26 August 2022 (UTC)

For anyone that wants to preview widemode, try this link. I think the main "known issue" right now is: if you dock the TOC to the title and collapse the sidebar, the pop-up TOC pops up a bit to the right. (If you have a pure-css fix for this, let us know at MediaWiki talk:Vector-2022.css. — xaosflux ^Talk 13:43, 26 August 2022 (UTC)

Thanks for the update. Reading the blog post, I have to say that it's quite disappointing. Wikipedia's present design absolutely has lacunae about the needs of a global audience, and I'm glad that the WMF is pursuing equity in the new design. But it's also clear that the efforts to avoid, as the post put it, "a scattered strategy" have failed, and that the idea that the foundation is pursuing equity has led it to unduly dismiss the community's concerns about the language switcher as just reactionary pushback. We've read the Hureo report and raised serious issues about its methodology and conclusions, but as we were not consulted before the decision to move the switcher was made, there was never any real opportunity to influence the WMF's course. And that's a mistake — we've also offered feedback about ways to make language switching genuinely more useful for multilingual users (e.g. take into account article length/quality, since a Google translated article in a topic's primary language is better than the WP article in your local language 9 times out of 10), but it seems that either came too late or was just ignored. Fundamentally, information dissemination is a lot more complex than the commercial products consultants like Hureo are used to working on, and not meaningfully collaborating with the folks in the editor community who actually have relevant expertise has harmed the result. {{u|Sdkb}} ^talk 05:32, 28 August 2022 (UTC)

Office Hours August 30

Hi everyone! We would like to invite you all to our office hours later today. 12:00 UTC and 19:00 UTC on Zoom. Click here to join. Meeting ID: 5304280674. Dial by your location.

We would like to discuss our preparation for the upcoming RfC, discuss and answer any questions on the tasks we are currently wrapping up, as well as any other blockers to deployment. Thank you and we hope to see some of you there! OVasileva (WMF) (talk) 08:36, 30 August 2022 (UTC)

UX Feedback, revisited (Sj)

Offer preferences. The lack of meaningful user prefs -- dark mode, wide-screen option, cookie-based skin prefs -- speaks to a deep challenge facing this design framework. Similarly, feature requests that originate from a community request or ticket seem to get much less traction than internal design ideas. This seems to lie at the heart of a range of common concerns.

• There should be a wide-screen preference. It's the most mentioned concern for a reason; the current whitespace / grayspace handling is the least strong aspect of the current design, so it's a matter of more than just "how wide is my column?". The current widemode css seems to work well, it should be offered as an easy to find pref.
• There should be basic skin-mod preferences that readers can toggle without logging in. There are many reasons a frequent reader might not want to log in; skinning is one of the simplest ways to feel a kinship to a site. cf @Daß Wölf:
• Add a dark-mode preference, please. By far the most-requested skin update for years.
• Make switching in/out as easy as possible for all parties. Lower the barrier to exploration and feedback after release.

  On fr:wp it is not very easy at all. Have a persistent link that you click to toggle the pref w/o leaving the current page.

Improve language switching

• The language switcher is more visible (nice) but slower, more confusing, and has specific unaddressed problems around what languages it highlights. Work w/ some of the people sharing detailed concerns + help get most switches down to 1-2 clicks. Something that explicitly elevates featured work on other projects would have a particularly wiki spirit.

Sidebar/TOC/top need work on margins/padding

• At all resolutions margins and padding are too big. At low resolution, the sidebar takes over everything -- looks like just a bug.
• The top now has significant extra padding above the article. (the margin + padding of the persistent header, in contrast, is elegant.)

Be kind to mobile users

• The new vector should not be significantly worse than current vector when viewed on mobile. In particular, it should not ever default to a massive sidebar taking up the entire screen when landing on a page.

  DJ wrote above: "This is indeed what you see if you force the mobile website to the desktop website/skin (not something anyone but a few realistically is doing)" but I and a number of others commenting here do use desktop-skin on mobile b/c the mobile skin is significantly harder to use for many types of pages, or hides elements of the page that are needed for intent reading/editing.

Honor whitespace management (more :)

• I know it's currently on the list of design features, but it deserves more focused attention, perhaps a dedicated proofreader for whitespace of all kinds. This accounts for the top three bugs I see in the current interface; which would make me hesitant to share it with others.

  Unappealing mix of white and grayspace at larger resolution; falls off the map on the sides; feels like the skin design is incomplete

  TOC / sidebar padding and margins both too wide

  Top now has 3 extra linespaces above the article

  Sidebar pops out to full rather than something more appropriate

Cheers, – SJ + 16:19, 1 September 2022 (UTC)

Strongly support the widescreen preference. The gutters are absolutely massive on 3860 resolution with 2x magnification - about 500px x 2 goes to vector-sidebar, margin, padding, etc, with the middle div mw-parser-output at like 950px, versus about 150px total for monobook's sidebar, leaving the main div about twice as large. The sidebar TOC is nice, but there's a huge gutter on the right. On a page like the Main Page or any page without a TOC, it looks really narrow and squished in the middle, making it basically unusable for my purposes. However, I just switched to Vector 2022 and it does appear to be in dark mode. I had the dark mode turned on in gadgets for Monobook and it seems to still work. Andre🚐 16:40, 1 September 2022 (UTC)

Also: make explicit use of the gutters: indicate what else they might be for. Annotation has been a perennial feature request for almost 20 years, and the primary challenge was figuring out where it might go without overwriting the page. If we have a path to solving annotation, that would be worth more than all of the difficulties w/ narrower text. – SJ + 21:20, 3 September 2022 (UTC)

Latest?

• Folks pardon the barging in. I got the new Vector 2022 desktop rollout earlier today. Has this now been rolled-out to all users? Can we still provide some feedback or is it too late? What is the best way for me to provide feedback at this time? Is there an upcoming office hours session? Thanks. Ktin (talk) 00:02, 10 September 2022 (UTC)

  I am adding a few of my observations here. If there is a different place, please feel free to move them.

  1. Full-screen width / wide-screen. This needs to be resolved as P0. There are a few issues here. If we do not want to go "full-screen" wide, but, want to leave a layer of gray on either side, that is fine, but the problem is further compounded because the text selection within the white area is again not 100% so that leaves a suboptimal screen utilization. Furthermore when you jump pages, depending on the presence or absence of the navigation bar the text jumps around and that is a bad visual experience.
  2. The top row (with the static WP icon) scrolls out of the screen when you move down the page and is replaced by a different row / header that does not allow for you to access the links present in the static banner row. e.g. WP homelogo, watchlist etc.
  3. The table of contents is on the LHS which is a new experience, but, perfectly alright from a design consideration. However, it has a scrollbar that shows up when the table of contents exceeds a particular length. That scrollbar is visually a disjointed experience. You can consider removing the scrollbar.
  4. <xx Languages>> Dropdown. E.g. on this page you see 47 Languages. That is the most prominent link on any given page now. Clicking on that link takes you down a rabbit hole of broken experiences. Not the least because clicking on any of the language links takes you to a different language wiki with a different look and feel from this new skin. On the classic skin, if we had enabled this jump wiki functionality, at least the skins would have been consistent. On the most prominent link on the page, this is a suboptimal experience. Curious if our analytics info indicated that folks were trying to look up the same page on different language wikis that we created this as the most prominent link. I think this is an interesting feature, but, not worth making it the most prominent link.

  Overall - I think the experience is still clunky and it would be worthwhile smoothening things out before rolling it to a wider audience.

  PS: I know a new UI/UX rollout is not easy and often has resistance, but, in this case, I think some more work needs to be done before this is ready for primetime. Ktin (talk) 03:16, 10 September 2022 (UTC)

  Hey @Ktin - thanks for your feedback on the new skin! Just to confirm, the skin is not currently rolled out by default to logged-in or logged-out users. However, we are running some banners that invite users with accounts to check out the new skin and give us feedback - so thank you for doing so :) Some initial thoughts on your feedback:

  - On the layout for wider screens. There is now limited width for the content. You can read more about the reasons for doing this in the FAQ. Generally, the limited width makes it easier to read content and to remember it after reading. That said, we encourage folks who prefer a more dense layout to customize the skin. There is currently a list of existing gadgets and customizations available.

  - Table of contents scrollbar. The scrollbar is controlled by the operating system itself and required for users that are using a keyboard and mouse. That said, we're planning on improving its styling a bit for a smoother experience. More details are available in this ticket.

  - Languages. Many of our readers and editors are multilingual and use English Wikipedia alongside their native languages. Our research showed that a lot of people were not aware that they could switch languages directly from the site and were using complicated workarounds like typing the url directly or searching for the page using a search engine. Increasing the visibility of this link makes it easier for them to switch directly from the page. That said, I agree with you that the current experience is a bit jarring due to the difference in the default experience across different wikis. We're currently working with the remainder of our communities to switch all projects to the Vector 2022 skin, which should resolve this. OVasileva (WMF) (talk) 13:10, 13 September 2022 (UTC)

Update on sentiment survey results

Hey everyone! Thank you for your continues feedback in preparation for the RfC.

As planned, we ran a survey for logged-out users about the Vector (2022) skin with the goal of gathering feedback for the new skin. Though there are some things we think we learned from the survey, we also ran into a number of issues with experimental design and technical constraints, meaning that the results of the survey did not give us a clear picture of overall sentiment and usability as we had hoped. That said, we believe the data we gathered can still give us some valuable information on the very first impressions of logged-out users of English Wikipedia when presented with the skin on a single pageview.

Overall, a close majority of logged-out users reported that they would view the changes either positively or neutrally. This was true for questions related to both the usability and welcomeness of the new experience. Among these, most respondents indicated that they perceive the old and the new skin equally.

However, we also received a large number of responses indicating preference for the current skin. After analyzing the reasons people gave for their preference, we identified that most of these responses mentioned familiarity with the current interface, or an aversion to change as the major factor in their response. Our next steps based on these results will be to look into ways we can prepare logged-out users for change more smoothly. This might include giving additional information ahead of deployment in the form of banners and other types of context on the upcoming change.

This information allows us to anticipate first-impressions that the general public might have immediately upon launch. This isn’t data on people’s thoughts and feelings after using the new skin, it is rather a measure of people’s feelings towards the initial change in look and feel within the first few minutes of making the change. Studying large design changes on other websites and related research, a significant amount of negative initial responses to changes is expected. The survey’s results are in line with this. Perhaps we can use these results to help us maintain realistic expectations of sentiment immediately after release.

In the future, we would like to revisit the experimental design itself in ways that would allow us to study the way people feel and use the skin once they begin using it across a session, rather than in a more static form. This will allow us to have data on people’s sentiment towards using the skin, as well as allow us to predict long-term opinions after deployment.

The full results are available here - let us know if you have any thoughts or questions. Thank you! OVasileva (WMF) (talk)

RfC Draft is now ready for review

Hi everyone! We are wrapping up the drafting phase of the RfC and would appreciate your feedback and thoughts prior to opening the RfC.  In particular, it would be great to get thoughts on whether the questions and language are clear, if the structure makes sense, if there’s too much or too little information we’re providing, if we’ve missed anything that might be important for the community to consider as part of the RfC, or any other open-ended feedback.

Currently, our plan is to open the RfC next Tuesday, September 20th.  The current version of the draft is available here, and we’ll be making small changes to the language as feedback comes in. Thank you! OVasileva (WMF) (talk) 15:35, 15 September 2022 (UTC)

RfC is now open for comments

Hi everyone! Thank you to everyone that has been helping us draft the RfC over these past few weeks.  The RfC on whether to adopt the new skin after the completion of the issues discussed in this conversation is now open for comments.  We look forward to continuing the conversation there. OVasileva (WMF) (talk) 15:42, 22 September 2022 (UTC)

Adding a ping to the folks that have been most involved in the discussion so far, as well as those specifically asking about the RfC: @Andrevan, @Barkeep49, @BilledMammal, @CactiStaccingCrane, @CX Zoom, @Daß Wölf,@Donald Albury, @Doug Weller, @Femke, @IAmChaos, @Ganesha811, @Ktin, @Jonesey95, @L235, @Pelagic, @Sdkb, @Sj, @Terasail, @Xaosflux. Thanks! OVasileva (WMF) (talk) 15:48, 22 September 2022 (UTC)