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(a)gmail.com> wrote:
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.
_______________________________________________
Wikimedia-l mailing list -- wikimedia-l(a)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(a)lists.wikimedia.org