Community Wishlist Survey 2023/Reading

From Meta, a Wikimedia project coordination wiki
Reading
11 proposals, 408 contributors, 651 support votes
The survey has closed. Thanks for your participation :)



Extend "Who Wrote That?" tool to more wikis

  • Problem: It is extremely cumbersome to find out who wrote a specific part of the article, get an overview of how the current content maps to the various authors etc. History search based tools like WikiBlame make it merely very cumbersome. Who Wrote That? is a tool that provides a decent experience, but it is only available at a select few large Wikipedias.
  • Proposed solution: Extend Who Wrote That? to more wikis.
  • Who would benefit: Editors who need to track down problematic (or particularly excellent) content, wiki historians, researchers, readers suspicious about the reliability of a page etc.
  • More comments:
  • Phabricator tickets: T243711, T270490 T296590, T298007
  • Proposer: Tgr (talk) 08:18, 5 February 2023 (UTC)Reply[reply]

Discussion

  • Personally I mainly care about huwiki, but the more, the merrier; I assume it makes more sense to do this in bigger blocks; whatever the team feels is achievable. (Eventually, would be nice to extend it to all Wikimedia wikis, except for Wikidata and Commons which are quite large and non-text based so that would be a waste of resources. Enwiki is about half of all wiki content and I imagine the resource cost for a tool like this scales superlinearly, so that doesn't seem like such a tall order.) --Tgr (talk) 08:18, 5 February 2023 (UTC)Reply[reply]
    Thanks for creating this proposal! I believe we're going to address this eventually anyway (at least for a few other popular languages), but with a proper proposal that hopefully does well in voting, it will make it much easier to prioritize, acquire funding if necessary, and so forth. If it means anything to voters, the system that powers Who Wrote That? is WikiWho. The algorithm works amazingly well, but it's very costly as it essentially processes and stores data on every single mainspace revision (i.e. the full history of pages). I think adding many of the popular languages won't be a problem. Doing every single wiki (except Commons/Wikidata) is probably not going to happen anytime soon. I think we'd need to first revise the architecture, do a proper production deployment, and go from there. The storage footprint is currently just too great (for context, the combined size of the currently supported languages is about 3.8TB). It would probably need a dedicated team working on it for a year or more. MusikAnimal (WMF) (talk) 03:29, 6 February 2023 (UTC)Reply[reply]
    It would be very nice to have docker/script image or something which user could just git clone from repository and it would download backup dump of the selected wiki from dumps.wikimedia.org, process it and then download and process new revisions using API to keep it sync to latest version. This would allow hackers from different language versions to test and dev it locally (and and run their own annotation servers if there is more wide interest) Zache (talk) 05:34, 19 February 2023 (UTC)Reply[reply]

Voting

Sister project read

  • Problem: Often times closely related projects might have very different pages on a topic which might appeal to different readers. These readers don't know that this other page exists as an option.
  • Proposed solution: Allow projects to define a sister project (e.g. Simple English Wikipedia for English Wikipedia) and if there is an article on the sister project display a button to allow them to click to the sister project page
  • Who would benefit: Readers who wish to try different versions to find the best one for them
  • More comments: Besides the Simple/non-simple example I gave, I could also see projects that have a very close language equivalent choosing to enable this option for their readers.
  • Phabricator tickets:
  • Proposer: Barkeep49 (talk) 17:53, 30 January 2023 (UTC)Reply[reply]

Discussion

Voting

Dark mode

  • Problem:
    Wikipedia's bright themes/skins are difficult on reader's eyes. Vector 2022 is live and both readers and editors alike are ready for a true dark/night mode, like the one already supported in the native iOS/Android apps, and joining the most popular websites, web browsers, and operating systems that offer built-in support without hacks or workarounds.
  • Proposed solution: Implement a dark mode.
  • Who would benefit: The average reader. This would also contribute to site accessibility and user energy savings (on OLED screens) and is already supported in the native iOS/Android Wikipedia apps.
  • More comments: This could be the year! This feature was previously blocked by the Desktop Improvements project, but can now proceed as directed by the Web team, built initially for logged-in users (see discussion below). In a previous update, that they stated it "would require significant work with the communities". Well this is the Community Wishlist Survey and we're ready for it!

    This request was ranked among the top wishes of 2022 (if it wasn't kept in a separate category) and was ranked #2 in 2019.

  • Phabricator tickets: task T26070
  • Proposer: czar 19:48, 23 January 2023 (UTC)Reply[reply]

Discussion

  • I definitely support this proposal. — Mr. Guye (talk) (contribs)  20:14, 23 January 2023 (UTC)Reply[reply]
  • I am strongly in favor of dark mode support on the site. - Odin (talk) 20:21, 23 January 2023 (UTC)Reply[reply]
  • Don't see why not, some people hate light colors. I followed The Username Policy (talk) 21:43, 23 January 2023 (UTC)Reply[reply]
  • I'm definitely in favour of this proposal, too. I'm aware that this will involve a massive conversion and testing of all the templates used on Wikipedia and other projects (including infoboxes, tables, charts etc.) to support, look good and be readable in both modes, and a lot of effort (and some discussion about some design choices) will be needed, but the community and the development team could work together on this for as long as necessary. --Lion-hearted85 (talk) 22:32, 23 January 2023 (UTC)Reply[reply]
  • It's rather conditional, but if another team is already doing to have to crack the problem for the Vector2022 work, then darkmode should be hanging off its shoulder, implemented 0.4 seconds after it's in place. Darkmode is the work that WMF and Community alike have been freely in lockstep agreeing that we desperately need one and only one big technical blocker prevents it. DI reckoned they'd know if their fix would be possible by the time we head to voting, so we should know well before community tech has to make their judgement if we can progress further. Personally, if we are going to have a darkmode, a palate akin to Discord's would be great - but that's one for later! Nosebagbear (talk) 22:56, 23 January 2023 (UTC)Reply[reply]
  • Support for this proposal; I'd like to look up the origins of the humble creme bruleé at 1am without blasting my eyeballs with a white text background. It would be a lot of work, but good god I think we'd all throw a party if it was implemented.Ineffablebookkeeper (talk) 23:15, 23 January 2023 (UTC)Reply[reply]
  • OK, fine, but please keep this optional. I prefer a light background when in well-lit surroundings. PJTraill (talk) 00:00, 24 January 2023 (UTC)Reply[reply]
    • "Well duh obviously" I thought when reading this, but then I realized that this proposal seems to have an assumption built-in that is yet unmentioned: that we would be able to toggle between dark and light modes. So thanks for bringing it up!
      I definitely support a dark mode that allows the users (accounts and IPs) to apply on the fly. — Mignof (talk | contribs) 02:57, 24 January 2023 (UTC)Reply[reply]
  • Support: i want to save my eyes to be honest but just make it a little greyer would be nice. 02:25, 24 January 2023 (UTC)
  • Yes, please! Honestly, even a random inversion filter of everything but images would already be a major improvement. And please, please, please, make it CSS-only, following the "prefers-color-scheme" information --Tfardet (talk) 06:41, 24 January 2023 (UTC)Reply[reply]
  • Strong agree. The brightness of the standard browser page and the style of the existing dark mode gadget have both triggered migraines for me in the past, limiting the contributions I can make. DJ Cane (talk) 08:49, 24 January 2023 (UTC)Reply[reply]
  • Strong support to save my eyes! Tryvix1509 (talk) 09:03, 24 January 2023 (UTC)Reply[reply]
  • Strong support, the gadget isn't actually a darkmode but simply just a color inverter which, in my opinion, is just a lazy way of doing it. Rather than putting in the effort to make a real darkmode it's basically jsut "You asked for a dark mode! This is a mdoe that's dark". We want a real dark mode, not a color inverter. ― Blaze WolfTalkBlaze Wolf#6545 13:38, 24 January 2023 (UTC)Reply[reply]
@Blaze Wolf: - are you aware of the reasons we don't have a full dark mode? Do you believe they are consistent with the WMF (or a team within) simply being "lazy"? Nosebagbear (talk) 11:12, 25 January 2023 (UTC)Reply[reply]
For whatever reason I was never notified of this response Isn't it something to do with not having enough money supposedly? I'm not saying the team is being lazy, I just feel they could've put some more effort into it other than just making it a color inverter which some OSes come with as an option default (I know Windows 10 and Chrome OS both have color inverters default, don't know about other OSes). ― Blaze WolfTalkBlaze Wolf#6545 23:04, 10 February 2023 (UTC)Reply[reply]
  • Strongly support: More people will want to edit at night in their dark rooms! Findingmoney100 (talk) 16:42, 24 January 2023 (UTC)Reply[reply]
  • I definitely agree. An easy to find, user friendly dark mode should definately be implemented. I use dark mode through CSS but there should definitely be an implemented dark mode for the ones who don't want to fix with CSS and stuff and just want a dark mode to easily turn on for either reading or editing. Vidde09 (talk) 16:44, 24 January 2023 (UCT)
  • Yes, a dark mode feature is definitely a must, even when logged out. Only if the colors of the images don't go negative while loading, though. Lamp301 (talk) 05:27, 26 January 2023 (UTC)Reply[reply]
  • Yes, the discussion [[1]] was started 7 Nov 2022. Seregadushka (talk) 23:45, 26 January 2023 (UTC)Reply[reply]
  • Another yes vote from me. Hedles (talk) 12:18, 27 January 2023 (UTC)Reply[reply]
  • Yes yes yes yes yes, I've been wanting this for a long time. SalomeCzapiewski (talk) 19:35, 28 January 2023 (UTC)Reply[reply]
  • I will sacrifice a goat, only to this become real. --NotHasn't (talk) 14:35, 29 January 2023 (UTC)Reply[reply]
  • Strong support. For a couple of months last year I suffered from photophobia, and had to set everything to dark mode to get any work done. A lot of migraine sufferers would appreciate this. Funcrunch (talk) 19:26, 30 January 2023 (UTC)Reply[reply]
  • Comment Comment: I see the gadget was mentioned above (and the extension uses the same styles), so what do people think of it? A patchdemo exists to demo the extension, but I'd recommend trying out the gadget for a bit to get a real feel for it. ~TheresNoTime-WMF (talk) 19:45, 30 January 2023 (UTC)Reply[reply]
    Having tried it a while back I thought perhaps I was remembering it poorly so loaded it back up for yesterday. Yes, I remember why I turned it off - it's very painful on the eyes, especially with blue/purple. I've also tried some of Giraffer's - which were less bad but still somewhat painful.
    I don't know if dark mode layouts can be viably copyrighted, but if not, Discord's imo is the best I know. A mix of soft and mid-grays, slightly lighter blues. There's a reason that light-mode users on Discord are viewed as heretics[FBDB] Nosebagbear (talk) 09:31, 31 January 2023 (UTC)Reply[reply]
    I tried the gadget a while back and it resulted in flashing screen and it missed a lot of elements. For me the flashing was worse than working in light mode. Flounder ceo (talk) 16:35, 31 January 2023 (UTC)Reply[reply]
    Please note my disappointment that meta does not have the "friendly banter, don't block" template, Nosebagbear (talk) —Preceding undated comment added 09:31, 31 January 2023 (UTC).Reply[reply]
    @Nosebagbear: Fixed. Quickest wishlist "proposal" ever granted? [FBDB]TheresNoTime (talk • they/them) 16:41, 7 February 2023 (UTC)Reply[reply]
  • I support dark mode. I think the quickest way to get there would be to allow mw:Skin:Citizen for logged-in users. This skin automatically detects browser preferences and engages dark mode. I have been using it on Encyc with very few problems. Flounder ceo (talk) 16:30, 31 January 2023 (UTC)Reply[reply]
  • Hey everyone! Good news, we are going to move this proposal and let it into "Voting." We anticipate it will be very popular, given how popular it was last year as a Larger Suggestion. This being said, we want to set up expectations up front. The team implementing this wish will have to take complex considerations into account when they work on this previously "way too Large" wish. Pending the Voting results, the Web team has signed up for making dark mode available on beta, at the least. However, deploying a dark mode functionality the right way will be a multi-step process and a lot of the complexity arises when considering logged-out users. The initial release of the wish will not include logged-out users for this reason. Hope that adds visibility! Excited to see how this proposal scores in the Voting phase. Thank you all for engaging thoughtfully on potential avenues for deploying a dark mode to users. NRodriguez (WMF) (talk) 16:04, 7 February 2023 (UTC)Reply[reply]
    @Czar Do you mind if I reword your proposal to indicate that the Web team will be working on it? I just want to make sure expectations are clear when this goes into voting. Thanks, MusikAnimal (WMF) (talk) 18:23, 7 February 2023 (UTC)Reply[reply]
    I went ahead and made some changes. Hope this is okay! Note also again it sounds like only logged-in users will get dark mode, initially, in case we feel that should be explicit in the proposal. Thanks and regards, MusikAnimal (WMF) (talk) 01:27, 8 February 2023 (UTC)Reply[reply]
    The changes keep the spirit of the proposal so all good and I've updated re: logged-in users. Thank you! czar 05:58, 8 February 2023 (UTC)Reply[reply]
  • One advantage I've not seen mentioned here yet is the potential for massive energy savings. Wikipedia is one of the most visited websites in the world, and the accumulated energy savings from viewer devices using dark mode could be huge. I think it would be worth considering this as part of Wikimedia's sustainability efforts. --Veikk0.ma (talk) 23:03, 11 February 2023 (UTC)Reply[reply]
  • Just make sure it is optional and not the default mode. Studies show that reading is harder in dark mode than light mode in general, and it's also much harder to read in dark mode when you have some vision issues like astygmatia.(talk) 13 February 2023
    That is implied obviously. None of us dark mode as default. —‍(ping on reply)—‍CX Zoom (A/अ/অ) (let's talk|contribs) 11:48, 18 February 2023 (UTC)Reply[reply]
  • A good starting point will be https://commons.wikimedia.beta.wmflabs.org/wiki/Main_Page . Go to that site without logging in. Open the "Tools" drop-down menu > Click "Gadgets" > Click "Dark mode". This allows even anonymous users to use dark mode smoothly across pages. There is no white flash now, which was the case earlier on simply putting dark mode on sitewide js. Developers may use this as a template going forward. —‍(ping on reply)—‍CX Zoom (A/अ/অ) (let's talk|contribs) 11:58, 18 February 2023 (UTC)Reply[reply]
    Alternatively, the Android mobile app dark mode can be used as a template but I know very little about Android app and its feasibility to extend dark mode onto website. —‍(ping on reply)—‍CX Zoom (A/अ/অ) (let's talk|contribs) 12:02, 18 February 2023 (UTC)Reply[reply]
    CX Zoom, several technical users (and I think some WMF devs) have suggested this would result in a "cache split" where the servers would cache "with dark mode" versions of the every page/article. This would considerable increase server load and result in more cache misses, so the site would be slower for the end user sometimes as well. (but not nearly as slow as it would be if everyone created an account which would destroy Wikimedia overnight)
    prefers-color-scheme is technically the superior solution, but sadly not uniformly (or even easily in many cases) switchable for the end user.
    However, unlike for example ?uselang=de, I don't think ?withgadget= or ?withCSS= affect parser cache. There are some minor differences in the HTML outside the parser output, most notably the returnto parameter for the Special:CreateAccount link and the "mobile view" link in the footer, but I'd think (if that's part of any cache) that could be resolved differently. (either strip GET parameters from the returnto parameter and mobile view link or hack them in using JS when the link is actually clicked) But a WMF dev would have to comment on this, while I think it's technically possible to have this without a cache split, I don't know exactly how the caching mechanism works.
    Whatever the Android (or iOS) apps do can't be implemented on the website. The apps adjust things locally, on the device of the user. Extending this to the website would mean writing browser extensions for Chrome, Firefox, Edge, etc. that the user would have to install.Alexis Jazz (talk or ping me) 14:44, 18 February 2023 (UTC)Reply[reply]

Voting