Editing Project:Village pump (proposals) (section)

===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.

@[[User:SGrabarczuk (WMF)|SGrabarczuk (WMF)]] and @[[User:OVasileva (WMF)|OVasileva (WMF)]]: In some other circumstances, I've [[Wikipedia_talk:Talk_pages_project#New_Topic_Tool_for_everyone|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 [https://www.fastcompany.com/3028615/the-beautiful-wikipedia-design-that-almost-was 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 [[:File:Wikipedia New Vector TOC screenshot.png|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 [[mw:Talk:Reading/Web/Desktop_Improvements#Table_of_contents_below_sidebar_just_doesn't_work|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 [[Wikipedia:Village_pump_(technical)/Archive_195#Coord_not_displaying_correctly|previously discussed]] (with {{u|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 [[mw:Reading/Web/Desktop_Improvements/Updates#July_2022:_Page_title/tabs_switch|most recent newsletter]], you write that the page tabs/title switch {{tq|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 [[Wikipedia:Village_pump_(proposals)/Archive_174#Move_good/featured_article_topicons_next_to_article_name|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 [[WP:FRAM|Framgate]]-level firestorm.) Cheers, <span style="color:#AAA"><small>&#123;{u&#124;</small><span style="border-radius:9em;padding:0 5px;background:#088">[[User:Sdkb|<span style="color:#FFF">'''Sdkb'''</span>]]</span><small>}&#125;</small></span> <sup>[[User talk:Sdkb|'''talk''']]</sup> 00:34, 14 July 2022 (UTC)

:@[[User:Sdkb|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:
:# 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.  
:# 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.  
:# 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.  
:# 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 [[Wikipedia:Village pump (technical)|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. [[User:OVasileva (WMF)|OVasileva (WMF)]] ([[User talk:OVasileva (WMF)|talk]]) 12:27, 27 July 2022 (UTC)
::@[[User:OVasileva (WMF)|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? <span style="color:#AAA"><small>&#123;{u&#124;</small><span style="border-radius:9em;padding:0 5px;background:#088">[[User:Sdkb|<span style="color:#FFF">'''Sdkb'''</span>]]</span><small>}&#125;</small></span> <sup>[[User talk:Sdkb|'''talk''']]</sup> 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. [[User:CactiStaccingCrane|CactiStaccingCrane]] ([[User talk:CactiStaccingCrane|talk]]) 04:14, 29 July 2022 (UTC)
:::Hey @[[User:Sdkb|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 [[Mw:Reading/Web/Desktop Improvements/Repository/Sticky Header and Table of Contents User Testing|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. [[User:OVasileva (WMF)|OVasileva (WMF)]] ([[User talk:OVasileva (WMF)|talk]]) 08:51, 2 August 2022 (UTC)