On Tue, Jan 30, 2024 at 2:52 PM Samuel Klein <meta.sj(a)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(a)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.