[Wikimedia-l] Re: We need more interactive content: we are doing it wrong

[rupert THURNER]

On Wed, Jan 31, 2024 at 1:27 AM Gergő Tisza  wrote:

> On Tue, Jan 30, 2024 at 1:57 PM Ori Livneh  wrote:
>
>> 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.
>>
>
> This concept was popularized by Bret Victor under the name "explorable
> explanations ". There is a
> whole Wikipedia article
>  on it. There are
> some great examples on his website, and there are some websites for
> collecting similar content, such as explorabl.es and an awesome list
> . I agree they are really
> cool but...
>
>
>> 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.
>>
>
> I think it's fundamentally a human scaling problem. Being able to create
> good interactive content is just a much more niche skill than being able to
> create good text content. Interactive animations were very much part of
> Yuri's vision
>  for the
> Graph extension, but during the decade Graph was deployed in production the
> number of such animations made was approximately zero. Granted Vega is
> probably not the easiest framework for creating animations, but I don't
> think there are other tools which would make it much easier. You could just
> write arbitrary Javascript and package it as a gadget; but no one did that
> either. Instead, both gadgets and Graph usage are mostly focused on very
> basic things like showing a chess board or showing bar charts, because
> those are the things that can be reused across a large number of articles
> without manually tailoring the code to each, so the economics of creating
> them work out.
>

> Security is a challenge but could be worked around via iframes. But it's
> hard to justify the effort required for doing that when there is no
> community of animation makers interested in it - there are plenty of
> volunteers who want to *have* animations, but it's not very clear that
> there are any who want to *make* animations. This is the same problem
> geni mentioned for videos - a lot of people say "we should have more
> videos", but it's not very clear who would make them. If platform support
> were the bottleneck here, I think the platform support would happen. But as
> things look now, it would just be a poor investment of resources IMO
> (compared to e.g. the Gadgets extension or Toolforge or Scribunto which do
> sustain vibrant volunteer ecosystems which are significantly held back by
> the limitations of these platforms).
>

thank you for sharing ori and gergo. coming from i opened the page "how to
tune a guitar": https://mathisonian.github.io/idyll/how-to-tune-a-guitar/,
and the readings about "reinventing human explanations" and so on:
https://explorabl.es/reading/. the sheer number of examples is saw out of
these links does not sound like there is a lack of persons who love to do
that.

rupert
___
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/message/7A6223FVC4SRJQSPZQLO5EILX7N7HZEG/
To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org

[Wikimedia-l] Re: We need more interactive content: we are doing it wrong

[Butch Bustria]

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  wrote:

> On Tue, Jan 30, 2024 at 2:52 PM Samuel Klein  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  wrote:
>>
>>> 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 

[Wikimedia-l] Re: We need more video: doing it right

[Erik Moeller]

Thanks Brion for the detailed breakdown re: video issues. Replying
under the changed subject line :)

Re: transcoding video, Brion wrote:

> Allowing *ingestion* of MP4 h.264/AAC would allow uploading camera
> originals from most consumer gear -- a major democratizing feature.
> Ingestion of MP4 HEVC/AAC would give more compatibility.
>
> In both cases we have all the software we need, we already use the
> Debian ffmpeg package which includes code supporting both formats;
> we just don't allow uploading the files, reading them to convert for playback,
> or downloading the originals from our web site.
>
> Do we need a MPEG-LA patent license for that? Nobody seemed to think so
> in 2014 but nobody could tell me for sure either, then or now.

IMO it would be useful to commission a renewed legal/policy assessment
of those questions. Similarly, it would be good to know if any
expiring patents might soon expand the range of options Wikimedia
projects could enable without a patent policy change. At least for
H.264 it seems like a pile of patents are coming up for expiry in 2024
and 2025, but I don't know if they alone help us much. [1]

Regardless of any changes to Wikimedia's hard line policy stance on
patent-encumbered codecs, the industry trend towards more open formats
does make me optimistic about video in the long run.

Warmly,
Erik

[1] Per this community-maintained page:
https://meta.wikimedia.org/wiki/Have_the_patents_for_H.264_MPEG-4_AVC_expired_yet%3F

On Tue, Jan 30, 2024 at 11:59 AM Samuel Klein  wrote:
>
> [New thread for the discussions started by brion, Ivan, James and others on 
> becoming video-friendly and building a community of video editors and 
> curators. Was "Re: We need more interactive content."]
>
> James Heilman wrote:
>>
>> With VideoWiki we have been able to create some higher quality content with 
>> a partner at MyUpchar. The text was written by us, the individual short 
>> animations were done by them, and then the tool combines it all together 
>> with text to speech. Hope to get the tool working again soon:
>> https://mdwiki.org/wiki/Video:Tuberculosis
>
>
> A nice example of a) creating a space explicitly to develop new tools and 
> encourage one another in using them; b) trialing a workflow that can be 
> automated at need.
>
> Text-to-speech and animation tools have also advanced tremendously since that 
> was produced; this is also becoming an important channel for more mainstream 
> media (I see the spammers taking over mainstream social media with it as 
> well, in how-tos, education, news, sports, and leisure).
>
> SJ
>
> On Tue, Jan 30, 2024 at 2:25 AM Ivan Martínez  wrote:
>>
>> It is not difficult to do something that is already happening. By referring 
>> to encyclopedic videos I am talking about multimedia that can enrich 
>> existing content. I understand your point, it's a bit like what happened 
>> with the project of reading recorded Wikipedia articles that after years 
>> seem obsolete.
>>
>> What I am referring to is all that multimedia material that is visual, that 
>> can be made into video to complement articles. The process you mention is 
>> complicated, but not impossible, in fact, there are many of us editors who 
>> have all those skills already implemented in the projects.
>>>
>>>
>>> > By not having a Youtube 2.0 we are avoiding a Wikipedia 2.0 with pure 
>>> > encyclopaedic videos. I see a false dilemma there.
>
>
>
> brion wrote:
>>
>> My recommendations for Wikimedia Foundation on this subject:
>> 1) Overturn the requirement to avoid handling h.264 files on Wikimedia 
>> servers or accept them from users or serve them to users. Allow importing 
>> h.264 uploads and creating h.264 transcodes for playback compatibility.
>> 2) Create an interactive media team with at least two engineers, a designer, 
>> and a project manager
>> 3) Give this team a remit to rebuild *and maintain in an ongoing fashion* 
>> the existing TimedMediaHandler, Graphs, Score, 3D, etc extensions
>> 4) Integrate those tools cleanly with mobile apps and social media embedding 
>> tools managed by other teams
>
> ___
> 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/message/KOJJRSMU62AOHW23TWWRYUKSPQETDEFD/
> To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org
___
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/message/CRBPTFP2XTGZPBYMEDABQSPXIGZPN5SN/
To unsubscribe send an email to 

[Wikimedia-l] Re: We need more interactive content: we are doing it wrong

[Gergő Tisza]

On Tue, Jan 30, 2024 at 1:57 PM Ori Livneh  wrote:

> 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.
>

This concept was popularized by Bret Victor under the name "explorable
explanations ". There is a
whole Wikipedia article
 on it. There are
some great examples on his website, and there are some websites for
collecting similar content, such as explorabl.es and an awesome list
. I agree they are really
cool but...


> 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.
>

I think it's fundamentally a human scaling problem. Being able to create
good interactive content is just a much more niche skill than being able to
create good text content. Interactive animations were very much part of
Yuri's vision
 for the
Graph extension, but during the decade Graph was deployed in production the
number of such animations made was approximately zero. Granted Vega is
probably not the easiest framework for creating animations, but I don't
think there are other tools which would make it much easier. You could just
write arbitrary Javascript and package it as a gadget; but no one did that
either. Instead, both gadgets and Graph usage are mostly focused on very
basic things like showing a chess board or showing bar charts, because
those are the things that can be reused across a large number of articles
without manually tailoring the code to each, so the economics of creating
them work out.

Security is a challenge but could be worked around via iframes. But it's
hard to justify the effort required for doing that when there is no
community of animation makers interested in it - there are plenty of
volunteers who want to *have* animations, but it's not very clear that
there are any who want to *make* animations. This is the same problem geni
mentioned for videos - a lot of people say "we should have more videos",
but it's not very clear who would make them. If platform support were the
bottleneck here, I think the platform support would happen. But as things
look now, it would just be a poor investment of resources IMO (compared to
e.g. the Gadgets extension or Toolforge or Scribunto which do sustain
vibrant volunteer ecosystems which are significantly held back by the
limitations of these platforms).
___
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/message/ZAB7URVFUDOSNUMB4E7KN4EAAF6WHKVT/
To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org

[Wikimedia-l] Re: We need more interactive content: we are doing it wrong

[rupert THURNER]

On Tue, Jan 23, 2024 at 12:03 PM Galder Gonzalez Larrañaga <
galder...@hotmail.com> wrote:

> We have plenty of roadmaps, but no vehicle to reach our destination.
> Seven years ago, we were discussing our Strategy for 2030. We used
> thousands of volunteer hours, thousands of staff hours and millions of
> dollars to build a really well-balanced strategy. There we concluded that "*By
> 2030, Wikimedia will become the essential infrastructure of the ecosystem
> of free knowledge*". We also made some recommendations to improve the
> User Experience (
> https://meta.wikimedia.org/wiki/Movement_Strategy/Recommendations/Improve_User_Experience)
> and claimed that we wanted to Innovate in Free Knowledge (
> https://meta.wikimedia.org/wiki/Movement_Strategy/Recommendations/Innovate_in_Free_Knowledge
> ).
>

cool summary, galder!  there is one sentence in there:

Build the necessary technology to make free knowledge content
accessible in various formats. Support more diverse modes of
consumption and contribution

to
our projects (e.g. text, audio,
 visual, video, geospatial, etc.).


the result is not so satisfying, i'd say. alone on this list, the only
discussion which comes out of such a sentence is we should put mp4 on
commons or not? really? of course i am exaggeration a little. but galder
has a point that wikipedia was disruptive 20 years ago and not so much
curently. admitted, it is kind of natural that an innovative company
looses the power to innovate over time, this is not necessarily true for
volunteer organisations. lodewijk showed it by launching a foto competition
which turned out to be the biggest one on this planet. it attracted people
who were not in the movement before, with ideas which we did not have in
the movement before. with the example in content space, there is no reason
to believe that approach would not work for technical innovation as well.
money is no problem, hosting is no problem, global reach and glory is not
an issue. we could create some "wiki loves new tech" competition, and, say,
pout 100 million into a five year program to do this, what you think? use
for example the price money to productize stuff, and not care too much if 9
out of 10 ideas fail. one out of ten will be good enough to disrupt.

rupert
___
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/message/5LFJFUUEP6YHNSJXCBX2PGXDJWGDSDQ3/
To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org

[Wikimedia-l] Re: We need more interactive content: we are doing it wrong

[Ori Livneh]

On Tue, Jan 30, 2024 at 2:52 PM Samuel Klein  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  wrote:
>
>> 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.
___
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/message/WQARRAVORPGCGIP5YOAHF7IYFOYVTF5D/
To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org

[Wikimedia-l] We need more video: doing it right

[Samuel Klein]

[New thread for the discussions started by brion, Ivan, James and others on
becoming video-friendly and building a community of video editors and
curators. Was "*Re: We need more interactive content.*"]

James Heilman wrote:

> With VideoWiki we have been able to create some higher quality content
> with a partner at MyUpchar. The text was written by us, the individual
> short animations were done by them, and then the tool combines it all
> together with text to speech. Hope to get the tool working again soon:
> https://mdwiki.org/wiki/Video:Tuberculosis
>

A nice example of a) creating a space explicitly to develop new tools and
encourage one another in using them; b) trialing a workflow that can be
automated at need.

Text-to-speech and animation tools have also advanced tremendously since
that was produced; this is also becoming an important channel for more
mainstream media (I see the spammers taking over mainstream social media
with it as well, in how-tos, education, news, sports, and leisure).

SJ

On Tue, Jan 30, 2024 at 2:25 AM Ivan Martínez  wrote:

> It is not difficult to do something that is already happening. By
> referring to encyclopedic videos I am talking about multimedia that can
> enrich existing content. I understand your point, it's a bit like what
> happened with the project of reading recorded Wikipedia articles that after
> years seem obsolete.
>
> What I am referring to is all that multimedia material that is visual,
> that can be made into video to complement articles. The process you mention
> is complicated, but not impossible, in fact, there are many of us editors
> who have all those skills already implemented in the projects.
>
>>
>> > By not having a Youtube 2.0 we are avoiding a Wikipedia 2.0 with pure
>> encyclopaedic videos. I see a false dilemma there.
>>
>

brion wrote:

> My recommendations for Wikimedia Foundation on this subject:
> 1) Overturn the requirement to avoid handling h.264 files on Wikimedia
> servers or accept them from users or serve them to users. Allow importing
> h.264 uploads and creating h.264 transcodes for playback compatibility.
> 2) Create an interactive media team with at least two engineers, a
> designer, and a project manager
> 3) Give this team a remit to rebuild *and maintain in an ongoing fashion*
> the existing TimedMediaHandler, Graphs, Score, 3D, etc extensions
> 4) Integrate those tools cleanly with mobile apps and social media
> embedding tools managed by other teams
___
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/message/KOJJRSMU62AOHW23TWWRYUKSPQETDEFD/
To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org

[Wikimedia-l] Re: We need more interactive content: we are doing it wrong

[Samuel Klein]

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  wrote:

> 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.

S.
___
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/message/ACAMRUFOIM5S6JLWVTHHE3KDWBXFPBCC/
To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org

[Wikimedia-l] Re: We need more interactive content: we are doing it wrong

[James Heilman]

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.

With VideoWiki we have been able to create some higher quality content with
a partner at MyUpchar. The text was written by us, the individual short
animations were done by them, and then the tool combines it all together
with text to speech. Hope to get the tool working again soon:

https://mdwiki.org/wiki/Video:Tuberculosis

On Tue, Jan 30, 2024 at 1:56 AM Galder Gonzalez Larrañaga <
galder...@hotmail.com> wrote:

> Dear all,
> I think we are mixing two different topics here, which are two different
> problems we should solve:
>
> We have series of problems regarding video upload, some of them technical
> (codecs, uploading process...) and other social (how to know if the video
> is freely licensed, etc). Both are interesting issues, and we should have a
> plan to solve them. Still, there are videos uploaded and used in Wikipedia.
> Technically, it is even possible to make a video portal, take a look to:
>  https://eu.wikipedia.org/wiki/Atari:Hezkuntza/Ikusgela
> . But videos are
> not, by definition, more interactive than audios, images or text. Videos
> are still passive content: you play them in the same way you could hear an
> audio sample or just read a text.
>
> When I talk about interactive content, I'm talking about content that can
> be manipulated by the reader:
>
>- Take a look to OurWorldInData climate change graphs and charts (
>https://ourworldindata.org/explorers/climate-change). These are freely
>licensed, we could have them in articles, but we can't because there are
>road blocks for this to happen (
>https://phabricator.wikimedia.org/T303853).
>- Take a look to brilliant and how to learn geometry there :
> https://brilliant.org/courses/geometry-fundamentals/?from_topic=geometry
>.
>You can just learn geometry manipulating objects, learning directly how
>changing a parameter changes the result.
>- Now take a look to this material by NASA:
>
> https://moon.nasa.gov/moon-in-motion/phases-eclipses-supermoons/moon-phases/.
>You can explore the moon phase with a slider, but for us this is completely
>impossible (there are more interactive features here:
>https://moon.nasa.gov/interactives/).
>- Now take a look to this 3D interactive models:
> https://sketchfab.com/juanbrualla .
>There are many more, and some of them are directly under cc-by license, but
>we can't use them because we can't render 3D objects with textures (
>https://phabricator.wikimedia.org/T246901).
>- Do you want to learn about equations? Wikipedia is not the best
>starting point, as math articles are normally complex. But we could have
>this: https://www.desmos.com/calculator. No, is not going to happen
>because we are going in the opposite direction. There are more great
>examples of graphic calculators in https://www.desmos.com/ or
>https://www.geogebra.org/. Now we have some GeoGebra created videos in
>Commons, even if there are some users who have tried to delete them:
>https://commons.wikimedia.org/wiki/Category:GeoGebra. Is to say,
>instead of adding a graphic calculator, we add the video of someone using
>it, losing all the interactivity of the learning process.
>- This is a vertical video in the project Ikusgela:
>https://eu.wikipedia.org/wiki/Fitxategi:Ikusgela-Tupustarriak.webm. It
>has subtitles, but we can't add more information than that, even if we have
>the script with links, because adding links to subtitles is not allowed.
>Now imagine you can annotate this audio by JFK to add context and links to
>what he is saying:
> https://commons.wikimedia.org/wiki/File:Jfk_berlin_address_high.ogg
>.
>- Now, this is the timeline of symphonies by Beethoven, with audio,
>from Wikidata: https://w.wiki/8$jk. The good news is that we can see
>it. The bad news is that we can't embed it in any article. Which is
>extremely weird, because both are our projects.
>
>
> So, we have two different problems. Video playing is quite evident. But
> lack of 

[Wikimedia-l] Re: We need more interactive content: we are doing it wrong

[Galder Gonzalez Larrañaga]

Dear all,
I think we are mixing two different topics here, which are two different 
problems we should solve:

We have series of problems regarding video upload, some of them technical 
(codecs, uploading process...) and other social (how to know if the video is 
freely licensed, etc). Both are interesting issues, and we should have a plan 
to solve them. Still, there are videos uploaded and used in Wikipedia. 
Technically, it is even possible to make a video portal, take a look to: 
https://eu.wikipedia.org/wiki/Atari:Hezkuntza/Ikusgela.
 But videos are not, by definition, more interactive than audios, images or 
text. Videos are still passive content: you play them in the same way you could 
hear an audio sample or just read a text.

When I talk about interactive content, I'm talking about content that can be 
manipulated by the reader:

  *   Take a look to OurWorldInData climate change graphs and charts 
(https://ourworldindata.org/explorers/climate-change). These are freely 
licensed, we could have them in articles, but we can't because there are road 
blocks for this to happen (https://phabricator.wikimedia.org/T303853).
  *   Take a look to brilliant and how to learn geometry there : 
https://brilliant.org/courses/geometry-fundamentals/?from_topic=geometry.
 You can just learn geometry manipulating objects, learning directly how 
changing a parameter changes the result.
  *   Now take a look to this material by 
NASA:https://moon.nasa.gov/moon-in-motion/phases-eclipses-supermoons/moon-phases/.
 You can explore the moon phase with a slider, but for us this is completely 
impossible (there are more interactive features here: 
https://moon.nasa.gov/interactives/).
  *   Now take a look to this 3D interactive models: 
https://sketchfab.com/juanbrualla. There are 
many more, and some of them are directly under cc-by license, but we can't use 
them because we can't render 3D objects with textures 
(https://phabricator.wikimedia.org/T246901).
  *   Do you want to learn about equations? Wikipedia is not the best starting 
point, as math articles are normally complex. But we could have this: 
https://www.desmos.com/calculator. No, is not going to happen because we are 
going in the opposite direction. There are more great examples of graphic 
calculators in https://www.desmos.com/ or https://www.geogebra.org/. Now we 
have some GeoGebra created videos in Commons, even if there are some users who 
have tried to delete them:https://commons.wikimedia.org/wiki/Category:GeoGebra. 
Is to say, instead of adding a graphic calculator, we add the video of someone 
using it, losing all the interactivity of the learning process.
  *   This is a vertical video in the project 
Ikusgela:https://eu.wikipedia.org/wiki/Fitxategi:Ikusgela-Tupustarriak.webm. It 
has subtitles, but we can't add more information than that, even if we have the 
script with links, because adding links to subtitles is not allowed. Now 
imagine you can annotate this audio by JFK to add context and links to what he 
is saying: 
https://commons.wikimedia.org/wiki/File:Jfk_berlin_address_high.ogg.
  *   Now, this is the timeline of symphonies by Beethoven, with audio, from 
Wikidata: https://w.wiki/8$jk. The good news is that we can see it. The bad 
news is that we can't embed it in any article. Which is extremely weird, 
because both are our projects.

So, we have two different problems. Video playing is quite evident. But lack of 
interactivity will add to the cost, because there are other platforms doing it 
way better.

I would really like to have an answer by the WMF.

Thanks

Galder






From: Ivan Martínez 
Sent: Tuesday, January 30, 2024 8:25 AM
To: Wikimedia Mailing List 
Subject: [Wikimedia-l] Re: We need more interactive content: we are doing it 
wrong

It is not difficult to do something that is already happening. By referring to 
encyclopedic videos I am talking about multimedia that can enrich existing 
content. I understand your point, it's a bit like what happened with the 
project of reading recorded Wikipedia articles that after years seem obsolete.

What I am referring to is all that multimedia material that is visual, that can 
be made into video to complement articles. The process you mention is 
complicated, but not impossible, in fact, there are many of us editors who have 
all those skills already implemented in the projects.

El vie, 26 ene 2024 a las 12:06, geni 
(mailto:geni...@gmail.com>>) escribió:
On Tue, 23 Jan 2024 at 22:24, Ivan Martínez 
mailto:gala...@gmail.com>> wrote:
> By not having a Youtube 2.0 we are avoiding a Wikipedia 2.0 with pure 
> encyclopaedic videos. I see a false dilemma there.


Creating good encyclopaedic videos is from a video production 

[Wikimedia-l] Re: We need more interactive content: we are doing it wrong

[Jan Ainali]

Den tis 30 jan. 2024 kl 02:37 skrev effe iets anders <
effeietsand...@gmail.com>:

> I can see one solution to that (albeit farfetched): an analogue to a super
> rigorous referencing approach. I am imagining it's possible to verify in an
> automated way that an edited video is exclusively constructed out of a list
> of cited materials. So if we would be able to build a database of freely
> licensed raw materials that can be sourced from (HUGE if, I know!)
>

It sounds like you are describing Videowiki:
https://meta.wikimedia.org/wiki/VideoWiki (where the database is Commons).

While valuable, I think that original content is needed, be it homemade
animations, or videos from events or places recorded by the user and never
published anywhere else.

/Jan
___
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/message/OGJ5OJZIYHVEJGD6M4NIT3GMVQM6L6SS/
To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org