Jump to content

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]

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]
    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]
    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]

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]

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]

Discussion

  • I definitely support this proposal. — Mr. Guye (talk) (contribs)  20:14, 23 January 2023 (UTC)[reply]
  • I am strongly in favor of dark mode support on the site. - Odin (talk) 20:21, 23 January 2023 (UTC)[reply]
  • Don't see why not, some people hate light colors. I followed The Username Policy (talk) 21:43, 23 January 2023 (UTC)[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]
  • 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]
  • 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]
  • 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]
    • "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]
  • 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]
  • 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]
  • Strong support to save my eyes! Tryvix1509 (talk) 09:03, 24 January 2023 (UTC)[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]
@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]
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]
  • Strongly support: More people will want to edit at night in their dark rooms! Findingmoney100 (talk) 16:42, 24 January 2023 (UTC)[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]
  • Yes, the discussion [[1]] was started 7 Nov 2022. Seregadushka (talk) 23:45, 26 January 2023 (UTC)[reply]
  • Another yes vote from me. Hedles (talk) 12:18, 27 January 2023 (UTC)[reply]
  • Yes yes yes yes yes, I've been wanting this for a long time. SalomeCzapiewski (talk) 19:35, 28 January 2023 (UTC)[reply]
  • I will sacrifice a goat, only to this become real. --NotHasn't (talk) 14:35, 29 January 2023 (UTC)[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]
  • 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]
    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]
    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]
    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]
    @Nosebagbear: Fixed. Quickest wishlist "proposal" ever granted? [FBDB]TheresNoTime (talk • they/them) 16:41, 7 February 2023 (UTC)[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]
  • 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]
    @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]
    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]
    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]
  • 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]
  • 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]
  • 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]
    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]
    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]

Voting

Moving page preview window

  • Problem: Page preview windows are sometimes uncomfortable. A example is when you want to take a quick look over a list of links, let's say, a category page. While your common method of looking over the list is to move the cursor upward or downward, the page preview may cover the later links you have to check, so you need to move your cursor off the link where the preview popped up to make it dissapear and continue normally.
  • Proposed solution: Make a mobile page preview, so that when the cursor passes over it, makes it repel. In other words, make the preview detect in which way the cursor is moving to appear in the opposite side. That means you can never click on it? Yes. You have the link you've hovered over for it.
  • Who would benefit: Users who want to do quick checking of articles with no distractions.
  • More comments: A simple functionality for that specific situation can also be made.
  • Phabricator tickets:
  • Proposer: De un millón (talk) 11:16, 5 February 2023 (UTC)[reply]

Discussion

Voting

Deploy Skin:Citizen to Wikimedia wikis

  • Problem: Currently skins of Wikimedia wikis don't support responsive layout, dark mode and font size adjusting. We need a modern skin in Wikimedia wikis.
  • Proposed solution: Deploy mw:Skin:Citizen to Wikimedia wikis.
  • Who would benefit: Readers who want a better reading experience.
  • More comments:
  • Phabricator tickets:
  • Proposer: Steven Sun (talk) 10:38, 29 January 2023 (UTC)[reply]

Discussion

  • You have to register / log in to be able to select a non-default skin. Without a good way of communicating that to readers, there isn't much value in a reader-focused skin. --Tgr (talk)
  • @Alistair3149 --Lens0021 (talk) 10:22, 12 February 2023 (UTC)[reply]
    Skin author here. I am not confident in my ability to maintain the skin up to WMF production standards by myself, due to the complexity and knowledge needed for the Wikimedia ecosystem (e.g. editor needs, extension support, etc.).
    I agree with Tgr here, anon makes up the majority of readers and there isn't a user-friendly way to switch skins. The problem listed above is being tackled in other ways, such as Vector 2022. Skin is only part of the equation. Many content on WMF wikis are designed for Vector and sometimes for a specific scenario, implementing responsive layout, dark mode, and flexible font size would be a huge challenge as well. Alistair3149 (talk) 22:55, 14 February 2023 (UTC)[reply]

Voting

Allow user to pin/unpin specific languages

  • Problem: It can be difficult to quickly find languages relevant to you from the list of language versions. The Compact Language Links feature is supposed to solve this, but ironically it makes it even more difficult so I've disabled it globally. Currently, there are three ways for a user to make specific languages appear in the abbreviated list. All have serious problems:
    • One way is to configure your browser's language preferences. But more often than not, the reason you want to see a page in a certain language isn't necessarily that you comprehend that language; it just means you suspect that language version might have information you're seeking that can be extracted even if you're not fluent in it. Not only that, just because you want to visit certain language versions of WMF projects doesn't mean you want to read other sites in those languages, let alone tell every website you visit that you understand them, which has serious privacy concerns because it enables them to fingerprint you more easily.
    • Another is to list languages in a Babel box on your user page. This has similar problems: The reason you want to read certain language versions isn't necessarily that you understand them, and you have to publicly state your language skills, which is a potential privacy issue.
    • The other is to select a language from the list, which makes it appear in the compact list. But just because you wanted to read one article in a language doesn't mean you might want to read all other articles in that language. The inability to remove languages from the compact list renders it useless.
  • Proposed solution: A "Pin" or "Unpin" button next to each language on the language selection panel. "Unpin" should appear next to not only user-pinned languages but also suggested ones based on geolocation or previous selection.
  • Who would benefit: Readers
  • More comments:
  • Phabricator tickets: T188401 (partial)
  • Proposer: Nardog (talk) 18:42, 23 January 2023 (UTC)[reply]

Discussion

  • I guess the solution exists, it is Full language list. It used to be a default option and was displayed on the left as a complete alphabetical list of interwikis. You could see at a quick glance whether the article exists in, say, Catalan (if you read something concerning Spain). Now this option is buried in Preferences > Appearance > Languages and unavailable for non-logged in users. Restoring this for all viewers is my fondest hope. — 2dk (talk) 20:04, 23 January 2023 (UTC)[reply]
  • I have just noticed this, having made a related suggestion for Wiktionary. It sounds reasonable, though it is not a problem I have. PJTraill (talk) 00:09, 24 January 2023 (UTC)[reply]
  • Strong support. When I read an article about Italian culture on Chinese Wikipedia, I usually go to Italian Wikipedia and read the Italian article using machine translation because I think Italian Wikipedia may have a better coverage of Italy-related topics, although I can't speak Italian, I can use machine translation to understand the article roughly. But when I go to Italian Wikipedia via Compact Language Links, The "Italian" option is permanently in my compact list, it's useless when I read articles not about Italy. A "Pin" or "Unpin" button would be useful for me. --BlackShadowG (talk) 13:27, 25 January 2023 (UTC)[reply]
  • Just wanted to share some mockups I've made during the process of designing Vector 2022, regarding this user need:
Prototype of pinning the language menu to the sidebar
Language toolbar in Vector 2022
Language link to switch back to French, next to language menu button
more details here: https://phabricator.wikimedia.org/T301787 AHollender (WMF) (talk) 20:25, 25 January 2023 (UTC)[reply]
I fail to see how that pertains to "this user need". None of those mockups show pinning or unpinning user-specified languages. Nardog (talk) 06:32, 26 January 2023 (UTC)[reply]
  • Vector 2022 has disabled this option of showing the language links but I think we should pin some specific language links to further reading of the same article in other languages. Thingofme (talk) 13:20, 29 January 2023 (UTC)[reply]
    Vector 2022 hasn't disabled it, it just shows them under a dropdown menu. This proposal isn't about getting them out of the dropdown but about letting the user choose what's at the top of the menu, whether it's inside a dropdown or not. Nardog (talk) 14:27, 29 January 2023 (UTC)[reply]
    This is like selecting language inside the dropdown menu for convenience. Thingofme (talk) 15:17, 18 February 2023 (UTC)[reply]
  • Currently it is already possible to pin languages just by selecting them. The user selections are the top priority used by the language selector to show the "suggested" languages on top. This aligns with a quite natural behaviour, people interested in language X will read contents in such language and it will become easier to find the next time. However, unpinning is not possible today and it may be convenient to add based on the comments above. If I navigated once for curiosity to the Y language, it may not be useful to have it in the "suggested" languages. Having the Y language displayed would cause no harm (the suggested languages are a short list quick to process and other relevant languages the user selects frequently will appear), but having a way to remove it can help people to avoid the surprise of finding an irrelevant suggestion. --Pginer-WMF (talk) 09:50, 6 February 2023 (UTC)[reply]
    Supporting unpin only would mean you'd have to remove it every time you chose a language you wanted to read just one page but not others in, which would not adequately address the wish. Having the Y language displayed DOES cause harm, because it drowns the other languages you actually want to see pinned. Nardog (talk) 11:20, 6 February 2023 (UTC)[reply]
    I “proposed” this in some forum a while ago and was told the same; this is extremely opaque (what we call a “hidden affordance” in design) and therefore extremely user-unfriendly. Tab browsing has existed for more than two decades. When we select a different language we right-click and open in new tab so that we can read both versions and compare them, so our true selections are never registered. When we left-click it’s a mistake. So oftentimes the compact menu registers the exact wrong selections. Al12si (talk) 19:55, 7 February 2023 (UTC)[reply]
    IOW what this wish does is to expose that affordance, making the “existing” feature user-friendly. This wish cannot be compared to the existing behaviour; they are apples and oranges. Al12si (talk) 20:06, 7 February 2023 (UTC)[reply]
    When we left-click it’s a mistake. So oftentimes the compact menu registers the exact wrong selections. Exactly! I had a language I'd never even heard of but misclicked at the top of the list for a long time and finally decided to figure out what the hell was the culprit, and turned the CLS off. Nardog (talk) 00:46, 8 February 2023 (UTC)[reply]

Voting

  • Problem: Opening a link
  • Proposed solution: Add a user preference that would set links to open automatically in a new window
  • Who would benefit: Good for everyone
  • More comments:
  • Phabricator tickets:
  • Proposer: Wthjmkuiper (talk) 12:50, 28 January 2023 (UTC)[reply]

Discussion

No, this is not good idea. Who use mouse, can use middle button. On mobile device use longer touch and select "open in new tab". Maybe exists some gadget which adds target="_blank" for links. JAn Dudík (talk) 08:39, 31 January 2023 (UTC)[reply]

Many browser preference and existing browser extensions/gadgets should already support this behavior.
Use of _target has been discouraged in web development for over a decade now, so like Jan, I wouldn't advise this. Jdlrobson (talk) 17:42, 3 February 2023 (UTC)[reply]
Also, the use of target="_blank" is bad for accessibility (this is especially a problem for blind users; it would not benefit them). It should not be done. The user needs to be in control and target="_blank" takes agency away from users. — Al12si (talk) 20:35, 7 February 2023 (UTC)[reply]
Actually, target="_blank" has been a (non-deprecated) part of HTML5 since at least 2011 (see, for example, the spec on Navigable target names). It was briefly deprecated in HTML 4 but that was a long time ago. - CRGreathouse (talk) 20:18, 21 February 2023 (UTC)[reply]

I'm a chronic open-in-new-tabber myself, so I appreciate and endorse the underlying sentiment here. Nevertheless, I don't think this is an appropriate domain for a Wikimedia intervention. It belongs at the browser level, where such options are already universally supported. It's strongly discouraged for individual web sites to insist on pages being opened in new tabs or windows, even by user request. NillaGoon (talk) 22:39, 11 February 2023 (UTC)[reply]

Too many times I followed links that looked promising but when I wanted to go back to where I came from, I couln't. I got stuck in one of these pages. When I use WordPress I have a choice. I would like to have the same choice in Wikipedia. Nobody is obliged to use that feature. That's all. Yours, Willem.

Voting

  • Problem: I know that in the vast majority of articles, some terms haven't a link because they've been mentioned before, so it wouldn't be necessary to link them again. However, trying to find in the article where's the term which is linked can borrow you time -what's more, you could be searching for a link that doesn't exist. In the last case, you have to spend more time editing the page, and adding those links (you can search it on the search box after all, but anyway).
  • Proposed solution: Creating a function while reading. Upon normal text, the user can select a fragment of it believing that could be the title for an existing article. Then, the selected fragment, if it matches with the title of an article, it will show the article preview window, just as if it was a normal link.
  • Who would benefit: Common users that enter Wikipedia to check or deepen information, avoiding any distraction.
  • More comments:
  • Phabricator tickets:
  • Proposer: De un millón (talk) 22:34, 4 February 2023 (UTC)[reply]

Discussion

Voting

Return to the article when closing the MediaViewer

Discussion

Voting

Customization of text

  • Problem: Text may be too small, not the right color, wrong font, or displeasing.
  • Proposed solution: Allow for users to set default font sizes, text colors (including normal, link, visited, and redlink colors). Text width may also be more granular instead of all or regular.
  • Who would benefit: Everyone because this brings greater accessibility.
  • More comments: I'd like for the settings to be available on each page, but also provide an opt out so the menu only is in the settings area.
  • Phabricator tickets: https://phabricator.wikimedia.org/T91201
  • Proposer: JackFromWisconsin (talk) 00:33, 24 January 2023 (UTC)[reply]

Discussion

  • Yes more like a user preference. I forgot that custom CSS was available, but that isn't accessible to those logged out, or to those who only read. Lots of websites have accesibility menus where you can change how the site looks. Wikimedia should be no different. --JackFromWisconsin (talk) 16:23, 26 January 2023 (UTC)[reply]

Voting

Create a button to expand all collapsible elements on a page

  • Problem: Some pages have many collapsible elements, for example Bulgaria women's national football team results, and it can be very tedious clicking "show" for each of those elements.
  • Proposed solution: Add a button to "Tools" that will expand all the collapsible elements with one click.
  • Who would benefit: Anyone who wants to see a page fully expanded; also editors who need to compare a preview of their edits to a page with the original page with all collapsed elements shown.
  • More comments:
  • Phabricator tickets:
  • Proposer: —Bruce1eetalk 10:12, 24 January 2023 (UTC)[reply]

Discussion

@MusikAnimal (WMF): I'm referring to the desktop, not the mobile. The "Tools" I'm referring to is the Tools menu at the top right in Vector 2022 (or the Tools menu in the left-hand side in Vector 2010). It doesn't matter where this button would go, the Tools menu was just a suggestion. —Bruce1eetalk 21:38, 24 January 2023 (UTC)[reply]
Okay, got it! I thought you meant the collapsible "sections" as seen on the mobile site. You're referring to collapsible elements. I have reworded and retitled your porposal accordingly. Hope this is okay! MusikAnimal (WMF) (talk) 21:57, 24 January 2023 (UTC)[reply]
@MusikAnimal (WMF): Thanks, that's better; "collapsible elements" is correct. —Bruce1eetalk 22:04, 24 January 2023 (UTC)[reply]
  • I vaguely remember that there was a userscript for this somewhere, but I can't find it right now.. It definitely wouldn't be hard to make one, as there is a hook that is triggered for all collapsible elements, which you can use to modify the behavior (this is how autocollapse works). —TheDJ (talkcontribs) 14:13, 25 January 2023 (UTC)[reply]
  • @Bruce1ee: I wish the Vector 2022 skin for the desktop site would have an option to move the global search box under everything else in the top header row (the site logo, the tools icons, et al.). I regularly look at Wikipedia with Firefox zoomed at 170% with the browser sidebar permanently expanded to display browser tabs vertically, and this causes the Wikipedia search box to collapse into a little magnifier icon I have to constantly click to expand again. I wish this need to click to expand a global search box at any page zoom setting would go away, at least optionally, if a user could go into settings (which unfortunately requires logging in), and ticking a box to permanently keep the search box in its own row in the site header, with nothing else in that row. — Derrgill (talk) 02:08, 21 February 2023 (UTC)[reply]
    @Derrgill: I think you may have misinterpreted this proposal. It refers to expanding all collapsible elements within an article. —Bruce1eetalk 07:02, 21 February 2023 (UTC)[reply]

Voting