Galder: fair enough, let's keep this thread for interactive content. Brion's excellent suggestions deserve their own thread.
With respect to OWID, one can see the interactive graphs working within a mediawiki environment
here. 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 when you request a layer such as "relief maps". This will then bring in the corresponding
interactive content hosted from the wmcloud. 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, like the ones on
bicycles and
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) 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.