Jump to content

Community Wishlist Survey 2021/Reading

Add links
From Meta, a Wikimedia project coordination wiki
Community Wishlist Survey 2021
Reading
13 proposals, 236 contributors, 346 support votes
The survey has closed. Thanks for your participation :)



"Favourite" or "Followed pages" button

  • Problem: Watchlist not so reader-friendly
  • Who would benefit: everyone
  • Proposed solution: either a new"Favourites" button or a button which would lead the reader directly to the read version of the watchlist pages, ordered alphabetically.
  • More comments:
  • Phabricator tickets:
  • Proposer: cristixav (talk) 09:05, 17 November 2020 (UTC)[reply]

Discussion

I think it would be helpful to have either a "Favourite pages" button, which would lead the readers straight to a list of pages they like/constantly need for reference etc, which would be internal, i.e. once a wikimedia project is accessed, and not relying on the "favourite" feature of the browser. Alternatively, one could create a button for the existing watchlist, which would lead the reader directly to the read version of the article. The list of favourites/watched pages should be alphabetical and not dependent upon the chronology of updates. All the existing features would remain in place. Ideally, such a button should also work across languages and projects. cristixav (talk) 09:05, 17 November 2020 (UTC)[reply]

I don't see what benefits this would bring over the bookmark feature or the session/tab-saving feature every browser I know of has. Silver hr (talk) 11:53, 17 November 2020 (UTC) Actually, I thought of one - storing the data remotely would make it work across devices. But then again, cloud services for storing bookmarks/browser sessions exist. I guess I'm neutral on this. Silver hr (talk) 12:00, 17 November 2020 (UTC)[reply]
  • I'm merging a very similar proposal here. It was Add a "favorite this page" in the "watch this page" star:
    • Problem: The most important articles to a particular editor get lost in a big watchlist
    • Who would benefit: Editors who watch a lot of stuff
    • Proposed solution: Add the possibility to "favorite this article". A favorite article would be represented by a golden star where the blue star currently is. Favorite articles (or pages in general) would always appear at the top of the watchlist. A favorite page would also include all the other characteristics of a watched page.
    • Proposer: Bageense (talk) 16:49, 24 November 2020 (UTC)
    @Bageense: I hope this is okay! Sam Wilson 02:35, 25 November 2020 (UTC)[reply]

Voting

Find a more satisfactory display of LaTeX formulas

(Machine translation from French to English.)

  • Problem: The current system for displaying and exporting mathematical formulas leaves much to be desired. The formulas are converted into images where the text appears in black on a transparent background, then inserted into the text thread. For this reason, mathematical formulas more or less clash with the surrounding text:
- on the site, the formulas are always black, whatever the color of the surrounding text (see this page, the note); the same on the e-reader, where the problem even more annoying for people who use an e-reader with a dark background: the formulas are properly illegible;
- the alignment of the mathematical text on the line is not perfect, nor its size;
- more anecdotally, the font differs from the ambient font.
This also causes purely typographical problems, in particular the rejection of punctuation on the next line when the formula is at the end of the line (cf. the same example, in the second paragraph, or the next page, first line).

I would therefore like to see the formulas rendered in a more coherent manner with the surrounding text, and above all in such a way as not to violate the most basic rules of typography.

  • Who would benefit: All readers of scientific texts, especially those who export them from Wikisource.
  • Proposed solution: For display on website: solutions, like MathJax for example? For export: we could offer several export options, one that would keep the current state, with conversion of formulas into images; another with export of the TeX syntax directly (well rendered under Caliber for example); etc.
  • Other comments: Please note that the request does not concern the input of mathematics by contributors, but their display and export.
  • Phabricator tasks:
  • Proposer: ElioPrrl (talk) 18:25, 23 November 2020 (UTC)[reply]

Discussion

Voting

Alt-Texts and Image Descriptions

  • Problem: There are many images without alt-texts and/or image descriptions for visually impaired people. Images without that are not accessible for blind people. Texts related to undescribed pictures aren’t fully accessible as well.
  • Who would benefit: Visually impaired people
  • Proposed solution: Add a field in media-uploader on Commons via structured data to raise awareness and to supply images with alt-texts and image descriptions.
  • More comments: Existing descriptions on Commons and Wikipedia f. e. are not descriptions as mentioned above.
  • Phabricator tickets: task T260006, task T21906, task T166094, task T213585
  • Proposer: Conny (talk) 05:52, 27 November 2020 (UTC)[reply]

Discussion

  • Good proposal. Also it would be helpful to explicitly describe what an alt text should be, as I suspect many people do not know (considering what I've seen in those instances where there is an alt text). On a related note, would it be possible to add default alt text automatically by a image recognition software (that can then be improved by humans)? --Ita140188 (talk) 04:24, 2 December 2020 (UTC)[reply]
  • If this is a proposal to centrally store alt text for images, to be used on projects, then I strongly oppose it, for the reasons given when it has been previously suggsted elsewhere, and rejected. At the very least, please do not progress this proposal without first consulting with screen reader users and/or accessibility professionals. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:39, 10 December 2020 (UTC)[reply]
  • Yet another field? Why not just use the image's plain old description? --NaBUru38 (talk) 21:04, 10 December 2020 (UTC)[reply]
    These are two different things. Alt text is a substitute for the seeing: it describes things that many readers have already seen in the image. A description explains something above and beyond what you’re seeing, it serves both sighted and blind readers, and it may be useless unless you can see the image or read the alt text. (I am not an expert, but I’m sure I can provide an example or two if this is still unclear.) —Michael Z. 2020-12-11 23:14 z 23:14, 11 December 2020 (UTC)[reply]
  • A proposal shall suggest that a particular problem needs to be solved, but it should refrain from requiring implementation details. It is up to research and broader considerations which approach is finally chosen to reach the target.
    An older plan for global storage of descriptive texts which will be delivered every time an image is transcluded on any page has been:
    <alternatetext lang="fr">…</alternatetext>
    <alternatetext lang="pt">…</alternatetext>
    Those would be located on description page, and best match for user language including finally fallback to English if present will be added to image presentation by the server. It is not limited to Commons and some Commons-only structured data, but will work on every wiki even out of WMF for local media as well.
    BTW, the technicalities about alt text and screen readers and accessibility started with HTML.4 in 1998, and were further developed by ARIA. It is quite clear what is to be delivered within the HTML document.
    --PerfektesChaos (talk) 16:42, 12 December 2020 (UTC)[reply]
  • I fully support the general idea of the proposal but it has some major flaws. First of all, this proposal would have huge impact on the Commons community's workload (manually adding structured text) and should therefore ask for their support at Commons:Requests and votes. Also, I agree with PerfektesChaos and Andy Mabbett. Chances are there is a different solution that serves people with a vision impairment better and faster. Any such solution needs to be based on actual user needs and their standard accessibility technology. I would rather support a community request to the Wikimedia Foundation asking they generally update their websites to meet current accessibility standards. --Martina Nolte (talk) 19:12, 12 December 2020 (UTC)[reply]
    Thank you for your general support. The Image Description is an optional additional information, so it should grow in a slow way. It would make sence to have new authors for reviewing these texts. Conny (talk) 10:59, 13 December 2020 (UTC).[reply]
  • As explained in the linked tasks, having a place in UploadWizard to enter alt text is part of the work needed to get it to users, but we'd also need a mechanism to transfer the data from Commons to the wikis using the image. I agree with PerfektesChaos that this proposal could use some more generic phrasing. --Tgr (talk) 00:26, 13 December 2020 (UTC)[reply]
  • What the proposal actually wanted to express:
    ❤ Implement a mechanism to deliver alternate texts with every image transclusion in user language that are stored and maintained centrally together with the image media, if the current transclusion does not provide an alt= parameter.
    However, the first proposal is too explicit and specific on the following keywords:
    ☛ Commons – what about images on local wikis? What about non-WMF MW installations?
    ☛ structured data – this is one particular storage mechanism, but quite limited to Commons and WMF at least. The proposal should not prejudice one solution only.
    ☛ Uploading – what about 100,000,000 images present on Commons and local wikis when roll out date of the new mechanism arrived? Really a feature for uploading future images only?
    The proposal sounds a bit as if everybody uploading a new image shall be forced to provide a description for blind people, even more as a mandatory requirement?
    ✦ Sounds like a further threshold to make uploading forms and procedure more difficult.
    ✦ It needs some understanding what visually impaired people need, and in opposite to a common legend. That was already raised in this section. The traditional legend is specifying which things are presented by the image. The alternate text is telling what is visible, and rather pointless for those who can see the image. Writers must have a deeper concept which information blind people require to imagine the image from text.
    ✦ The uploader could have taken a picture of the it:colosseo and provided an alternate text in mother tongue, Italian. Readers of a Wikipedia article in Japanese or Spanish might want to hear a concise description, not really a machine generated one, in their native language.
    ✦ However, if ever working current automatic translations are pretty smart and might create a version in user language on the fly. But this is step 2+x far off.
    There is already an implementation for the tag extension approach <alternatetext> running: TemplateData are creating a compressed JSON description of the <templatedata> element which is stored as page property of the template page. That might be a role model how <alternatetext> can be evaluated when saving an image description page and create a similar page property of the media. When delivering an image transclusion within a particular HTML page in a particular user language that page property may be evaluated by fallback cascade. If cache administration is complaining then page language is acceptable.
    ✎ Rather than delivering to everybody with all HTML pages, a page property could be evaluated and add alt text on client side to the document in user language by a MW gadget for those who have a preference for this feature. However, screenreaders are reluctant to execute JavaScript.
    Greetings --PerfektesChaos (talk) 18:29, 13 December 2020 (UTC)[reply]
    The "user language" part is debatable (everything else about the article, including the image caption, is in content language; why would the alt text be an exception? Architecturally, it wouldn't really fit into our current caching model); otherwise this is a good description. Using structured data is a no-brainer, but certainly doesn't have to be stated explicitly in the proposal. --Tgr (talk) 23:57, 13 December 2020 (UTC)[reply]
    I wrote “If cache administration is complaining”.
    Looking at my last point delivering later on client side for a very small minority rather than for everybody but ignored by >99% of visitors and consuming bandwidth, on client side the user language is known, and of course the description would be told in user language if available even when visiting an article in a different wiki but the environment around the article is in user language.
    How does “structured data” fit into local and non-WMF wikis?
    Greetings --PerfektesChaos (talk) 17:06, 14 December 2020 (UTC)[reply]
  • As a screen reader user, I think this is a good idea in theory, but I tend to agree with the concerns of Andy Mabbett, PerfektesChaos, etc. The correct alt text for an image (as opposed to its description) can depend on context as well. Graham87 (talk) 13:04, 16 December 2020 (UTC)[reply]
  • To echo want Graham87 says, alt text will often depend on context. When images are used in Wikipedia articles, they are intended to convey information relevant to the article; and it is the pieces of that information visible to a sighted reader (but not to a screen reader) that need to be conveyed by alt text. If we use the image File:Washington and Lafayette at Valley Forge.jpg in an article about Valley Forge, we probably intend to convey the winter conditions depicted, but the colour of the brown horse is immaterial, so the alt text describes the conditions and not the horse. If we use the image in an article about George Washington's horses, we will probably take the opposite course.
    I'm sorry, but I don't see how a central repository like Commons can anticipate every possible use of their images and be able to usefully suggest alt text for them. Writing good alt text is very often a bespoke job for editors at individual articles, not an automated process. --RexxS (talk) 21:26, 16 December 2020 (UTC)[reply]
    When I reformulated the proposal, I wrote: if the current transclusion does not provide an alt= parameter.
    If an individual text is provided with transclusion, that one will take precedence.
    If not and it happens that a text is available in a fallback language, the one from local or commons image description page is offered in current page.
    Looking at 100,000,000 images when the proposal has been implemented and perhaps 10,000 local alt as starting point (those might be collected and made available for all pages on all wikis) we are at 0,01 % of the images with one single language. The issue of context dependant description is probably the least problem.
    Greetings --PerfektesChaos (talk) 14:35, 18 December 2020 (UTC)[reply]
  • Please excuse me if this is a stupid question, but can you tell me, how many images do already have alt-texts? Or how many percent? --KH32 (talk) 12:02, 18 December 2020 (UTC)[reply]
    This is no stupid question at all.
    German Wikipedia has 2,500,000 articles, 500,000 with at least one image transclusion, about 4,000 with at least one non-empty alt parameter, most of them insufficient since stupidly repeating legend but no visual description; perhaps 1,000 or 2,000 meaningful alternate texts. IIRC enWP and others have no better ratio.
    One of the ideas is to collect all existing alternate texts by gadget, check them manually whether they are a visual description and not confusing, and populate the linked media description page (local or commons) with that entry for that language. Then they are available on all other pages and wikis where the same image is transcluded. Further descriptions and languages may be added later.
    Commons has 66,988,373 media files right now.
    Greetings --PerfektesChaos (talk) 14:35, 18 December 2020 (UTC)[reply]
  • Thank you very much. And on the other hand most most most images in articles get a caption there that is delivering context. So what would we loose if we would introduce alt-texts that mostly deliver a short image description, a translation of the visual content for blind users? The context would still be added article by article in the captions. This way we would avoid duplication and would allow automatic translation. --KH32 (talk) 12:00, 19 December 2020 (UTC)[reply]
  • PS I'm just about to expand the article on alt-texts in the German Wikipedia. Maybe someone here is on the same track? Maybe we could join forces then. In any case I would be happy for your response:-) --KH32 (talk) 12:08, 19 December 2020 (UTC)[reply]

Voting

Add a Back to Top function in Wikivoyage desktop version

  • Problem: The content of any page of Wikivoyage is constantly increasing. Although we have the Pagebanner directory function, when the page moves down, Pagebanner will not follow it. So I think we can add the Back to Top function to the lower right corner of the page, which is convenient After clicking, return to the top Pagebanner block.
  • Who would benefit: Reader and editor
  • Proposed solution:Add a function for Back to Top or Pagebanner can move down with the page in Wikivoyage desktop version
  • More comments: This feature will help readers find the Pagebanner directory they want to query faster.
  • Phabricator tickets:
  • Proposer: ✈IGOR／ 〒 Tell Me What?! ． Wikivoyager 16:27, 20 November 2020 (UTC)

Discussion

Voting

Bookmarking

  • Problem: There are no bookmarking if reader is on break or sleep.
  • Who would benefit: Everyone
  • Proposed solution: To resume reading if reader takes break.
  • More comments:
  • Phabricator tickets:
  • Proposer: Farpen (talk) 05:32, 17 November 2020 (UTC)[reply]

Discussion

  • If you need to save an article, you can press the star button and it is added to your watchlist, if you want to save the section of the article you are reading, you can click that section on the content table and save it as a browser bookmark.WikiAviator (talk) 13:56, 17 November 2020 (UTC)[reply]
  • A list of "Saved pages" could be really useful, if readers were informed of the feature. Browser bookmarks can be hard to navigate through, and have limited scalability; Watchlists serve a different purpose. — Bilorv (talk) 20:02, 17 November 2020 (UTC)[reply]
  • I’d really welcome such a feature. In contrast to client-side, most browser’s bookmarks functionality our implementation could (and should) take account of collections, i.e. books on Wikibooks. I usually only have one bookmark in physical/paper books. Setting a new bookmark should override the last bookmark in the same collection/Wikibook. (I mean, in addition to that, sometimes I mark individual pages by putting sticky notes on them, but those aren’t really bookmarks, rather mere labels.) Kays (talk) 23:09, 20 November 2020 (UTC)[reply]
  • fwiw, this is a feature in the native smartphone app, so sounds like a matter of bringing it to desktop/browser. This said, I agree with the comments above—browsers already have ample built-in and extension-based methods for saving links across the Internet and there is little benefit in competing with that unless there is something about bookmarking behavior specific to browsing Wikimedia properties. czar 05:31, 23 November 2020 (UTC)[reply]
  • Problem: It's hard to keep track of what you want to read. Sometimes you're in the middle of an article, and see a link to an interesting page, but forget about it because there's no easy way to save it.
  • Who would benefit: Everyone who does a lot of in-depth research on WikiPedia!
  • Proposed solution: Implement a library of reading lists, similar to the one present on the mobile versions of WikiPedia
  • Proposer: Raven rs (talk) 01:12, 18 November 2020 (UTC)

Discussion

In My Library you make your categories and save articles to the section. Favorites are star marked and head each category or overview page.


Ldorigo95 (talk) 09:52, 18 November 2020 (UTC) I added some details on this submissions as I would also like it to see the day. The functionality is already present on mobile, I feel like it's really missing on the online version.

  • I appreciate that this proposal suggests the user's Reading List should sync across all devices (mobile and web browsers). - ZuluKane (talk) 17:46, 24 November 2020 (UTC)
  • @Ldorigo95: Yes, there are similarities with favorites, bookmark etc. However, I think multiple propasals can be combined. My proposal is "My Library" where you collect all your articles. But you can subdivide them by category (you make a "folder" where you put your articles by your topics "WW II", "US history" etc). But you can also mark "favorite/star marked", rate them by importance (5 points) articles you just "follow" for updates etc. So you can have several markings on an article you put in "economy" which you "follow" and you rate it 4 points making raknking it higher and you have it as your favorite. On your my library screen you see the latest updates on your followed and you have an short-overview to your favorites. In this way you always find and can sort the articles most important to you as fast as possible. A "Reading List" can extract updated articles you follow or related articles. There should also be "unread/read".

    — The preceding unsigned comment was added by Raven rs (talk) 08:38, 25 November 2020 (UTC)

  • @Raven rs, Ldorigo95, and ZuluKane: I've merged this in to the Bookmarking proposal. Feel free to add more info here as you see fit. —Sam Wilson 03:01, 25 November 2020 (UTC)

Voting

Increased accessibility

  • Problem: Some readers find Wikipedia pages difficult to read due to sight and other reading issues involving colours.
  • Who would benefit: Those with sight and reading difficulties.
  • Proposed solution: Have an accessibility section on the left-hand side of the page (where Community, Beyond the Web and Tools are located). This would allow readers to quickly and easily change the size of the text in the article, change the font colour from black to a range of other colours and allow the changing of blue links to an alternate colour. You could have Accessibility at the top, then the clickable links underneath: Font size, Font colour, Link colour (and any other accessibility options people wish to add to this). The default font size and colours would still remain as they currently are. If an article has a spoken version this could also be listed in this accessibility section.
  • More comments:
  • Phabricator tickets:
  • Proposer: Helper201 (talk) 22:57, 25 November 2020 (UTC)[reply]

Discussion

In the years 2016-2019 we've replaced the colors in Wikimedia products to comply with Web Content Accessibility Guidelines 2.0/2.1 level AA. Colors are part of a palette defined with these considerations in mind. For a discussion around settings beyond, you're probably looking for something similar to what's described in phab:T91201 – (easily accessible) accessibility settings --Volker E. (WMF) (talk) 20:00, 29 November 2020 (UTC)[reply]

Voting

  • Problem: In my humble opinion, it is most likely that people using PCs when following a link of format https://en.m.wikipedia.org/w/... would probably want to switch back to desktop view to read it, since they used to it. Currently, users have to find the small button of desktop version in the very bottom of the page.
  • Who would benefit: I think most of the desktop users following mobile links.
  • Proposed solution: Detect the way of browsing and based on that switch to a corresponding view type.
  • More comments: Of course there might be people who want to use the mobile version on PC, but this function should be switchable then.
  • Phabricator tickets:
  • Proposer: Stanislav Kondratev Станислав Кондратьев (talk) 12:59, 20 November 2020 (UTC)[reply]

Discussion

  • This will be appreciated. I use Firefox both on mobile and desktop and Firefox Sync allows me to syncronize bookmarks. This is very helpful in my workflow but I end saving a lot of mobile versions to be later edited on desktop. When I start a session in my desktop, I have to manually update the links to make it more comfortable to read/edit. However, I see an issue with automatically redirecting to the desktop version. Since the url are different, the browser does treat changes as redirect and does not recognize the page as bookmarked (since the bookmark url is different). That means that once I'm finished I'd need to manually go to my bookmark list to remove the bookmark from my to do list. --FAR (talk) 09:49, 29 November 2020 (UTC)[reply]

Voting

Show Wiktionary definitions in Page Previews

čeština: Pohodlné a příruční propojení projektů wiki, zejména wikipedie a wikislovníku

  • Problem: the connection between Wiktionary and Wikipedia (which in my opinion should never have been separate) is awkward, and it is necessary to switch and search them separately
čeština: propojení wikislovníku a wikipedie (které podle mého neměly být nikdy oddělené) je nešikovné a je nutné přepínat a hledat samostatně
  • Who would benefit: all users, especially those who explore the interpretation in more depth - about the meaning of terms, including synonyms and their origin (etymology)
čeština: všem uživatelům, zejména těm, kteří zkoumají výklad hlouběji - o významu pojmů včetně synonym a jejich původu (etymologie)
  • Proposed solution: to expand the speech bubble (Page preview) with the introduction of the Wikipedia article by a link to or even better a similar citation from the Wiktionary and possibly some other wiki projects
čeština: na odkazy rozšířit bublinu s citací úvodu hesla wikipedie o odkaz nebo ještě lépe obdobnou citaci z wikislovníku a možná i nějakých jiných projektů wiki

Discussion

  • What about something similar to the dictionary functionality in the Kindle e-reader? If a word is highlighted, a small window opens displaying its definition. You can find examples by searching "kindle dictionary" on Google images. It may be turned on or off as an option. --Ita140188 (talk) 01:15, 4 December 2020 (UTC)[reply]
  • Yes, it could work this way: highlighting by user some (one or more) word(s) should produce bubble or window with introduction from wiktionary and links to other dictionaries. (I don't know macOS and iOS and Kindle.) Tosek (talk) 23:52, 5 January 2021 (UTC)[reply]

Voting

Possibility to expand subsections, button to expand all/collapse all

  • Problem: Scrolling long articles is a bit difficult. Skipping chapters or subsection is a lot of down scrolling.
  • Who would benefit: anyone
  • Proposed solution: possibility to collapse not only first level section but any level and button to collapse all/Expand all
  • More comments: not sure if that's already being worked at, sorry!
  • Phabricator tickets:
  • Proposer: Gfombell (talk) 05:47, 17 November 2020 (UTC)[reply]

Discussion

Voting

Enable sticky table headers

  • Problem: In tables with many lines, the header scrolls out of the reader's view and is no further visible for him. That could cause confusion of column contents (for example for tables with numeric data).
  • Who would benefit: everyone reading articles with large tables
  • Proposed solution: implement the position:sticky attribute for table headers natively in MediaWiki through a class, e.g. mw-stickyhead.
  • More comments: This can be realized through templatestyles (example) but interferes the native wikitable styling which requires extra workarounds.
  • Phabricator tickets: phab:T42763
  • Proposer: hgzh 13:52, 18 November 2020 (UTC)[reply]

Discussion

Voting

Add Preference setting to offer Desktop view as default for mobile

  • Problem: switching to Desktop view on mobile every time is annoying; plus, the link is at the bottom.
  • Who would benefit: everyone who often, or always (my case) uses Desktop view on mobile
  • Proposed solution: 1st choice: a Preference setting allowing me to select my default view while on mobile. 2nd: just remember my last mobile view, and use that (cookie). Optimal: 3-way radio button: Default view on mobile: 🔘 mobile view ⭕ desktop view ⭕ same as previous view
  • More comments: Inspired by Stanislav's proposal above.
  • Phabricator tickets: phab:T173527
  • Proposer: Mathglot (talk) 02:56, 24 November 2020 (UTC)[reply]

Discussion

  • @Mathglot: After you click 'Desktop' in the mobile footer and go to the desktop view, you should be able to follow any links and it'll stay in the desktop view (even with 'open in new tab' etc.). Is that much working for you? Is it when you open a link from e.g. an email that you're having to manually switch views? i.e. when you've ended up at the en.m.wikipedia.org domain? —Sam Wilson 03:23, 1 December 2020 (UTC)[reply]
@Samwilson:, thank you for your questions. Yes, following links is not a problem. The problem can be either a Wikipedia link on a website (or email, or note on the phone, etc.) Sometimes, even when I'm already in desktop view, it flips back into mobile when other tabs are involved; I'll have to observe more carefully next time it happens to make sure I'm reporting it correctly, but I believe it's something like when I touch-hold to get a context menu (right-click equivalent) and then choose 'open in new tab' or similar. Let's call that "hearsay" for the time being, until I observe it and get a more accurate report. If you have specific use-cases or scenarios, definitely list them, and I will check them out and report back. Also, I switch between sister projects including foreign wikipedias, either via typed search such as fr:# if I just want to change languages, or an article, if I want to go somewhere specific, and I *think* it might be happening sometimes then, also, but I need to make sure. Mathglot (talk) 03:58, 1 December 2020 (UTC)[reply]
@Mathglot: hmm interesting, well if you do figure out specifics let us know. I've been experimenting and things like 'open in new tab' and even opening a blank new tab and typing in the URL work fine. Could be vagaries with different browsers and things though. —Sam Wilson 04:17, 1 December 2020 (UTC)[reply]

Voting

  • Problem: We've all been there. We look up a term in Wikipedia only to be enticed by another term and another term until we have spent three fascinating, caffeine-filled hours discovering things we knew, things we didn't know, and things we probably should have left alone. At this point, we may have forgotten why we even came to Wikipedia in the first place. Or perhaps we wanted to follow up on the seventh son of the third king from that weird country in a link an hour back.
  • Who would benefit: (A lot of) people that does that
  • Proposed solution: Wouldn't it be nice to be able to click a link at the top of the page which would expand a Link Tree showing how you got to where you were and the links past you may want to visit again?
  • More comments:
  • Phabricator tickets:
  • Proposer: Spiel 02:53, 17 November 2020 (UTC)[reply]

Discussion

Voting

Hiding References

  • Problem: The list of references can be very long, and distort the expectation of how much article is remaining. Yes, this is a first world problem, I know. But it is also trivially easy to fix ;)
  • Who would benefit: Anyone who treats the length of the scroll bar as a ballpark figure of how much there is (left) to read.
  • Proposed solution: A user setting "Collapse/Hide resources by default"
  • More comments: For PC/desktop users, the sources are mostly visible/to be consulted by hovering over the reference to them, so more often than not you do not need the list at the bottom anyhow.
  • Phabricator tickets:
  • Proposer: Irresistance (talk) 17:15, 17 November 2020 (UTC)[reply]

Discussion

  • I would oppose this. For instance, on Wikipedia I would like more readers to be seeing the references section as an integral part of the article, for further reading and research (rather than treating Wikipedia as an authoritative source). I think the scrollbar will never be more accurate than a ballpark guess (there could be long external links, navboxes, categories; the article could contain a long table containing names which you'll want to skip past etc.) — Bilorv (talk) 19:59, 17 November 2020 (UTC)[reply]
    • I see this proposal as a way of bridging mobile and desktop versions. Mobile already has collapsing sections, and this proposal is suggesting the same, but for desktop. JMVR1 (talk) 21:13, 17 November 2020 (UTC)[reply]
      • Mobile's collapsing sections relate to the fact that there is a smaller screen and more limited scrolling capabilities, so ease of navigating between different sections is more important. There are many ways in which I support bridging mobile and desktop versions, but not this one. — Bilorv (talk) 00:32, 18 November 2020 (UTC)[reply]
  • Web format is much richer than paper format, and unless you're interested in reference list itself, you should never need to open the reference section, and should never scroll down and back up to find that information. A click on an inline citation should open a pop-up window (baloon) with all the information you need. I'd support the proposal. And I am proposing in another category the pop-up references should be further developed. Ponor (talk) 04:54, 18 November 2020 (UTC)[reply]
    Pop-ups are disabled by default on many web browsers for security reasons, and certainly would be less convenient for me as a reader. — Bilorv (talk) 09:20, 21 November 2020 (UTC)[reply]
    These are not full windows, just a div element that shows up when citation number is hovered. They're already in place on en.wiki, even for anonymous users, they just don't work properly for all citation styles.
  • I'd actually a prefer a way to do this when in the wikitext editor - ref-heavy articles can be really hard to find the actual text because references take up so much space in that position. However, it seems fairly unneeded on an article-reading approach Nosebagbear (talk) 15:27, 18 November 2020 (UTC)[reply]
  • There are articles that limit the heights of the references section and one can limit the height of the section from the individual CSS settings.--Strainu (talk) 09:28, 19 November 2020 (UTC)[reply]
  • Counterproposal: Move the references list to a separately scrolling panel on the right. Similar to the format used by some academic journals (E.g. journals published by Annual Reviews and Biomed Central). This solves the above problem and actually emphasises WP's strong focus on sources. T.Shafee(Evo﹠Evo)talk 10:01, 20 November 2020 (UTC)[reply]
    Really like this, when responsive design/screen size permits. Otherwise I wonder which wikis would be in favor of hiding reference by default? If I recall correctly, at least one of the major language wikis does this, I'm but forgetting which. To the original proposal, I hesitate at the thought that we might reinforce for readers that it's okay to not read through to the reliable source. We need that kind of literacy now more than ever. czar 05:28, 23 November 2020 (UTC)[reply]
  • Being able to set the references as hidden by default does not mean they are not interesting, nor that the reader does not care about them; not all readers use Wikipedia as an academic research aid, and at any rate, you can always not hide them by default ;) This is not some slippery slope towards unsourced/made up content - rather, a simple matter of convenience. I agree references are an integral part of the article. - re counterproposal - that may also be useful in some cases, so instead of having the options "Show References" or "Hide References" you could add a third choice "Show references in sidebar" - the only thing I'd add is that hiding or showing by default is very simple to do and already an existing mechanism, whereas a scroll-along sidebar is not and is considerably more work due to the revival of the browser-wars :( — Irresistance (talk)
    not all readers use Wikipedia as an academic research aid - this isn't the only reason to check a reference. If you encounter content that is surprising or counter-intuitive, it is good practice to verify the content in the source given as it could be false. — Bilorv (talk) 09:20, 21 November 2020 (UTC)[reply]
    Exactly.. and it's as much education (information literacy) as it is to actually provide some sort of reliability trace for user generated content. There are way too many places that DONT quote and source the content they publish. —TheDJ (talk • contribs) 22:37, 25 November 2020 (UTC)[reply]
    I don't see how this feature conflicts with verifying sources. The sources section will just be collapsed until you click on a reference (as per my understanding). Martinkunev (talk) 14:26, 9 December 2020 (UTC)[reply]
  • If I want to print article for my children, make pdf or read about place I am currenty, I do not need references. And when I want to s find book about, I can enable them again. Collapsible reference section (before print) should be fine. JAn Dudík (talk) 11:50, 25 November 2020 (UTC)[reply]
    @JAn Dudík: I have a userscript on English Wikipedia which allows you to customize the printability of certain elements btw, including the presence of references. —TheDJ (talk • contribs) 22:37, 25 November 2020 (UTC)[reply]

Voting

Retrieved from "https://meta.wikimedia.org/w/index.php?title=Community_Wishlist_Survey_2021/Reading&oldid=20877430"