Community Wishlist Survey 2019/Reading

Add links
From Meta, a Wikimedia project coordination wiki
Community Wishlist Survey 2019
Reading
8 proposals, 278 contributors, 406 support votes
The survey has closed. Thanks for your participation :)



View list of articles in subcategories all on one page

  • Problem: Many projects use categories in a sense where subcategories mean subsets of categories (in a mathematical way). Hence, articles in subcategories are actually content of the supercategory as well, but not sorted this way to gain better overview.
  • Who would benefit: Editors and readers trying to get an overview over the articles about a given topic.
  • Proposed solution: Add an option to show all pages and files in subcategories as well. There could maybe be a cache of this information, that is updated regularly or on categorization, to make this work reasonably well. Maybe this cache wouldn't have to contain all pages contained in a category or its subsets, but only subcategories. A limit of a few 10 000 pages could make sure that the amount of pages is manageable for the software with reasonable effort.
  • More comments:
  • Phabricator tickets: T4725

Discussion

Note that you can approximate this with deepcat searching: search query example. —TheDJ (talk • contribs) 10:45, 31 October 2018 (UTC)[reply]
While this is a workaroung, it doesn't provide the same user experience as category pages. It's a bit like suggesting to drop category pages entirely, as you can use incategory seacrhing instead. --MGChecker (talk) 21:56, 31 October 2018 (UTC)[reply]
I would ask the reverse proposal: change the search page to allow users to select views: default, compact (as per this proposal) and image (as per this proposal). --NaBUru38 (talk) 19:10, 7 November 2018 (UTC)[reply]
  • Could you share some examples of categories with subcategories used in the way you describe? It might help others, including me, better understand this proposal's goals. AEzell (WMF) (talk) 19:33, 31 October 2018 (UTC)[reply]
    • While enwiki doesn't use categories this way, dewikis whole category system is organized this way. It might be more useful to provide an example for what would be never done there: en:Köln-Düsseldorfer is indirectly part of en:Category:Rivers of Switzerland, even though it is neither a river nor in Switzerland. This leads to two concepts roughly translatable as "Topic category" and "Object category", where the latter is only allowed to contain articles that satisfy d:Property:P31: „Article is a Category“. en:Category:Rivers of Switzerland wouldn't be allowed to contain articles that aren't rivers of Switzerland, not even in subcategories. Using a system like this for categories renders viewing lists of articles in subcategories all on one page much more useful than it would be in enwiki. --MGChecker (talk) 21:56, 31 October 2018 (UTC)[reply]
  • I would like to make sure I understand this proposal MGChecker. On en.wiki, as I'm sure you know, subcategories do not inherit from supercategories. So, paradoxically, the broader the category one searches by, the fewer results one gets. E.g., a search by Category:Rivers of the United States would find almost no actual river articles—and any it did find would turn up only because they were mis-categorized (because they should have been filed in various sub-categories). So are you saying 1) that you want to change the category system so that articles in subcategories do inherit from parent categories? Or are you saying 2) that you want a special page that shows you a hierarchically organized view of categories and subcategories, where each is subcategory openable so that you can see the actual articles in the subcategory, instead of simply seeing a count of them, as now? —JMatazzoni (WMF) (talk) 00:56, 2 November 2018 (UTC)[reply]
    • With this proposal I want 1, but you would be free to chose: There should be a button to chose between these two modes so everyone who is happy with the current system won't complain. --MGChecker (talk) 23:05, 13 November 2018 (UTC)[reply]
  • I also am not sure of what you are proposing. Would a category tree map, draggable and with local zoom possiblity, be a solution? Jürgen Eissink (talk) 01:01, 4 November 2018 (UTC).[reply]
    • This would not really be a solution, as this isn't about the subcat structure itself, but about the articles in there. You would gain the possibility to view the articles/files in a category and its subcategories at the same time without the need to use Cirrus. --MGChecker (talk) 23:05, 13 November 2018 (UTC)[reply]
  • See also Community Wishlist Survey 2019/Miscellaneous/Button to show subcategories. Certes (talk) 00:03, 7 November 2018 (UTC)[reply]

Voting

Night mode

Projects, results

Dark mode user script by WMF

Section added for those interested in the developments after the survey concluded.

Experimental Dark theme on Timeless skin, English Wikipedia main page
  • Skin themes – dark and gray themes for Timeless and Vector skins. Custom color palette, similar to discord's colors. Experimental volunteer project: there is some content that's hard to read with it.

Discussion

Voting

Functional and beautiful math for everyone

  • Problem:The math extension has a lot of bugs, missing features and deficiencies due to the output being images rather than text-like. Most math related websites like math.stackexchange.com use "MathJax out of the box" and do not have these problems. Re-submission of Community Wishlist Survey 2017/Reading/Functional and beautiful math for everyone
  • Who would benefit: Readers and editors of mathematical articles, books etc.
  • Proposed solution: In a commission of interested volunteers we came up with a road-map to remove the problematic conversion of "texvc" to standard LaTeX syntax. For a state-of-the-art rendering system we also need to improve the output format. Making it more like "MathJax out of the box" might need additional infrastructure (e.g. to supply web-fonts), needs a long-term maintenance concept and has to work together with almost all software components, so we would like WMF staff to help us.
  • More comments:
  • Phabricator tickets: phab:T195861
  • Proposer: Debenben (talk) 19:29, 4 November 2018 (UTC)[reply]

Discussion

Voting

@Bestoernesto: Why oppose? Do you have concerns regarding the roadmap or because you think the other wishes here are more important than providing a math extension that works properly?--Debenben (talk) 19:03, 28 November 2018 (UTC)[reply]

Improve graphs and interactive content

Examples of Vega and Vega-Lite graphs we can build

  • Problem: Wikipedia would benefit from more animations, interactive content, and self-updating infographics
When we discuss historical changes, we should be able to view those changes interactively, e.g. side by side. Statistical data should be represented as easy to understand charts, and when the new data becomes available, those charts should update. We already have some of the tools for this (the <graph> tag, the shared data on commons, maps), but the current tools are hard to use, not maintained, and need improvements. The comprehensive vision was presented several years ago in a short I Dream of Content paper.
The Graph extension has many advantages for Wikimedia projects. In brief, it allows data to by displayed by generating graphs on-the-fly (we do not need a picture file anymore, and so we do not need to create a new picture each time the data are updated). However, the Graph extension is currently not widely used, probably partly because the code is not really user-friendly.
  • Who would benefit: Readers and content creators
  • Proposed solution: Upgrade the Vega library, add Vega-Lite support, and add multilingual support to Graphs.
Develop a GUI Visual-Editor-like tool to help contributors to create nice graphs. This tool could look a bit like those in spreadsheet software (the user selects the data to plot and the type of graph, then fine-tunes it). This tool could be integrated with the Data namespace on Wikimedia Commons (example) and with the Wikidata Query Service. The latter already offers different visualisation methods, with the ability to export results to several formats (html, json, svg). See this example. Adding customizable Vega code as an output would be nice.
Community Wishlist Survey 2016/Categories/Multimedia#Support SVG interactivity and animation in Media Viewer discussed making animation and interactivity easier for SVGs.
  • More comments:

Discussion

Yes, I wish there was improved documentation for mw:Extension:Graph. Gryllida 23:00, 30 October 2018 (UTC)[reply]

Hmmm, actually I wrote a similar proposition here (I did not see this one before). Should we merge both proposals? Pamputt (talk)
Pamputt, yep, makes sense. Want to port your info to here, and just leave a redirect? Feel free to change the proposal. --Yurik (talk) 15:56, 1 November 2018 (UTC)[reply]
I modified the text above. Feel free to edit it. I also copied the discussion from the other proposal below in order to keep a record. Finally, I redirected the other proposal to this one. Pamputt (talk) 18:18, 2 November 2018 (UTC)[reply]
@Gryllida: the Vega official documentation page has tons of great documentation, but unfortunately it is for Vega 3,4+. MW is still on Vega 2, two major versions behind. If we upgrade and add Vega-Lite, it will be far easier to use (Vega-Lite has much simpler syntax), and we will be able to use the proper documentation site. --Yurik (talk) 22:54, 2 November 2018 (UTC)[reply]

One of the Vega-Lite authors and Vega contributors here. I'd like to express my full support for this effort and offer my help with any issues that come up. Dominik Moritz (talk) 18:25, 24 November 2018 (UTC)[reply]

Discussion from the other proposal

From Community Wishlist Survey 2019/Miscellaneous/Graph extension before merging

So I think one of the problems here is that Graph simply allows you to do too much... People want full flexibility but full flexibility turns out to be really hard to use if you are not an expert (nor interested in becoming one). I think many people are looking for simple graphs. I was thinking if it was perhaps an idea to add simple "graph" buttons to the Data namespace on Wikimedia Commons for instance. Like with spreadsheet software, select your data, choose a graph type, generate graph (Vega spec) and done... That would make creating simple graphs much easier, helping 80% of the people. And then when people want to get really down and dirty, they can modify those results etc. If you have similar ideas or thoughts on how to do this for data sources other than the tabular data, I would welcome them. I think that having a better insight into what would work is important to convince the foundation to work on issues like this. —TheDJ (talk • contribs) 16:08, 1 November 2018 (UTC)[reply]

Also, this is another "Fix all da things" wishlist item. I advise rewording it to be more specific and limiting the scope to the most useful tickets, in order to increase the changes of the item being successful and not to be excluded from voting by the team due to scope issues, please read Community_Wishlist_Survey_2019#proposalsphase. —TheDJ (talk • contribs) 16:10, 1 November 2018 (UTC)[reply]
Actually there are two points. First, the graph extension has been developed and now it has no support anymore. This is a global issue of Mediawiki. Some nice tools are developed at some time and finally they are not maintained on a long term and so they are not used because bugs that are reported are not fixed and contributors understand that no one is in charge of these tools. This was the basic idea of this proposal, just assign a developer to this tool to improve and fix it. Actually there was already a proposal about this and I think it is better written.
The second point is what you wrote above. The graph extension is rather difficult to use and a user friendly tool would help to use this nice extension. What you propose, a tool allowing to generate graph in a spreadsheet-like way, would be really nice.
So it looks like this is two proposals (one for upgrading Vega version and implementing lolisation) and the other one to provide user-friendly tools to generate graphs. Pamputt (talk) 09:18, 2 November 2018 (UTC)[reply]

There is a "Vega-Lite" version of Vega - it is by far easier than the full Vega, and can work together with the full Vega. Please update graphs/interactive content proposal with your thoughts. Ideally, I would even consolidate these two, as it seems a single proposal gets more votes, and attracts more attention than multiple ones. Thx! --Yurik (talk) 16:43, 2 November 2018 (UTC)[reply]

A gif player that can allow pausing dynamic .gif map would be a nice feature. C933103 (talk) 06:45, 4 November 2018 (UTC)[reply]
@C933103: sure - essentially GIF and Video player should be one and the same, and it could be a good addition. Unfortunately that wouldn't solve the fundamental problem - ability to easily generate data-driven content/visualizations. One would have to be a video editor to create either one. The <graph> driven vis is different because it relies on data sources, thus when data changes, the visualization is updated. Plus it also means that the visualization can be translated without recreating the whole thing (unlike a gif/video). But I do like your idea for the simple GIFs! --Yurik (talk) 22:19, 7 November 2018 (UTC)[reply]

Wikidata

How do Vega graphs fit in with interactive-graph Wikidata queries like Number of museums per country? HLHJ (talk) 08:31, 14 November 2018 (UTC)[reply]

I do not know for such complex case but in principle it works. You can see this graph that uses data from Wikidata. Pamputt (talk) 09:05, 14 November 2018 (UTC)[reply]
@HLHJ: Vega graphs can already get the data from Wikidata directly. The process right now is not very user friendly (you have to URL-encode the query), but it can be made far easier, e.g. "url": { "sparql": "SELECT ..." }. Thanks Pamputt for the link! --Yurik (talk) 17:46, 14 November 2018 (UTC)[reply]

Voting

Accessibility settings for everyone

  • Problem: We should offer a satisfying user-interface experience to as many people as possible. Anything accessibility & usability, that is purely reading-related could be moved to a simple site-style menu, and thereby become available to logged-out users, too.
    We have been striving for a one-size-fits-all interface. In contrast this solution offers users with very common disabilities and impairments, which we know the current interface doesn't offer best experience, an easy way to adapt the interface to their needs and to serve them the best we could. We’re talking about flexibility in changing basic settings like (any of):
    • font size & styling,
    • day/night modes,
    • photophobia,
    • grayscale,
    • fixed/full width layouts for widescreen options,
    • …
  • Who would benefit: For all readers including not-logged-in ones. (Note: Technical limitation to support it for every user is, that it has to be implemented client-side in JavaScript to avoid cache fragmentation.)
Napkin sketch concept - more details at phab:M17.

Discussion

Voting

Create URL Shortener extension for Wikimedia wikis

  • Problem: I think it would be great if we had URL shortener for Wikimedia websites 3rd party services aren't a great idea due to privacy concerns and for example in WDQS is used tinyurl.com and that website have a limit so many queries can't be shortened.
  • Who would benefit: Anyone who is using Wikimedia websites.
  • Proposed solution: Currently, there is Extension:ShortUrl, but the URLs generated by this aren't much shorter than the existing URLs, so probably the best way would be to create a new short domain for this.
  • Related Phabricator tickets: T112715

Discussion

I agree. Good and usefull thing. Acamicamacaraca (talk) 11:47, 4 November 2018 (UTC)[reply]

Acamicamacaraca, Sabas88 Thanks, if you liked it you can now support it. --Walter Klosse (talk) 09:41, 17 November 2018 (UTC)[reply]

I agree, I commented the related ticket some months ago and did a bit of research but never found a nice solution. --Sabas88 (talk) 14:52, 9 November 2018 (UTC)[reply]

Walter Klosse The link you put under More comments does not work. Did you mean to put in this link instead? -- NKohli (WMF) (talk) 20:05, 16 November 2018 (UTC)[reply]

Yes, thanks! --Walter Klosse (talk) 09:21, 17 November 2018 (UTC)[reply]

The following would be particularly important to me: In the lower section of every Wikipedia article, every Wikimedia Commons image and so on, the corresponding (as permanent as possible) short link is shown (see also) --Molgreen 05:17, 17 November 2018 (UTC)

The domain w.wiki has been acquired for this a couple years ago. It already exists in DNS and our cluster Apache config.

  1. w.wiki - upcoming URL shortener

funnel *w.wiki //meta.wikimedia.org/wiki/Special:UrlShortener

I wanted to point this out because i see a reference to "a new domain" above and it can already be more specific and should save us time bikeshedding over the domain. That has already happened in the past. Mutante (talk) 14:06, 17 November 2018 (UTC)[reply]

Doesn't this already exist at Special:UrlShortener and just needs to be enabled? --Terra ❤ (talk) 03:11, 21 November 2018 (UTC)[reply]

Voting

Wikipedia-Translator for articles word by word based on Wiktionary

  • Problem: Read Wikipedia articles in other languages and understand some of the words or phrases. There is not a link to a Wiktionary page or a visible translation if we mark a word or a phrase.
  • Who would benefit: All readers, who visit Wikipedia or Commons pages written in unknown languages. Our Wiktionary, if users add a new translation there, when they see that it is missing. Learners. Worldwide communication.
  • Proposed solution: I have written some words at my Commons page. Or a "Translation" button additional to "Read" "Edit" on top of articles, where you can choose a language and change in a "Translation modus", where every word shows a tooltip with translation (like a link), if you touch that word, and a link to wiktionary if you doubbleclick the mouseover tooltip then. "??? Add a translation!" tooltip if there is no entry in Wiktionary. Or show a translation for the whole text, if you mark the text with fingers or a computer mouse.
  • More comments: One step, handmade links to wiktionary in a text (example in discussion)
  • Phabricator tickets:
  • Proposer: LudwigSebastianMicheler (talk) 20:08, 6 November 2018 (UTC)[reply]

Discussion

@LudwigSebastianMicheler: In the long run, I wonder if this first needs d:Wikidata:Lexicographical_data to provide support for d:Wikidata:Wiktionary. In the short run, does w:en:MediaWiki:Gadget-GoogleTrans.js/w:en:User:Endo999/GoogleTrans.js fulfill your needs? --AKlapper (WMF) (talk) 07:23, 7 November 2018 (UTC)[reply]

My knowledge and my English is not good enough to understand all, but Google-translate is Google and the Gadget is not for all readers of Wikipedia articles. Maybe it will help developers to use Wiktionary for the translation. --LudwigSebastianMicheler (talk) 00:12, 9 November 2018 (UTC)[reply]
Word-by-word translation is often worse than reading in original. But some kint of tool: I click on the word and popup with wiktionary entry appears could be fine. But there are many blockers (first phab:T67117, then unusability ov hovercards on wiktionary...), not only technical, but also data - lack of entries on wiktionary. 07:28, 9 November 2018 (UTC)

If I look up the words in the short, simple sentence "Han springer till henne" ("He runs to her") on English Wiktionary (German Wiktionary didn't know any meaning of the word "springer" or "springa" in any of the languages it exists in), we run into a problem already on the second word: "springer" isn't translated, but explained as "present tense of springa". This is going to be true for a lot of words one encounters, unless the text is in e.g. Chinese. /Johan (WMF) (talk) 10:53, 9 November 2018 (UTC)[reply]

So in that case we need to concatenate entries? This would be useful for learning languages, just to check the odd word you don't know without breaking the flow of reading too much. HLHJ (talk) 08:20, 14 November 2018 (UTC)[reply]
I really fail to see how this would improve the Wikipedia reader experience. Word to word translations are often a complete disaster, even from one European language to the next. Needless to say the result is likely to be worse for non European languages with sometimes very different grammatical structures. --Braveheidi (talk) 02:06, 17 November 2018 (UTC)[reply]

Voting

Add buttons and keyboard shortcuts to move through category pages quickly

  • Problem: English: It would be great if you could click on the forward or back arrow in the preview of the Wikimedia Commons file, causing the next or next file in the category to be loaded, respectively. I know that there is a 'Slideshow', but its launch closes the preview and access to categories, closes the panel on the left with tools and links for editors.
Original: Byłoby wspaniale, gdyby w podglądzie pliku na Wikimedia Commons można było kliknąć na strzałkę do przodu lub do tyłu powodując załadowanie odpowiednio pliku poprzedzającego lub następnego z kategorii. Wiem, że istnieje 'Slideshow', ale jego uruchomienie zamyka podgląd i dostęp do kategorii, zamyka panel z lewej strony z narzędziami i linkami dla edytorów.
  • Who would benefit: English: Commons users looking for files in the category structure.
Original: Użytkownicy Commons, poszukujący plików w strukturze kategorii.
  • Proposed solution: English: Add to the toolbar the left and right arrows displayed above the file, allowing you to load the previous and next file from the given category. The same effect should be given by pressing the "right / left" arrows on the keyboard.
Original: Dodanie do paska narzędzi wyświetlanego nad plikiem strzałek w lewo i prawo pozwalających na załadowanie pliku poprzedzającego i następnego z danej kategorii. Taki sam efekt powinno dawać naciśnięcie strzałek "prawo/lewo" na klawiaturze.
  • More comments:
  • Pharbricator tickets:

English

Arrows to navigate to next or previous file in category, visible on file description page but without opening slideshow function.

Dyskusja

Zapewne jakiś prosty gadżet mógłby to rozwiązać, ale kwestia jest taka, że musiałby wiedzieć z której kategorii wszedłeś w plik. --Wargo (talk) 23:36, 29 October 2018 (UTC)[reply]
Och, faktycznie. Zważywszy, że na stronę pliku można wejść z różnych miejsc, przeglądanie kolejnych plików wymagałoby raczej zawsze (przy uruchamianiu funkcji) wskazania kategorii, której zawartość chce się przeglądać... Kenraiz (talk) 12:40, 30 October 2018 (UTC)[reply]

I added Google translations for the proposal. I will rename the proposal as well. Thanks for submitting the proposal. -- NKohli (WMF) (talk) 21:38, 14 November 2018 (UTC)[reply]

Voting

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