Hi
Just chiming into this discussion on *Graphs*. During the pandemic, I devoted much time on Wikidata building large datasets such as poverty incidence data and financial data. It is live now with at least being queried in 1700 Wikipedia articles multiplied by 8 languages and one chart contain 5-7 wikidata queries. With the graph not visible, it makes the chart useless in the Wikipedia article. I am mulling the idea to change it to a table of figures rather than a chart since the graph module downtime is taking too long already.
There are more datasets in the pipeline but I am holding it for now.
I am not sure if the Foundation lack budget for technical infrastructure research and development and that Wikimedia's technical features is at the level of the year 2012 or they lack manpower. I hope they invest donor's money on this first then when there is budget surplus it could go to conference & meetings travel and grants to 3rd party organizations.
Kind regards,
Butch Bustria
On Wed, Jan 31, 2024, 5:57 AM Ori Livneh ori.livneh@gmail.com wrote:
On Tue, Jan 30, 2024 at 2:52 PM Samuel Klein meta.sj@gmail.com wrote:
Galder: fair enough, let's keep this thread for interactive content. Brion's excellent suggestions deserve their own thread.
On Tue, Jan 30, 2024 at 1:14 PM James Heilman jmh649@gmail.com wrote:
With respect to OWID, one can see the interactive graphs working within a mediawiki environment here https://mdwiki.org/wiki/WikiProjectMed:OWID. Our hope for next steps to get around the current blockers is to show a static version of the graph from Commons with a play button overlay. When the play button is hit a consent pop up similar to what you see for maps on Wikivoyage https://en.wikivoyage.org/wiki/Cranbrook when you request a layer such as "relief maps". This will then bring in the corresponding interactive content hosted from the wmcloud https://owidm.wmcloud.org/grapher/share-of-population-with-schizophrenia. While this be acceptable to the powers that be? I am not sure.
Yea, this is fantastic. Thank you for the demonstration. We should creatively upgrade our approaches to privacy and security to make it possible to do this. This is a purely technical challenge, not a social adoption or licensing one, for overcoming self-imposed obstacles of our ecosystem.
I appreciate Galder focusing the attention back on non-video content.
If we're collecting exemplars, I'd like to add Bartosz Ciechanowski's superlative articles https://ciechanow.ski/archives/, like the ones on bicycles https://ciechanow.ski/bicycle/ and sound https://ciechanow.ski/sound/. His articles are the best examples I know of interactive content that complements long-form text content.
Beside the complementary relationship with long-form text, there is another aspect to this type of content that makes it a great fit for Wikipedia. Interactive visualizations are usually built by combining vector graphics (graphics based on geometric shapes that are defined mathematically, rather than bitmaps) and code. Both of these are at bottom textual media and thus very amenable to collaborative, iterative improvement via wikis.
Proposals to enable support for this sort of content (for example, via interactive SVGs https://phabricator.wikimedia.org/T138665) have languished for years. I think it is worth asking why, and to approach the question with intellectual curiosity rather than frustration. My intuition is that the core reason is that the security dimension of this work is non-intuitive and poorly understood.
My hunch is that if you asked a bunch of random people about what sort of engineering work might be needed to support more interactive content on Wikipedia, the answers you will get will be disproportionately focused on missing user-facing interfaces and functionality for editing and displaying such content. And if that's your view, it is very natural for various assumptions to follow about what sort of expertise is required. But it's the wrong view and the wrong assumptions.
The critical issue is *security*. Security is the reason the graph extension is not enabled. Security is the reason why interactive SVGs are not enabled. Interactive visualizations have a programmatic element that consists of code that executes in the user's browser. Such code needs to be carefully sandboxed to ensure it cannot be used to exfiltrate user data or surreptitiously perform actions on wiki.
The bar for shipping security-critical features is high. You can ship code with crummy UX and iterate on it. But something that touches security requires a higher amount of up-front technical design work and close scrutiny in the form of peer review. And this means that it cannot progress spontaneously, through sporadic bursts of effort here and there (which is how a lot of engineering work happens) but requires a solid commitment of focused attention from multiple people with relevant expertise.
There are engineers at the Wikimedia Foundation and in the technical contributor community with the relevant expertise but as a rule they are extremely oversubscribed. My recommendation would be to engage them in crafting a job description for this role and in reviewing candidates. _______________________________________________ Wikimedia-l mailing list -- wikimedia-l@lists.wikimedia.org, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l Public archives at https://lists.wikimedia.org/hyperkitty/list/wikimedia-l@lists.wikimedia.org/... To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org