Extension:Graph/Plans/Research

What follows are the questions, and corresponding responses, needed to converge on a plan for safely and securely restoring access to the information and capabilities disabling the Graph Extension has left people without.

Who depend on the Graph Extension? In what way(s) had people been using the Graph Extension?

1. An (old, but I doubt much has changed) analysis of this is at User:Bawolff/Reflections on graphs
2. Volunteers
   1. Generate infographics to present data to readers in a variety of forms. E.g. bar charts, stacked graphs, pie charts, scatter plots, timelines, histograms, geographic maps.
      1. See Category:Pages with disabled graphs for the range of pages/contexts where the Graph Extension was used
   2. Generate graphs on talk pages to show article and user page views over time.
   3. Use the Graph extension to generate maps with more features than the Kartographer extension provides.
   4. Generate page view graphs on ?action=info as part of Extension:PageViewInfo
   5. Generate Interactive COVID-19 maps
   6. Pamputt: Generate up-to-date graph from Wikidata data. The only workaround is to create by hand an image, to upload it on Commons and to redo it each time the values are updated.
3. WMF Staff
   1. PPelberg (WMF): While WMF Teams do not yet seem to be depending on the Graph Extension, teams' longer-term plans/strategies do depend on a future wherein functionality exists on-wiki to: 1) ingest data stored off-wiki and 2) "transform" it into infographics/visualizations that people can explore/interact with on-wiki.
      1. "1)" and "2)" named above are strategically important to the Movement being able to evaluate the impact of the work it's doing and monitor its health. At present, storing data and generating "artifacts" that enable people to interact and explore this data happens off-wiki and takes a great deal of time and technical expertise.

What is no longer possible as a result of the Graph Extension being disabled?

Asked another way: what capabilities did the Graph Extension provide for which you have not yet found a viable workaround?

1. Nux: Generating page views charts for popular pages. E.g. page views template on pl.wiki
2. Nux: Generating charts based on Wikidata. E.g. en:Template:Airport-Statistics (used by multiple other languages).
3. TheDJ: Generate page view graphs on ?action=info.
4. Pamputt: Generate up-to-date graph from Wikidata data.
5. Sj: Viewing graphs already generated by this extension, illustrating tens of thousands of pages and articles E.g. mass migration needed
6. colt_browning: Generating population history graphs using ru:Template:Население from sophisticated in-wiki census data tables.

What did you notice yourself (and other people) using the Graph Extension to do that you hadn't been doing before?

1. Ahecht: Treating charts as collaborative content equivalent to the rest of a Wikipedia article. Editors are reluctant to tweak a chart when it requires downloading the source data, recreating a similar chart from scratch in external software, converting it to an image, and uploading it over another editor's image, and therefore each chart would only be edited by it's initial creator. +1
2. Sj: Being able to inspect individual data points in a graph (rather than guessing by zooming in), and to get readable diffs of updates

What – if anything – did the Graph Extension make it easier/more convenient to do?

If you can, please describe what each "task" you used the Graph Extension for looked like before and after it existed.

1. RobinLeicester: As with the charts, improving/adding to an annotated map, either your own or someone elses, became much more like proper wikipedia editing, compared to uploading a 'finished' item to commons. With such limited options within maplink, external graphics programs would have to be used and the result is then fossilised on the page, or never attempted in the first place. Also, placing annotations using 'coords', on a reliable base map, makes them more verifiable and correctable.

What workarounds have you developed and/or seen other volunteers develop in the time between now and when the Graph Extension was disabled?

1. 86.122.161.172: Nothing, there are just too many pages and there was too much effort involved in developing the existing graphs to replicate at once on smaller wikis. I really hope that if another solution is provided, an automatic converter will also exist.
   1. +1, a lot of pages just look broken now.
2. Nux: Moved a bar chart from graph to timeline [1]. This kind of works, but timeline is rather static (not tooltips on hover) and fonts are less readable.

   TheDJ: EasyTimeline itself is also no longer receiving updates and depends on perl. I think we should consider that this too will require replacement at some point !!

3. Nux: Added generic pie chart with 2 values pl:Szablon:Wykres Smooth Pie 2. This is a fully functional replacement for pl:Szablon:Demografia powiatu#Przykład. Though this doesn't look the same (especially the labels of charts could be better). And also it's not easy to add more then 2 values on this pie chart.
4. Edu!: At Portuguese Wikinews, the Graph 2 module was developed, which uses CSS to generate line, area and column graphs in the Gráfico template. The module does not have limitations that exist in alternative templates used in some Wikipedia languages. The community is working on improvements.
   1. TheDJ: The limitation of CSS based graphs is that they generally are not that accessible. There are problems with color inversion, screenreaders etc. This particular example is even worse, as it uses HTML tables to do layout (there is no reason to use tables).
5. TheDJ: en:Template:OSM Location map was switched from the Graph mode to pure Kartographer. This made it loose some features (custom pogs, minimap, custom labels etc). See also comments by RobinLeicester
6. User:Snævar: Created is:Module:Flugvallar tölfræði to replace Template:Airport-statistics using Wikibase Lua access and Easytimeline.

   Great but excuse me, isn't there a pb on the years at, for instance, is:Reykjavíkurflugvöllur given the max year was 2007 with 471372 pax ?Bouzinac (talk) 12:38, 10 August 2023 (UTC)

   Use whole words instead of pb and pax, you are not making yourself clear.--Snævar (talk) 23:45, 8 September 2023 (UTC)

7. colt_browning: Using bar chart instead of a line graph. Unfortunately, the former is significantly inferior for visualizing the dynamics with unevenly distributed data points.
8. JoeNMLC: added two simple bar graphs at en. Category:Orphaned_articles#Progress en.JoeNMLC (talk) 19:56, 18 September 2023 (UTC)

What tools (on- and off-wiki) are you currently using to create data visualizations for Wikipedia?

1. Nux: I know en.wiki is linking to Wikidata for some stats... But that UX of having to see huge SPARQL on WikidataQueryService is terrible (see the Airport-Statistics template)...

   Lighlty fixed with +"embed.html" on the link, but I agree, the direct graph is far more desirable. Bouzinac (talk) 12:52, 10 August 2023 (UTC)

2. There's always the unmaintained Extension:pChart4mw

Why do you think it is or is not strategically important for the Wikimedia Movement to offer on-wiki tools for storing, editing, and visualizing data?

1. Nux: A picture is worth a thousand words. And a dynamic chart with context is even more precious...

What requests (e.g. wishes) have volunteers made over time to improve support for storing and representing/visualizing data on-wiki?

1. T195627: Support Vega 3.0 in Graphoid
2. T195628: Support Vega Lite 2.0 in Graphoid
3. T100444: Graph localization support
4. T165118: Support Vega 5.0+
5. m:Improve graphs and interactive content
6. Many were translated into Graph feature requests + tasks. (Generate graph from wikitable;
7. T236892#6135375: Don’t break the Compatibility#Basic (Grade C) promise by not showing anything to non-JS users

What – if anything – could be done to safely reenable the Graph Extension?

1. Some proposals have included (These may or may not be sufficient and different people have different opinions)
   1. phab:T222807 - Use browser based iframe sandboxing
      1. PPelberg (WMF): per what Tgr shared in T222807#8858868, and what SBassett (WMF), Tgr, and I met to talk about offline on 20 July 2023, the prospect of iframe sandboxed enhanced with a Content Security Policy seems potentially viable.
   2. Render server side (or render client side with some sanitization layer) to allow static but not interactive graphs
   3. phab:T336595 - Make editing graphs be restricted similar to MediaWiki:Common.js
2. Bawolff: The elephant in the room is that graph is a high maintenance extension, even before this, that on the whole is not that widely used and where it is used, it is used mostly in a fairly simple fashion. Given its usage numbers and how it is used, it is unclear that further investment is worth it.
3. Bawolff: It was pointed out on phab that vega has not fixed the underlying security issue despite presumably having been aware of it for a while now. In order to be deployed again we would want both the known security issue fixed and some assurance there won't be more or have some sandboxing to lower the impact of any currently unknown issues. If Vega is not fixing it in a timely fashion, WMF could perhaps contribute fixes themselves, but being required to take that on is a very large red flag for the overall security of the library.
4. T336544: Codex, Graph, and Wikistats date

Of the pages that display graphs/infographics, what proportion of them depended on the Graph Extension?

Project	Pages using Graph Extension	Pages using alternative means to display data
⧼project-localized-name-mediawikiwiki⧽	243
⧼project-localized-name-commonswiki⧽	53
⧼Wikibase-otherprojects-wikipedia⧽	1,321,167 (as of 7 Sep 2023)
⧼project-localized-name-metawiki⧽	636
⧼project-localized-name-wikidatawiki⧽	739
⧼Wikibase-otherprojects-wikinews⧽	1
⧼Wikibase-otherprojects-wikiquote⧽	0
⧼Wikibase-otherprojects-wikisource⧽	24
⧼Wikibase-otherprojects-wikiversity⧽	25
⧼Wikibase-otherprojects-wikivoyage⧽	5
⧼Wikibase-otherprojects-wiktionary⧽	4

TheDJ: any sort of listing will be hard to trust, as people have already started to migrate away in various ways. It would be good if we can see if we have some numbers from before somewhere. When it was initially disabled, I mentioned that en.wp had: en.wp used "about 60 000 [pages] for en.wp, or just 16k articles". I'm however not sure where i pulled those numbers from.

PPelberg: also see User:Bawolff/Reflections on graphs#How is the Graphs extension used currently via SBassett (WMF).

d:Q117788173, which used to be linked here, has a listing of every category on every language of every site.