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

[Charles Roberson]

My main concern is that we’re risking third parties controlling the
movement. I don’t mean to make a slippery slope argument, but it is kind of
easy to head off at the pass before things get worse.

 - Charles

On Sunday, April 28, 2024, Nicolas VIGNERON 
wrote:

> Hi y'all,
>
> Maybe a naive question but why don't we store the data in Wikidata and/or
> on Commons (in the data namespace) ?
>
> Cheers,
> Nicolas
>
> Le dim. 28 avr. 2024 à 09:18, Galder Gonzalez Larrañaga <
> galder...@hotmail.com> a écrit :
>
>> No, we can't.
>> The Wikimedia Foundation also blocked the option for mirroring, that was
>> our first approach because it reduces 3rd party involvement and we could
>> translate the software. WMF's approach is "don't do anything".
>>
>> A complete waste of time.
>>
>> Galder
>> --
>> *From:* Samuel Klein 
>> *Sent:* Sunday, April 28, 2024 8:56 AM
>> *To:* Wikimedia Mailing List 
>> *Subject:* [Wikimedia-l] Re: We need more interactive content: we are
>> doing it wrong
>>
>> Thoughtful mirroring would address some of Amir's concerns.  (Amir: which
>> ones remain?)
>>
>> Could you use the gadget with a mirror?
>>
>> On Sat, Apr 27, 2024 at 1:50 PM James Heilman  wrote:
>>
>> The other option would be to have a copy of the OWID software on our own
>> servers (it is all openly licensed). We tried this sort of with the OWID
>> mirror which you can see here on the wmcloud
>>
>> https://owidm.wmcloud.org/
>>
>> And functional within a mediawiki install here
>>
>> https://mdwiki.org/wiki/WikiProjectMed_talk:OWID/Archive_1
>>
>> From what I understand moving in this direction would require the
>> software running on production servers with WMF staff support and maintance.
>>
>> We have already uploaded all the data that makes these graphs to Commons
>> by the way.
>>
>> James
>>
>> On Sat, Apr 27, 2024 at 11:11 AM Amir Sarabadani 
>> wrote:
>>
>> (Not Andy, but a global interface admin in my volunteer capacity)
>> Hi,
>> The difference is that here the third party code is being run under the
>> context of Wikipedia. That means even with sandboxing mitigation such as
>> iframe (which has been broken before), it's much easier to break out and
>> collect user credentials such as session information or run any arbitrary
>> action on behalf of the users. While, opening a link explicitly is
>> protected by browsers to make sure they won't be able to access cookies in
>> wikimedia or run arbitrary code on behalf of the user targetting wikimedia
>> projects. That's not impossible to break but it's much much harder (and
>> zero day bugs of this type are in range of millions of dollars). That's why
>> it's recommended to avoid opening unknown links or if you really have to,
>> open them in services such as "Joe's sandbox". What I'm saying is that it's
>> making it easier and cheaper to attack users.
>>
>> The second aspect is trust. Users understand links go to external website
>> we don't control but a dialog is not enough to convey wikimedia's lack of
>> control. People might assume the code or security has been vetted by
>> wikimedia which is not the case. It's worth noting that the click through
>> rate for SSL/TLS security warnings for Chrome was 70% (
>> https://www.usenix.org/system/files/conference/
>> usenixsecurity13/sec13-paper_akhawe.pdf). Even in many cases where it
>> was a legitimate "man in the middle attack". It got better since 2013 but
>> it's still quite high.
>>
>> Another aspect is that, it basically this turns OWID into a target for
>> what's called "watering hole attacks" (https://en.wikipedia.org/
>> wiki/Watering_hole_attack). This is similar to what happened to MeDoc, a
>> tax helper app where it got compromised to launch NotPetya, one of the most
>> devastating cyber attack ever recorded (https://www.wired.com/story/
>> notpetya-cyberattack-ukraine-russia-code-crashed-the-world/).
>>
>> It also brings to question of users data being transferred. As far as I
>> know (I might be very wrong), we instruct browsers not to provide referer
>> information to target websites (via noreferrer attribute) so they can't see
>> any information that the user has clicked on Wikipedia while that's no
>> longer the case here and no way to prevent that from happening (I might be
>> wrong again. Writing this on phone).
>>
>> Last but not least, I'm seriously worried about the impact of this change
>> on 

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

[Galder Gonzalez Larrañaga]

@Vigneron: the data is stored in Commons. But the visualization is impossible. The WMF has blocked all possibilities to show it that are not an static image.2024(e)ko api. 28(a) 11:32 erabiltzaileak hau idatzi du (Nicolas VIGNERON ):Hi y'all,Maybe a naive question but why don't we store the data in Wikidata and/or on Commons (in the data namespace) ?Cheers,NicolasLe dim. 28 avr. 2024 à 09:18, Galder Gonzalez Larrañaga <galder...@hotmail.com> a écrit :






No, we can't.

The Wikimedia Foundation also blocked the option for mirroring, that was our first approach because it reduces 3rd party involvement and we could translate the software. WMF's approach is "don't do anything". 




A complete waste of time.




Galder


From: Samuel Klein <meta...@gmail.com>
Sent: Sunday, April 28, 2024 8:56 AM
To: Wikimedia Mailing List <wikimedia-l@lists.wikimedia.org>
Subject: [Wikimedia-l] Re: We need more interactive content: we are doing it wrong
 


Thoughtful mirroring would address some of Amir's concerns.  (Amir: which ones remain?)


Could you use the gadget with a mirror?



On Sat, Apr 27, 2024 at 1:50 PM James Heilman <jmh...@gmail.com> wrote:


The other option would be to have a copy of the OWID software on our own servers (it is all openly licensed). We tried this sort of with the OWID mirror which you can see here on the wmcloud


https://owidm.wmcloud.org/


And functional within a mediawiki install here


https://mdwiki.org/wiki/WikiProjectMed_talk:OWID/Archive_1


From what I understand moving in this direction would require the software running on production servers with WMF staff support and maintance.


We have already uploaded all the data that makes these graphs to Commons by the way.


James




On Sat, Apr 27, 2024 at 11:11 AM Amir Sarabadani <ladsgr...@gmail.com> wrote:



(Not Andy, but a global interface admin in my volunteer capacity)
Hi,
The difference is that here the third party code is being run under the context of Wikipedia. That means even with sandboxing mitigation such as iframe (which has been broken before), it's much easier to break out and collect user credentials
 such as session information or run any arbitrary action on behalf of the users. While, opening a link explicitly is protected by browsers to make sure they won't be able to access cookies in wikimedia or run arbitrary code on behalf of the user targetting
 wikimedia projects. That's not impossible to break but it's much much harder (and zero day bugs of this type are in range of millions of dollars). That's why it's recommended to avoid opening unknown links or if you really have to, open them in services such
 as "Joe's sandbox". What I'm saying is that it's making it easier and cheaper to attack users.


The second aspect is trust. Users understand links go to external website we don't control but a dialog is not enough to convey wikimedia's lack of control. People might assume the code or security has been vetted by wikimedia which is not the
 case. It's worth noting that the click through rate for SSL/TLS security warnings for Chrome was 70% (https://www.usenix.org/system/files/conference/usenixsecurity13/sec13-paper_akhawe.pdf).
 Even in many cases where it was a legitimate "man in the middle attack". It got better since 2013 but it's still quite high.


Another aspect is that, it basically this turns OWID into a target for what's called "watering hole attacks" (https://en.wikipedia.org/wiki/Watering_hole_attack).
 This is similar to what happened to MeDoc, a tax helper app where it got compromised to launch NotPetya, one of the most devastating cyber attack ever recorded (https://www.wired.com/story/notpetya-cyberattack-ukraine-russia-code-crashed-the-world/).


It also brings to question of users data being transferred. As far as I know (I might be very wrong), we instruct browsers not to provide referer information to target websites (via noreferrer attribute) so they can't see any information that
 the user has clicked on Wikipedia while that's no longer the case here and no way to prevent that from happening (I might be wrong again. Writing this on phone).


Last but not least, I'm seriously worried about the impact of this change on wikis where editors are in countries that don't have a good track record of respecting human rights. Breaking iframe or compromising OWID is not something a basic hacker
 can do but it's not hard to do for an APT or a government with deep pockets. That's why I urge you (as a fellow volunteer) to remove this.


Hope that helps,
Obviously my own ideas and limited knowledge. Not on behalf of WMF or the security team.


Best



James Heilman <jmh...@gmail.com> schrieb am Fr., 26. Apr. 2024, 22:16:


Hey Andy


How is the risk any different than having a reference for a graph that includes a url which links to OWID? When one clicks on such a url it brings you to OWID and shares your IP address with them. W

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

[Nicolas VIGNERON]

Hi y'all,

Maybe a naive question but why don't we store the data in Wikidata and/or
on Commons (in the data namespace) ?

Cheers,
Nicolas

Le dim. 28 avr. 2024 à 09:18, Galder Gonzalez Larrañaga <
galder...@hotmail.com> a écrit :

> No, we can't.
> The Wikimedia Foundation also blocked the option for mirroring, that was
> our first approach because it reduces 3rd party involvement and we could
> translate the software. WMF's approach is "don't do anything".
>
> A complete waste of time.
>
> Galder
> --
> *From:* Samuel Klein 
> *Sent:* Sunday, April 28, 2024 8:56 AM
> *To:* Wikimedia Mailing List 
> *Subject:* [Wikimedia-l] Re: We need more interactive content: we are
> doing it wrong
>
> Thoughtful mirroring would address some of Amir's concerns.  (Amir: which
> ones remain?)
>
> Could you use the gadget with a mirror?
>
> On Sat, Apr 27, 2024 at 1:50 PM James Heilman  wrote:
>
> The other option would be to have a copy of the OWID software on our own
> servers (it is all openly licensed). We tried this sort of with the OWID
> mirror which you can see here on the wmcloud
>
> https://owidm.wmcloud.org/
>
> And functional within a mediawiki install here
>
> https://mdwiki.org/wiki/WikiProjectMed_talk:OWID/Archive_1
>
> From what I understand moving in this direction would require the software
> running on production servers with WMF staff support and maintance.
>
> We have already uploaded all the data that makes these graphs to Commons
> by the way.
>
> James
>
> On Sat, Apr 27, 2024 at 11:11 AM Amir Sarabadani 
> wrote:
>
> (Not Andy, but a global interface admin in my volunteer capacity)
> Hi,
> The difference is that here the third party code is being run under the
> context of Wikipedia. That means even with sandboxing mitigation such as
> iframe (which has been broken before), it's much easier to break out and
> collect user credentials such as session information or run any arbitrary
> action on behalf of the users. While, opening a link explicitly is
> protected by browsers to make sure they won't be able to access cookies in
> wikimedia or run arbitrary code on behalf of the user targetting wikimedia
> projects. That's not impossible to break but it's much much harder (and
> zero day bugs of this type are in range of millions of dollars). That's why
> it's recommended to avoid opening unknown links or if you really have to,
> open them in services such as "Joe's sandbox". What I'm saying is that it's
> making it easier and cheaper to attack users.
>
> The second aspect is trust. Users understand links go to external website
> we don't control but a dialog is not enough to convey wikimedia's lack of
> control. People might assume the code or security has been vetted by
> wikimedia which is not the case. It's worth noting that the click through
> rate for SSL/TLS security warnings for Chrome was 70% (
> https://www.usenix.org/system/files/conference/usenixsecurity13/sec13-paper_akhawe.pdf).
> Even in many cases where it was a legitimate "man in the middle attack". It
> got better since 2013 but it's still quite high.
>
> Another aspect is that, it basically this turns OWID into a target for
> what's called "watering hole attacks" (
> https://en.wikipedia.org/wiki/Watering_hole_attack). This is similar to
> what happened to MeDoc, a tax helper app where it got compromised to launch
> NotPetya, one of the most devastating cyber attack ever recorded (
> https://www.wired.com/story/notpetya-cyberattack-ukraine-russia-code-crashed-the-world/
> ).
>
> It also brings to question of users data being transferred. As far as I
> know (I might be very wrong), we instruct browsers not to provide referer
> information to target websites (via noreferrer attribute) so they can't see
> any information that the user has clicked on Wikipedia while that's no
> longer the case here and no way to prevent that from happening (I might be
> wrong again. Writing this on phone).
>
> Last but not least, I'm seriously worried about the impact of this change
> on wikis where editors are in countries that don't have a good track record
> of respecting human rights. Breaking iframe or compromising OWID is not
> something a basic hacker can do but it's not hard to do for an APT or a
> government with deep pockets. That's why I urge you (as a fellow volunteer)
> to remove this.
>
> Hope that helps,
> Obviously my own ideas and limited knowledge. Not on behalf of WMF or the
> security team.
>
> Best
>
> James Heilman  schrieb am Fr., 26. Apr. 2024, 22:16:
>
> Hey Andy
>
> How is the risk any different than having a reference for a graph that
> includes a url whi

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

[Galder Gonzalez Larrañaga]

No, we can't.
The Wikimedia Foundation also blocked the option for mirroring, that was our 
first approach because it reduces 3rd party involvement and we could translate 
the software. WMF's approach is "don't do anything".

A complete waste of time.

Galder

From: Samuel Klein 
Sent: Sunday, April 28, 2024 8:56 AM
To: Wikimedia Mailing List 
Subject: [Wikimedia-l] Re: We need more interactive content: we are doing it 
wrong

Thoughtful mirroring would address some of Amir's concerns.  (Amir: which ones 
remain?)

Could you use the gadget with a mirror?

On Sat, Apr 27, 2024 at 1:50 PM James Heilman 
mailto:jmh...@gmail.com>> wrote:
The other option would be to have a copy of the OWID software on our own 
servers (it is all openly licensed). We tried this sort of with the OWID mirror 
which you can see here on the wmcloud

https://owidm.wmcloud.org/

And functional within a mediawiki install here

https://mdwiki.org/wiki/WikiProjectMed_talk:OWID/Archive_1

From what I understand moving in this direction would require the software 
running on production servers with WMF staff support and maintance.

We have already uploaded all the data that makes these graphs to Commons by the 
way.

James

On Sat, Apr 27, 2024 at 11:11 AM Amir Sarabadani 
mailto:ladsgr...@gmail.com>> wrote:
(Not Andy, but a global interface admin in my volunteer capacity)
Hi,
The difference is that here the third party code is being run under the context 
of Wikipedia. That means even with sandboxing mitigation such as iframe (which 
has been broken before), it's much easier to break out and collect user 
credentials such as session information or run any arbitrary action on behalf 
of the users. While, opening a link explicitly is protected by browsers to make 
sure they won't be able to access cookies in wikimedia or run arbitrary code on 
behalf of the user targetting wikimedia projects. That's not impossible to 
break but it's much much harder (and zero day bugs of this type are in range of 
millions of dollars). That's why it's recommended to avoid opening unknown 
links or if you really have to, open them in services such as "Joe's sandbox". 
What I'm saying is that it's making it easier and cheaper to attack users.

The second aspect is trust. Users understand links go to external website we 
don't control but a dialog is not enough to convey wikimedia's lack of control. 
People might assume the code or security has been vetted by wikimedia which is 
not the case. It's worth noting that the click through rate for SSL/TLS 
security warnings for Chrome was 70% 
(https://www.usenix.org/system/files/conference/usenixsecurity13/sec13-paper_akhawe.pdf).
 Even in many cases where it was a legitimate "man in the middle attack". It 
got better since 2013 but it's still quite high.

Another aspect is that, it basically this turns OWID into a target for what's 
called "watering hole attacks" 
(https://en.wikipedia.org/wiki/Watering_hole_attack). This is similar to what 
happened to MeDoc, a tax helper app where it got compromised to launch 
NotPetya, one of the most devastating cyber attack ever recorded 
(https://www.wired.com/story/notpetya-cyberattack-ukraine-russia-code-crashed-the-world/).

It also brings to question of users data being transferred. As far as I know (I 
might be very wrong), we instruct browsers not to provide referer information 
to target websites (via noreferrer attribute) so they can't see any information 
that the user has clicked on Wikipedia while that's no longer the case here and 
no way to prevent that from happening (I might be wrong again. Writing this on 
phone).

Last but not least, I'm seriously worried about the impact of this change on 
wikis where editors are in countries that don't have a good track record of 
respecting human rights. Breaking iframe or compromising OWID is not something 
a basic hacker can do but it's not hard to do for an APT or a government with 
deep pockets. That's why I urge you (as a fellow volunteer) to remove this.

Hope that helps,
Obviously my own ideas and limited knowledge. Not on behalf of WMF or the 
security team.

Best

James Heilman mailto:jmh...@gmail.com>> schrieb am Fr., 26. 
Apr. 2024, 22:16:
Hey Andy

How is the risk any different than having a reference for a graph that includes 
a url which links to OWID? When one clicks on such a url it brings you to OWID 
and shares your IP address with them. We have millions of references that 
include urls without warnings or consent before loading.

James

On Fri, Apr 26, 2024 at 1:44 PM Galder Gonzalez Larrañaga 
mailto:galder...@hotmail.com>> wrote:
Hello Andy,
There was a solution involving adding the software to our own platform instead 
of loading it. It was dismissed by the Wikimedia Foundation. It's not 
disappointment the word I'm looking for.

Best

Galder

2024(e)ko api. 26(a) 21:38 erabiltzaileak hau idatzi d

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

[Samuel Klein]

Thoughtful mirroring would address some of Amir's concerns.  (Amir: which
ones remain?)

Could you use the gadget with a mirror?

On Sat, Apr 27, 2024 at 1:50 PM James Heilman  wrote:

> The other option would be to have a copy of the OWID software on our own
> servers (it is all openly licensed). We tried this sort of with the OWID
> mirror which you can see here on the wmcloud
>
> https://owidm.wmcloud.org/
>
> And functional within a mediawiki install here
>
> https://mdwiki.org/wiki/WikiProjectMed_talk:OWID/Archive_1
>
> From what I understand moving in this direction would require the software
> running on production servers with WMF staff support and maintance.
>
> We have already uploaded all the data that makes these graphs to Commons
> by the way.
>
> James
>
> On Sat, Apr 27, 2024 at 11:11 AM Amir Sarabadani 
> wrote:
>
>> (Not Andy, but a global interface admin in my volunteer capacity)
>> Hi,
>> The difference is that here the third party code is being run under the
>> context of Wikipedia. That means even with sandboxing mitigation such as
>> iframe (which has been broken before), it's much easier to break out and
>> collect user credentials such as session information or run any arbitrary
>> action on behalf of the users. While, opening a link explicitly is
>> protected by browsers to make sure they won't be able to access cookies in
>> wikimedia or run arbitrary code on behalf of the user targetting wikimedia
>> projects. That's not impossible to break but it's much much harder (and
>> zero day bugs of this type are in range of millions of dollars). That's why
>> it's recommended to avoid opening unknown links or if you really have to,
>> open them in services such as "Joe's sandbox". What I'm saying is that it's
>> making it easier and cheaper to attack users.
>>
>> The second aspect is trust. Users understand links go to external website
>> we don't control but a dialog is not enough to convey wikimedia's lack of
>> control. People might assume the code or security has been vetted by
>> wikimedia which is not the case. It's worth noting that the click through
>> rate for SSL/TLS security warnings for Chrome was 70% (
>> https://www.usenix.org/system/files/conference/usenixsecurity13/sec13-paper_akhawe.pdf).
>> Even in many cases where it was a legitimate "man in the middle attack". It
>> got better since 2013 but it's still quite high.
>>
>> Another aspect is that, it basically this turns OWID into a target for
>> what's called "watering hole attacks" (
>> https://en.wikipedia.org/wiki/Watering_hole_attack). This is similar to
>> what happened to MeDoc, a tax helper app where it got compromised to launch
>> NotPetya, one of the most devastating cyber attack ever recorded (
>> https://www.wired.com/story/notpetya-cyberattack-ukraine-russia-code-crashed-the-world/
>> ).
>>
>> It also brings to question of users data being transferred. As far as I
>> know (I might be very wrong), we instruct browsers not to provide referer
>> information to target websites (via noreferrer attribute) so they can't see
>> any information that the user has clicked on Wikipedia while that's no
>> longer the case here and no way to prevent that from happening (I might be
>> wrong again. Writing this on phone).
>>
>> Last but not least, I'm seriously worried about the impact of this change
>> on wikis where editors are in countries that don't have a good track record
>> of respecting human rights. Breaking iframe or compromising OWID is not
>> something a basic hacker can do but it's not hard to do for an APT or a
>> government with deep pockets. That's why I urge you (as a fellow volunteer)
>> to remove this.
>>
>> Hope that helps,
>> Obviously my own ideas and limited knowledge. Not on behalf of WMF or the
>> security team.
>>
>> Best
>>
>> James Heilman  schrieb am Fr., 26. Apr. 2024, 22:16:
>>
>>> Hey Andy
>>>
>>> How is the risk any different than having a reference for a graph that
>>> includes a url which links to OWID? When one clicks on such a url it brings
>>> you to OWID and shares your IP address with them. We have millions of
>>> references that include urls without warnings or consent before loading.
>>>
>>> James
>>>
>>> On Fri, Apr 26, 2024 at 1:44 PM Galder Gonzalez Larrañaga <
>>> galder...@hotmail.com> wrote:
>>>
 Hello Andy,
 There was a solution involving adding the software to our own platform
 instead of loading it. It was dismissed by the Wikimedia Foundation. It's
 not disappointment the word I'm looking for.

 Best

 Galder

 2024(e)ko api. 26(a) 21:38 erabiltzaileak hau idatzi du (
 acoo...@wikimedia.org):

 Hello everyone,

 I’m Andy Cooper, the Director of Security at the Wikimedia Foundation.
 Over the past week, teams within the Wikimedia Foundation have met to
 discuss the potential legal, security, and privacy risks from the OWID
 gadget introduced on this thread. We’re still looking into the risks that
 

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

[Felipe Schenone]

Very well, I just deactivated the gadget from the Spanish Wikipedia and
removed the now broken template from the two articles that used it, until
some decision is made about it. I shared my views at
https://meta.wikimedia.org/wiki/Talk:OWID_Gadget#Three_ideas, in case
anyone's interested. Kind regards,

On Sat, Apr 27, 2024 at 2:50 PM James Heilman  wrote:

> The other option would be to have a copy of the OWID software on our own
> servers (it is all openly licensed). We tried this sort of with the OWID
> mirror which you can see here on the wmcloud
>
> https://owidm.wmcloud.org/
>
> And functional within a mediawiki install here
>
> https://mdwiki.org/wiki/WikiProjectMed_talk:OWID/Archive_1
>
> From what I understand moving in this direction would require the software
> running on production servers with WMF staff support and maintance.
>
> We have already uploaded all the data that makes these graphs to Commons
> by the way.
>
> James
>
> On Sat, Apr 27, 2024 at 11:11 AM Amir Sarabadani 
> wrote:
>
>> (Not Andy, but a global interface admin in my volunteer capacity)
>> Hi,
>> The difference is that here the third party code is being run under the
>> context of Wikipedia. That means even with sandboxing mitigation such as
>> iframe (which has been broken before), it's much easier to break out and
>> collect user credentials such as session information or run any arbitrary
>> action on behalf of the users. While, opening a link explicitly is
>> protected by browsers to make sure they won't be able to access cookies in
>> wikimedia or run arbitrary code on behalf of the user targetting wikimedia
>> projects. That's not impossible to break but it's much much harder (and
>> zero day bugs of this type are in range of millions of dollars). That's why
>> it's recommended to avoid opening unknown links or if you really have to,
>> open them in services such as "Joe's sandbox". What I'm saying is that it's
>> making it easier and cheaper to attack users.
>>
>> The second aspect is trust. Users understand links go to external website
>> we don't control but a dialog is not enough to convey wikimedia's lack of
>> control. People might assume the code or security has been vetted by
>> wikimedia which is not the case. It's worth noting that the click through
>> rate for SSL/TLS security warnings for Chrome was 70% (
>> https://www.usenix.org/system/files/conference/usenixsecurity13/sec13-paper_akhawe.pdf).
>> Even in many cases where it was a legitimate "man in the middle attack". It
>> got better since 2013 but it's still quite high.
>>
>> Another aspect is that, it basically this turns OWID into a target for
>> what's called "watering hole attacks" (
>> https://en.wikipedia.org/wiki/Watering_hole_attack). This is similar to
>> what happened to MeDoc, a tax helper app where it got compromised to launch
>> NotPetya, one of the most devastating cyber attack ever recorded (
>> https://www.wired.com/story/notpetya-cyberattack-ukraine-russia-code-crashed-the-world/
>> ).
>>
>> It also brings to question of users data being transferred. As far as I
>> know (I might be very wrong), we instruct browsers not to provide referer
>> information to target websites (via noreferrer attribute) so they can't see
>> any information that the user has clicked on Wikipedia while that's no
>> longer the case here and no way to prevent that from happening (I might be
>> wrong again. Writing this on phone).
>>
>> Last but not least, I'm seriously worried about the impact of this change
>> on wikis where editors are in countries that don't have a good track record
>> of respecting human rights. Breaking iframe or compromising OWID is not
>> something a basic hacker can do but it's not hard to do for an APT or a
>> government with deep pockets. That's why I urge you (as a fellow volunteer)
>> to remove this.
>>
>> Hope that helps,
>> Obviously my own ideas and limited knowledge. Not on behalf of WMF or the
>> security team.
>>
>> Best
>>
>> James Heilman  schrieb am Fr., 26. Apr. 2024, 22:16:
>>
>>> Hey Andy
>>>
>>> How is the risk any different than having a reference for a graph that
>>> includes a url which links to OWID? When one clicks on such a url it brings
>>> you to OWID and shares your IP address with them. We have millions of
>>> references that include urls without warnings or consent before loading.
>>>
>>> James
>>>
>>> On Fri, Apr 26, 2024 at 1:44 PM Galder Gonzalez Larrañaga <
>>> galder...@hotmail.com> wrote:
>>>
 Hello Andy,
 There was a solution involving adding the software to our own platform
 instead of loading it. It was dismissed by the Wikimedia Foundation. It's
 not disappointment the word I'm looking for.

 Best

 Galder

 2024(e)ko api. 26(a) 21:38 erabiltzaileak hau idatzi du (
 acoo...@wikimedia.org):

 Hello everyone,

 I’m Andy Cooper, the Director of Security at the Wikimedia Foundation.
 Over the past week, teams within the Wikimedia Foundation 

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

[James Heilman]

The other option would be to have a copy of the OWID software on our own
servers (it is all openly licensed). We tried this sort of with the OWID
mirror which you can see here on the wmcloud

https://owidm.wmcloud.org/

And functional within a mediawiki install here

https://mdwiki.org/wiki/WikiProjectMed_talk:OWID/Archive_1

>From what I understand moving in this direction would require the software
running on production servers with WMF staff support and maintance.

We have already uploaded all the data that makes these graphs to Commons by
the way.

James

On Sat, Apr 27, 2024 at 11:11 AM Amir Sarabadani 
wrote:

> (Not Andy, but a global interface admin in my volunteer capacity)
> Hi,
> The difference is that here the third party code is being run under the
> context of Wikipedia. That means even with sandboxing mitigation such as
> iframe (which has been broken before), it's much easier to break out and
> collect user credentials such as session information or run any arbitrary
> action on behalf of the users. While, opening a link explicitly is
> protected by browsers to make sure they won't be able to access cookies in
> wikimedia or run arbitrary code on behalf of the user targetting wikimedia
> projects. That's not impossible to break but it's much much harder (and
> zero day bugs of this type are in range of millions of dollars). That's why
> it's recommended to avoid opening unknown links or if you really have to,
> open them in services such as "Joe's sandbox". What I'm saying is that it's
> making it easier and cheaper to attack users.
>
> The second aspect is trust. Users understand links go to external website
> we don't control but a dialog is not enough to convey wikimedia's lack of
> control. People might assume the code or security has been vetted by
> wikimedia which is not the case. It's worth noting that the click through
> rate for SSL/TLS security warnings for Chrome was 70% (
> https://www.usenix.org/system/files/conference/usenixsecurity13/sec13-paper_akhawe.pdf).
> Even in many cases where it was a legitimate "man in the middle attack". It
> got better since 2013 but it's still quite high.
>
> Another aspect is that, it basically this turns OWID into a target for
> what's called "watering hole attacks" (
> https://en.wikipedia.org/wiki/Watering_hole_attack). This is similar to
> what happened to MeDoc, a tax helper app where it got compromised to launch
> NotPetya, one of the most devastating cyber attack ever recorded (
> https://www.wired.com/story/notpetya-cyberattack-ukraine-russia-code-crashed-the-world/
> ).
>
> It also brings to question of users data being transferred. As far as I
> know (I might be very wrong), we instruct browsers not to provide referer
> information to target websites (via noreferrer attribute) so they can't see
> any information that the user has clicked on Wikipedia while that's no
> longer the case here and no way to prevent that from happening (I might be
> wrong again. Writing this on phone).
>
> Last but not least, I'm seriously worried about the impact of this change
> on wikis where editors are in countries that don't have a good track record
> of respecting human rights. Breaking iframe or compromising OWID is not
> something a basic hacker can do but it's not hard to do for an APT or a
> government with deep pockets. That's why I urge you (as a fellow volunteer)
> to remove this.
>
> Hope that helps,
> Obviously my own ideas and limited knowledge. Not on behalf of WMF or the
> security team.
>
> Best
>
> James Heilman  schrieb am Fr., 26. Apr. 2024, 22:16:
>
>> Hey Andy
>>
>> How is the risk any different than having a reference for a graph that
>> includes a url which links to OWID? When one clicks on such a url it brings
>> you to OWID and shares your IP address with them. We have millions of
>> references that include urls without warnings or consent before loading.
>>
>> James
>>
>> On Fri, Apr 26, 2024 at 1:44 PM Galder Gonzalez Larrañaga <
>> galder...@hotmail.com> wrote:
>>
>>> Hello Andy,
>>> There was a solution involving adding the software to our own platform
>>> instead of loading it. It was dismissed by the Wikimedia Foundation. It's
>>> not disappointment the word I'm looking for.
>>>
>>> Best
>>>
>>> Galder
>>>
>>> 2024(e)ko api. 26(a) 21:38 erabiltzaileak hau idatzi du (
>>> acoo...@wikimedia.org):
>>>
>>> Hello everyone,
>>>
>>> I’m Andy Cooper, the Director of Security at the Wikimedia Foundation.
>>> Over the past week, teams within the Wikimedia Foundation have met to
>>> discuss the potential legal, security, and privacy risks from the OWID
>>> gadget introduced on this thread. We’re still looking into the risks that
>>> this particular gadget presents, but have identified that it raises larger
>>> and more definite concerns around gadgets that use third party websites
>>> more broadly, such as in a worst case scenario theft or misuse of user’s
>>> personal identity and edit history. This, in turn, raises further 

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

[Amir Sarabadani]

(Not Andy, but a global interface admin in my volunteer capacity)
Hi,
The difference is that here the third party code is being run under the
context of Wikipedia. That means even with sandboxing mitigation such as
iframe (which has been broken before), it's much easier to break out and
collect user credentials such as session information or run any arbitrary
action on behalf of the users. While, opening a link explicitly is
protected by browsers to make sure they won't be able to access cookies in
wikimedia or run arbitrary code on behalf of the user targetting wikimedia
projects. That's not impossible to break but it's much much harder (and
zero day bugs of this type are in range of millions of dollars). That's why
it's recommended to avoid opening unknown links or if you really have to,
open them in services such as "Joe's sandbox". What I'm saying is that it's
making it easier and cheaper to attack users.

The second aspect is trust. Users understand links go to external website
we don't control but a dialog is not enough to convey wikimedia's lack of
control. People might assume the code or security has been vetted by
wikimedia which is not the case. It's worth noting that the click through
rate for SSL/TLS security warnings for Chrome was 70% (
https://www.usenix.org/system/files/conference/usenixsecurity13/sec13-paper_akhawe.pdf).
Even in many cases where it was a legitimate "man in the middle attack". It
got better since 2013 but it's still quite high.

Another aspect is that, it basically this turns OWID into a target for
what's called "watering hole attacks" (
https://en.wikipedia.org/wiki/Watering_hole_attack). This is similar to
what happened to MeDoc, a tax helper app where it got compromised to launch
NotPetya, one of the most devastating cyber attack ever recorded (
https://www.wired.com/story/notpetya-cyberattack-ukraine-russia-code-crashed-the-world/
).

It also brings to question of users data being transferred. As far as I
know (I might be very wrong), we instruct browsers not to provide referer
information to target websites (via noreferrer attribute) so they can't see
any information that the user has clicked on Wikipedia while that's no
longer the case here and no way to prevent that from happening (I might be
wrong again. Writing this on phone).

Last but not least, I'm seriously worried about the impact of this change
on wikis where editors are in countries that don't have a good track record
of respecting human rights. Breaking iframe or compromising OWID is not
something a basic hacker can do but it's not hard to do for an APT or a
government with deep pockets. That's why I urge you (as a fellow volunteer)
to remove this.

Hope that helps,
Obviously my own ideas and limited knowledge. Not on behalf of WMF or the
security team.

Best

James Heilman  schrieb am Fr., 26. Apr. 2024, 22:16:

> Hey Andy
>
> How is the risk any different than having a reference for a graph that
> includes a url which links to OWID? When one clicks on such a url it brings
> you to OWID and shares your IP address with them. We have millions of
> references that include urls without warnings or consent before loading.
>
> James
>
> On Fri, Apr 26, 2024 at 1:44 PM Galder Gonzalez Larrañaga <
> galder...@hotmail.com> wrote:
>
>> Hello Andy,
>> There was a solution involving adding the software to our own platform
>> instead of loading it. It was dismissed by the Wikimedia Foundation. It's
>> not disappointment the word I'm looking for.
>>
>> Best
>>
>> Galder
>>
>> 2024(e)ko api. 26(a) 21:38 erabiltzaileak hau idatzi du (
>> acoo...@wikimedia.org):
>>
>> Hello everyone,
>>
>> I’m Andy Cooper, the Director of Security at the Wikimedia Foundation.
>> Over the past week, teams within the Wikimedia Foundation have met to
>> discuss the potential legal, security, and privacy risks from the OWID
>> gadget introduced on this thread. We’re still looking into the risks that
>> this particular gadget presents, but have identified that it raises larger
>> and more definite concerns around gadgets that use third party websites
>> more broadly, such as in a worst case scenario theft or misuse of user’s
>> personal identity and edit history. This, in turn, raises further questions
>> and how we should govern and manage this type of content as a movement.
>>
>> As a result, we’re asking volunteers to hold off on enabling the OWID
>> gadget on more wikis and to refrain from deploying more gadgets that use
>> third party content and/or are automatically enabled for all users for
>> certain pages until we have a better review process in place. I realize
>> that this is frustrating for people here who have been working on OWID and
>> are excited about it as a work around while graphs are disabled. The
>> creativity and effort of volunteer developers has been and continues to be
>> crucial for our movement’s success, and part of our team’s job is to make
>> sure that happens in scalable and responsible ways. We wanted to let
>> 

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

[James Heilman]

Hey Andy

How is the risk any different than having a reference for a graph that
includes a url which links to OWID? When one clicks on such a url it brings
you to OWID and shares your IP address with them. We have millions of
references that include urls without warnings or consent before loading.

James

On Fri, Apr 26, 2024 at 1:44 PM Galder Gonzalez Larrañaga <
galder...@hotmail.com> wrote:

> Hello Andy,
> There was a solution involving adding the software to our own platform
> instead of loading it. It was dismissed by the Wikimedia Foundation. It's
> not disappointment the word I'm looking for.
>
> Best
>
> Galder
>
> 2024(e)ko api. 26(a) 21:38 erabiltzaileak hau idatzi du (
> acoo...@wikimedia.org):
>
> Hello everyone,
>
> I’m Andy Cooper, the Director of Security at the Wikimedia Foundation.
> Over the past week, teams within the Wikimedia Foundation have met to
> discuss the potential legal, security, and privacy risks from the OWID
> gadget introduced on this thread. We’re still looking into the risks that
> this particular gadget presents, but have identified that it raises larger
> and more definite concerns around gadgets that use third party websites
> more broadly, such as in a worst case scenario theft or misuse of user’s
> personal identity and edit history. This, in turn, raises further questions
> and how we should govern and manage this type of content as a movement.
>
> As a result, we’re asking volunteers to hold off on enabling the OWID
> gadget on more wikis and to refrain from deploying more gadgets that use
> third party content and/or are automatically enabled for all users for
> certain pages until we have a better review process in place. I realize
> that this is frustrating for people here who have been working on OWID and
> are excited about it as a work around while graphs are disabled. The
> creativity and effort of volunteer developers has been and continues to be
> crucial for our movement’s success, and part of our team’s job is to make
> sure that happens in scalable and responsible ways. We wanted to let
> everyone here know about these concerns right away while we work to better
> understand the issue. If you’d like to be further involved in this topic,
> please visit the new Meta-Wiki page [1] where we’ll share updates,
> questions, and discuss next steps.
>
> Thanks,
> Andy
>
> [1] https://meta.wikimedia.org/wiki/OWID_Gadget
> ___
> 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/TW3UIL7OEDQRVOQNLJS5RVZD546TADHB/
> 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/TKADHNQOEYPDSJDFEKXDZEME4U55TZWA/
> To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org



-- 
James Heilman
MD, CCFP-EM, Wikipedian
___
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/ASKWWMDFHZNR46BCJQ6Q2EIJOELML3BT/
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

[Galder Gonzalez Larrañaga]

Hello Andy,There was a solution involving adding the software to our own platform instead of loading it. It was dismissed by the Wikimedia Foundation. It's not disappointment the word I'm looking for.BestGalder2024(e)ko api. 26(a) 21:38 erabiltzaileak hau idatzi du (acoo...@wikimedia.org):Hello everyone,

I’m Andy Cooper, the Director of Security at the Wikimedia Foundation.  Over the past week, teams within the Wikimedia Foundation have met to discuss the potential legal, security, and privacy risks from the OWID gadget introduced on this thread. We’re still looking into the risks that this particular gadget presents, but have identified that it raises larger and more definite concerns around gadgets that use third party websites more broadly, such as in a worst case scenario theft or misuse of user’s personal identity and edit history. This, in turn, raises further questions and how we should govern and manage this type of content as a movement. 

As a result, we’re asking volunteers to hold off on enabling the OWID gadget on more wikis and to refrain from deploying more gadgets that use third party content and/or are automatically enabled for all users for certain pages until we have a better review process in place. I realize that this is frustrating for people here who have been working on OWID and are excited about it as a work around while graphs are disabled. The creativity and effort of volunteer developers has been and continues to be crucial for our movement’s success, and part of our team’s job is to make sure that happens in scalable and responsible ways. We wanted to let everyone here know about these concerns right away while we work to better understand the issue. If you’d like to be further involved in this topic, please visit the new Meta-Wiki page [1] where we’ll share updates, questions, and discuss next steps. 

Thanks,
Andy

[1] https://meta.wikimedia.org/wiki/OWID_Gadget
___
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/TW3UIL7OEDQRVOQNLJS5RVZD546TADHB/
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/TKADHNQOEYPDSJDFEKXDZEME4U55TZWA/
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

[acooper]

Hello everyone,

I’m Andy Cooper, the Director of Security at the Wikimedia Foundation.  Over 
the past week, teams within the Wikimedia Foundation have met to discuss the 
potential legal, security, and privacy risks from the OWID gadget introduced on 
this thread. We’re still looking into the risks that this particular gadget 
presents, but have identified that it raises larger and more definite concerns 
around gadgets that use third party websites more broadly, such as in a worst 
case scenario theft or misuse of user’s personal identity and edit history. 
This, in turn, raises further questions and how we should govern and manage 
this type of content as a movement. 

As a result, we’re asking volunteers to hold off on enabling the OWID gadget on 
more wikis and to refrain from deploying more gadgets that use third party 
content and/or are automatically enabled for all users for certain pages until 
we have a better review process in place. I realize that this is frustrating 
for people here who have been working on OWID and are excited about it as a 
work around while graphs are disabled. The creativity and effort of volunteer 
developers has been and continues to be crucial for our movement’s success, and 
part of our team’s job is to make sure that happens in scalable and responsible 
ways. We wanted to let everyone here know about these concerns right away while 
we work to better understand the issue. If you’d like to be further involved in 
this topic, please visit the new Meta-Wiki page [1] where we’ll share updates, 
questions, and discuss next steps. 

Thanks,
Andy

[1] https://meta.wikimedia.org/wiki/OWID_Gadget
___
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/TW3UIL7OEDQRVOQNLJS5RVZD546TADHB/
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]

Hey Andy

We have added alt text

https://www.mediawiki.org/wiki/Template:OWID

Not sure how well the OWID website works with screen-readers. Would be
interested in hearing feedback regarding this.
James

On Thu, Apr 18, 2024 at 5:51 AM Andy Mabbett 
wrote:

> On Tue, 16 Apr 2024 at 22:14, James Heilman  wrote:
> >
> > We have Interactive graphs from OWID working
>
> What are the accessibility implications of presenting data in this
> manner? How is the data available to people with a visual impairment,
> for instance?
>
> Has anyone done an audit, to check compliance with WCAG [1]? Or
> performance in screen-readers [2]?
>
> [1] https://en.wikipedia.org/wiki/Web_Content_Accessibility_Guidelines
>
> [2] https://en.wikipedia.org/wiki/Screen_reader
>
> --
> Andy Mabbett
> @pigsonthewing
> http://pigsonthewing.org.uk
> ___
> 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/LZZSZNC263YLPJZXZDIOTBZ3HR5F6AL3/
> To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org
>


-- 
James Heilman
MD, CCFP-EM, Wikipedian
___
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/T5HU2IJCG7MBPNAIODN46KKEOSHSZEA3/
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

[Andy Mabbett]

On Tue, 16 Apr 2024 at 22:14, James Heilman  wrote:
>
> We have Interactive graphs from OWID working

What are the accessibility implications of presenting data in this
manner? How is the data available to people with a visual impairment,
for instance?

Has anyone done an audit, to check compliance with WCAG [1]? Or
performance in screen-readers [2]?

[1] https://en.wikipedia.org/wiki/Web_Content_Accessibility_Guidelines

[2] https://en.wikipedia.org/wiki/Screen_reader

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk
___
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/LZZSZNC263YLPJZXZDIOTBZ3HR5F6AL3/
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]

an be easily installed in any wiki (Wikimedia or not).
>>>>> See https://www.mediawiki.org/wiki/Template:OWID for the documentation
>>>>> and https://www.mediawiki.org/wiki/MediaWiki:Gadget-OWID.js for the
>>>>> code
>>>>> and https://www.mediawiki.org/wiki/Template_gadgets for more context
>>>>>
>>>>> Galder, perhaps you'd like to update the usage at the Basque Wikipedia
>>>>> (see https://www.mediawiki.org/wiki/Template:OWID) so as to help
>>>>> centralize and coordinate our efforts?
>>>>> Some technical notes:
>>>>> - I simplified the code considerably using the pre-built methods
>>>>> OO.ui.alert and OO.ui.confirm rather than those complicated (and
>>>>> unnecessary, in this case) OOUI classes. I hope you like it.
>>>>> - I wrapped the code with an "OWID" object to keep it out of the
>>>>> global space and make sure the 'oojs-ui-windows' dependency is always
>>>>> loaded.
>>>>> - The localized messages should probably be moved to their own JSON
>>>>> file and loaded from there, but I'm not sure about the best way to do that
>>>>> while keep it template gadgets centralized at MediaWiki.org, and possibly
>>>>> having the strings translated by translatewiki.net. Perhaps we can
>>>>> set up a call to discuss some options?
>>>>>
>>>>> PS, I enabled the template on the Spanish Wikipedia (see
>>>>> https://es.wikipedia.org/wiki/Plantilla:OWID) but we're having some
>>>>> local trouble with template gadgets so it's not working right now. I 
>>>>> should
>>>>> be able to fix it in the next few hours.
>>>>>
>>>>> On Tue, Apr 16, 2024 at 6:34 PM Galder Gonzalez Larrañaga <
>>>>> galder...@hotmail.com> wrote:
>>>>>
>>>>>> Thanks, James, for all the work done,
>>>>>> We now have 14 articles with interactive graphs, as we are exploring
>>>>>> this new feature:
>>>>>> https://eu.wikipedia.org/wiki/Kategoria:Our_World_in_Data_grafikoak_dituzten_artikuluak.
>>>>>> The deployment is pretty easy, it took around 10 minutes with only four
>>>>>> things: a template, a css, a js and a gadget definition. This is so 
>>>>>> simple,
>>>>>> that I think it should be implemented by everyone.
>>>>>>
>>>>>> We should think on how we make it multilingual.
>>>>>>
>>>>>> Thanks again to all the members of WikiProject Med for the step
>>>>>> forward.
>>>>>>
>>>>>> Galder
>>>>>> --
>>>>>> *From:* James Heilman 
>>>>>> *Sent:* Tuesday, April 16, 2024 11:14 PM
>>>>>> *To:* Wikimedia Mailing List 
>>>>>> *Subject:* [Wikimedia-l] Re: We need more interactive content: we
>>>>>> are doing it wrong
>>>>>> We have Interactive graphs from OWID working on Basque Wikipedia,
>>>>>> following a consent popup.
>>>>>>
>>>>>> https://eu.wikipedia.org/wiki/Haurdunaldi#Nerabezaroa
>>>>>>
>>>>>> Still need to figure out a way to make them multilingual.
>>>>>>
>>>>>> --
>>>>>> James Heilman
>>>>>> MD, CCFP-EM, Wikipedian
>>>>>> ___
>>>>>> 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/MFERHIM5S5BNJCM52YYB2Q6T7FO3ZLAL/
>>>>>> 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.wikim

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

[F. Xavier Dengra i Grau via Wikimedia-l]

haps you'd like to update the usage at the Basque Wikipedia 
>>>>> (see https://www.mediawiki.org/wiki/Template:OWID) so as to help 
>>>>> centralize and coordinate our efforts?
>>>>> Some technical notes:
>>>>> - I simplified the code considerably using the pre-built methods 
>>>>> OO.ui.alert and OO.ui.confirm rather than those complicated (and 
>>>>> unnecessary, in this case) OOUI classes. I hope you like it.
>>>>> - I wrapped the code with an "OWID" object to keep it out of the global 
>>>>> space and make sure the 'oojs-ui-windows' dependency is always loaded.
>>>>> - The localized messages should probably be moved to their own JSON file 
>>>>> and loaded from there, but I'm not sure about the best way to do that 
>>>>> while keep it template gadgets centralized at MediaWiki.org, and possibly 
>>>>> having the strings translated by translatewiki.net. Perhaps we can set up 
>>>>> a call to discuss some options?
>>>>>
>>>>> PS, I enabled the template on the Spanish Wikipedia (see 
>>>>> https://es.wikipedia.org/wiki/Plantilla:OWID) but we're having some local 
>>>>> trouble with template gadgets so it's not working right now. I should be 
>>>>> able to fix it in the next few hours.
>>>>>
>>>>> On Tue, Apr 16, 2024 at 6:34 PM Galder Gonzalez Larrañaga 
>>>>>  wrote:
>>>>>
>>>>>> Thanks, James, for all the work done,
>>>>>> We now have 14 articles with interactive graphs, as we are exploring 
>>>>>> this new 
>>>>>> feature:https://eu.wikipedia.org/wiki/Kategoria:Our_World_in_Data_grafikoak_dituzten_artikuluak.
>>>>>>  The deployment is pretty easy, it took around 10 minutes with only four 
>>>>>> things: a template, a css, a js and a gadget definition. This is so 
>>>>>> simple, that I think it should be implemented by everyone.
>>>>>>
>>>>>> We should think on how we make it multilingual.
>>>>>>
>>>>>> Thanks again to all the members of WikiProject Med for the step forward.
>>>>>>
>>>>>> Galder
>>>>>>
>>>>>> ---
>>>>>>
>>>>>> From: James Heilman 
>>>>>> Sent: Tuesday, April 16, 2024 11:14 PM
>>>>>> To: Wikimedia Mailing List 
>>>>>> Subject: [Wikimedia-l] Re: We need more interactive content: we are 
>>>>>> doing it wrong
>>>>>>
>>>>>> We have Interactive graphs from OWID working on Basque Wikipedia, 
>>>>>> following a consent popup.
>>>>>>
>>>>>> https://eu.wikipedia.org/wiki/Haurdunaldi#Nerabezaroa
>>>>>>
>>>>>> Still need to figure out a way to make them multilingual.
>>>>>>
>>>>>> --
>>>>>>
>>>>>> James Heilman
>>>>>> MD, CCFP-EM, Wikipedian
>>>>>> ___
>>>>>> 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/MFERHIM5S5BNJCM52YYB2Q6T7FO3ZLAL/
>>>>>> 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/RKXWQ2QVN6XMFBKHFYDXUWO4SXRL64LK/
>>>>> 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/4CXDQL5XXNEJ4NDC42BROSM6LUWH7QFI/
>>>> To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org
>>>
>>> --
>>>
>>> James Heilman
>>> MD, CCFP-EM, Wikipedian
>>> ___
>>> 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/WB3IV5GBHNK2LKUQJXQS4HAQDQ3QIHAC/
>>> 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/A4CFX6DAU7VLO7SG3IL7A3IO6IXRHWI6/
>> To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org
>
> --
>
> James Heilman
> MD, CCFP-EM, Wikipedian___
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/CXUG7HMUMX7Z5UTD5EDEWZMBTCLMRV5S/
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]

we can set
>>>> up a call to discuss some options?
>>>>
>>>> PS, I enabled the template on the Spanish Wikipedia (see
>>>> https://es.wikipedia.org/wiki/Plantilla:OWID) but we're having some
>>>> local trouble with template gadgets so it's not working right now. I should
>>>> be able to fix it in the next few hours.
>>>>
>>>> On Tue, Apr 16, 2024 at 6:34 PM Galder Gonzalez Larrañaga <
>>>> galder...@hotmail.com> wrote:
>>>>
>>>>> Thanks, James, for all the work done,
>>>>> We now have 14 articles with interactive graphs, as we are exploring
>>>>> this new feature:
>>>>> https://eu.wikipedia.org/wiki/Kategoria:Our_World_in_Data_grafikoak_dituzten_artikuluak.
>>>>> The deployment is pretty easy, it took around 10 minutes with only four
>>>>> things: a template, a css, a js and a gadget definition. This is so 
>>>>> simple,
>>>>> that I think it should be implemented by everyone.
>>>>>
>>>>> We should think on how we make it multilingual.
>>>>>
>>>>> Thanks again to all the members of WikiProject Med for the step
>>>>> forward.
>>>>>
>>>>> Galder
>>>>> --
>>>>> *From:* James Heilman 
>>>>> *Sent:* Tuesday, April 16, 2024 11:14 PM
>>>>> *To:* Wikimedia Mailing List 
>>>>> *Subject:* [Wikimedia-l] Re: We need more interactive content: we are
>>>>> doing it wrong
>>>>>
>>>>> We have Interactive graphs from OWID working on Basque Wikipedia,
>>>>> following a consent popup.
>>>>>
>>>>> https://eu.wikipedia.org/wiki/Haurdunaldi#Nerabezaroa
>>>>>
>>>>> Still need to figure out a way to make them multilingual.
>>>>>
>>>>> --
>>>>> James Heilman
>>>>> MD, CCFP-EM, Wikipedian
>>>>> ___
>>>>> 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/MFERHIM5S5BNJCM52YYB2Q6T7FO3ZLAL/
>>>>> 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/RKXWQ2QVN6XMFBKHFYDXUWO4SXRL64LK/
>>>> 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/4CXDQL5XXNEJ4NDC42BROSM6LUWH7QFI/
>>> To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org
>>
>>
>>
>> --
>> James Heilman
>> MD, CCFP-EM, Wikipedian
>> ___
>> 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/WB3IV5GBHNK2LKUQJXQS4HAQDQ3QIHAC/
>> 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/A4CFX6DAU7VLO7SG3IL7A3IO6IXRHWI6/
> To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org



-- 
James Heilman
MD, CCFP-EM, Wikipedian
___
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/NKYA4HFP4AVTVON7C2TISYO5DSQ7ZRTP/
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

[Brooke Vibber]

Note that a third-party web service is not ideal; in addition to the issues
of tracking and privacy, it can't work offline and likely would require
additional work to get the graphics working on mobile web, mobile apps, and
offline (kiwix etc). Integrating fully with a self-contained service that
is supported by our whole ecosystem and maintained in the future would be
desirable in the work I'd like to make sure we do on multimedia.

-- brooke

On Wed, Apr 17, 2024 at 12:59 PM James Heilman  wrote:

> A bit more background on Our World in Data.
>
> They currently have about 4,500 data visualization
> https://ourworldindata.org/charts
>
> They come in two main formats:
>
> 1) Grapher: These are simpler and their older work
> https://ourworldindata.org/grapher/deaths-from-substance-disorders
> 2) Explorers: These are newer with more ways to adjust data
> https://ourworldindata.org/explorers/natural-resources
>
> Both of these work via the consent pop up workflow.
>
> We last coordinated the mass upload of still images from OWID to Commons
> in 2020. https://commons.wikimedia.org/wiki/Category:Our_World_in_Data
> And are beginning to look at doing an update. One thought as part of this
> update would be to include within the commons page the mediawiki markup
> needed to have the consent pop up work in target languages that have it
> activated.
>
> James
>
> On Wed, Apr 17, 2024 at 1:29 PM Brooke Vibber 
> wrote:
>
>> This is exciting -- let's make sure we capture any usage requirements for
>> the upcoming Graphs modernization work so we can have these features built
>> in again soon!
>>
>> -- brooke
>>
>> On Wed, Apr 17, 2024 at 7:43 AM Felipe Schenone 
>> wrote:
>>
>>> Amazing work, James and Galder!
>>>
>>> Today I was bold, made it fully multilingual and generalized it so that
>>> it can be easily installed in any wiki (Wikimedia or not).
>>> See https://www.mediawiki.org/wiki/Template:OWID for the documentation
>>> and https://www.mediawiki.org/wiki/MediaWiki:Gadget-OWID.js for the code
>>> and https://www.mediawiki.org/wiki/Template_gadgets for more context
>>>
>>> Galder, perhaps you'd like to update the usage at the Basque Wikipedia
>>> (see https://www.mediawiki.org/wiki/Template:OWID) so as to help
>>> centralize and coordinate our efforts?
>>> Some technical notes:
>>> - I simplified the code considerably using the pre-built methods
>>> OO.ui.alert and OO.ui.confirm rather than those complicated (and
>>> unnecessary, in this case) OOUI classes. I hope you like it.
>>> - I wrapped the code with an "OWID" object to keep it out of the global
>>> space and make sure the 'oojs-ui-windows' dependency is always loaded.
>>> - The localized messages should probably be moved to their own JSON file
>>> and loaded from there, but I'm not sure about the best way to do that while
>>> keep it template gadgets centralized at MediaWiki.org, and possibly having
>>> the strings translated by translatewiki.net. Perhaps we can set up a
>>> call to discuss some options?
>>>
>>> PS, I enabled the template on the Spanish Wikipedia (see
>>> https://es.wikipedia.org/wiki/Plantilla:OWID) but we're having some
>>> local trouble with template gadgets so it's not working right now. I should
>>> be able to fix it in the next few hours.
>>>
>>> On Tue, Apr 16, 2024 at 6:34 PM Galder Gonzalez Larrañaga <
>>> galder...@hotmail.com> wrote:
>>>
>>>> Thanks, James, for all the work done,
>>>> We now have 14 articles with interactive graphs, as we are exploring
>>>> this new feature:
>>>> https://eu.wikipedia.org/wiki/Kategoria:Our_World_in_Data_grafikoak_dituzten_artikuluak.
>>>> The deployment is pretty easy, it took around 10 minutes with only four
>>>> things: a template, a css, a js and a gadget definition. This is so simple,
>>>> that I think it should be implemented by everyone.
>>>>
>>>> We should think on how we make it multilingual.
>>>>
>>>> Thanks again to all the members of WikiProject Med for the step forward.
>>>>
>>>> Galder
>>>> --
>>>> *From:* James Heilman 
>>>> *Sent:* Tuesday, April 16, 2024 11:14 PM
>>>> *To:* Wikimedia Mailing List 
>>>> *Subject:* [Wikimedia-l] Re: We need more interactive content: we are
>>>> doing it wrong
>>>>
>>>> We have Interactive graphs from OWID working on Basque Wikipedia,
>>>>

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

[James Heilman]

A bit more background on Our World in Data.

They currently have about 4,500 data visualization
https://ourworldindata.org/charts

They come in two main formats:

1) Grapher: These are simpler and their older work
https://ourworldindata.org/grapher/deaths-from-substance-disorders
2) Explorers: These are newer with more ways to adjust data
https://ourworldindata.org/explorers/natural-resources

Both of these work via the consent pop up workflow.

We last coordinated the mass upload of still images from OWID to Commons in
2020. https://commons.wikimedia.org/wiki/Category:Our_World_in_Data And are
beginning to look at doing an update. One thought as part of this update
would be to include within the commons page the mediawiki markup needed to
have the consent pop up work in target languages that have it activated.

James

On Wed, Apr 17, 2024 at 1:29 PM Brooke Vibber  wrote:

> This is exciting -- let's make sure we capture any usage requirements for
> the upcoming Graphs modernization work so we can have these features built
> in again soon!
>
> -- brooke
>
> On Wed, Apr 17, 2024 at 7:43 AM Felipe Schenone 
> wrote:
>
>> Amazing work, James and Galder!
>>
>> Today I was bold, made it fully multilingual and generalized it so that
>> it can be easily installed in any wiki (Wikimedia or not).
>> See https://www.mediawiki.org/wiki/Template:OWID for the documentation
>> and https://www.mediawiki.org/wiki/MediaWiki:Gadget-OWID.js for the code
>> and https://www.mediawiki.org/wiki/Template_gadgets for more context
>>
>> Galder, perhaps you'd like to update the usage at the Basque Wikipedia
>> (see https://www.mediawiki.org/wiki/Template:OWID) so as to help
>> centralize and coordinate our efforts?
>> Some technical notes:
>> - I simplified the code considerably using the pre-built methods
>> OO.ui.alert and OO.ui.confirm rather than those complicated (and
>> unnecessary, in this case) OOUI classes. I hope you like it.
>> - I wrapped the code with an "OWID" object to keep it out of the global
>> space and make sure the 'oojs-ui-windows' dependency is always loaded.
>> - The localized messages should probably be moved to their own JSON file
>> and loaded from there, but I'm not sure about the best way to do that while
>> keep it template gadgets centralized at MediaWiki.org, and possibly having
>> the strings translated by translatewiki.net. Perhaps we can set up a
>> call to discuss some options?
>>
>> PS, I enabled the template on the Spanish Wikipedia (see
>> https://es.wikipedia.org/wiki/Plantilla:OWID) but we're having some
>> local trouble with template gadgets so it's not working right now. I should
>> be able to fix it in the next few hours.
>>
>> On Tue, Apr 16, 2024 at 6:34 PM Galder Gonzalez Larrañaga <
>> galder...@hotmail.com> wrote:
>>
>>> Thanks, James, for all the work done,
>>> We now have 14 articles with interactive graphs, as we are exploring
>>> this new feature:
>>> https://eu.wikipedia.org/wiki/Kategoria:Our_World_in_Data_grafikoak_dituzten_artikuluak.
>>> The deployment is pretty easy, it took around 10 minutes with only four
>>> things: a template, a css, a js and a gadget definition. This is so simple,
>>> that I think it should be implemented by everyone.
>>>
>>> We should think on how we make it multilingual.
>>>
>>> Thanks again to all the members of WikiProject Med for the step forward.
>>>
>>> Galder
>>> --
>>> *From:* James Heilman 
>>> *Sent:* Tuesday, April 16, 2024 11:14 PM
>>> *To:* Wikimedia Mailing List 
>>> *Subject:* [Wikimedia-l] Re: We need more interactive content: we are
>>> doing it wrong
>>>
>>> We have Interactive graphs from OWID working on Basque Wikipedia,
>>> following a consent popup.
>>>
>>> https://eu.wikipedia.org/wiki/Haurdunaldi#Nerabezaroa
>>>
>>> Still need to figure out a way to make them multilingual.
>>>
>>> --
>>> James Heilman
>>> MD, CCFP-EM, Wikipedian
>>> ___
>>> 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/MFERHIM5S5BNJCM52YYB2Q6T7FO3ZLAL/
>>> 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

[Brooke Vibber]

This is exciting -- let's make sure we capture any usage requirements for
the upcoming Graphs modernization work so we can have these features built
in again soon!

-- brooke

On Wed, Apr 17, 2024 at 7:43 AM Felipe Schenone  wrote:

> Amazing work, James and Galder!
>
> Today I was bold, made it fully multilingual and generalized it so that it
> can be easily installed in any wiki (Wikimedia or not).
> See https://www.mediawiki.org/wiki/Template:OWID for the documentation
> and https://www.mediawiki.org/wiki/MediaWiki:Gadget-OWID.js for the code
> and https://www.mediawiki.org/wiki/Template_gadgets for more context
>
> Galder, perhaps you'd like to update the usage at the Basque Wikipedia
> (see https://www.mediawiki.org/wiki/Template:OWID) so as to help
> centralize and coordinate our efforts?
> Some technical notes:
> - I simplified the code considerably using the pre-built methods
> OO.ui.alert and OO.ui.confirm rather than those complicated (and
> unnecessary, in this case) OOUI classes. I hope you like it.
> - I wrapped the code with an "OWID" object to keep it out of the global
> space and make sure the 'oojs-ui-windows' dependency is always loaded.
> - The localized messages should probably be moved to their own JSON file
> and loaded from there, but I'm not sure about the best way to do that while
> keep it template gadgets centralized at MediaWiki.org, and possibly having
> the strings translated by translatewiki.net. Perhaps we can set up a call
> to discuss some options?
>
> PS, I enabled the template on the Spanish Wikipedia (see
> https://es.wikipedia.org/wiki/Plantilla:OWID) but we're having some local
> trouble with template gadgets so it's not working right now. I should be
> able to fix it in the next few hours.
>
> On Tue, Apr 16, 2024 at 6:34 PM Galder Gonzalez Larrañaga <
> galder...@hotmail.com> wrote:
>
>> Thanks, James, for all the work done,
>> We now have 14 articles with interactive graphs, as we are exploring this
>> new feature:
>> https://eu.wikipedia.org/wiki/Kategoria:Our_World_in_Data_grafikoak_dituzten_artikuluak.
>> The deployment is pretty easy, it took around 10 minutes with only four
>> things: a template, a css, a js and a gadget definition. This is so simple,
>> that I think it should be implemented by everyone.
>>
>> We should think on how we make it multilingual.
>>
>> Thanks again to all the members of WikiProject Med for the step forward.
>>
>> Galder
>> ------
>> *From:* James Heilman 
>> *Sent:* Tuesday, April 16, 2024 11:14 PM
>> *To:* Wikimedia Mailing List 
>> *Subject:* [Wikimedia-l] Re: We need more interactive content: we are
>> doing it wrong
>>
>> We have Interactive graphs from OWID working on Basque Wikipedia,
>> following a consent popup.
>>
>> https://eu.wikipedia.org/wiki/Haurdunaldi#Nerabezaroa
>>
>> Still need to figure out a way to make them multilingual.
>>
>> --
>> James Heilman
>> MD, CCFP-EM, Wikipedian
>> ___
>> 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/MFERHIM5S5BNJCM52YYB2Q6T7FO3ZLAL/
>> 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/RKXWQ2QVN6XMFBKHFYDXUWO4SXRL64LK/
> 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/4CXDQL5XXNEJ4NDC42BROSM6LUWH7QFI/
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

[Felipe Schenone]

Amazing work, James and Galder!

Today I was bold, made it fully multilingual and generalized it so that it
can be easily installed in any wiki (Wikimedia or not).
See https://www.mediawiki.org/wiki/Template:OWID for the documentation
and https://www.mediawiki.org/wiki/MediaWiki:Gadget-OWID.js for the code
and https://www.mediawiki.org/wiki/Template_gadgets for more context

Galder, perhaps you'd like to update the usage at the Basque Wikipedia (see
https://www.mediawiki.org/wiki/Template:OWID) so as to help centralize and
coordinate our efforts?
Some technical notes:
- I simplified the code considerably using the pre-built methods
OO.ui.alert and OO.ui.confirm rather than those complicated (and
unnecessary, in this case) OOUI classes. I hope you like it.
- I wrapped the code with an "OWID" object to keep it out of the global
space and make sure the 'oojs-ui-windows' dependency is always loaded.
- The localized messages should probably be moved to their own JSON file
and loaded from there, but I'm not sure about the best way to do that while
keep it template gadgets centralized at MediaWiki.org, and possibly having
the strings translated by translatewiki.net. Perhaps we can set up a call
to discuss some options?

PS, I enabled the template on the Spanish Wikipedia (see
https://es.wikipedia.org/wiki/Plantilla:OWID) but we're having some local
trouble with template gadgets so it's not working right now. I should be
able to fix it in the next few hours.

On Tue, Apr 16, 2024 at 6:34 PM Galder Gonzalez Larrañaga <
galder...@hotmail.com> wrote:

> Thanks, James, for all the work done,
> We now have 14 articles with interactive graphs, as we are exploring this
> new feature:
> https://eu.wikipedia.org/wiki/Kategoria:Our_World_in_Data_grafikoak_dituzten_artikuluak.
> The deployment is pretty easy, it took around 10 minutes with only four
> things: a template, a css, a js and a gadget definition. This is so simple,
> that I think it should be implemented by everyone.
>
> We should think on how we make it multilingual.
>
> Thanks again to all the members of WikiProject Med for the step forward.
>
> Galder
> --
> *From:* James Heilman 
> *Sent:* Tuesday, April 16, 2024 11:14 PM
> *To:* Wikimedia Mailing List 
> *Subject:* [Wikimedia-l] Re: We need more interactive content: we are
> doing it wrong
>
> We have Interactive graphs from OWID working on Basque Wikipedia,
> following a consent popup.
>
> https://eu.wikipedia.org/wiki/Haurdunaldi#Nerabezaroa
>
> Still need to figure out a way to make them multilingual.
>
> --
> James Heilman
> MD, CCFP-EM, Wikipedian
> ___
> 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/MFERHIM5S5BNJCM52YYB2Q6T7FO3ZLAL/
> 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/RKXWQ2QVN6XMFBKHFYDXUWO4SXRL64LK/
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

[Galder Gonzalez Larrañaga]

Thanks, James, for all the work done,
We now have 14 articles with interactive graphs, as we are exploring this new 
feature:https://eu.wikipedia.org/wiki/Kategoria:Our_World_in_Data_grafikoak_dituzten_artikuluak.
 The deployment is pretty easy, it took around 10 minutes with only four 
things: a template, a css, a js and a gadget definition. This is so simple, 
that I think it should be implemented by everyone.

We should think on how we make it multilingual.

Thanks again to all the members of WikiProject Med for the step forward.

Galder

From: James Heilman 
Sent: Tuesday, April 16, 2024 11:14 PM
To: Wikimedia Mailing List 
Subject: [Wikimedia-l] Re: We need more interactive content: we are doing it 
wrong

We have Interactive graphs from OWID working on Basque Wikipedia, following a 
consent popup.

https://eu.wikipedia.org/wiki/Haurdunaldi#Nerabezaroa

Still need to figure out a way to make them multilingual.

--
James Heilman
MD, CCFP-EM, Wikipedian
___
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/MFERHIM5S5BNJCM52YYB2Q6T7FO3ZLAL/
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]

We have Interactive graphs from OWID working on Basque Wikipedia, following
a consent popup.

https://eu.wikipedia.org/wiki/Haurdunaldi#Nerabezaroa

Still need to figure out a way to make them multilingual.

-- 
James Heilman
MD, CCFP-EM, Wikipedian
___
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/Z7ODLVNH7BXP5RR4L4O2KSVOB4YUN35D/
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

[Daniel Mui]

I would agree that no mention in the OKR would be quite disturbing...
However the 2024 report is NOT out yet, these are draft issues and I would
not make judgement until the full report is ready, which i believe to be
april.


--
Dear All,

I understand the frustration around the lack of progress on interactive
content and the discontinuation of the Graph extension. However, I'd like
to point out a few things.

First, the response from staff members reaching out to editors for their
opinions was remarkably quick. This type of response is not common, and
Wikipedia is unique in its hands-on approach to issues like this, it is
something to be proud of and also something that takes time.

Second, the Graph tool is being overhauled rather than patched. This is a
significant undertaking that will bring all our tools into the modern age,
making them more accessible and removing the underlying vulnerabilities
that led to the current situation in the first place, it will also ensure
the tool is up-to-date in terms of UX through things like codex and other
modern improvements that long term will allow more users to create graphs
which hopefully will keep it a priority to maintain, again thinking long
term here.

I know that this is taking time, but I believe that developing a robust and
sustainable solution is the best approach. Doing it this way rather than
delaying it for another six months is something I'd rather have and I'd
like to thank the hard working wikimedia team for that.

Thanks,
Daniel

On Tue, Mar 26, 2024 at 8:03 PM Galder Gonzalez Larrañaga <
galder...@hotmail.com> wrote:

> Dear all,
> Soon it will be a year since the Graph extension is disabled in all wikis.
> Meanwhile, we have been discussing about interactive content here and
> there, and there have been some promises about changes in the platform so
> these changes are possible in the future.
>
> Today the draft of the Key Results for the 2024-2025 annual plan was
> published and there's no single mention to this, nor to improving the
> multimedia experience. The disconnection between the needs and the plans is
> so evident, that I don't really know why we even bother discussing. You can
> see the Key Results here:
>  
> https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2024-2025/Product_%26_Technology_OKRs
> <https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2024-2025/Product_%26_Technology_OKRs>
> .
>
> This is extremely disappointing.
>
> Best,
> Galder
>
> --
> *From:* Samuel Klein 
> *Sent:* Saturday, March 23, 2024 3:37 PM
> *To:* Wikimedia Mailing List 
> *Subject:* [Wikimedia-l] Re: We need more interactive content: we are
> doing it wrong
>
> Beautiful. Thank you Felipe!!
>
> 
>
> On Sat, Mar 23, 2024, 5:54 AM Felipe Schenone  wrote:
>
> Hi Galder, I just did this fix
> <https://eu.wikipedia.org/w/index.php?title=MediaWiki:Gadgets-definition=prev=9637458>
>  and
> your Vivarium seems to be working now. The documentation was ok, but a bit
> confusing, so I improved it too. Soon I'll send a patch to make those
> "special categories" unnecessary. In the meantime, they're a necessary
> annoyance, I'm afraid. Cheers!
>
> On Sat, Mar 23, 2024 at 5:37 AM Galder Gonzalez Larrañaga <
> galder...@hotmail.com> wrote:
>
> Thanks Felipe, that's a really great move. I looked to these examples a
> couple o years ago, and this seems that a good option to add some
> interactive content. Anyway, I have tried to replicate it and can't make it
> work (https://eu.wikipedia.org/wiki/Txantiloi:Vivarium). Is the
> documentation right?
>
> Best
>
> Galder
> ------
> *From:* Felipe Schenone 
> *Sent:* Friday, March 22, 2024 10:39 PM
> *To:* Wikimedia Mailing List 
> *Subject:* [Wikimedia-l] Re: We need more interactive content: we are
> doing it wrong
>
> Hi everyone, good news!
>
> Thanks to this humble change
> <https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Gadgets/+/1005092> 
> (deployed
> today) it is now possible to load a specific gadget when a specific
> template is used in a page. This opens the door (or perhaps a window?) to
> interactive content using JavaScript. See for example this article in the
> Spanish Wikipedia <https://es.wikipedia.org/wiki/Juego_de_la_vida> for an
> interactive instance of Conway's Game of Life, and scroll down for more
> instances!
>
> I started documenting the system at MediaWiki.org, under the title template
> gadgets <https://www.mediawiki.org/wiki/Template_gadgets>, and included
> many working examples. Check it out!
>
> Perhaps the system isn't as friendly or powerful a solution as some might
> hope. But it's ve

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

[Galder Gonzalez Larrañaga]

Dear all,
Soon it will be a year since the Graph extension is disabled in all wikis. 
Meanwhile, we have been discussing about interactive content here and there, 
and there have been some promises about changes in the platform so these 
changes are possible in the future.

Today the draft of the Key Results for the 2024-2025 annual plan was published 
and there's no single mention to this, nor to improving the multimedia 
experience. The disconnection between the needs and the plans is so evident, 
that I don't really know why we even bother discussing. You can see the Key 
Results here: 
https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2024-2025/Product_%26_Technology_OKRs<https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2024-2025/Product_%26_Technology_OKRs>.

This is extremely disappointing.

Best,
Galder


From: Samuel Klein 
Sent: Saturday, March 23, 2024 3:37 PM
To: Wikimedia Mailing List 
Subject: [Wikimedia-l] Re: We need more interactive content: we are doing it 
wrong

Beautiful. Thank you Felipe!!



On Sat, Mar 23, 2024, 5:54 AM Felipe Schenone 
mailto:scheno...@gmail.com>> wrote:
Hi Galder, I just did this 
fix<https://eu.wikipedia.org/w/index.php?title=MediaWiki:Gadgets-definition=prev=9637458>
 and your Vivarium seems to be working now. The documentation was ok, but a bit 
confusing, so I improved it too. Soon I'll send a patch to make those "special 
categories" unnecessary. In the meantime, they're a necessary annoyance, I'm 
afraid. Cheers!

On Sat, Mar 23, 2024 at 5:37 AM Galder Gonzalez Larrañaga 
mailto:galder...@hotmail.com>> wrote:
Thanks Felipe, that's a really great move. I looked to these examples a couple 
o years ago, and this seems that a good option to add some interactive content. 
Anyway, I have tried to replicate it and can't make it work 
(https://eu.wikipedia.org/wiki/Txantiloi:Vivarium). Is the documentation right?

Best

Galder

From: Felipe Schenone mailto:scheno...@gmail.com>>
Sent: Friday, March 22, 2024 10:39 PM
To: Wikimedia Mailing List 
mailto:wikimedia-l@lists.wikimedia.org>>
Subject: [Wikimedia-l] Re: We need more interactive content: we are doing it 
wrong

Hi everyone, good news!

Thanks to this humble 
change<https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Gadgets/+/1005092> 
(deployed today) it is now possible to load a specific gadget when a specific 
template is used in a page. This opens the door (or perhaps a window?) to 
interactive content using JavaScript. See for example this article in the 
Spanish Wikipedia<https://es.wikipedia.org/wiki/Juego_de_la_vida> for an 
interactive instance of Conway's Game of Life, and scroll down for more 
instances!

I started documenting the system at MediaWiki.org, under the title template 
gadgets<https://www.mediawiki.org/wiki/Template_gadgets>, and included many 
working examples. Check it out!

Perhaps the system isn't as friendly or powerful a solution as some might hope. 
But it's very real, and it only depends on us now. Next week, when the 
documentation and examples are a bit more cooked, I'll propose adding a few 
"template gadgets" to the English Wikipedia, since my experience has taught me 
that when something hits the English Wikipedia, it quickly spreads elsewhere. 
I'll link to the proposal when I do, in case you want to participate.

There's so much more that could be said about this, but I'd rather keep it 
short. If you have questions or ideas, feel free to write them here or at the 
relevant talk page<https://www.mediawiki.org/wiki/Talk:Template_gadgets>.

Kind regards,
Felipe (User:Sophivorus)

On Thu, Feb 8, 2024 at 5:31 AM danboy12342 Mui 
mailto:danboy12...@gmail.com>> wrote:
Hi everyone,

I agree that Wikipedia needs to spend a few quarters spending time on our main 
product. The website is very impressively still the top result of a huge number 
of searches and in this new AI age; despite the controversy around it, 
wikipedia is the top source for many LLMs. Therefore while it doesn't need to 
be the only focus or even *the* focus most of the time it does need to be kept 
working but not just kept as is, it needs to be innovative and continue to meet 
the growing demands of a "modern" and "useable" site that allow users to get 
the information they need as fast and effectively as possible, these days that 
means interactivity.

I feel I'm repeating others but a quick burst of very serious investment into 
the site and its many sister pages needs to happen sooner rather than later.
Finally I'd like to thank Marshall again for his remarkable comments. It's good 
to see that this issue is clearly a priority that foundation staff are already 
looking at.

- Daniel.

-



On Wed, Feb 7, 2024, 09:17 Gnangarra 
mailto:gnanga...@gmail.com>> wrote:
Hi

I just like

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

[Samuel Klein]

Beautiful. Thank you Felipe!!



On Sat, Mar 23, 2024, 5:54 AM Felipe Schenone  wrote:

> Hi Galder, I just did this fix
> <https://eu.wikipedia.org/w/index.php?title=MediaWiki:Gadgets-definition=prev=9637458>
>  and
> your Vivarium seems to be working now. The documentation was ok, but a bit
> confusing, so I improved it too. Soon I'll send a patch to make those
> "special categories" unnecessary. In the meantime, they're a necessary
> annoyance, I'm afraid. Cheers!
>
> On Sat, Mar 23, 2024 at 5:37 AM Galder Gonzalez Larrañaga <
> galder...@hotmail.com> wrote:
>
>> Thanks Felipe, that's a really great move. I looked to these examples a
>> couple o years ago, and this seems that a good option to add some
>> interactive content. Anyway, I have tried to replicate it and can't make it
>> work (https://eu.wikipedia.org/wiki/Txantiloi:Vivarium). Is the
>> documentation right?
>>
>> Best
>>
>> Galder
>> --
>> *From:* Felipe Schenone 
>> *Sent:* Friday, March 22, 2024 10:39 PM
>> *To:* Wikimedia Mailing List 
>> *Subject:* [Wikimedia-l] Re: We need more interactive content: we are
>> doing it wrong
>>
>> Hi everyone, good news!
>>
>> Thanks to this humble change
>> <https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Gadgets/+/1005092> 
>> (deployed
>> today) it is now possible to load a specific gadget when a specific
>> template is used in a page. This opens the door (or perhaps a window?) to
>> interactive content using JavaScript. See for example this article in
>> the Spanish Wikipedia <https://es.wikipedia.org/wiki/Juego_de_la_vida> for
>> an interactive instance of Conway's Game of Life, and scroll down for more
>> instances!
>>
>> I started documenting the system at MediaWiki.org, under the title template
>> gadgets <https://www.mediawiki.org/wiki/Template_gadgets>, and included
>> many working examples. Check it out!
>>
>> Perhaps the system isn't as friendly or powerful a solution as some might
>> hope. But it's very real, and it only depends on us now. Next week, when
>> the documentation and examples are a bit more cooked, I'll propose adding a
>> few "template gadgets" to the English Wikipedia, since my experience has
>> taught me that when something hits the English Wikipedia, it quickly
>> spreads elsewhere. I'll link to the proposal when I do, in case you want to
>> participate.
>>
>> There's so much more that could be said about this, but I'd rather keep
>> it short. If you have questions or ideas, feel free to write them here or
>> at the relevant talk page
>> <https://www.mediawiki.org/wiki/Talk:Template_gadgets>.
>>
>> Kind regards,
>> Felipe (User:Sophivorus)
>>
>> On Thu, Feb 8, 2024 at 5:31 AM danboy12342 Mui 
>> wrote:
>>
>> Hi everyone,
>>
>> I agree that Wikipedia needs to spend a few quarters spending time on our
>> main product. The website is very impressively still the top result of a
>> huge number of searches and in this new AI age; despite the controversy
>> around it, wikipedia is the top source for many LLMs. Therefore while it
>> doesn't need to be the only focus or even *the* focus most of the time
>> it does need to be kept working but not just kept as is, it needs to be
>> innovative and continue to meet the growing demands of a "modern" and
>> "useable" site that allow users to get the information they need as fast
>> and effectively as possible, these days that means interactivity.
>>
>> I feel I'm repeating others but a quick burst of very serious investment
>> into the site and its many sister pages needs to happen sooner rather than
>> later.
>> Finally I'd like to thank Marshall again for his remarkable comments.
>> It's good to see that this issue is clearly a priority that foundation
>> staff are already looking at.
>>
>> - Daniel.
>>
>> -
>>
>>
>>
>> On Wed, Feb 7, 2024, 09:17 Gnangarra  wrote:
>>
>> Hi
>>
>> I just like to highlight one point, that raises concerns;
>>
>>
>> perhaps enabling other platforms/apps to use our content to make
>> interactive or video materials there.
>>
>>
>> While this sounds like an easy solution we run into a number of hidden
>> costs.  These are significant when we push for reusers to present what we
>> are doing in better ways we lose the movement's revenue stream as less
>> people see our donation banners.  With less direct traff

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

[Felipe Schenone]

Hi Galder, I just did this fix
<https://eu.wikipedia.org/w/index.php?title=MediaWiki:Gadgets-definition=prev=9637458>
and
your Vivarium seems to be working now. The documentation was ok, but a bit
confusing, so I improved it too. Soon I'll send a patch to make those
"special categories" unnecessary. In the meantime, they're a necessary
annoyance, I'm afraid. Cheers!

On Sat, Mar 23, 2024 at 5:37 AM Galder Gonzalez Larrañaga <
galder...@hotmail.com> wrote:

> Thanks Felipe, that's a really great move. I looked to these examples a
> couple o years ago, and this seems that a good option to add some
> interactive content. Anyway, I have tried to replicate it and can't make it
> work (https://eu.wikipedia.org/wiki/Txantiloi:Vivarium). Is the
> documentation right?
>
> Best
>
> Galder
> --
> *From:* Felipe Schenone 
> *Sent:* Friday, March 22, 2024 10:39 PM
> *To:* Wikimedia Mailing List 
> *Subject:* [Wikimedia-l] Re: We need more interactive content: we are
> doing it wrong
>
> Hi everyone, good news!
>
> Thanks to this humble change
> <https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Gadgets/+/1005092> 
> (deployed
> today) it is now possible to load a specific gadget when a specific
> template is used in a page. This opens the door (or perhaps a window?) to
> interactive content using JavaScript. See for example this article in the
> Spanish Wikipedia <https://es.wikipedia.org/wiki/Juego_de_la_vida> for an
> interactive instance of Conway's Game of Life, and scroll down for more
> instances!
>
> I started documenting the system at MediaWiki.org, under the title template
> gadgets <https://www.mediawiki.org/wiki/Template_gadgets>, and included
> many working examples. Check it out!
>
> Perhaps the system isn't as friendly or powerful a solution as some might
> hope. But it's very real, and it only depends on us now. Next week, when
> the documentation and examples are a bit more cooked, I'll propose adding a
> few "template gadgets" to the English Wikipedia, since my experience has
> taught me that when something hits the English Wikipedia, it quickly
> spreads elsewhere. I'll link to the proposal when I do, in case you want to
> participate.
>
> There's so much more that could be said about this, but I'd rather keep it
> short. If you have questions or ideas, feel free to write them here or at the
> relevant talk page <https://www.mediawiki.org/wiki/Talk:Template_gadgets>.
>
> Kind regards,
> Felipe (User:Sophivorus)
>
> On Thu, Feb 8, 2024 at 5:31 AM danboy12342 Mui 
> wrote:
>
> Hi everyone,
>
> I agree that Wikipedia needs to spend a few quarters spending time on our
> main product. The website is very impressively still the top result of a
> huge number of searches and in this new AI age; despite the controversy
> around it, wikipedia is the top source for many LLMs. Therefore while it
> doesn't need to be the only focus or even *the* focus most of the time it
> does need to be kept working but not just kept as is, it needs to be
> innovative and continue to meet the growing demands of a "modern" and
> "useable" site that allow users to get the information they need as fast
> and effectively as possible, these days that means interactivity.
>
> I feel I'm repeating others but a quick burst of very serious investment
> into the site and its many sister pages needs to happen sooner rather than
> later.
> Finally I'd like to thank Marshall again for his remarkable comments. It's
> good to see that this issue is clearly a priority that foundation staff are
> already looking at.
>
> - Daniel.
>
> -
>
>
>
> On Wed, Feb 7, 2024, 09:17 Gnangarra  wrote:
>
> Hi
>
> I just like to highlight one point, that raises concerns;
>
>
> perhaps enabling other platforms/apps to use our content to make
> interactive or video materials there.
>
>
> While this sounds like an easy solution we run into a number of hidden
> costs.  These are significant when we push for reusers to present what we
> are doing in better ways we lose the movement's revenue stream as less
> people see our donation banners.  With less direct traffic we also
> sacrifice the ability to convert readers into contributors which has always
> been our primary source of community sustainability and growth.   I know
> other providers will find different ways to present our efforts in part or
> in whole that is part of our purpose, to do our mission and achieve our
> goals we need prioritise internal solutions.
>
> This also leads us to a related issue that our mission is to make the sum
> of all knowledge freely available. When we look to outs

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

[Galder Gonzalez Larrañaga]

Thanks Felipe, that's a really great move. I looked to these examples a couple 
o years ago, and this seems that a good option to add some interactive content. 
Anyway, I have tried to replicate it and can't make it work 
(https://eu.wikipedia.org/wiki/Txantiloi:Vivarium). Is the documentation right?

Best

Galder

From: Felipe Schenone 
Sent: Friday, March 22, 2024 10:39 PM
To: Wikimedia Mailing List 
Subject: [Wikimedia-l] Re: We need more interactive content: we are doing it 
wrong

Hi everyone, good news!

Thanks to this humble 
change<https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Gadgets/+/1005092> 
(deployed today) it is now possible to load a specific gadget when a specific 
template is used in a page. This opens the door (or perhaps a window?) to 
interactive content using JavaScript. See for example this article in the 
Spanish Wikipedia<https://es.wikipedia.org/wiki/Juego_de_la_vida> for an 
interactive instance of Conway's Game of Life, and scroll down for more 
instances!

I started documenting the system at MediaWiki.org, under the title template 
gadgets<https://www.mediawiki.org/wiki/Template_gadgets>, and included many 
working examples. Check it out!

Perhaps the system isn't as friendly or powerful a solution as some might hope. 
But it's very real, and it only depends on us now. Next week, when the 
documentation and examples are a bit more cooked, I'll propose adding a few 
"template gadgets" to the English Wikipedia, since my experience has taught me 
that when something hits the English Wikipedia, it quickly spreads elsewhere. 
I'll link to the proposal when I do, in case you want to participate.

There's so much more that could be said about this, but I'd rather keep it 
short. If you have questions or ideas, feel free to write them here or at the 
relevant talk page<https://www.mediawiki.org/wiki/Talk:Template_gadgets>.

Kind regards,
Felipe (User:Sophivorus)

On Thu, Feb 8, 2024 at 5:31 AM danboy12342 Mui 
mailto:danboy12...@gmail.com>> wrote:
Hi everyone,

I agree that Wikipedia needs to spend a few quarters spending time on our main 
product. The website is very impressively still the top result of a huge number 
of searches and in this new AI age; despite the controversy around it, 
wikipedia is the top source for many LLMs. Therefore while it doesn't need to 
be the only focus or even *the* focus most of the time it does need to be kept 
working but not just kept as is, it needs to be innovative and continue to meet 
the growing demands of a "modern" and "useable" site that allow users to get 
the information they need as fast and effectively as possible, these days that 
means interactivity.

I feel I'm repeating others but a quick burst of very serious investment into 
the site and its many sister pages needs to happen sooner rather than later.
Finally I'd like to thank Marshall again for his remarkable comments. It's good 
to see that this issue is clearly a priority that foundation staff are already 
looking at.

- Daniel.

-



On Wed, Feb 7, 2024, 09:17 Gnangarra 
mailto:gnanga...@gmail.com>> wrote:
Hi

I just like to highlight one point, that raises concerns;

perhaps enabling other platforms/apps to use our content to make interactive or 
video materials there.

While this sounds like an easy solution we run into a number of hidden costs.  
These are significant when we push for reusers to present what we are doing in 
better ways we lose the movement's revenue stream as less people see our 
donation banners.  With less direct traffic we also sacrifice the ability to 
convert readers into contributors which has always been our primary source of 
community sustainability and growth.   I know other providers will find 
different ways to present our efforts in part or in whole that is part of our 
purpose, to do our mission and achieve our goals we need prioritise internal 
solutions.

This also leads us to a related issue that our mission is to make the sum of 
all knowledge freely available. When we look to outside parties to share our 
efforts we lose our ability to ensure that the information is neutral, and that 
it's freely accessible.  Butch is right in noting that when we put funding into 
third party sites it is taking resources away from the movement, yet those same 
funds were donated to us on the basis of maintaining and building our 
infrastructure.  It would be a wise investment to enable some of those much 
needed interactive and video content here through purchasing rights.

On Wed, 7 Feb 2024 at 12:20, Butch Bustria 
mailto:bustr...@gmail.com>> wrote:
Hi Everyone,

My earnest hope that the Wikimedia Foundation on its 2024-2025 Annual Financial 
Plan prioritize and I mean put first among all is the technical infrastructure 
among all its budgetary items. We can scale down budgets to 3rd party 
organizations like the Knowl

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

[Felipe Schenone]

Hi everyone, good news!

Thanks to this humble change

(deployed
today) it is now possible to load a specific gadget when a specific
template is used in a page. This opens the door (or perhaps a window?) to
interactive content using JavaScript. See for example this article in the
Spanish Wikipedia  for an
interactive instance of Conway's Game of Life, and scroll down for more
instances!

I started documenting the system at MediaWiki.org, under the title template
gadgets , and included
many working examples. Check it out!

Perhaps the system isn't as friendly or powerful a solution as some might
hope. But it's very real, and it only depends on us now. Next week, when
the documentation and examples are a bit more cooked, I'll propose adding a
few "template gadgets" to the English Wikipedia, since my experience has
taught me that when something hits the English Wikipedia, it quickly
spreads elsewhere. I'll link to the proposal when I do, in case you want to
participate.

There's so much more that could be said about this, but I'd rather keep it
short. If you have questions or ideas, feel free to write them here or at the
relevant talk page .

Kind regards,
Felipe (User:Sophivorus)

On Thu, Feb 8, 2024 at 5:31 AM danboy12342 Mui 
wrote:

> Hi everyone,
>
> I agree that Wikipedia needs to spend a few quarters spending time on our
> main product. The website is very impressively still the top result of a
> huge number of searches and in this new AI age; despite the controversy
> around it, wikipedia is the top source for many LLMs. Therefore while it
> doesn't need to be the only focus or even *the* focus most of the time it
> does need to be kept working but not just kept as is, it needs to be
> innovative and continue to meet the growing demands of a "modern" and
> "useable" site that allow users to get the information they need as fast
> and effectively as possible, these days that means interactivity.
>
> I feel I'm repeating others but a quick burst of very serious investment
> into the site and its many sister pages needs to happen sooner rather than
> later.
> Finally I'd like to thank Marshall again for his remarkable comments. It's
> good to see that this issue is clearly a priority that foundation staff are
> already looking at.
>
> - Daniel.
>
> -
>
>
>
> On Wed, Feb 7, 2024, 09:17 Gnangarra  wrote:
>
>> Hi
>>
>> I just like to highlight one point, that raises concerns;
>>
>>
>> perhaps enabling other platforms/apps to use our content to make
>> interactive or video materials there.
>>
>>
>> While this sounds like an easy solution we run into a number of hidden
>> costs.  These are significant when we push for reusers to present what we
>> are doing in better ways we lose the movement's revenue stream as less
>> people see our donation banners.  With less direct traffic we also
>> sacrifice the ability to convert readers into contributors which has always
>> been our primary source of community sustainability and growth.   I know
>> other providers will find different ways to present our efforts in part or
>> in whole that is part of our purpose, to do our mission and achieve our
>> goals we need prioritise internal solutions.
>>
>> This also leads us to a related issue that our mission is to make the sum
>> of all knowledge freely available. When we look to outside parties to share
>> our efforts we lose our ability to ensure that the information is neutral,
>> and that it's freely accessible.  Butch is right in noting that when we put
>> funding into third party sites it is taking resources away from the
>> movement, yet those same funds were donated to us on the basis of
>> maintaining and building our infrastructure.  It would be a wise investment
>> to enable some of those much needed interactive and video content here
>> through purchasing rights.
>>
>> On Wed, 7 Feb 2024 at 12:20, Butch Bustria  wrote:
>>
>>> Hi Everyone,
>>>
>>> My earnest hope that the Wikimedia Foundation on its 2024-2025 Annual
>>> Financial Plan prioritize and I mean put first among all is the technical
>>> infrastructure among all its budgetary items. We can scale down budgets to
>>> 3rd party organizations like the Knowledge Equity Fund, Movement Strategy
>>> Governance funding, campaign grants, and other "wants" to accomodate a
>>> highly technically reliable and stable Wikimedia online projects ("needs"),
>>> future proof, and user friendly experience which require investments on
>>> quality manpower, hardware, applications and the like. We love open source
>>> but we also be pragmatic and wise on selection of choices because we want
>>> our content be conveniently available and reliable to our readers, users,
>>> consumers and also editors.
>>>
>>> A welcome development is the 

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

[Kimmo Virtanen]

Hi,

Just to note that wikivoyage (and Wikimedia Commons also) will lose some of
the features enabled for all users by default which are relying on third
party services when third-party resources policy currently under
discussions will be enforced for security reasons. This includes map tiles
loaded directly from third party sites. The idea of the policy is that the
site should not be loading scripts or data from third party sites without
explicit permission from the user because it leaks information privacy
point of view, but also it is an attack vector for malicious scripts.
- https://meta.wikimedia.org/wiki/Third-party_resources_policy

Br,
-- Kimmo Virtanen, Zache

On Sun, Feb 25, 2024 at 12:24 PM Galder Gonzalez Larrañaga <
galder...@hotmail.com> wrote:

> That is the point, James.
> We know that using graphs is possible within the current system, we know
> that adding OWID interactive content is possible, we know that adding
> interactive maps in Wikivoyage is possible, and we even have examples of
> using full color 3D models. I understand that these are not the only
> options for interactive content, and some other proposals (something like
> brilliant.com) are way more complex. But, at least, ''some''
> interactivity is currently possible.
>
> The problem is that Marshall says that adding interactive content is
> completely out of our possibilities, and we don't know if this is because
> there's no will nor plan to do it, or because it is extremely complex and
> expensive, as Gnangarra points out.
>
> But, in order to know if this is actually extremely complex and expensive,
> we need a roadmap. Marshall said that it is out of scope, but we don't know
> how than claim is backed. Because, as far as we know, there's not even a
> roadmap. So, the claim of the extreme complexity is not based on any actual
> idea of the process we need to achieve this. With no roadmap ahead,
> everything is completely impossible. If we never start walking, we surely
> won't move anywhere.
>
> Galder
> --
> *From:* James Heilman 
> *Sent:* Sunday, February 25, 2024 11:00 AM
> *To:* Wikimedia Mailing List 
> *Subject:* [Wikimedia-l] Re: We need more interactive content: we are
> doing it wrong
>
> But...
>
> We have managed to put maps into Wikivoyage that are interactive
> https://en.wikivoyage.org/wiki/Cranbrook They even have third party
> overlays for topography and other features.
>
> We at Wiki Project Med have added OWID interactive graphs to a mediawiki
> install of which thousands of visualizations are available
> https://mdwiki.org/wiki/WikiProjectMed:OWID#How_to_use
>
> And we did the latter with a few thousand in funding and a bunch of
> volunteer time. We need the will to do this and it could happen.
>
> James
>
> On Sat, Feb 24, 2024 at 10:41 PM Gnangarra  wrote:
>
> Thats a fair question, but its not a simple answer, nor something that can
> be properly assessed on short notice.  I think one of the first issues I
> see is that the underlying mediawiki coding would need to be completely
> overhauled to enable  full interactive architecture.  That it would need to
> be done in a way that enable ease of interaction for all contributors so
> that we dont lose a large portion of our existing community which itself is
> already struggling to maintain currently levels.   The next issue is
> bringing 25 years of accumulated content across to the new architecture
> while keeping all the history of that in place.
>
> I'd be more concerned if the WMF stumped up with a figure this quickly if
> they even understood the question even though its our whole foundation.
> There has never been any big picture architectural planning even the
> creation of WikiData infrastructure wasnt as big as this will need to be.
>  I know Marshall has just started asking questions about what people are
> envisioning the future to look like, I'd expect that the Hackathon and
> Wikimania will be where we start hearing more about what the future can
> look like and the steps that will need to take place to achieve that.
>
> Galder please keep on asking these questions, I suspect a lot of what we
> want is already being done by many different sites in a multitude of ways.
> We just need to identify our own needs and make sure that each step can be
> achieved without the negative impact that so many past changes have had.
> This will take a multi year commitment in both funding and support from the
> WMF and the Community the later of which is a lot harder to establish.
>
> On Fri, 23 Feb 2024 at 21:58, Galder Gonzalez Larrañaga <
> galder...@hotmail.com> wrote:
>
> Two weeks have passed since we last heard about the WMF explaining why
> they renounce to add interactive 

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

[Galder Gonzalez Larrañaga]

That is the point, James.
We know that using graphs is possible within the current system, we know that 
adding OWID interactive content is possible, we know that adding interactive 
maps in Wikivoyage is possible, and we even have examples of using full color 
3D models. I understand that these are not the only options for interactive 
content, and some other proposals (something like brilliant.com) are way more 
complex. But, at least, ''some'' interactivity is currently possible.

The problem is that Marshall says that adding interactive content is completely 
out of our possibilities, and we don't know if this is because there's no will 
nor plan to do it, or because it is extremely complex and expensive, as 
Gnangarra points out.

But, in order to know if this is actually extremely complex and expensive, we 
need a roadmap. Marshall said that it is out of scope, but we don't know how 
than claim is backed. Because, as far as we know, there's not even a roadmap. 
So, the claim of the extreme complexity is not based on any actual idea of the 
process we need to achieve this. With no roadmap ahead, everything is 
completely impossible. If we never start walking, we surely won't move anywhere.

Galder

From: James Heilman 
Sent: Sunday, February 25, 2024 11:00 AM
To: Wikimedia Mailing List 
Subject: [Wikimedia-l] Re: We need more interactive content: we are doing it 
wrong

But...

We have managed to put maps into Wikivoyage that are interactive 
https://en.wikivoyage.org/wiki/Cranbrook They even have third party overlays 
for topography and other features.

We at Wiki Project Med have added OWID interactive graphs to a mediawiki 
install of which thousands of visualizations are available 
https://mdwiki.org/wiki/WikiProjectMed:OWID#How_to_use

And we did the latter with a few thousand in funding and a bunch of volunteer 
time. We need the will to do this and it could happen.

James

On Sat, Feb 24, 2024 at 10:41 PM Gnangarra 
mailto:gnanga...@gmail.com>> wrote:
Thats a fair question, but its not a simple answer, nor something that can be 
properly assessed on short notice.  I think one of the first issues I see is 
that the underlying mediawiki coding would need to be completely overhauled to 
enable  full interactive architecture.  That it would need to be done in a way 
that enable ease of interaction for all contributors so that we dont lose a 
large portion of our existing community which itself is already struggling to 
maintain currently levels.   The next issue is bringing 25 years of accumulated 
content across to the new architecture while keeping all the history of that in 
place.

I'd be more concerned if the WMF stumped up with a figure this quickly if they 
even understood the question even though its our whole foundation. There has 
never been any big picture architectural planning even the creation of WikiData 
infrastructure wasnt as big as this will need to be.   I know Marshall has just 
started asking questions about what people are envisioning the future to look 
like, I'd expect that the Hackathon and Wikimania will be where we start 
hearing more about what the future can look like and the steps that will need 
to take place to achieve that.

Galder please keep on asking these questions, I suspect a lot of what we want 
is already being done by many different sites in a multitude of ways. We just 
need to identify our own needs and make sure that each step can be achieved 
without the negative impact that so many past changes have had. This will take 
a multi year commitment in both funding and support from the WMF and the 
Community the later of which is a lot harder to establish.

On Fri, 23 Feb 2024 at 21:58, Galder Gonzalez Larrañaga 
mailto:galder...@hotmail.com>> wrote:
Two weeks have passed since we last heard about the WMF explaining why they 
renounce to add interactive content and infrastructure, and the question 
remains unanswered: how much would it cost this so it can't be done?

I really hope to have an answer, as we could know if what it is needed is 
totally out of scope, or is something that could be payed for.

Thanks

Galder

From: Galder Gonzalez Larrañaga 
mailto:galder...@hotmail.com>>
Sent: Wednesday, February 7, 2024 9:09 AM
To: Wikimedia Mailing List 
mailto:wikimedia-l@lists.wikimedia.org>>
Subject: Re: [Wikimedia-l] Re: We need more interactive content: we are doing 
it wrong

Thanks Marshall for your pointing out an official answer from the WMF,
Let me say that this is not only disappointing, you are also presenting a false 
dichotomy where we can only "save a kitten" OR "plant a tree", while we have 
budget, staff and enough talented volunteers to do both. The dichotomy is 
presented in a way that makes us think that an estimation of the cost of 
solving this problem has been done and it is out of all the possibilities, but 
we don't know wh

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

[James Heilman]

But...

We have managed to put maps into Wikivoyage that are interactive
https://en.wikivoyage.org/wiki/Cranbrook They even have third party
overlays for topography and other features.

We at Wiki Project Med have added OWID interactive graphs to a mediawiki
install of which thousands of visualizations are available
https://mdwiki.org/wiki/WikiProjectMed:OWID#How_to_use

And we did the latter with a few thousand in funding and a bunch of
volunteer time. We need the will to do this and it could happen.

James

On Sat, Feb 24, 2024 at 10:41 PM Gnangarra  wrote:

> Thats a fair question, but its not a simple answer, nor something that can
> be properly assessed on short notice.  I think one of the first issues I
> see is that the underlying mediawiki coding would need to be completely
> overhauled to enable  full interactive architecture.  That it would need to
> be done in a way that enable ease of interaction for all contributors so
> that we dont lose a large portion of our existing community which itself is
> already struggling to maintain currently levels.   The next issue is
> bringing 25 years of accumulated content across to the new architecture
> while keeping all the history of that in place.
>
> I'd be more concerned if the WMF stumped up with a figure this quickly if
> they even understood the question even though its our whole foundation.
> There has never been any big picture architectural planning even the
> creation of WikiData infrastructure wasnt as big as this will need to be.
>  I know Marshall has just started asking questions about what people are
> envisioning the future to look like, I'd expect that the Hackathon and
> Wikimania will be where we start hearing more about what the future can
> look like and the steps that will need to take place to achieve that.
>
> Galder please keep on asking these questions, I suspect a lot of what we
> want is already being done by many different sites in a multitude of ways.
> We just need to identify our own needs and make sure that each step can be
> achieved without the negative impact that so many past changes have had.
> This will take a multi year commitment in both funding and support from the
> WMF and the Community the later of which is a lot harder to establish.
>
> On Fri, 23 Feb 2024 at 21:58, Galder Gonzalez Larrañaga <
> galder...@hotmail.com> wrote:
>
>> Two weeks have passed since we last heard about the WMF explaining why
>> they renounce to add interactive content and infrastructure, and the
>> question remains unanswered: how much would it cost this so it can't be
>> done?
>>
>> I really hope to have an answer, as we could know if what it is needed is
>> totally out of scope, or is something that could be payed for.
>>
>> Thanks
>>
>> Galder
>> ------------------
>> *From:* Galder Gonzalez Larrañaga 
>> *Sent:* Wednesday, February 7, 2024 9:09 AM
>> *To:* Wikimedia Mailing List 
>> *Subject:* Re: [Wikimedia-l] Re: We need more interactive content: we
>> are doing it wrong
>>
>> Thanks Marshall for your pointing out an official answer from the WMF,
>> Let me say that this is not only disappointing, you are also presenting a
>> false dichotomy where we can only "save a kitten" OR "plant a tree", while
>> we have budget, staff and enough talented volunteers to do both. The
>> dichotomy is presented in a way that makes us think that an estimation of
>> the cost of solving this problem has been done and it is out of all the
>> possibilities, but we don't know what the estimation is. Is there an
>> estimation of how much would this cost? If so, could you please share it so
>> we know why this is out of our possibilities?
>>
>> I say that this dichotomy is false and I will try to explain why:
>>
>>- When Maryana Iskander assumed her CEO role, she pointed that the
>>way the annual plan is done should be changed, because the previous
>>monolithic assumption that only things reflected in the annual plan can be
>>done (and nothing else) was preventing us from going forward. You can read
>>it the full reflection here:
>>
>> https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Chief_Executive_Officer/Maryana%E2%80%99s_Listening_Tour/My_Incoming_Priorities.
>>Claiming that a high priority problem can't be solved now because it 
>> wasn't
>>planned one year ago is not the way it was supposed this to be done.
>>- The message is not about the Graphs extension. It has some weight
>>there, but reading this message about interactive content in terms of "if
>>we solve the graphs issue, our job here is done" is also a wr

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

[Gnangarra]

Thats a fair question, but its not a simple answer, nor something that can
be properly assessed on short notice.  I think one of the first issues I
see is that the underlying mediawiki coding would need to be completely
overhauled to enable  full interactive architecture.  That it would need to
be done in a way that enable ease of interaction for all contributors so
that we dont lose a large portion of our existing community which itself is
already struggling to maintain currently levels.   The next issue is
bringing 25 years of accumulated content across to the new architecture
while keeping all the history of that in place.

I'd be more concerned if the WMF stumped up with a figure this quickly if
they even understood the question even though its our whole foundation.
There has never been any big picture architectural planning even the
creation of WikiData infrastructure wasnt as big as this will need to be.
 I know Marshall has just started asking questions about what people are
envisioning the future to look like, I'd expect that the Hackathon and
Wikimania will be where we start hearing more about what the future can
look like and the steps that will need to take place to achieve that.

Galder please keep on asking these questions, I suspect a lot of what we
want is already being done by many different sites in a multitude of ways.
We just need to identify our own needs and make sure that each step can be
achieved without the negative impact that so many past changes have had.
This will take a multi year commitment in both funding and support from the
WMF and the Community the later of which is a lot harder to establish.

On Fri, 23 Feb 2024 at 21:58, Galder Gonzalez Larrañaga <
galder...@hotmail.com> wrote:

> Two weeks have passed since we last heard about the WMF explaining why
> they renounce to add interactive content and infrastructure, and the
> question remains unanswered: how much would it cost this so it can't be
> done?
>
> I really hope to have an answer, as we could know if what it is needed is
> totally out of scope, or is something that could be payed for.
>
> Thanks
>
> Galder
> --
> *From:* Galder Gonzalez Larrañaga 
> *Sent:* Wednesday, February 7, 2024 9:09 AM
> *To:* Wikimedia Mailing List 
> *Subject:* Re: [Wikimedia-l] Re: We need more interactive content: we are
> doing it wrong
>
> Thanks Marshall for your pointing out an official answer from the WMF,
> Let me say that this is not only disappointing, you are also presenting a
> false dichotomy where we can only "save a kitten" OR "plant a tree", while
> we have budget, staff and enough talented volunteers to do both. The
> dichotomy is presented in a way that makes us think that an estimation of
> the cost of solving this problem has been done and it is out of all the
> possibilities, but we don't know what the estimation is. Is there an
> estimation of how much would this cost? If so, could you please share it so
> we know why this is out of our possibilities?
>
> I say that this dichotomy is false and I will try to explain why:
>
>- When Maryana Iskander assumed her CEO role, she pointed that the way
>the annual plan is done should be changed, because the previous monolithic
>assumption that only things reflected in the annual plan can be done (and
>nothing else) was preventing us from going forward. You can read it the
>full reflection here:
>
> https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Chief_Executive_Officer/Maryana%E2%80%99s_Listening_Tour/My_Incoming_Priorities.
>Claiming that a high priority problem can't be solved now because it wasn't
>planned one year ago is not the way it was supposed this to be done.
>- The message is not about the Graphs extension. It has some weight
>there, but reading this message about interactive content in terms of "if
>we solve the graphs issue, our job here is done" is also a wrong reduction.
>But let's think that, indeed, this was the only problem we should solve.
>Arguing that it is not in the Annual plan so it can't be solved is a
>fallacy, as explained above, but even then, the annual plan was done AFTER
>the graph extension was broken. Waiting two years for a high importance
>problem to be solved can't be the way to do things.
>- Two weeks after Iskander's message, Yael Weissburg wrote in Diff
>this post:
> 
> https://diff.wikimedia.org/2022/01/28/what-does-the-world-need-from-us-now-external-trends-to-watch/
>
> <https://diff.wikimedia.org/2022/01/28/what-does-the-world-need-from-us-now-external-trends-to-watch/>.
>In this post Weissburg wrote about "trends that we should expect to
>accelerate in the years to come because they relate to key changes

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

[Galder Gonzalez Larrañaga]

Two weeks have passed since we last heard about the WMF explaining why they 
renounce to add interactive content and infrastructure, and the question 
remains unanswered: how much would it cost this so it can't be done?

I really hope to have an answer, as we could know if what it is needed is 
totally out of scope, or is something that could be payed for.

Thanks

Galder

From: Galder Gonzalez Larrañaga 
Sent: Wednesday, February 7, 2024 9:09 AM
To: Wikimedia Mailing List 
Subject: Re: [Wikimedia-l] Re: We need more interactive content: we are doing 
it wrong

Thanks Marshall for your pointing out an official answer from the WMF,
Let me say that this is not only disappointing, you are also presenting a false 
dichotomy where we can only "save a kitten" OR "plant a tree", while we have 
budget, staff and enough talented volunteers to do both. The dichotomy is 
presented in a way that makes us think that an estimation of the cost of 
solving this problem has been done and it is out of all the possibilities, but 
we don't know what the estimation is. Is there an estimation of how much would 
this cost? If so, could you please share it so we know why this is out of our 
possibilities?

I say that this dichotomy is false and I will try to explain why:

  *   When Maryana Iskander assumed her CEO role, she pointed that the way the 
annual plan is done should be changed, because the previous monolithic 
assumption that only things reflected in the annual plan can be done (and 
nothing else) was preventing us from going forward. You can read it the full 
reflection 
here:https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Chief_Executive_Officer/Maryana%E2%80%99s_Listening_Tour/My_Incoming_Priorities.
 Claiming that a high priority problem can't be solved now because it wasn't 
planned one year ago is not the way it was supposed this to be done.
  *
The message is not about the Graphs extension. It has some weight there, but 
reading this message about interactive content in terms of "if we solve the 
graphs issue, our job here is done" is also a wrong reduction. But let's think 
that, indeed, this was the only problem we should solve. Arguing that it is not 
in the Annual plan so it can't be solved is a fallacy, as explained above, but 
even then, the annual plan was done AFTER the graph extension was broken. 
Waiting two years for a high importance problem to be solved can't be the way 
to do things.
  *
Two weeks after Iskander's message, Yael Weissburg wrote in Diff this post: 
https://diff.wikimedia.org/2022/01/28/what-does-the-world-need-from-us-now-external-trends-to-watch/<https://diff.wikimedia.org/2022/01/28/what-does-the-world-need-from-us-now-external-trends-to-watch/>.
 In this post Weissburg wrote about "trends that we should expect to accelerate 
in the years to come because they relate to key changes in how people access, 
interact with, and share knowledge". You can read the post by yourself, but 
there is an important takeaway: people is searching for content in another way, 
and we should give them "rich content". Whatever it takes.
  *
One year after Iskander assumed she wrote an update. There we can read that the 
number 2 priority is "Re-centering the Foundation's responsibility in 
supporting the technology needs of the Wikimedia movement by understanding the 
needs of our contributor communities, as well as emerging topics like machine 
learning/artificial intelligence and innovations for new audiences." We should 
be doing that "innovations for new audiences", but from you message it seems 
that we still need "a conversation to happen" 
https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Chief_Executive_Officer/Updates/Year_One_Update
  *
Later that year, Selena Deckelmann wrote that "The Foundation needs to exhibit 
better accountability in maintaining essential services (e.g. 2-factor 
authentication), and to be explicit about the technical tasks that it is 
definitely leaving for volunteers to own." 
(https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Executive_and_Leadership_teams/Chief_Product_and_Technology_Officer/Selena%27s_Listening_Tour).
 Yes, I understand that the example given is another one, but the idea is 
there: "the foundation needs to exhibit better accountability in maintaining 
essential services". The message follows with an elephant in the room, but we 
are not going to talk again about the elephant, for sure.
  *   Finally, last two years annual plans were said to be rooted in the 2030 
Strategy (which talks about this issue) and, more specifically, on the 2019 
Medium Term 
plan.https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Medium-term_plan_2019.
 This Medium Term plan (which, again, is the one used as a roadmap) has only 
two high priority topics, the second one being: "2. Modernize our product 
experien

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

[danboy12342 Mui]

Hi everyone,

I agree that Wikipedia needs to spend a few quarters spending time on our
main product. The website is very impressively still the top result of a
huge number of searches and in this new AI age; despite the controversy
around it, wikipedia is the top source for many LLMs. Therefore while it
doesn't need to be the only focus or even *the* focus most of the time it
does need to be kept working but not just kept as is, it needs to be
innovative and continue to meet the growing demands of a "modern" and
"useable" site that allow users to get the information they need as fast
and effectively as possible, these days that means interactivity.

I feel I'm repeating others but a quick burst of very serious investment
into the site and its many sister pages needs to happen sooner rather than
later.
Finally I'd like to thank Marshall again for his remarkable comments. It's
good to see that this issue is clearly a priority that foundation staff are
already looking at.

- Daniel.

-



On Wed, Feb 7, 2024, 09:17 Gnangarra  wrote:

> Hi
>
> I just like to highlight one point, that raises concerns;
>
>
> perhaps enabling other platforms/apps to use our content to make
> interactive or video materials there.
>
>
> While this sounds like an easy solution we run into a number of hidden
> costs.  These are significant when we push for reusers to present what we
> are doing in better ways we lose the movement's revenue stream as less
> people see our donation banners.  With less direct traffic we also
> sacrifice the ability to convert readers into contributors which has always
> been our primary source of community sustainability and growth.   I know
> other providers will find different ways to present our efforts in part or
> in whole that is part of our purpose, to do our mission and achieve our
> goals we need prioritise internal solutions.
>
> This also leads us to a related issue that our mission is to make the sum
> of all knowledge freely available. When we look to outside parties to share
> our efforts we lose our ability to ensure that the information is neutral,
> and that it's freely accessible.  Butch is right in noting that when we put
> funding into third party sites it is taking resources away from the
> movement, yet those same funds were donated to us on the basis of
> maintaining and building our infrastructure.  It would be a wise investment
> to enable some of those much needed interactive and video content here
> through purchasing rights.
>
> On Wed, 7 Feb 2024 at 12:20, Butch Bustria  wrote:
>
>> Hi Everyone,
>>
>> My earnest hope that the Wikimedia Foundation on its 2024-2025 Annual
>> Financial Plan prioritize and I mean put first among all is the technical
>> infrastructure among all its budgetary items. We can scale down budgets to
>> 3rd party organizations like the Knowledge Equity Fund, Movement Strategy
>> Governance funding, campaign grants, and other "wants" to accomodate a
>> highly technically reliable and stable Wikimedia online projects ("needs"),
>> future proof, and user friendly experience which require investments on
>> quality manpower, hardware, applications and the like. We love open source
>> but we also be pragmatic and wise on selection of choices because we want
>> our content be conveniently available and reliable to our readers, users,
>> consumers and also editors.
>>
>> A welcome development is the MediaWiki Users and Developers Conference,
>> the successor to EMWCon.
>>
>> https://www.mediawiki.org/wiki/MediaWiki_Users_and_Developers_Conference_2024
>>
>> The said conference will be held in Portland, Oregon, from April 17–19,
>> 2024.
>>
>> I also hope the Foundation invest in more technical gatherings, both
>> onsite, hybrid or online to engage and reach out to more technical
>> contributors, within and beyond the Wikimedia movement. I also hope WMF to
>> start exploring eastward to Asia or elsewhere in the world as well fully
>> diversify the technical community.
>>
>>
>>
>> Kind regards,
>>
>> *Butch Bustria*
>>
>>
>>
>>
>> On Wed, Feb 7, 2024, 4:54 AM Brion Vibber  wrote:
>>
>>> Thanks for weighing in, Marshall!
>>>
>>> I agree wholeheartedly that we need to do a proper architecture for a
>>> sandbox for interactive media, that will be safe (first and foremost),
>>> perform well in the browser, work across device types (desktop web, mobile
>>> web, mobile apps), and maintain our key requirements on editability and
>>> reusability, balanced against the security and privacy needs of users if
>>> we're going to invest the effort.
>>>
>>> Backing up to do it right rather than patch up Graphs “one more time” is
>>> the right thing, and I’m very happy to see a confluence of interest around
>>> this now!
>>>
>>> My hope is we can figure out how to make that architecture & testing
>>> work happen in the near term until we collectively (inside WMF and out) can
>>> wrangle resources to make the implementation production-ready.
>>>
>>> Once we 

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

[Ashwin Baindur]

I agree with Butch Bustria.

Considering that the WMF is not short of funds, and there appears to be
adequate funds to establish fund deposits outside WMF and fund third party
organisations not directly involved in the core vision of the Movement,
i.e. to make the sum of human knowledge available to all (paraphrasing
here), it is hard to understand how funds are a constraint as one
understands by the lead of the Product Team.

Without delivery of the most modern and highest quality content, all other
activities such as Movement strategy, offline activities etc are
meaningless activity that can be done away with.

There is urgent need for a vision that gives primacy to the platform, it's
capabilities and tools to support those that make the content. If it
requires substantial investment and time, so be it, but at present there
seems to be no sign on ground that the infrastructure is being improved us
a substantial rewrite or major upgrade.

The activities mentioned by the Products lead are reasonably important but
they are just isolated disjunct things while the creaking infrastructure
isn't addressed as a whole.

I hope this changes in the near future and we get the strong framework that
will enable graphs, video, interactivity, accessibility and all modern
features of the future.

AshLin

On Wed, 7 Feb 2024, 09:50 Butch Bustria,  wrote:

> Hi Everyone,
>
> My earnest hope that the Wikimedia Foundation on its 2024-2025 Annual
> Financial Plan prioritize and I mean put first among all is the technical
> infrastructure among all its budgetary items. We can scale down budgets to
> 3rd party organizations like the Knowledge Equity Fund, Movement Strategy
> Governance funding, campaign grants, and other "wants" to accomodate a
> highly technically reliable and stable Wikimedia online projects ("needs"),
> future proof, and user friendly experience which require investments on
> quality manpower, hardware, applications and the like. We love open source
> but we also be pragmatic and wise on selection of choices because we want
> our content be conveniently available and reliable to our readers, users,
> consumers and also editors.
>
> A welcome development is the MediaWiki Users and Developers Conference,
> the successor to EMWCon.
>
> https://www.mediawiki.org/wiki/MediaWiki_Users_and_Developers_Conference_2024
>
> The said conference will be held in Portland, Oregon, from April 17–19,
> 2024.
>
> I also hope the Foundation invest in more technical gatherings, both
> onsite, hybrid or online to engage and reach out to more technical
> contributors, within and beyond the Wikimedia movement. I also hope WMF to
> start exploring eastward to Asia or elsewhere in the world as well fully
> diversify the technical community.
>
>
>
> Kind regards,
>
> *Butch Bustria*
>
>
>
>
> On Wed, Feb 7, 2024, 4:54 AM Brion Vibber  wrote:
>
>> Thanks for weighing in, Marshall!
>>
>> I agree wholeheartedly that we need to do a proper architecture for a
>> sandbox for interactive media, that will be safe (first and foremost),
>> perform well in the browser, work across device types (desktop web, mobile
>> web, mobile apps), and maintain our key requirements on editability and
>> reusability, balanced against the security and privacy needs of users if
>> we're going to invest the effort.
>>
>> Backing up to do it right rather than patch up Graphs “one more time” is
>> the right thing, and I’m very happy to see a confluence of interest around
>> this now!
>>
>> My hope is we can figure out how to make that architecture & testing work
>> happen in the near term until we collectively (inside WMF and out) can
>> wrangle resources to make the implementation production-ready.
>>
>> Once we have a common infrastructure to build on, it’ll be easier for
>> work to progress on individual types of media (graphs, charts, maps,
>> animations, editable simulations, coding examples, etc, as well as classics
>> like panorama viewers and integrating the audio/video player into a sandbox
>> for heightened security).
>>
>> My biggest hope is that we’ll enable more work from outside WMF to happen
>> – letting volunteers and other orgs who might have their own specialty
>> areas and work funding to progress without every change being a potential
>> new security risk.
>>
>> When we have succeeded in the past, we have succeeded by making tools
>> that other people can use as their own basis to build their own works. I’m
>> confident we can get there on interactive media with some common focus.
>>
>> Let's all try to capture some of this momentum while we've got it and set
>> ourselves up for success down the road.
>>
>> – b
>>
>>
>> On Tue, Feb 6, 2024, 12:27 PM  wrote:
>>
>>> Hi everyone – My name is Marshall Miller, I am a Senior Director of
>>> Product at the Wikimedia Foundation, and I work with many of the teams that
>>> are involved with the user experience of our websites and apps, such as the
>>> Editing, Web, Growth, and Mobile Apps teams (among 

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

[Gnangarra]

Hi

I just like to highlight one point, that raises concerns;


perhaps enabling other platforms/apps to use our content to make
interactive or video materials there.


While this sounds like an easy solution we run into a number of hidden
costs.  These are significant when we push for reusers to present what we
are doing in better ways we lose the movement's revenue stream as less
people see our donation banners.  With less direct traffic we also
sacrifice the ability to convert readers into contributors which has always
been our primary source of community sustainability and growth.   I know
other providers will find different ways to present our efforts in part or
in whole that is part of our purpose, to do our mission and achieve our
goals we need prioritise internal solutions.

This also leads us to a related issue that our mission is to make the sum
of all knowledge freely available. When we look to outside parties to share
our efforts we lose our ability to ensure that the information is neutral,
and that it's freely accessible.  Butch is right in noting that when we put
funding into third party sites it is taking resources away from the
movement, yet those same funds were donated to us on the basis of
maintaining and building our infrastructure.  It would be a wise investment
to enable some of those much needed interactive and video content here
through purchasing rights.

On Wed, 7 Feb 2024 at 12:20, Butch Bustria  wrote:

> Hi Everyone,
>
> My earnest hope that the Wikimedia Foundation on its 2024-2025 Annual
> Financial Plan prioritize and I mean put first among all is the technical
> infrastructure among all its budgetary items. We can scale down budgets to
> 3rd party organizations like the Knowledge Equity Fund, Movement Strategy
> Governance funding, campaign grants, and other "wants" to accomodate a
> highly technically reliable and stable Wikimedia online projects ("needs"),
> future proof, and user friendly experience which require investments on
> quality manpower, hardware, applications and the like. We love open source
> but we also be pragmatic and wise on selection of choices because we want
> our content be conveniently available and reliable to our readers, users,
> consumers and also editors.
>
> A welcome development is the MediaWiki Users and Developers Conference,
> the successor to EMWCon.
>
> https://www.mediawiki.org/wiki/MediaWiki_Users_and_Developers_Conference_2024
>
> The said conference will be held in Portland, Oregon, from April 17–19,
> 2024.
>
> I also hope the Foundation invest in more technical gatherings, both
> onsite, hybrid or online to engage and reach out to more technical
> contributors, within and beyond the Wikimedia movement. I also hope WMF to
> start exploring eastward to Asia or elsewhere in the world as well fully
> diversify the technical community.
>
>
>
> Kind regards,
>
> *Butch Bustria*
>
>
>
>
> On Wed, Feb 7, 2024, 4:54 AM Brion Vibber  wrote:
>
>> Thanks for weighing in, Marshall!
>>
>> I agree wholeheartedly that we need to do a proper architecture for a
>> sandbox for interactive media, that will be safe (first and foremost),
>> perform well in the browser, work across device types (desktop web, mobile
>> web, mobile apps), and maintain our key requirements on editability and
>> reusability, balanced against the security and privacy needs of users if
>> we're going to invest the effort.
>>
>> Backing up to do it right rather than patch up Graphs “one more time” is
>> the right thing, and I’m very happy to see a confluence of interest around
>> this now!
>>
>> My hope is we can figure out how to make that architecture & testing work
>> happen in the near term until we collectively (inside WMF and out) can
>> wrangle resources to make the implementation production-ready.
>>
>> Once we have a common infrastructure to build on, it’ll be easier for
>> work to progress on individual types of media (graphs, charts, maps,
>> animations, editable simulations, coding examples, etc, as well as classics
>> like panorama viewers and integrating the audio/video player into a sandbox
>> for heightened security).
>>
>> My biggest hope is that we’ll enable more work from outside WMF to happen
>> – letting volunteers and other orgs who might have their own specialty
>> areas and work funding to progress without every change being a potential
>> new security risk.
>>
>> When we have succeeded in the past, we have succeeded by making tools
>> that other people can use as their own basis to build their own works. I’m
>> confident we can get there on interactive media with some common focus.
>>
>> Let's all try to capture some of this momentum while we've got it and set
>> ourselves up for success down the road.
>>
>> – b
>>
>>
>> On Tue, Feb 6, 2024, 12:27 PM  wrote:
>>
>>> Hi everyone – My name is Marshall Miller, I am a Senior Director of
>>> Product at the Wikimedia Foundation, and I work with many of the teams that
>>> are involved with the user experience 

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

[Galder Gonzalez Larrañaga]

 media dominates learning, 
content is structured, and collaboration tools work across multiple devices and 
have minimal technical requirements. (...)Addressing content gaps also includes 
making it easier to incorporate rich media, which requires more storage and 
server power, and better tooling for editing, uploading, and incorporating more 
types of media. On the engineering front, better automation of the software 
release process through continuous integration, and a more intentional focus on 
code quality and testing will allow for more innovative and faster 
experimentation". Again, this is not something new that happened two months 
ago, this was written in 2019 coming for an extremely long conversation that 
already happened between 2017-2019 and that is the guiding principle of our 
current Annual Plan, stated by the authors of the annual plan. If we are not 
moving in the way we decided, we are doing it wrong.

I could continue making a list of claims, but I think that is enough to 
understand that the conversation has happened, that we can save the kitten and 
plant the tree, that we already have decided that we need this and that it is 
already written in the annual plan. Claiming that there's no budget is also a 
bad move, because we don't know how much would this cost. In fact, knowing the 
cost would be the result of having a plan, but if there's no plan, we can't 
know if we can pay for it.

Let me end pointing again the big issue here: if we don't go forward with our 
top importance strategic goals because they are too complex to be solved, then 
every year will be more difficult to get there. The only way to solve complex 
issues is to start doing them. Postponing them while we try to take the low 
hanging fruits is a bad move; claiming that we are not working on them ("one 
that we have not yet started given the other priorities we’ve been working on") 
because we have been solving other issues is the worst news we can have.

Have a nice day

Galder



  *


________________
From: Butch Bustria 
Sent: Wednesday, February 7, 2024 5:19 AM
To: Wikimedia Mailing List 
Subject: [Wikimedia-l] Re: We need more interactive content: we are doing it 
wrong

Hi Everyone,

My earnest hope that the Wikimedia Foundation on its 2024-2025 Annual Financial 
Plan prioritize and I mean put first among all is the technical infrastructure 
among all its budgetary items. We can scale down budgets to 3rd party 
organizations like the Knowledge Equity Fund, Movement Strategy Governance 
funding, campaign grants, and other "wants" to accomodate a highly technically 
reliable and stable Wikimedia online projects ("needs"), future proof, and user 
friendly experience which require investments on quality manpower, hardware, 
applications and the like. We love open source but we also be pragmatic and 
wise on selection of choices because we want our content be conveniently 
available and reliable to our readers, users, consumers and also editors.

A welcome development is the MediaWiki Users and Developers Conference, the 
successor to EMWCon.
https://www.mediawiki.org/wiki/MediaWiki_Users_and_Developers_Conference_2024

The said conference will be held in Portland, Oregon, from April 17–19, 2024.

I also hope the Foundation invest in more technical gatherings, both onsite, 
hybrid or online to engage and reach out to more technical contributors, within 
and beyond the Wikimedia movement. I also hope WMF to start exploring eastward 
to Asia or elsewhere in the world as well fully diversify the technical 
community.



Kind regards,

Butch Bustria




On Wed, Feb 7, 2024, 4:54 AM Brion Vibber 
mailto:bvib...@wikimedia.org>> wrote:
Thanks for weighing in, Marshall!

I agree wholeheartedly that we need to do a proper architecture for a sandbox 
for interactive media, that will be safe (first and foremost), perform well in 
the browser, work across device types (desktop web, mobile web, mobile apps), 
and maintain our key requirements on editability and reusability, balanced 
against the security and privacy needs of users if we're going to invest the 
effort.

Backing up to do it right rather than patch up Graphs “one more time” is the 
right thing, and I’m very happy to see a confluence of interest around this now!

My hope is we can figure out how to make that architecture & testing work 
happen in the near term until we collectively (inside WMF and out) can wrangle 
resources to make the implementation production-ready.

Once we have a common infrastructure to build on, it’ll be easier for work to 
progress on individual types of media (graphs, charts, maps, animations, 
editable simulations, coding examples, etc, as well as classics like panorama 
viewers and integrating the audio/video player into a sandbox for heightened 
security).

My biggest hope is that we’ll enable more work from outside WMF to happen – 
letting volunteers and other orgs who migh

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

[Butch Bustria]

Hi Everyone,

My earnest hope that the Wikimedia Foundation on its 2024-2025 Annual
Financial Plan prioritize and I mean put first among all is the technical
infrastructure among all its budgetary items. We can scale down budgets to
3rd party organizations like the Knowledge Equity Fund, Movement Strategy
Governance funding, campaign grants, and other "wants" to accomodate a
highly technically reliable and stable Wikimedia online projects ("needs"),
future proof, and user friendly experience which require investments on
quality manpower, hardware, applications and the like. We love open source
but we also be pragmatic and wise on selection of choices because we want
our content be conveniently available and reliable to our readers, users,
consumers and also editors.

A welcome development is the MediaWiki Users and Developers Conference, the
successor to EMWCon.
https://www.mediawiki.org/wiki/MediaWiki_Users_and_Developers_Conference_2024

The said conference will be held in Portland, Oregon, from April 17–19,
2024.

I also hope the Foundation invest in more technical gatherings, both
onsite, hybrid or online to engage and reach out to more technical
contributors, within and beyond the Wikimedia movement. I also hope WMF to
start exploring eastward to Asia or elsewhere in the world as well fully
diversify the technical community.



Kind regards,

*Butch Bustria*




On Wed, Feb 7, 2024, 4:54 AM Brion Vibber  wrote:

> Thanks for weighing in, Marshall!
>
> I agree wholeheartedly that we need to do a proper architecture for a
> sandbox for interactive media, that will be safe (first and foremost),
> perform well in the browser, work across device types (desktop web, mobile
> web, mobile apps), and maintain our key requirements on editability and
> reusability, balanced against the security and privacy needs of users if
> we're going to invest the effort.
>
> Backing up to do it right rather than patch up Graphs “one more time” is
> the right thing, and I’m very happy to see a confluence of interest around
> this now!
>
> My hope is we can figure out how to make that architecture & testing work
> happen in the near term until we collectively (inside WMF and out) can
> wrangle resources to make the implementation production-ready.
>
> Once we have a common infrastructure to build on, it’ll be easier for work
> to progress on individual types of media (graphs, charts, maps, animations,
> editable simulations, coding examples, etc, as well as classics like
> panorama viewers and integrating the audio/video player into a sandbox for
> heightened security).
>
> My biggest hope is that we’ll enable more work from outside WMF to happen
> – letting volunteers and other orgs who might have their own specialty
> areas and work funding to progress without every change being a potential
> new security risk.
>
> When we have succeeded in the past, we have succeeded by making tools that
> other people can use as their own basis to build their own works. I’m
> confident we can get there on interactive media with some common focus.
>
> Let's all try to capture some of this momentum while we've got it and set
> ourselves up for success down the road.
>
> – b
>
>
> On Tue, Feb 6, 2024, 12:27 PM  wrote:
>
>> Hi everyone – My name is Marshall Miller, I am a Senior Director of
>> Product at the Wikimedia Foundation, and I work with many of the teams that
>> are involved with the user experience of our websites and apps, such as the
>> Editing, Web, Growth, and Mobile Apps teams (among others) [1]. I’m part of
>> the leadership group that makes decisions about how the WMF teams approach
>> things like graphs, interactive content, and video.  Thank you all for
>> having this in-depth and important discussion.
>>
>> I know that issues with graphs [2] are what started this discussion, but
>> I agree that it makes sense to think about this in terms of the broader
>> category of “interactive content”, because other kinds of interactive
>> content, such as maps or timelines, would share architecture with what is
>> needed for graphs (video is a different and more complicated content
>> type).  I wrote a lot in this email, but here are a couple of the main
>> points up front: to support graphs and other interactive content, we would
>> need to take a step back and make a substantial investment in sustainable
>> architecture to do it – so that it works well, safely, and is built to
>> last.  And because that’s a substantial investment, we need to weigh it
>> against other important investments in order to decide whether and when to
>> do it.
>>
>> I know that it is very frustrating that the Graph extension has not been
>> operational for many months – it means readers haven’t been seeing graphs
>> in articles, and editors haven’t been able to use graphs to do things like
>> monitor backlogs in WikiProjects.  Over the months of trying to find a way
>> to turn graphs back on, it has become clear that there isn’t a safe
>> shortcut here 

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

[Brion Vibber]

Thanks for weighing in, Marshall!

I agree wholeheartedly that we need to do a proper architecture for a
sandbox for interactive media, that will be safe (first and foremost),
perform well in the browser, work across device types (desktop web, mobile
web, mobile apps), and maintain our key requirements on editability and
reusability, balanced against the security and privacy needs of users if
we're going to invest the effort.

Backing up to do it right rather than patch up Graphs “one more time” is
the right thing, and I’m very happy to see a confluence of interest around
this now!

My hope is we can figure out how to make that architecture & testing work
happen in the near term until we collectively (inside WMF and out) can
wrangle resources to make the implementation production-ready.

Once we have a common infrastructure to build on, it’ll be easier for work
to progress on individual types of media (graphs, charts, maps, animations,
editable simulations, coding examples, etc, as well as classics like
panorama viewers and integrating the audio/video player into a sandbox for
heightened security).

My biggest hope is that we’ll enable more work from outside WMF to happen –
letting volunteers and other orgs who might have their own specialty areas
and work funding to progress without every change being a potential new
security risk.

When we have succeeded in the past, we have succeeded by making tools that
other people can use as their own basis to build their own works. I’m
confident we can get there on interactive media with some common focus.

Let's all try to capture some of this momentum while we've got it and set
ourselves up for success down the road.

– b


On Tue, Feb 6, 2024, 12:27 PM  wrote:

> Hi everyone – My name is Marshall Miller, I am a Senior Director of
> Product at the Wikimedia Foundation, and I work with many of the teams that
> are involved with the user experience of our websites and apps, such as the
> Editing, Web, Growth, and Mobile Apps teams (among others) [1]. I’m part of
> the leadership group that makes decisions about how the WMF teams approach
> things like graphs, interactive content, and video.  Thank you all for
> having this in-depth and important discussion.
>
> I know that issues with graphs [2] are what started this discussion, but I
> agree that it makes sense to think about this in terms of the broader
> category of “interactive content”, because other kinds of interactive
> content, such as maps or timelines, would share architecture with what is
> needed for graphs (video is a different and more complicated content
> type).  I wrote a lot in this email, but here are a couple of the main
> points up front: to support graphs and other interactive content, we would
> need to take a step back and make a substantial investment in sustainable
> architecture to do it – so that it works well, safely, and is built to
> last.  And because that’s a substantial investment, we need to weigh it
> against other important investments in order to decide whether and when to
> do it.
>
> I know that it is very frustrating that the Graph extension has not been
> operational for many months – it means readers haven’t been seeing graphs
> in articles, and editors haven’t been able to use graphs to do things like
> monitor backlogs in WikiProjects.  Over the months of trying to find a way
> to turn graphs back on, it has become clear that there isn’t a safe
> shortcut here and that the path forward will require a substantial
> investment – one that we have not yet started given the other priorities
> we’ve been working on.  Every year we have to make difficult tradeoffs
> around what areas of our technical infrastructure we can and cannot take
> on.  In the current fiscal year, the Product and Technology department has
> made experienced editors a priority [3], and many things that volunteers
> have asked for are either accomplished or in flight:
>
> Improvements to PageTriage (complete) [4]
> Watchlist in the iOS app (complete) [5]
> Patrolling in the Android app (in progress) [6]
> Dark mode (in progress) [7]
> Improvements to the Commons Upload Wizard (in progress) [8]
> …and other projects.
>
> But I know this conversation isn’t as much about what editors need as what
> current and future readers need.  Between talking about interactive content
> and talking about video, it sounds like we’re having the larger
> conversation of what we should be offering today’s and tomorrow’s readers
> to help them learn from encyclopedic content – whether we need to be
> offering interactivity, or video, or perhaps enabling other platforms/apps
> to use our content to make interactive or video materials there.  This is a
> really important conversation, because even working together we probably
> will not be able to build all of it – we’ll have to make hard choices about
> where to invest.  One place where this broader conversation is happening is
> called “Future Audiences”, which does 

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

[mmiller]

Hi everyone – My name is Marshall Miller, I am a Senior Director of Product at 
the Wikimedia Foundation, and I work with many of the teams that are involved 
with the user experience of our websites and apps, such as the Editing, Web, 
Growth, and Mobile Apps teams (among others) [1]. I’m part of the leadership 
group that makes decisions about how the WMF teams approach things like graphs, 
interactive content, and video.  Thank you all for having this in-depth and 
important discussion.

I know that issues with graphs [2] are what started this discussion, but I 
agree that it makes sense to think about this in terms of the broader category 
of “interactive content”, because other kinds of interactive content, such as 
maps or timelines, would share architecture with what is needed for graphs 
(video is a different and more complicated content type).  I wrote a lot in 
this email, but here are a couple of the main points up front: to support 
graphs and other interactive content, we would need to take a step back and 
make a substantial investment in sustainable architecture to do it – so that it 
works well, safely, and is built to last.  And because that’s a substantial 
investment, we need to weigh it against other important investments in order to 
decide whether and when to do it.

I know that it is very frustrating that the Graph extension has not been 
operational for many months – it means readers haven’t been seeing graphs in 
articles, and editors haven’t been able to use graphs to do things like monitor 
backlogs in WikiProjects.  Over the months of trying to find a way to turn 
graphs back on, it has become clear that there isn’t a safe shortcut here and 
that the path forward will require a substantial investment – one that we have 
not yet started given the other priorities we’ve been working on.  Every year 
we have to make difficult tradeoffs around what areas of our technical 
infrastructure we can and cannot take on.  In the current fiscal year, the 
Product and Technology department has made experienced editors a priority [3], 
and many things that volunteers have asked for are either accomplished or in 
flight:

Improvements to PageTriage (complete) [4]
Watchlist in the iOS app (complete) [5]
Patrolling in the Android app (in progress) [6]
Dark mode (in progress) [7]
Improvements to the Commons Upload Wizard (in progress) [8]
…and other projects.

But I know this conversation isn’t as much about what editors need as what 
current and future readers need.  Between talking about interactive content and 
talking about video, it sounds like we’re having the larger conversation of 
what we should be offering today’s and tomorrow’s readers to help them learn 
from encyclopedic content – whether we need to be offering interactivity, or 
video, or perhaps enabling other platforms/apps to use our content to make 
interactive or video materials there.  This is a really important conversation, 
because even working together we probably will not be able to build all of it – 
we’ll have to make hard choices about where to invest.  One place where this 
broader conversation is happening is called “Future Audiences”, which does 
experiments on how to reach newer generations who use the internet differently 
than previous generations – and thinking particularly about video.  Future 
Audiences has regular calls with community members to shape the direction of 
those experiments, which in turn inform how the broader Foundation prioritizes. 
 I hope many of you will get involved in those conversations – you can sign up 
here. [9]

Focusing back on graphs, since that’s what kicked this thread off, the several 
approaches we’ve attempted for quickly re-enabling the extension have ended up 
having security or performance problems.  Therefore, we think that if we were 
to support graphs and other interactive content, we would need to plan 
substantial investment in sustainable architecture.  This way, our approach 
would work securely and stably for the longer term.  But that would take 
significant resources, and we’ll need to weigh it against many other important 
priorities, like tools for functionaries, improvements to the editing 
experience, automated ways to stop vandals, etc.  

To be clear, if we do assign resources to the planning and building of an 
architecture for graphs (and other interactive content), it means that we are 
still at least several more months away from having a working 
Foundation-supported architecture.  Therefore, I think we should also be having 
the additional conversation that many others have brought up about what 
volunteers can do in these intervening months to make graphs somewhat available 
to users.  I know people are talking about that concretely on the Phabricator 
task, and I will join that conversation as well.
For the bigger question, I would like to start with some more learning about 
which kinds of interactive content are important for our encyclopedia, and 

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

[James Heilman]

We at Wiki Project Med Foundation are looking for contractors to work on
aspects of this problem. Reach out if you are interested.

James

On Thu, Feb 1, 2024 at 3:32 AM Paulo Santos Perneta 
wrote:

> WMF is doing it wrong, not we.
> Many people in the movement have been alerting to this situation over the
> years, apparently to deaf ears.
>
> Paulo
>
> Felipe Schenone  escreveu (quinta, 1/02/2024 à(s)
> 07:09):
>
>> Well, perhaps you'll be elated to know then that the grants for tech seem
>> to have been removed
>> 
>>  after
>> many months of waiting for them
>> 
>> .
>> We're doing it wrong, indeed.
>>
>> El mié., 31 de ene. de 2024 11:02 p. m., Gnangarra 
>> escribió:
>>
>>> Before the WMF starts hiring, we need to be very clear exactly what
>>> pathways and objectives we want to pursue, along with what functions should
>>> be internally maintained. With that what happens with community built tools
>>> that cross over from great tools to essential community infrastructure that
>>> needs continued updates.  Perhaps part of the "hiring" option is rewarding
>>> volunteers who create them to help transition the tool to the internal
>>> system.
>>>
>>> On Thu, 1 Feb 2024 at 01:35, Felipe Schenone 
>>> wrote:
>>>
 I also think the WMF should prioritize hiring more developers over
 other roles and expenditures. The WMF has only a few hundred developers
 while other top sites have many thousands. While this efficiency is
 something to be proud of, it evidently comes at a cost.

 El mié., 31 de ene. de 2024 4:08 a. m., rupert THURNER <
 rupert.thur...@gmail.com> escribió:

> 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 

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

[Paulo Santos Perneta]

WMF is doing it wrong, not we.
Many people in the movement have been alerting to this situation over the
years, apparently to deaf ears.

Paulo

Felipe Schenone  escreveu (quinta, 1/02/2024 à(s)
07:09):

> Well, perhaps you'll be elated to know then that the grants for tech seem
> to have been removed
> 
>  after
> many months of waiting for them
> 
> .
> We're doing it wrong, indeed.
>
> El mié., 31 de ene. de 2024 11:02 p. m., Gnangarra 
> escribió:
>
>> Before the WMF starts hiring, we need to be very clear exactly what
>> pathways and objectives we want to pursue, along with what functions should
>> be internally maintained. With that what happens with community built tools
>> that cross over from great tools to essential community infrastructure that
>> needs continued updates.  Perhaps part of the "hiring" option is rewarding
>> volunteers who create them to help transition the tool to the internal
>> system.
>>
>> On Thu, 1 Feb 2024 at 01:35, Felipe Schenone  wrote:
>>
>>> I also think the WMF should prioritize hiring more developers over other
>>> roles and expenditures. The WMF has only a few hundred developers while
>>> other top sites have many thousands. While this efficiency is something to
>>> be proud of, it evidently comes at a cost.
>>>
>>> El mié., 31 de ene. de 2024 4:08 a. m., rupert THURNER <
>>> rupert.thur...@gmail.com> escribió:
>>>
 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
> 

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

[Felipe Schenone]

Well, perhaps you'll be elated to know then that the grants for tech seem
to have been removed

after
many months of waiting for them

.
We're doing it wrong, indeed.

El mié., 31 de ene. de 2024 11:02 p. m., Gnangarra 
escribió:

> Before the WMF starts hiring, we need to be very clear exactly what
> pathways and objectives we want to pursue, along with what functions should
> be internally maintained. With that what happens with community built tools
> that cross over from great tools to essential community infrastructure that
> needs continued updates.  Perhaps part of the "hiring" option is rewarding
> volunteers who create them to help transition the tool to the internal
> system.
>
> On Thu, 1 Feb 2024 at 01:35, Felipe Schenone  wrote:
>
>> I also think the WMF should prioritize hiring more developers over other
>> roles and expenditures. The WMF has only a few hundred developers while
>> other top sites have many thousands. While this efficiency is something to
>> be proud of, it evidently comes at a cost.
>>
>> El mié., 31 de ene. de 2024 4:08 a. m., rupert THURNER <
>> rupert.thur...@gmail.com> escribió:
>>
>>> 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:
>>> 

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

[Gnangarra]

Before the WMF starts hiring, we need to be very clear exactly what
pathways and objectives we want to pursue, along with what functions should
be internally maintained. With that what happens with community built tools
that cross over from great tools to essential community infrastructure that
needs continued updates.  Perhaps part of the "hiring" option is rewarding
volunteers who create them to help transition the tool to the internal
system.

On Thu, 1 Feb 2024 at 01:35, Felipe Schenone  wrote:

> I also think the WMF should prioritize hiring more developers over other
> roles and expenditures. The WMF has only a few hundred developers while
> other top sites have many thousands. While this efficiency is something to
> be proud of, it evidently comes at a cost.
>
> El mié., 31 de ene. de 2024 4:08 a. m., rupert THURNER <
> rupert.thur...@gmail.com> escribió:
>
>> 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
>> 

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

[Felipe Schenone]

I also think the WMF should prioritize hiring more developers over other
roles and expenditures. The WMF has only a few hundred developers while
other top sites have many thousands. While this efficiency is something to
be proud of, it evidently comes at a cost.

El mié., 31 de ene. de 2024 4:08 a. m., rupert THURNER <
rupert.thur...@gmail.com> escribió:

> 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 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/WJHXZMUH7QRMYU5SR5HU5OZNN7SD7M5D/
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 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 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] 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]

 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 () escribió:
>
> On Tue, 23 Jan 2024 at 22:24, Ivan Martínez  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 point of
> view a far harder problem that dealing with the technical hurdles in
> uploading video to commons. Going to take a lot of effort in
> scripting, shooting, lighting and editing. And having your editor of
> choice render the final project in a wikipedia friendly format should
> not present a problem (and if it does handbrake exists).
>
> I really doubt we will ever get much in the way of encyclopaedic
> videos on our platforms since they take so much time and cost so much
> to make that they are only viable at scale from people who can do it
> at as a full time job. Youtubers find ways to do that through adsense,
> sponsor spots and Patreon. Not really something you can do on
> wikipedia.
>
>
> --
> geni
> ___
> 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/F7HLTFUUFIW2MI3XH3UQO2TNHAKZITNS/
> To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org
>
>
>
> --
> *Iván Martínez*
>
> *Voluntario - Wikimedia México A.C. User:ProtoplasmaKid *
>
> // Mis comunicaciones respecto a Wikipedia/Wikimedia pueden tener una
> moratoria en su atención debido a que es un voluntariado.
> // Ayuda a proteger a Wikipedia, dona ahora: https://donate.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/GQBQYOF23JBETMFC732PXNAXBXT2LPDX/
> To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org
>


-- 
James Heilman
MD, CCFP-EM, Wikipedian
___
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/KT2DELITTLEMTIYXNU7X7WETXYV34EZJ/
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

[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<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<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<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<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 encyc

[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

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

[Ivan Martínez]

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 () escribió:

> On Tue, 23 Jan 2024 at 22:24, Ivan Martínez  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 point of
> view a far harder problem that dealing with the technical hurdles in
> uploading video to commons. Going to take a lot of effort in
> scripting, shooting, lighting and editing. And having your editor of
> choice render the final project in a wikipedia friendly format should
> not present a problem (and if it does handbrake exists).
>
> I really doubt we will ever get much in the way of encyclopaedic
> videos on our platforms since they take so much time and cost so much
> to make that they are only viable at scale from people who can do it
> at as a full time job. Youtubers find ways to do that through adsense,
> sponsor spots and Patreon. Not really something you can do on
> wikipedia.
>
>
> --
> geni
> ___
> 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/F7HLTFUUFIW2MI3XH3UQO2TNHAKZITNS/
> To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org



-- 
*Iván Martínez*

*Voluntario - Wikimedia México A.C.User:ProtoplasmaKid *

// Mis comunicaciones respecto a Wikipedia/Wikimedia pueden tener una
moratoria en su atención debido a que es un voluntariado.
// Ayuda a proteger a Wikipedia, dona ahora: https://donate.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/HAG67DCJDVO5BZLH7OHP34O57AO6A6QN/
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

[effe iets anders]

Thanks Asaf, very true: I can totally see how the copyright issue would
remain a big problem, even if you solve the technical challenges...

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!) I
imagine that video editors could possibly limit themselves to that and
credibly claim free licensing that way? But I'm guessing that the typical
youtuber won't be very excited about that prospect with severe limitations
on their creativity. You may still have to deal with a bunch of edge cases,
but it would give a starting point.

Another way would be if we force creators to edit their videos all the way
from the raw materials on a platform controlled by us, rather than upload
the end product - resulting in an edit history that can trace back what
materials were used and that they were freely licensed. This is very much
in line with our traditional Wikipedia approach, but would be impossible to
sell unless we have a pretty awesome video editor. Which brings us back to
the start of this conversation :). In a way, the Kaltura editor felt more
advanced than what we currently make available.

The downside is, as long as we remain copyright sticklers, it'll not be
very 'fun' to develop videos for us, let alone with us. Any solution will
have to be a combination of massive technical improvements, a change of
attitude and an increased library of free raw materials.

Lodewijk

On Mon, Jan 29, 2024 at 3:24 PM Asaf Bartov  wrote:

> On Mon, Jan 29, 2024 at 10:29 PM geni  wrote:
>
>> On Sat, 27 Jan 2024 at 05:07, Samuel Klein  wrote:
>>
>> > ?   Many creators say they are glad to relicense their existing
>> fantastic work, but don't have time/will to overcome the current obstacles
>> to such reuse that they have to [personally] overcome for each video.  So
>> we only get bulk contributions, through a third-party who is familiar with
>> the wikis, once in a while...  a modest homegrown example: depthsofwiki has
>> a range of great short videos that are partly educational and mainly
>> inspiring to delve into the wikis and learn things. I suspect none of them
>> are on Commons despite obvious relevance to the movement for outreach,
>> illustration, and the like.
>>
>>
>> I suspect we are dealing with Stated vs. Revealed Preferences. Saying
>> no to wikipedia has more of a social cost than talking about technical
>> issues. Converting to something wikipedia will accept is fairly
>> straightforward. Handbrake has a GUI and pops up in creator workflows
>> as a convient way to compress B-roll. Uploading presents more of a
>> challange than most areas but that would be because we care more about
>> copyright than most so probably unavoidable,
>>
>
> A bigger issue with a random YouTuber or other individual video creator
> re-licensing their work is that *very* often, their "own work" is not
> purely "own work"; rather, they use non-free music as background,
> incorporate clips or memes in their video, etc., making the video
> potentially *unacceptable* on Commons, even if the author of the full video
> represents that they are willing to license their work under a free license.
>
> This is a sticky issue, because there is no easy fix, technological or
> otherwise, for clearing those copyright concerns.  If a video creator has
> their contributions wait in some review limbo for weeks (or months), and
> then has, say, four out of five of them rejected on copyright grounds, they
> would be overwhelmingly unlikely to keep contributing.
>
> (I'm just bringing up this issue that doesn't seem to have been mentioned
> as a factor. I do agree and wholeheartedly support the need to accept more
> formats and take on the burden of determining whether videos are usable
> (what SJ above called "a stickier ingenstion process"); even if it won't
> attract hordes of YouTubers to contribute, it could allow those of us
> already involved with and interested in free knowledge/culture to
> contribute more easily and frequently, and that itself could be
> transformative, in terms of the presence of video content on the wikis
> compared to status quo.)
>
>A.
>   (in my volunteer capacity)
> --
> Asaf Bartov 
> ___
> 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/TOBTVCCGIIUIU2AH5MHBM3VZP54HCNN5/
> To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org
___
Wikimedia-l mailing list -- 

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

[Asaf Bartov]

On Mon, Jan 29, 2024 at 10:29 PM geni  wrote:

> On Sat, 27 Jan 2024 at 05:07, Samuel Klein  wrote:
>
> > ?   Many creators say they are glad to relicense their existing
> fantastic work, but don't have time/will to overcome the current obstacles
> to such reuse that they have to [personally] overcome for each video.  So
> we only get bulk contributions, through a third-party who is familiar with
> the wikis, once in a while...  a modest homegrown example: depthsofwiki has
> a range of great short videos that are partly educational and mainly
> inspiring to delve into the wikis and learn things. I suspect none of them
> are on Commons despite obvious relevance to the movement for outreach,
> illustration, and the like.
>
>
> I suspect we are dealing with Stated vs. Revealed Preferences. Saying
> no to wikipedia has more of a social cost than talking about technical
> issues. Converting to something wikipedia will accept is fairly
> straightforward. Handbrake has a GUI and pops up in creator workflows
> as a convient way to compress B-roll. Uploading presents more of a
> challange than most areas but that would be because we care more about
> copyright than most so probably unavoidable,
>

A bigger issue with a random YouTuber or other individual video creator
re-licensing their work is that *very* often, their "own work" is not
purely "own work"; rather, they use non-free music as background,
incorporate clips or memes in their video, etc., making the video
potentially *unacceptable* on Commons, even if the author of the full video
represents that they are willing to license their work under a free license.

This is a sticky issue, because there is no easy fix, technological or
otherwise, for clearing those copyright concerns.  If a video creator has
their contributions wait in some review limbo for weeks (or months), and
then has, say, four out of five of them rejected on copyright grounds, they
would be overwhelmingly unlikely to keep contributing.

(I'm just bringing up this issue that doesn't seem to have been mentioned
as a factor. I do agree and wholeheartedly support the need to accept more
formats and take on the burden of determining whether videos are usable
(what SJ above called "a stickier ingenstion process"); even if it won't
attract hordes of YouTubers to contribute, it could allow those of us
already involved with and interested in free knowledge/culture to
contribute more easily and frequently, and that itself could be
transformative, in terms of the presence of video content on the wikis
compared to status quo.)

   A.
  (in my volunteer capacity)
-- 
Asaf Bartov 
___
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/TOBTVCCGIIUIU2AH5MHBM3VZP54HCNN5/
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

[geni]

On Sat, 27 Jan 2024 at 05:07, Samuel Klein  wrote:

> ?   Many creators say they are glad to relicense their existing fantastic 
> work, but don't have time/will to overcome the current obstacles to such 
> reuse that they have to [personally] overcome for each video.  So we only get 
> bulk contributions, through a third-party who is familiar with the wikis, 
> once in a while...  a modest homegrown example: depthsofwiki has a range of 
> great short videos that are partly educational and mainly inspiring to delve 
> into the wikis and learn things. I suspect none of them are on Commons 
> despite obvious relevance to the movement for outreach, illustration, and the 
> like.


I suspect we are dealing with Stated vs. Revealed Preferences. Saying
no to wikipedia has more of a social cost than talking about technical
issues. Converting to something wikipedia will accept is fairly
straightforward. Handbrake has a GUI and pops up in creator workflows
as a convient way to compress B-roll. Uploading presents more of a
challange than most areas but that would be because we care more about
copyright than most so probably unavoidable,



-- 
geni
___
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/N66SBYP4BT6YWJQEJK5PKKYAZTUPYQTD/
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

[Brion Vibber]

On Sat, Jan 27, 2024 at 12:57 PM Erik Moeller  wrote:

> On Tue, Jan 23, 2024 at 11:44 AM Brion Vibber 
> wrote:
> > 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.
>
> The last RFC [1] will reach its 10 year anniversary in February, so I
> think it would be reasonable to re-engage with the (Wikimedia-wide)
> community if anything about the current policy should change.
> Personally, I continue to be in favor of Wikimedia transcoding
> uploads, as long as WMF doesn't end up paying licensing fees to the
> video patent monopolists.


*nod*

What's changed over the last 10 years? Looking at Commons:Video, it
> currently says:
>
> > The preferred video format is VP9 video in the WebM container, but Theora
> > video in the ogv container and VP8 or AV1 video in the WebM container are
> > also allowed.
>
> So at least it looks like there are now new royalty-free formats that
> are widely supported in browsers, right?
>

We have playback covered reasonably well and it's getting better because
our old "frenemies" at Microsoft and Apple are now pulling their weight for
universal compatibility. They are both members of the industry consortium
pushing the royalty-free AV1 codec and have both adopted VP9 as its
predecessor bridge codec. :)

Allowing us to create MP4 h.264/AAC output in limited resolutions would
increase compatibility with older iOS devices and other "funky" browsers,
but we don't "need" it for the latest devices.


Reuse is more problematic. If you download our VP9 WebM or MP4/HLS playback
derivatives, or a WebM, Ogg, or MPEG-1/2 source file, many other sites and
tools won't take them because they expect MP4s with h.264 or HEVC. Can you
save the video to your camera roll? Repost it? Edit it in your video editor
of choice? Maybe, maybe not. Manual conversion will take time and requires
extra effort.

Note that h.264/AVC and HEVC are both international standards but not open
standards, and they both have active patent pools and require licensing to
produce and distribute an encoder or decoder. I'll leave it to a future
consultation to figure out what that means to us, users of Debian's ffmpeg
package. ;)
Allowing us to create MP4 h.264/AVC output could increase ease of use /
compatibility for reusers.


Contributing is also more problematic, because most modern cameras and
editing tools produce H.264 or HEVC video in some flavor of MP4 container
by default. We accept some old formats (MPEG-1 and MPEG-2 and Ogg Theora)
and some weird formats (WebM with VP8 or VP9) but not the actually commonly
used ones. This means almost every video upload is recoded by the uploader,
either manually or through a tool. This reduces the quality of the stored
file and the subsequent playback derivatives, and gives another opportunity
to massively mis-estimate bitrate and produce a very bad quality stored
file by accident that cannot be fixed by anyone else (this happens a lot).


> Is there anything that can be done to expand the server-side format
> support further without changing Wikimedia's stance on patents? For
> example, should Wikimedia Commons support additional container formats
> or codecs that are royalty-free or whose patents have expired?
>

The only functional change we need is to enable uploading .mp4 and .mov
files with the h.264 video and AAC-LC audio codecs. (And optionally HEVC if
it's not problematic).

Without reinterpreting or changing the policy, I think we're not meant to
be *using* the h.264 or HEVC codecs in ffmpeg, even though it's in our
Debian installations. This means our only hopes for ingesting common video
files are reevaluating the policy or doing a Rube Goldberg machine where we
transcode client-side using hardware codecs via Web Codecs. ;)

While that would be a fun project, it shouldn't be necessary IMO.

Container formats are not a problem; everybody ships MP4/ISO BMFF
muxer/demuxer code without a second thought about patents. We're even
producing MP4 files for HLS playback tracks for iOS (with free codecs
inside).

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.

We'd also have to make the choice of whether distributing the files as
originals is somehow violating a patent or if nobody cares about
distribution of files encoded by someone else. Nobody knew for sure what
that 

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

[Erik Moeller]

On Tue, Jan 23, 2024 at 11:44 AM Brion Vibber  wrote:
> 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.

The last RFC [1] will reach its 10 year anniversary in February, so I
think it would be reasonable to re-engage with the (Wikimedia-wide)
community if anything about the current policy should change.
Personally, I continue to be in favor of Wikimedia transcoding
uploads, as long as WMF doesn't end up paying licensing fees to the
video patent monopolists.

What's changed over the last 10 years? Looking at Commons:Video, it
currently says:

> The preferred video format is VP9 video in the WebM container, but Theora
> video in the ogv container and VP8 or AV1 video in the WebM container are
> also allowed.

So at least it looks like there are now new royalty-free formats that
are widely supported in browsers, right?

Is there anything that can be done to expand the server-side format
support further without changing Wikimedia's stance on patents? For
example, should Wikimedia Commons support additional container formats
or codecs that are royalty-free or whose patents have expired?

Warmly,
Erik

[1] https://commons.wikimedia.org/wiki/Commons:Requests_for_comment/MP4_Video
___
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/FPV4PBWUUANZDX43QDOWCUE6CB733X6S/
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]

>From my non-lawyer reading of the Wikipedia page on the topic, the patent
is for the devices or hardware that reads the files, not on those that
distribute or make the files.

https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding

Since we do not manufacture hardware. Not seeing the issue.

James

On Sat, Jan 27, 2024 at 1:11 AM Kimmo Virtanen 
wrote:

> On Fri, Jan 26, 2024 at 1:23 PM Kimmo Virtanen <
> kimmo.virta...@wikimedia.fi> wrote:
>
>> Could somebody explain what is problem with VP9 or AV1 with WebM
>> container? These are supported in Wikimedia Commons.
>>
>
> OK, I will try to answer my own question:
>
> AV1 is technically superior to h.264 in terms of file size and quality as
> it is one generation newer.  h.265 (HVEC) would be in quality level than
> AV1, but there is licence fee for using it and open source tools support is
> better for AV1 than h.265. If we include closed source encoders then h.265
> encoders are in ame level than open source AV1 encoders. AV1 is generally
> widely used as it is used by Netflix and Youtube etc.
>
> Browser support for AV1 seems to be OK
> - https://caniuse.com/?search=VP9
>
> The missing thing is that hardware support is in the transition phase. Ie.
> Most notably, widely available Apple support is missing as it supports AV1
> only devices where there is hardware support for decoding. Apple added
> hardware decoding AV1 support to its latest generation chipsets (A17, M3).
>
> On Android Google defined that AV1 support is mandatory for Android 14
> (released 2023) compliance.
>
> On PC side hardware decoding / encoding support has been added like this
> * AMD RDNA2 = AV1 decode (released 2020)
> * AMD RDNA3 = AV1 decode/encode (released 2022)
> * Intel 11th gen = AV1 decode (released 2021)
> * Intel 14th gen = AV1 decode/encode (released 2023)
>
> So, all new devices which are released in 2024 will support AV1 and in a
> couple years perspective the devices which don't support AV1 are legacy
> ones. Hardware decoding is relevant for mobile devices as without it power
> consumption would be too high even if the device could decode the stream.
> Legacy desktop computers can do the software decoding in terms of CPU/GPU
> performance required.
>
> Br,
> -- Kimmo Virtanen, Zache
>
>
> ___
> 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/LS7GVOWOCEKOQ7QIE4MEMBT5AAYQLRC4/
> To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org



-- 
James Heilman
MD, CCFP-EM, Wikipedian
___
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/AG7PTMDGJP2VVG3743NZ7UGXIQOMJOGX/
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

[Kimmo Virtanen]

On Fri, Jan 26, 2024 at 1:23 PM Kimmo Virtanen 
wrote:

> Could somebody explain what is problem with VP9 or AV1 with WebM
> container? These are supported in Wikimedia Commons.
>

OK, I will try to answer my own question:

AV1 is technically superior to h.264 in terms of file size and quality as
it is one generation newer.  h.265 (HVEC) would be in quality level than
AV1, but there is licence fee for using it and open source tools support is
better for AV1 than h.265. If we include closed source encoders then h.265
encoders are in ame level than open source AV1 encoders. AV1 is generally
widely used as it is used by Netflix and Youtube etc.

Browser support for AV1 seems to be OK
- https://caniuse.com/?search=VP9

The missing thing is that hardware support is in the transition phase. Ie.
Most notably, widely available Apple support is missing as it supports AV1
only devices where there is hardware support for decoding. Apple added
hardware decoding AV1 support to its latest generation chipsets (A17, M3).

On Android Google defined that AV1 support is mandatory for Android 14
(released 2023) compliance.

On PC side hardware decoding / encoding support has been added like this
* AMD RDNA2 = AV1 decode (released 2020)
* AMD RDNA3 = AV1 decode/encode (released 2022)
* Intel 11th gen = AV1 decode (released 2021)
* Intel 14th gen = AV1 decode/encode (released 2023)

So, all new devices which are released in 2024 will support AV1 and in a
couple years perspective the devices which don't support AV1 are legacy
ones. Hardware decoding is relevant for mobile devices as without it power
consumption would be too high even if the device could decode the stream.
Legacy desktop computers can do the software decoding in terms of CPU/GPU
performance required.

Br,
-- Kimmo Virtanen, Zache
___
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/LS7GVOWOCEKOQ7QIE4MEMBT5AAYQLRC4/
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]

On Fri, Jan 26, 2024 at 2:53 AM Jan Ainali  wrote:

> Brion wrote:
>> > 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.
>>
>> Yes, this is essential.  Can be via a separate videowiki in the short
>> term (or NCcommons) if the WM Commons community is united in opposition.
>>
>
> I disagree. Using non-open tools in our workflows is a poison that should
> be resisted by any means possible.
>

You've single-handedly contributed massively to free knowledge outputs and
education across a range of formats, so surely something poisonous to your
work (or enthusiasm!) would be problematic.  But I don't think tools that
allow people to share free knowledge in whatever format they have and
thereby convert it to free formats, are remotely harmful.

People who have existing media will generally not use a new app; the most
impactful missing steps are
a) a stickier intake wizard (iterative uploading and license-clearing)
b) automatic transcoding (without the uploader having to grok + do it)

geni wrote:
> I really doubt we will ever get much in the way of encyclopaedic videos
on our platforms

?   Many creators say they are glad to relicense their existing fantastic
work, but don't have time/will to overcome the current obstacles to such
reuse that they have to [personally] overcome for each video.  So we only
get bulk contributions, through a third-party who is familiar with the
wikis, once in a while...  a modest homegrown example: depthsofwiki has a
range of great short videos that are partly educational and mainly
inspiring to delve into the wikis and learn things. I suspect none of them
are on Commons despite obvious relevance to the movement for outreach,
illustration, and the like.

SJ.
___
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/N7HN5WHIMPGP3YIDERYOWKER4IO5GQAK/
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

[Galder Gonzalez Larrañaga]

Yes, we have videos. And we even have video creation projects. https://eu.wikipedia.org/wiki/Atari: Hezkuntza/Ikusgela is a good example of that.Still, those are multimedia but not interactive. And adding subtitles is complex (we could have a translation tool for those). We can't dub videos natively, which would be a great addition that anybode else is doing. And we can't add links to subtitles, as we could before the new player was adopted.Imagine a world where multilanguage videos are widely available. We could be the best doing that. But not with our current situation and technology.2024(e)ko urt. 26(a) 22:49 erabiltzaileak hau idatzi du (James Heilman ):And here we have >300 videos donated by Osmosishttps://commons.wikimedia.org/wiki/Category:Videos_from_OsmosisJamesOn Fri, Jan 26, 2024 at 11:45 AM Amir Sarabadani  wrote:Maybe people don't know but video donation happens in Wikimedia already and it doesn't need to be from Youtubers.Here is my favorite example: German public broadcaster (ARD) donates short informational videos to Wikipedia and they are used in articles in German Wikipedia. They get a lot of views. Here is a list of videos from one of their programs named Tagesschau:https://mvc.toolforge.org/index.php?category=Videos+by+Tagesschau+(ARD)==2023-08-01=2023-09-01=100For example, this video about Golf Stream and impact of climate change on it which is used in the article of Golf Stream in German Wikipedia:https://commons.wikimedia.org/wiki/File:Kurzerkl%C3%A4rt,_Golfstrom_-_Tagesschau.webmOr when cold or hot temperatures can be dangerous to humans: https://commons.wikimedia.org/wiki/File:Gut_zu_wissen,_Wann_wird_K%C3%A4lte_gef%C3%A4hrlich_-_Tagesschau.webmOr an explanation on Carthage, even with English subtitles: https://commons.wikimedia.org/wiki/File:Karthago,_Ph%C3%B6nizische_Gro%C3%9Fstadt_(CC_BY-SA_4.0).webmIt'd really be nice to see more partnerships like this. Whether with youtubers, public broadcasters, museums, universities, or anything like that!Am Fr., 26. Jan. 2024 um 19:29 Uhr schrieb Andrew Bogott :On 1/26/24 12:05 PM, geni wrote:
> On Tue, 23 Jan 2024 at 22:24, Ivan Martínez  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 point of
> view a far harder problem that dealing with the technical hurdles in
> uploading video to commons. Going to take a lot of effort in
> scripting, shooting, lighting and editing. And having your editor of
> choice render the final project in a wikipedia friendly format should
> not present a problem (and if it does handbrake exists).
>
> I really doubt we will ever get much in the way of encyclopaedic
> videos on our platforms since they take so much time and cost so much
> to make that they are only viable at scale from people who can do it
> at as a full time job. Youtubers find ways to do that through adsense,
> sponsor spots and Patreon. Not really something you can do on
> wikipedia.
I don't know much of anything about youtube licensing... is it possible 
for youtubers to dual or re-license their content? Could we invite 
creators to donate their content to the commons after a year or two when 
their revenue stream has trailed off?
___
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/HBN55JV62BGTTBZHVVNBLPFHHHF2Y4XO/
To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org-- Amir (he/him)
___
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/PPSSF4WI4VOU7ULX3HNSWTTULEM2WZHN/
To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org-- James HeilmanMD, CCFP-EM, Wikipedian
___
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/XMBPF2EJ3J6HIACNSGZ2BF6NGBMJHDTY/
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]

And here we have >300 videos donated by Osmosis

https://commons.wikimedia.org/wiki/Category:Videos_from_Osmosis

James

On Fri, Jan 26, 2024 at 11:45 AM Amir Sarabadani 
wrote:

> Maybe people don't know but video donation happens in Wikimedia already
> and it doesn't need to be from Youtubers.
>
> Here is my favorite example: German public broadcaster (ARD) donates short
> informational videos to Wikipedia and they are used in articles in German
> Wikipedia. They get a lot of views. Here is a list of videos from one of
> their programs named Tagesschau:
>
> https://mvc.toolforge.org/index.php?category=Videos+by+Tagesschau+(ARD)==2023-08-01=2023-09-01=100
>
> For example, this video about Golf Stream and impact of climate change on
> it which is used in the article of Golf Stream in German Wikipedia:
>
> https://commons.wikimedia.org/wiki/File:Kurzerkl%C3%A4rt,_Golfstrom_-_Tagesschau.webm
> Or when cold or hot temperatures can be dangerous to humans:
> https://commons.wikimedia.org/wiki/File:Gut_zu_wissen,_Wann_wird_K%C3%A4lte_gef%C3%A4hrlich_-_Tagesschau.webm
> Or an explanation on Carthage, even with English subtitles:
> https://commons.wikimedia.org/wiki/File:Karthago,_Ph%C3%B6nizische_Gro%C3%9Fstadt_(CC_BY-SA_4.0).webm
>
> It'd really be nice to see more partnerships like this. Whether with
> youtubers, public broadcasters, museums, universities, or anything like
> that!
>
>
> Am Fr., 26. Jan. 2024 um 19:29 Uhr schrieb Andrew Bogott <
> abog...@wikimedia.org>:
>
>> On 1/26/24 12:05 PM, geni wrote:
>> > On Tue, 23 Jan 2024 at 22:24, Ivan Martínez  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 point of
>> > view a far harder problem that dealing with the technical hurdles in
>> > uploading video to commons. Going to take a lot of effort in
>> > scripting, shooting, lighting and editing. And having your editor of
>> > choice render the final project in a wikipedia friendly format should
>> > not present a problem (and if it does handbrake exists).
>> >
>> > I really doubt we will ever get much in the way of encyclopaedic
>> > videos on our platforms since they take so much time and cost so much
>> > to make that they are only viable at scale from people who can do it
>> > at as a full time job. Youtubers find ways to do that through adsense,
>> > sponsor spots and Patreon. Not really something you can do on
>> > wikipedia.
>> I don't know much of anything about youtube licensing... is it possible
>> for youtubers to dual or re-license their content? Could we invite
>> creators to donate their content to the commons after a year or two when
>> their revenue stream has trailed off?
>> ___
>> 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/HBN55JV62BGTTBZHVVNBLPFHHHF2Y4XO/
>> To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org
>
>
>
> --
> Amir (he/him)
>
> ___
> 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/PPSSF4WI4VOU7ULX3HNSWTTULEM2WZHN/
> To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org



-- 
James Heilman
MD, CCFP-EM, Wikipedian
___
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/OPH4VL4RGSRYVC774LGC2CD764AQTN4T/
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

[Amir Sarabadani]

Maybe people don't know but video donation happens in Wikimedia already and
it doesn't need to be from Youtubers.

Here is my favorite example: German public broadcaster (ARD) donates short
informational videos to Wikipedia and they are used in articles in German
Wikipedia. They get a lot of views. Here is a list of videos from one of
their programs named Tagesschau:
https://mvc.toolforge.org/index.php?category=Videos+by+Tagesschau+(ARD)==2023-08-01=2023-09-01=100

For example, this video about Golf Stream and impact of climate change on
it which is used in the article of Golf Stream in German Wikipedia:
https://commons.wikimedia.org/wiki/File:Kurzerkl%C3%A4rt,_Golfstrom_-_Tagesschau.webm
Or when cold or hot temperatures can be dangerous to humans:
https://commons.wikimedia.org/wiki/File:Gut_zu_wissen,_Wann_wird_K%C3%A4lte_gef%C3%A4hrlich_-_Tagesschau.webm
Or an explanation on Carthage, even with English subtitles:
https://commons.wikimedia.org/wiki/File:Karthago,_Ph%C3%B6nizische_Gro%C3%9Fstadt_(CC_BY-SA_4.0).webm

It'd really be nice to see more partnerships like this. Whether with
youtubers, public broadcasters, museums, universities, or anything like
that!


Am Fr., 26. Jan. 2024 um 19:29 Uhr schrieb Andrew Bogott <
abog...@wikimedia.org>:

> On 1/26/24 12:05 PM, geni wrote:
> > On Tue, 23 Jan 2024 at 22:24, Ivan Martínez  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 point of
> > view a far harder problem that dealing with the technical hurdles in
> > uploading video to commons. Going to take a lot of effort in
> > scripting, shooting, lighting and editing. And having your editor of
> > choice render the final project in a wikipedia friendly format should
> > not present a problem (and if it does handbrake exists).
> >
> > I really doubt we will ever get much in the way of encyclopaedic
> > videos on our platforms since they take so much time and cost so much
> > to make that they are only viable at scale from people who can do it
> > at as a full time job. Youtubers find ways to do that through adsense,
> > sponsor spots and Patreon. Not really something you can do on
> > wikipedia.
> I don't know much of anything about youtube licensing... is it possible
> for youtubers to dual or re-license their content? Could we invite
> creators to donate their content to the commons after a year or two when
> their revenue stream has trailed off?
> ___
> 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/HBN55JV62BGTTBZHVVNBLPFHHHF2Y4XO/
> To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org



-- 
Amir (he/him)
___
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/PPSSF4WI4VOU7ULX3HNSWTTULEM2WZHN/
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

[Andrew Bogott]

On 1/26/24 12:05 PM, geni wrote:

On Tue, 23 Jan 2024 at 22:24, Ivan Martínez  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 point of
view a far harder problem that dealing with the technical hurdles in
uploading video to commons. Going to take a lot of effort in
scripting, shooting, lighting and editing. And having your editor of
choice render the final project in a wikipedia friendly format should
not present a problem (and if it does handbrake exists).

I really doubt we will ever get much in the way of encyclopaedic
videos on our platforms since they take so much time and cost so much
to make that they are only viable at scale from people who can do it
at as a full time job. Youtubers find ways to do that through adsense,
sponsor spots and Patreon. Not really something you can do on
wikipedia.
I don't know much of anything about youtube licensing... is it possible 
for youtubers to dual or re-license their content? Could we invite 
creators to donate their content to the commons after a year or two when 
their revenue stream has trailed off?

___
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/HBN55JV62BGTTBZHVVNBLPFHHHF2Y4XO/
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

[Amir Sarabadani]

I'm not an expert in multimedia codecs or patents so I leave the actual
decision to people who know better (maybe legal team in WMF?) but according
to tech news, major patents for mp4 have already expired and the rest will
expire soon, a large batch of them expired in November 2023 and a major
batch will expire by March this year.

There are many types of mp4, I think H.263 is now expired but again, not an
expert.
https://meta.wikimedia.org/wiki/Have_the_patents_for_H.263_expired_yet%3F
https://meta.wikimedia.org/wiki/Have_the_patents_for_MPEG-4_Visual_expired_yet%3F

VP9 and H.264 are not expired yet (but H.264 seems to be expiring soon so
maybe we should prepare?):
https://meta.wikimedia.org/wiki/Have_the_patents_for_VP9_expired_yet%3F
https://meta.wikimedia.org/wiki/Have_the_patents_for_H.264_MPEG-4_AVC_expired_yet%3F


Am Fr., 26. Jan. 2024 um 18:59 Uhr schrieb geni :

> On Wed, 24 Jan 2024 at 07:00, Gnangarra  wrote:
> > Simple mp4 upload option would be a starting point, surely we are big
> enough for any copyright holders to donate the licensing if wmf comes made
> a request
> >
>
> No. There are still members of the MP4 patent pool who expect that at
> some point they will make a lot of money off it.
>
> --
> geni
> ___
> 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/R6OSNWH57OCQCJT3DUMEQASR4PI4CUXJ/
> To unsubscribe send an email to wikimedia-l-le...@lists.wikimedia.org
>


-- 
Amir (he/him)
___
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/MLZXI2THG3YDUTFLFT5H7CDZYTRGA3QA/
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

[geni]

On Tue, 23 Jan 2024 at 22:24, Ivan Martínez  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 point of
view a far harder problem that dealing with the technical hurdles in
uploading video to commons. Going to take a lot of effort in
scripting, shooting, lighting and editing. And having your editor of
choice render the final project in a wikipedia friendly format should
not present a problem (and if it does handbrake exists).

I really doubt we will ever get much in the way of encyclopaedic
videos on our platforms since they take so much time and cost so much
to make that they are only viable at scale from people who can do it
at as a full time job. Youtubers find ways to do that through adsense,
sponsor spots and Patreon. Not really something you can do on
wikipedia.


-- 
geni
___
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/F7HLTFUUFIW2MI3XH3UQO2TNHAKZITNS/
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

[geni]

On Wed, 24 Jan 2024 at 07:00, Gnangarra  wrote:
> Simple mp4 upload option would be a starting point, surely we are big enough 
> for any copyright holders to donate the licensing if wmf comes made a request
>

No. There are still members of the MP4 patent pool who expect that at
some point they will make a lot of money off it.

-- 
geni
___
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/R6OSNWH57OCQCJT3DUMEQASR4PI4CUXJ/
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

[Galder Gonzalez Larrañaga]

Thanks for bringing this also, Xavier. Last Wikimania I went to a great session 
about the new tools the Research Team is building. Most of them are really 
useful. It's a pity I can't find them if I don't try to search specifically for 
them, and that no one will ever find them because we don't have those tools are 
external and not integrated in our platforms. This is another great example of 
the lack of ambition in the product infrastructure.

I really hope someone will handle these issues, but I have more doubts that it 
will happen by the day.

Have a nice weekend to those that have weekends,

Galder

From: Kimmo Virtanen 
Sent: Friday, January 26, 2024 12:23 PM
To: Wikimedia Mailing List 
Subject: [Wikimedia-l] Re: We need more interactive content: we are doing it 
wrong

Hi,

Could somebody explain what is problem with VP9 or AV1 with WebM container? 
These are supported in Wikimedia Commons.

Br,
-- Kimmo Virtanen / Zache

On Tue, Jan 23, 2024 at 11:05 PM Brion Vibber 
mailto:bvib...@wikimedia.org>> wrote:
Converting them to suitably compact files in h.264/aac in .MP4 format would be 
by far the simplest way. Use ffmpeg as we do on the server side for online 
playback.

Conforming to the arbitrary Wikimedia prohibition on h.264 you could use mpeg-4 
visual instead, still in .mp4 - afaik patents are expired and it'll play in 
standalone files (not in HLS)

If you jump through enough hoops you might get vp9 working in HLS offline, but 
adaptive streaming may be irrelevant to offline use.

-- brion

On Tue, Jan 23, 2024, 12:52 PM James Heilman 
mailto:jmh...@gmail.com>> wrote:
It would be amazing if one could play videos on iPhones when the videos are 
within ZIMs in an offline environment aswell. Brion not sure what barriers 
there are to this currently?

James

On Tue, Jan 23, 2024 at 12:48 PM Paulo Santos Perneta 
mailto:paulospern...@gmail.com>> wrote:
Should read 2030 Strategy, not 2023 strategy, sorry.

Paulo Santos Perneta mailto:paulospern...@gmail.com>> 
escreveu (terça, 23/01/2024 à(s) 19:41):
I wholeheartedly agree with this sentiment. We are currently grappling with 
rather rudimentary approaches when it comes to uploading and reusing video and 
music files...
The incredibly useful Graph has been down for quite some time. The extensive 
capabilities of Wikidata query representations, particularly with geolocated 
data on maps, appear to have barely scratched the surface. Listeria frequently 
experiences issues and underwent a major update that disrupted previous queries.

On a personal note, I attempted to create a dynamic digital library of works 
under a free license using Wikidata for our Digital Humanistics centre. 
However, I discovered that with the available tools, I would need to code the 
presentation myself, as the options for reuse outside of Wikidata were very 
basic.

On the whole, the Wikipedia experience remains challenging, especially for 
newcomers. The much wanted Visual Editor developments and improvements seem to 
have stopped years ago. The recent changes made by the 'Desktop Improvement' 
team to the default Wikipedia skin seem to be more geared towards readers than 
editors and have apparently worsened the overall experience, according to 
feedback I've received from newcomers.

These are just a few instances that have underscored, and continue to 
underscore, my belief that we are likely not on the path towards achieving the 
objectives outlined in the 2023 Strategy.

My personal impression is that the issue doesn't necessarily stem from a lack 
of funding to pursue these objectives but rather from the ineffective 
expenditure and allocation of those funds. I wish I knew how to contribute to 
changing or improving this situation.
It would also be great to see a comment/opinion from current CEO Maryana 
Iskander on this state of affairs, and if there is some roadmap for improving 
it.

Best,
Paulo


Galder Gonzalez Larrañaga mailto:galder...@hotmail.com>> 
escreveu (terça, 23/01/2024 à(s) 11:03):
Dear wikimedians,
Nearly one year ago, the Graphs extension was disabled from all wikis, because 
there was a security issue that should be solved 
(https://phabricator.wikimedia.org/T334940). A wide team from the WMF worked on 
a solution for some weeks, but after Northern Hemisphere spring ended, summer 
came, then the monsoon season, and now it is again summer in the Southern 
Hemisphere... and Graphs are still disabled. All the solutions proposed have 
been dismissed, but every two months there's a proposal to make a new roadmap 
to solve the issue. 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 eco

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

[Kimmo Virtanen]

Hi,

Could somebody explain what is problem with VP9 or AV1 with WebM container?
These are supported in Wikimedia Commons.

Br,
-- Kimmo Virtanen / Zache

On Tue, Jan 23, 2024 at 11:05 PM Brion Vibber  wrote:

> Converting them to suitably compact files in h.264/aac in .MP4 format
> would be by far the simplest way. Use ffmpeg as we do on the server side
> for online playback.
>
> Conforming to the arbitrary Wikimedia prohibition on h.264 you could use
> mpeg-4 visual instead, still in .mp4 - afaik patents are expired and it'll
> play in standalone files (not in HLS)
>
> If you jump through enough hoops you might get vp9 working in HLS offline,
> but adaptive streaming may be irrelevant to offline use.
>
> -- brion
>
> On Tue, Jan 23, 2024, 12:52 PM James Heilman  wrote:
>
>> It would be amazing if one could play videos on iPhones when the videos
>> are within ZIMs in an offline environment aswell. Brion not sure what
>> barriers there are to this currently?
>>
>> James
>>
>> On Tue, Jan 23, 2024 at 12:48 PM Paulo Santos Perneta <
>> paulospern...@gmail.com> wrote:
>>
>>> Should read 2030 Strategy, not 2023 strategy, sorry.
>>>
>>> Paulo Santos Perneta  escreveu (terça,
>>> 23/01/2024 à(s) 19:41):
>>>
 I wholeheartedly agree with this sentiment. We are currently grappling
 with rather rudimentary approaches when it comes to uploading and reusing
 video and music files...
 The incredibly useful Graph has been down for quite some time. The
 extensive capabilities of Wikidata query representations, particularly with
 geolocated data on maps, appear to have barely scratched the surface.
 Listeria frequently experiences issues and underwent a major update that
 disrupted previous queries.

 On a personal note, I attempted to create a dynamic digital library of
 works under a free license using Wikidata for our Digital Humanistics
 centre. However, I discovered that with the available tools, I would need
 to code the presentation myself, as the options for reuse outside of
 Wikidata were very basic.

 On the whole, the Wikipedia experience remains challenging, especially
 for newcomers. The much wanted Visual Editor developments and improvements
 seem to have stopped years ago. The recent changes made by the 'Desktop
 Improvement' team to the default Wikipedia skin seem to be more geared
 towards readers than editors and have apparently worsened the overall
 experience, according to feedback I've received from newcomers.

 These are just a few instances that have underscored, and continue to
 underscore, my belief that we are likely not on the path towards achieving
 the objectives outlined in the 2023 Strategy.

 My personal impression is that the issue doesn't necessarily stem from
 a lack of funding to pursue these objectives but rather from the
 ineffective expenditure and allocation of those funds. I wish I knew how to
 contribute to changing or improving this situation.
 It would also be great to see a comment/opinion from current CEO
 Maryana Iskander on this state of affairs, and if there is some roadmap for
 improving it.

 Best,
 Paulo


 Galder Gonzalez Larrañaga  escreveu (terça,
 23/01/2024 à(s) 11:03):

> Dear wikimedians,
> Nearly one year ago, the Graphs extension was disabled from all wikis,
> because there was a security issue that should be solved (
> https://phabricator.wikimedia.org/T334940). A wide team from the WMF
> worked on a solution for some weeks, but after Northern Hemisphere spring
> ended, summer came, then the monsoon season, and now it is again summer in
> the Southern Hemisphere... and Graphs are still disabled. All the 
> solutions
> proposed have been dismissed, but every two months there's a proposal to
> make a new roadmap to solve the issue. 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).
> Well, the situation is now worse than it was seven years ago, let me give
> some examples:
>
>
>- Graph extension is used in thousands of pages, some of them
>highly relevant, as COVID or Climate Change information. There are
>thousands of 

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

[F. Xavier Dengra i Grau via Wikimedia-l]

Bon dia/Hi,

I don't want to add even more seriousness to the thread; I am happy to read 
that there is an absolute agreement on the topic.

But interactivity is not only about embedding video: we currently must leave 
each project to Toolforge for supporting editing tools, to Humanwiki to read 
biases, to OAuth to participate in polls or some editathons, or to 
MediawikiStats + WMFCloud to even see mapped or plotted the simplest statistics 
of each article or user contributions! Not to mention the struggles to keep 
“attractive” main pages of our hundreds of projects. Mobile browsers open them 
as mobile versions, and most become an unreadable disaster. Who will be still 
willing to read a minoritized language content like the Kurdish Wikiquote (just 
an example) if there are no templates that can support thriving communities to 
show decent main pages after the 2010s social desktop-to-phone transition? 
That's also interactivity, and that fight we already heavily lost it since a 
decade ago. No wonder that another thread brings up Google not indexing 
Wikisource properly... It is somehow part of the same problem.

Technical teams have been around 15 years externalizing an interface ecosystem 
to not confront that what needs to be improved and reintegrated is Mediawiki 
itself. The result is a labyrinth for the newcomers and a vast ocean of pending 
updates and bugs. Video failures are among the symptoms of such software 
externalization.

Salutacions/Best,

Xavier Dengra
El divendres, 26 de gener 2024 a les 08:53, Jan Ainali  va 
escriure:

> Den fre 26 jan. 2024 kl 04:10 skrev Samuel Klein :
>
>> Brion wrote:
>>> 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.
>>
>> Yes, this is essential. Can be via a separate videowiki in the short term 
>> (or NCcommons) if the WM Commons community is united in opposition.
>
> I disagree. Using non-open tools in our workflows is a poison that should be 
> resisted by any means possible.
>
> Instead, we should create an app (or integrate in the Commons app), the 
> possibility to record video natively in a free and open format.
> Yes, it would be a big task, but it would show that we mean what we say when 
> we talk about the essential infrastructure of the ecosystem of free knowledge 
> and would be of great benefit not only to our movement, but to the society in 
> general.
>
> /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/TNFH6T6Z6FRCKH2YPKHQPCFYDJEYHQVZ/
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

[Jan Ainali]

Den fre 26 jan. 2024 kl 04:10 skrev Samuel Klein :

>
> Brion wrote:
> > 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.
>
> Yes, this is essential.  Can be via a separate videowiki in the short term
> (or NCcommons) if the WM Commons community is united in opposition.
>

I disagree. Using non-open tools in our workflows is a poison that should
be resisted by any means possible.

Instead, we should create an app (or integrate in the Commons app), the
possibility to record video natively in a free and open format.
Yes, it would be a big task, but it would show that we mean what we say
when we talk about the essential infrastructure of the ecosystem of free
knowledge and would be of great benefit not only to our movement, but to
the society in general.

/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/J7QKQ5J3HENCGVDHL6X6HVMZVM7CRWMV/
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

[Eduardo Testart]

Hi all,

Who is in charge to make the call for this to happen?

It just seems so necessary and yet, here we are. Video handling is not the
future, is the present, and that's just the beginning...


Cheers,

On Fri, Jan 26, 2024, 00:10 Samuel Klein  wrote:

> On Thu, Jan 25, 2024 at 9:51 PM Ivan Martínez  wrote:
>
> Strategy 2030 was clear that the way was in the opposite direction
>> 
>> .
>>
>
> Absolutely.  That has only become more true.   (Happy new year, my friend.)
>
> Brion wrote:
> > 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.
>
> Yes, this is essential.  Can be via a separate videowiki in the short term
> (or NCcommons) if the WM Commons community is united in opposition.
>
> > 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
>
> Yes. Just to coordinate + streamline all the development, design, and
> coordination across the movement.  It would likely save everyone time and
> resources in the end, instead of so many half-focused groups and good ideas
> hitting dead ends.
>
> wʍ, SJ
> ___
> 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/PBTTFDOZTFQOKFX6KRGN25HWRPG6FTHR/
> 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/UVLCWM7A537EJSGNNBI3THBDP7O4IGBY/
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]

On Thu, Jan 25, 2024 at 9:51 PM Ivan Martínez  wrote:

Strategy 2030 was clear that the way was in the opposite direction
> 
> .
>

Absolutely.  That has only become more true.   (Happy new year, my friend.)

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

Yes, this is essential.  Can be via a separate videowiki in the short term
(or NCcommons) if the WM Commons community is united in opposition.

> 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

Yes. Just to coordinate + streamline all the development, design, and
coordination across the movement.  It would likely save everyone time and
resources in the end, instead of so many half-focused groups and good ideas
hitting dead ends.

wʍ, SJ
___
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/PBTTFDOZTFQOKFX6KRGN25HWRPG6FTHR/
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

[Ivan Martínez]

And with this thread, we had an example of exactly what tends to happen to
novices, to new contributors, to interested people who are used to other
simpler interfaces. Faced with raising a problem like the one Galder
exposed, and having as an answer the technicalities and the tortuous path
of having to go through 10 steps to place a video that is aligned with the
Commons mission.

I love the *different* way of our free and openly developed community
tools, except that Strategy 2030 was clear that the way was in the opposite
direction
<https://meta.wikimedia.org/wiki/Movement_Strategy/Recommendations/Improve_User_Experience>
.

Best,

El mié, 24 ene 2024 a las 11:13, Galder Gonzalez Larrañaga (<
galder...@hotmail.com>) escribió:

> Thanks for the links, Yaroslav, I'll take a look.
>
> About the embedding, yes, you can embed an image using HTML code. You
> can't embed an image or a video using oEmbed, so you can't share a video
> from Commons in, lets's say, Facebook. And you can't just add the URL of
> the video in WordPress and play it, like millions of blogs are doing with
> YouTube or Vimeo videos. So you can't share externally a video (or an
> image) just using the URL, which is one of the main entry points YouTube is
> using for external playing. Is it technically possible to embed a video
> from Commons in a place which is not Facebook/Xitter/Mastodon... yes, it
> is, but coding is necessary, which is not how to make Commons part of the
> essential ecosystem of free knowledge.
>
> In the same way, you can upload a video to Commons. We upload two every
> week for the project Ikusgela (
> https://eu.wikipedia.org/wiki/Atari:Hezkuntza/Ikusgela), but it's not a
> simple process, which is the point of this message.
>
> Thanks
>
> Galder
>
>
> --
> *From:* Yaroslav Blanter 
> *Sent:* Wednesday, January 24, 2024 5:59 PM
> *To:* Wikimedia Mailing List 
> *Subject:* [Wikimedia-l] Re: We need more interactive content: we are
> doing it wrong
>
> Dear All,
>
> I can easily find two recent discussions which touch the topic of video on
> Commons:
>
>
> https://commons.wikimedia.org/wiki/Commons:Village_pump/Archive/2023/12#Prioritizing_our_technical_needs
>
> and
>
>
> https://commons.wikimedia.org/wiki/Commons_talk:Requests_for_comment/Technical_needs_survey#No_objection,_but.
> ..
>
> I am sure there were more.
>
> I do not know whether videos can be embedded externally, but images
> certainly can. I for example embed them in my blog (random example:
> https://ymblanter.dreamwidth.org/146913.html; the text is in Russian
> which is irrelevant for my point). I have been doing this for years and
> never encountered any issues.
>
> Best
> Yaroslav
>
> On Wed, Jan 24, 2024 at 8:00 AM Gnangarra  wrote:
>
> Kaya
>
> I'd like to my perspective from wikimania side the amount of effort
> volunteers and time to bring every session alive on commons is all
> consuming yes YouTube is the best place to put that content.  It gets
> harder the smaller the event is. Video needs to be addresses as a priority
> along with issues raise by galder. Simple mp4 upload option would be a
> starting point, surely we are big enough for any copyright holders to
> donate the licensing if wmf comes made a request
>
> On Wed, 24 Jan 2024, 2:44 pm Mrb Rafi,  wrote:
>
> +1 to Galder.
>
> Sharing a current situation.
>
> A significant number of non wikimedian photographers participate in the
> wiki loves X campaigns and since the upload process in commons is complex
> than any other site, most of them feel lost and don't retain.
>
> We are arranging wiki loves folklore in Bangladesh this year and we have
> prepared a handbook for the participants considering the above situation.
> The handbook has been uploaded to commons and now we're receiving feedback
> that our participants are feeling lost after visiting the description page,
> they can't decide how to view the pdf.
>
> Wikimedia commons needs a user friendly and intuitive pdf viewer asap.
>
> Best,
> Rafi
>
> On Wed, Jan 24, 2024, 4:24 AM Ivan Martínez  wrote:
>
> Thank you Yaroslav, I would very much appreciate a link to the discussion.
> By not having a Youtube 2.0 we are avoiding a Wikipedia 2.0 with pure
> encyclopaedic videos. I see a false dilemma there.
>
> El mar, 23 ene 2024 a las 16:03, Galder Gonzalez Larrañaga (<
> galder...@hotmail.com>) escribió:
>
> Thanks to everyone for your comments.
> We don't need to worry about Commons being "Youtube 2.0", because we can't
> embed Commons video outside. Furthermore, we can't even embed Commons
> images or videos in Diff, because oEmbed is not working for Commons and
> Wordpress c

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

[Galder Gonzalez Larrañaga]

Thanks for the links, Yaroslav, I'll take a look.

About the embedding, yes, you can embed an image using HTML code. You can't 
embed an image or a video using oEmbed, so you can't share a video from Commons 
in, lets's say, Facebook. And you can't just add the URL of the video in 
WordPress and play it, like millions of blogs are doing with YouTube or Vimeo 
videos. So you can't share externally a video (or an image) just using the URL, 
which is one of the main entry points YouTube is using for external playing. Is 
it technically possible to embed a video from Commons in a place which is not 
Facebook/Xitter/Mastodon... yes, it is, but coding is necessary, which is not 
how to make Commons part of the essential ecosystem of free knowledge.

In the same way, you can upload a video to Commons. We upload two every week 
for the project Ikusgela 
(https://eu.wikipedia.org/wiki/Atari:Hezkuntza/Ikusgela), but it's not a simple 
process, which is the point of this message.

Thanks

Galder



From: Yaroslav Blanter 
Sent: Wednesday, January 24, 2024 5:59 PM
To: Wikimedia Mailing List 
Subject: [Wikimedia-l] Re: We need more interactive content: we are doing it 
wrong

Dear All,

I can easily find two recent discussions which touch the topic of video on 
Commons:

https://commons.wikimedia.org/wiki/Commons:Village_pump/Archive/2023/12#Prioritizing_our_technical_needs

and

https://commons.wikimedia.org/wiki/Commons_talk:Requests_for_comment/Technical_needs_survey#No_objection,_but...

I am sure there were more.

I do not know whether videos can be embedded externally, but images certainly 
can. I for example embed them in my blog (random example: 
https://ymblanter.dreamwidth.org/146913.html; the text is in Russian which is 
irrelevant for my point). I have been doing this for years and never 
encountered any issues.

Best
Yaroslav

On Wed, Jan 24, 2024 at 8:00 AM Gnangarra 
mailto:gnanga...@gmail.com>> wrote:
Kaya

I'd like to my perspective from wikimania side the amount of effort volunteers 
and time to bring every session alive on commons is all consuming yes YouTube 
is the best place to put that content.  It gets harder the smaller the event 
is. Video needs to be addresses as a priority along with issues raise by 
galder. Simple mp4 upload option would be a starting point, surely we are big 
enough for any copyright holders to donate the licensing if wmf comes made a 
request

On Wed, 24 Jan 2024, 2:44 pm Mrb Rafi, 
mailto:mrbrafi1...@gmail.com>> wrote:
+1 to Galder.

Sharing a current situation.

A significant number of non wikimedian photographers participate in the wiki 
loves X campaigns and since the upload process in commons is complex than any 
other site, most of them feel lost and don't retain.

We are arranging wiki loves folklore in Bangladesh this year and we have 
prepared a handbook for the participants considering the above situation. The 
handbook has been uploaded to commons and now we're receiving feedback that our 
participants are feeling lost after visiting the description page, they can't 
decide how to view the pdf.

Wikimedia commons needs a user friendly and intuitive pdf viewer asap.

Best,
Rafi

On Wed, Jan 24, 2024, 4:24 AM Ivan Martínez 
mailto:gala...@gmail.com>> wrote:
Thank you Yaroslav, I would very much appreciate a link to the discussion.
By not having a Youtube 2.0 we are avoiding a Wikipedia 2.0 with pure 
encyclopaedic videos. I see a false dilemma there.

El mar, 23 ene 2024 a las 16:03, Galder Gonzalez Larrañaga 
(mailto:galder...@hotmail.com>>) escribió:
Thanks to everyone for your comments.
We don't need to worry about Commons being "Youtube 2.0", because we can't 
embed Commons video outside. Furthermore, we can't even embed Commons images or 
videos in Diff, because oEmbed is not working for Commons and Wordpress can't 
take directly images or videos from Commons. This has been known since... 2010!


  *
https://phabricator.wikimedia.org/T27854
  *
https://phabricator.wikimedia.org/T309101

Again, the problem is not about this code or that specific piece of code. The 
problem is lack of direction, ambition and goals.

Cheers,

Galder

From: James Heilman mailto:jmh...@gmail.com>>
Sent: Tuesday, January 23, 2024 10:49 PM
To: Wikimedia Mailing List 
mailto:wikimedia-l@lists.wikimedia.org>>
Subject: [Wikimedia-l] Re: We need more interactive content: we are doing it 
wrong

Yes we see this sentiment regarding a number of issues in our movement. The 
existing community wants to keep certain processes more difficult / time 
consuming to make sure that those involved in the process are sufficiently 
"dedicated".

Maybe we just need a flag which can be given to allow certain folks we trust to 
use an easier process or only allow video upload by people with so many edits 
which can be removed if they misuse it?

James

On Tue, Jan 23, 2024 at 2

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

[Yaroslav Blanter]

Dear All,

I can easily find two recent discussions which touch the topic of video on
Commons:

https://commons.wikimedia.org/wiki/Commons:Village_pump/Archive/2023/12#Prioritizing_our_technical_needs

and

https://commons.wikimedia.org/wiki/Commons_talk:Requests_for_comment/Technical_needs_survey#No_objection,_but.
..

I am sure there were more.

I do not know whether videos can be embedded externally, but images
certainly can. I for example embed them in my blog (random example:
https://ymblanter.dreamwidth.org/146913.html; the text is in Russian which
is irrelevant for my point). I have been doing this for years and never
encountered any issues.

Best
Yaroslav

On Wed, Jan 24, 2024 at 8:00 AM Gnangarra  wrote:

> Kaya
>
> I'd like to my perspective from wikimania side the amount of effort
> volunteers and time to bring every session alive on commons is all
> consuming yes YouTube is the best place to put that content.  It gets
> harder the smaller the event is. Video needs to be addresses as a priority
> along with issues raise by galder. Simple mp4 upload option would be a
> starting point, surely we are big enough for any copyright holders to
> donate the licensing if wmf comes made a request
>
> On Wed, 24 Jan 2024, 2:44 pm Mrb Rafi,  wrote:
>
>> +1 to Galder.
>>
>> Sharing a current situation.
>>
>> A significant number of non wikimedian photographers participate in the
>> wiki loves X campaigns and since the upload process in commons is complex
>> than any other site, most of them feel lost and don't retain.
>>
>> We are arranging wiki loves folklore in Bangladesh this year and we have
>> prepared a handbook for the participants considering the above situation.
>> The handbook has been uploaded to commons and now we're receiving feedback
>> that our participants are feeling lost after visiting the description page,
>> they can't decide how to view the pdf.
>>
>> Wikimedia commons needs a user friendly and intuitive pdf viewer asap.
>>
>> Best,
>> Rafi
>>
>> On Wed, Jan 24, 2024, 4:24 AM Ivan Martínez  wrote:
>>
>>> Thank you Yaroslav, I would very much appreciate a link to the
>>> discussion.
>>> By not having a Youtube 2.0 we are avoiding a Wikipedia 2.0 with pure
>>> encyclopaedic videos. I see a false dilemma there.
>>>
>>> El mar, 23 ene 2024 a las 16:03, Galder Gonzalez Larrañaga (<
>>> galder...@hotmail.com>) escribió:
>>>
>>>> Thanks to everyone for your comments.
>>>> We don't need to worry about Commons being "Youtube 2.0", because we
>>>> can't embed Commons video outside. Furthermore, we can't even embed Commons
>>>> images or videos in Diff, because oEmbed is not working for Commons and
>>>> Wordpress can't take directly images or videos from Commons. This has been
>>>> known since... 2010!
>>>>
>>>>
>>>>- https://phabricator.wikimedia.org/T27854
>>>>- https://phabricator.wikimedia.org/T309101
>>>>
>>>>
>>>> Again, the problem is not about this code or that specific piece of
>>>> code. The problem is lack of direction, ambition and goals.
>>>>
>>>> Cheers,
>>>>
>>>> Galder
>>>> --
>>>> *From:* James Heilman 
>>>> *Sent:* Tuesday, January 23, 2024 10:49 PM
>>>> *To:* Wikimedia Mailing List 
>>>> *Subject:* [Wikimedia-l] Re: We need more interactive content: we are
>>>> doing it wrong
>>>>
>>>> Yes we see this sentiment regarding a number of issues in our movement.
>>>> The existing community wants to keep certain processes more difficult /
>>>> time consuming to make sure that those involved in the process are
>>>> sufficiently "dedicated".
>>>>
>>>> Maybe we just need a flag which can be given to allow certain folks we
>>>> trust to use an easier process or only allow video upload by people with so
>>>> many edits which can be removed if they misuse it?
>>>>
>>>> James
>>>>
>>>> On Tue, Jan 23, 2024 at 2:38 PM Yaroslav Blanter 
>>>> wrote:
>>>>
>>>> Specifically related to video uploads, we had discussions on Commons on
>>>> different strategic issues recently, in particular, about this. The general
>>>> sentiment was, to my understanding (pls correct me if I am wrong) that
>>>> Commons has no ambition to become Youtube 2.0 and we do not have any
>>>> resources for this. If 

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

[Gnangarra]

Kaya

I'd like to my perspective from wikimania side the amount of effort
volunteers and time to bring every session alive on commons is all
consuming yes YouTube is the best place to put that content.  It gets
harder the smaller the event is. Video needs to be addresses as a priority
along with issues raise by galder. Simple mp4 upload option would be a
starting point, surely we are big enough for any copyright holders to
donate the licensing if wmf comes made a request

On Wed, 24 Jan 2024, 2:44 pm Mrb Rafi,  wrote:

> +1 to Galder.
>
> Sharing a current situation.
>
> A significant number of non wikimedian photographers participate in the
> wiki loves X campaigns and since the upload process in commons is complex
> than any other site, most of them feel lost and don't retain.
>
> We are arranging wiki loves folklore in Bangladesh this year and we have
> prepared a handbook for the participants considering the above situation.
> The handbook has been uploaded to commons and now we're receiving feedback
> that our participants are feeling lost after visiting the description page,
> they can't decide how to view the pdf.
>
> Wikimedia commons needs a user friendly and intuitive pdf viewer asap.
>
> Best,
> Rafi
>
> On Wed, Jan 24, 2024, 4:24 AM Ivan Martínez  wrote:
>
>> Thank you Yaroslav, I would very much appreciate a link to the discussion.
>> By not having a Youtube 2.0 we are avoiding a Wikipedia 2.0 with pure
>> encyclopaedic videos. I see a false dilemma there.
>>
>> El mar, 23 ene 2024 a las 16:03, Galder Gonzalez Larrañaga (<
>> galder...@hotmail.com>) escribió:
>>
>>> Thanks to everyone for your comments.
>>> We don't need to worry about Commons being "Youtube 2.0", because we
>>> can't embed Commons video outside. Furthermore, we can't even embed Commons
>>> images or videos in Diff, because oEmbed is not working for Commons and
>>> Wordpress can't take directly images or videos from Commons. This has been
>>> known since... 2010!
>>>
>>>
>>>- https://phabricator.wikimedia.org/T27854
>>>- https://phabricator.wikimedia.org/T309101
>>>
>>>
>>> Again, the problem is not about this code or that specific piece of
>>> code. The problem is lack of direction, ambition and goals.
>>>
>>> Cheers,
>>>
>>> Galder
>>> --
>>> *From:* James Heilman 
>>> *Sent:* Tuesday, January 23, 2024 10:49 PM
>>> *To:* Wikimedia Mailing List 
>>> *Subject:* [Wikimedia-l] Re: We need more interactive content: we are
>>> doing it wrong
>>>
>>> Yes we see this sentiment regarding a number of issues in our movement.
>>> The existing community wants to keep certain processes more difficult /
>>> time consuming to make sure that those involved in the process are
>>> sufficiently "dedicated".
>>>
>>> Maybe we just need a flag which can be given to allow certain folks we
>>> trust to use an easier process or only allow video upload by people with so
>>> many edits which can be removed if they misuse it?
>>>
>>> James
>>>
>>> On Tue, Jan 23, 2024 at 2:38 PM Yaroslav Blanter 
>>> wrote:
>>>
>>> Specifically related to video uploads, we had discussions on Commons on
>>> different strategic issues recently, in particular, about this. The general
>>> sentiment was, to my understanding (pls correct me if I am wrong) that
>>> Commons has no ambition to become Youtube 2.0 and we do not have any
>>> resources for this. If video upload is encouraged, very strict policies
>>> must be in force concerning of what is in the scope of Commons.
>>>
>>> Best
>>> Yaroslav
>>>
>>> On Tue, Jan 23, 2024 at 10:05 PM Brion Vibber 
>>> wrote:
>>>
>>> Converting them to suitably compact files in h.264/aac in .MP4 format
>>> would be by far the simplest way. Use ffmpeg as we do on the server side
>>> for online playback.
>>>
>>> Conforming to the arbitrary Wikimedia prohibition on h.264 you could use
>>> mpeg-4 visual instead, still in .mp4 - afaik patents are expired and it'll
>>> play in standalone files (not in HLS)
>>>
>>> If you jump through enough hoops you might get vp9 working in HLS
>>> offline, but adaptive streaming may be irrelevant to offline use.
>>>
>>> -- brion
>>>
>>> On Tue, Jan 23, 2024, 12:52 PM James Heilman  wrote:
>>>
>>> It would be amazing if one could play videos o

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

[Mrb Rafi]

+1 to Galder.

Sharing a current situation.

A significant number of non wikimedian photographers participate in the
wiki loves X campaigns and since the upload process in commons is complex
than any other site, most of them feel lost and don't retain.

We are arranging wiki loves folklore in Bangladesh this year and we have
prepared a handbook for the participants considering the above situation.
The handbook has been uploaded to commons and now we're receiving feedback
that our participants are feeling lost after visiting the description page,
they can't decide how to view the pdf.

Wikimedia commons needs a user friendly and intuitive pdf viewer asap.

Best,
Rafi

On Wed, Jan 24, 2024, 4:24 AM Ivan Martínez  wrote:

> Thank you Yaroslav, I would very much appreciate a link to the discussion.
> By not having a Youtube 2.0 we are avoiding a Wikipedia 2.0 with pure
> encyclopaedic videos. I see a false dilemma there.
>
> El mar, 23 ene 2024 a las 16:03, Galder Gonzalez Larrañaga (<
> galder...@hotmail.com>) escribió:
>
>> Thanks to everyone for your comments.
>> We don't need to worry about Commons being "Youtube 2.0", because we
>> can't embed Commons video outside. Furthermore, we can't even embed Commons
>> images or videos in Diff, because oEmbed is not working for Commons and
>> Wordpress can't take directly images or videos from Commons. This has been
>> known since... 2010!
>>
>>
>>- https://phabricator.wikimedia.org/T27854
>>- https://phabricator.wikimedia.org/T309101
>>
>>
>> Again, the problem is not about this code or that specific piece of code.
>> The problem is lack of direction, ambition and goals.
>>
>> Cheers,
>>
>> Galder
>> --------------
>> *From:* James Heilman 
>> *Sent:* Tuesday, January 23, 2024 10:49 PM
>> *To:* Wikimedia Mailing List 
>> *Subject:* [Wikimedia-l] Re: We need more interactive content: we are
>> doing it wrong
>>
>> Yes we see this sentiment regarding a number of issues in our movement.
>> The existing community wants to keep certain processes more difficult /
>> time consuming to make sure that those involved in the process are
>> sufficiently "dedicated".
>>
>> Maybe we just need a flag which can be given to allow certain folks we
>> trust to use an easier process or only allow video upload by people with so
>> many edits which can be removed if they misuse it?
>>
>> James
>>
>> On Tue, Jan 23, 2024 at 2:38 PM Yaroslav Blanter 
>> wrote:
>>
>> Specifically related to video uploads, we had discussions on Commons on
>> different strategic issues recently, in particular, about this. The general
>> sentiment was, to my understanding (pls correct me if I am wrong) that
>> Commons has no ambition to become Youtube 2.0 and we do not have any
>> resources for this. If video upload is encouraged, very strict policies
>> must be in force concerning of what is in the scope of Commons.
>>
>> Best
>> Yaroslav
>>
>> On Tue, Jan 23, 2024 at 10:05 PM Brion Vibber 
>> wrote:
>>
>> Converting them to suitably compact files in h.264/aac in .MP4 format
>> would be by far the simplest way. Use ffmpeg as we do on the server side
>> for online playback.
>>
>> Conforming to the arbitrary Wikimedia prohibition on h.264 you could use
>> mpeg-4 visual instead, still in .mp4 - afaik patents are expired and it'll
>> play in standalone files (not in HLS)
>>
>> If you jump through enough hoops you might get vp9 working in HLS
>> offline, but adaptive streaming may be irrelevant to offline use.
>>
>> -- brion
>>
>> On Tue, Jan 23, 2024, 12:52 PM James Heilman  wrote:
>>
>> It would be amazing if one could play videos on iPhones when the videos
>> are within ZIMs in an offline environment aswell. Brion not sure what
>> barriers there are to this currently?
>>
>> James
>>
>> On Tue, Jan 23, 2024 at 12:48 PM Paulo Santos Perneta <
>> paulospern...@gmail.com> wrote:
>>
>> Should read 2030 Strategy, not 2023 strategy, sorry.
>>
>> Paulo Santos Perneta  escreveu (terça,
>> 23/01/2024 à(s) 19:41):
>>
>> I wholeheartedly agree with this sentiment. We are currently grappling
>> with rather rudimentary approaches when it comes to uploading and reusing
>> video and music files...
>> The incredibly useful Graph has been down for quite some time. The
>> extensive capabilities of Wikidata query representations, particularly with
>> geolocated data on maps, appear to have barely scratched the surface.
>> Liste

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

[Ivan Martínez]

Thank you Yaroslav, I would very much appreciate a link to the discussion.
By not having a Youtube 2.0 we are avoiding a Wikipedia 2.0 with pure
encyclopaedic videos. I see a false dilemma there.

El mar, 23 ene 2024 a las 16:03, Galder Gonzalez Larrañaga (<
galder...@hotmail.com>) escribió:

> Thanks to everyone for your comments.
> We don't need to worry about Commons being "Youtube 2.0", because we can't
> embed Commons video outside. Furthermore, we can't even embed Commons
> images or videos in Diff, because oEmbed is not working for Commons and
> Wordpress can't take directly images or videos from Commons. This has been
> known since... 2010!
>
>
>- https://phabricator.wikimedia.org/T27854
>- https://phabricator.wikimedia.org/T309101
>
>
> Again, the problem is not about this code or that specific piece of code.
> The problem is lack of direction, ambition and goals.
>
> Cheers,
>
> Galder
> --
> *From:* James Heilman 
> *Sent:* Tuesday, January 23, 2024 10:49 PM
> *To:* Wikimedia Mailing List 
> *Subject:* [Wikimedia-l] Re: We need more interactive content: we are
> doing it wrong
>
> Yes we see this sentiment regarding a number of issues in our movement.
> The existing community wants to keep certain processes more difficult /
> time consuming to make sure that those involved in the process are
> sufficiently "dedicated".
>
> Maybe we just need a flag which can be given to allow certain folks we
> trust to use an easier process or only allow video upload by people with so
> many edits which can be removed if they misuse it?
>
> James
>
> On Tue, Jan 23, 2024 at 2:38 PM Yaroslav Blanter  wrote:
>
> Specifically related to video uploads, we had discussions on Commons on
> different strategic issues recently, in particular, about this. The general
> sentiment was, to my understanding (pls correct me if I am wrong) that
> Commons has no ambition to become Youtube 2.0 and we do not have any
> resources for this. If video upload is encouraged, very strict policies
> must be in force concerning of what is in the scope of Commons.
>
> Best
> Yaroslav
>
> On Tue, Jan 23, 2024 at 10:05 PM Brion Vibber 
> wrote:
>
> Converting them to suitably compact files in h.264/aac in .MP4 format
> would be by far the simplest way. Use ffmpeg as we do on the server side
> for online playback.
>
> Conforming to the arbitrary Wikimedia prohibition on h.264 you could use
> mpeg-4 visual instead, still in .mp4 - afaik patents are expired and it'll
> play in standalone files (not in HLS)
>
> If you jump through enough hoops you might get vp9 working in HLS offline,
> but adaptive streaming may be irrelevant to offline use.
>
> -- brion
>
> On Tue, Jan 23, 2024, 12:52 PM James Heilman  wrote:
>
> It would be amazing if one could play videos on iPhones when the videos
> are within ZIMs in an offline environment aswell. Brion not sure what
> barriers there are to this currently?
>
> James
>
> On Tue, Jan 23, 2024 at 12:48 PM Paulo Santos Perneta <
> paulospern...@gmail.com> wrote:
>
> Should read 2030 Strategy, not 2023 strategy, sorry.
>
> Paulo Santos Perneta  escreveu (terça,
> 23/01/2024 à(s) 19:41):
>
> I wholeheartedly agree with this sentiment. We are currently grappling
> with rather rudimentary approaches when it comes to uploading and reusing
> video and music files...
> The incredibly useful Graph has been down for quite some time. The
> extensive capabilities of Wikidata query representations, particularly with
> geolocated data on maps, appear to have barely scratched the surface.
> Listeria frequently experiences issues and underwent a major update that
> disrupted previous queries.
>
> On a personal note, I attempted to create a dynamic digital library of
> works under a free license using Wikidata for our Digital Humanistics
> centre. However, I discovered that with the available tools, I would need
> to code the presentation myself, as the options for reuse outside of
> Wikidata were very basic.
>
> On the whole, the Wikipedia experience remains challenging, especially for
> newcomers. The much wanted Visual Editor developments and improvements seem
> to have stopped years ago. The recent changes made by the 'Desktop
> Improvement' team to the default Wikipedia skin seem to be more geared
> towards readers than editors and have apparently worsened the overall
> experience, according to feedback I've received from newcomers.
>
> These are just a few instances that have underscored, and continue to
> underscore, my belief that we are likely not on the path towards achieving
> the objectives outlined in the 2023 Strategy.
>
> My

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

[Galder Gonzalez Larrañaga]

Thanks to everyone for your comments.
We don't need to worry about Commons being "Youtube 2.0", because we can't 
embed Commons video outside. Furthermore, we can't even embed Commons images or 
videos in Diff, because oEmbed is not working for Commons and Wordpress can't 
take directly images or videos from Commons. This has been known since... 2010!


  *
https://phabricator.wikimedia.org/T27854
  *
https://phabricator.wikimedia.org/T309101

Again, the problem is not about this code or that specific piece of code. The 
problem is lack of direction, ambition and goals.

Cheers,

Galder

From: James Heilman 
Sent: Tuesday, January 23, 2024 10:49 PM
To: Wikimedia Mailing List 
Subject: [Wikimedia-l] Re: We need more interactive content: we are doing it 
wrong

Yes we see this sentiment regarding a number of issues in our movement. The 
existing community wants to keep certain processes more difficult / time 
consuming to make sure that those involved in the process are sufficiently 
"dedicated".

Maybe we just need a flag which can be given to allow certain folks we trust to 
use an easier process or only allow video upload by people with so many edits 
which can be removed if they misuse it?

James

On Tue, Jan 23, 2024 at 2:38 PM Yaroslav Blanter 
mailto:ymb...@gmail.com>> wrote:
Specifically related to video uploads, we had discussions on Commons on 
different strategic issues recently, in particular, about this. The general 
sentiment was, to my understanding (pls correct me if I am wrong) that Commons 
has no ambition to become Youtube 2.0 and we do not have any resources for 
this. If video upload is encouraged, very strict policies must be in force 
concerning of what is in the scope of Commons.

Best
Yaroslav

On Tue, Jan 23, 2024 at 10:05 PM Brion Vibber 
mailto:bvib...@wikimedia.org>> wrote:
Converting them to suitably compact files in h.264/aac in .MP4 format would be 
by far the simplest way. Use ffmpeg as we do on the server side for online 
playback.

Conforming to the arbitrary Wikimedia prohibition on h.264 you could use mpeg-4 
visual instead, still in .mp4 - afaik patents are expired and it'll play in 
standalone files (not in HLS)

If you jump through enough hoops you might get vp9 working in HLS offline, but 
adaptive streaming may be irrelevant to offline use.

-- brion

On Tue, Jan 23, 2024, 12:52 PM James Heilman 
mailto:jmh...@gmail.com>> wrote:
It would be amazing if one could play videos on iPhones when the videos are 
within ZIMs in an offline environment aswell. Brion not sure what barriers 
there are to this currently?

James

On Tue, Jan 23, 2024 at 12:48 PM Paulo Santos Perneta 
mailto:paulospern...@gmail.com>> wrote:
Should read 2030 Strategy, not 2023 strategy, sorry.

Paulo Santos Perneta mailto:paulospern...@gmail.com>> 
escreveu (terça, 23/01/2024 à(s) 19:41):
I wholeheartedly agree with this sentiment. We are currently grappling with 
rather rudimentary approaches when it comes to uploading and reusing video and 
music files...
The incredibly useful Graph has been down for quite some time. The extensive 
capabilities of Wikidata query representations, particularly with geolocated 
data on maps, appear to have barely scratched the surface. Listeria frequently 
experiences issues and underwent a major update that disrupted previous queries.

On a personal note, I attempted to create a dynamic digital library of works 
under a free license using Wikidata for our Digital Humanistics centre. 
However, I discovered that with the available tools, I would need to code the 
presentation myself, as the options for reuse outside of Wikidata were very 
basic.

On the whole, the Wikipedia experience remains challenging, especially for 
newcomers. The much wanted Visual Editor developments and improvements seem to 
have stopped years ago. The recent changes made by the 'Desktop Improvement' 
team to the default Wikipedia skin seem to be more geared towards readers than 
editors and have apparently worsened the overall experience, according to 
feedback I've received from newcomers.

These are just a few instances that have underscored, and continue to 
underscore, my belief that we are likely not on the path towards achieving the 
objectives outlined in the 2023 Strategy.

My personal impression is that the issue doesn't necessarily stem from a lack 
of funding to pursue these objectives but rather from the ineffective 
expenditure and allocation of those funds. I wish I knew how to contribute to 
changing or improving this situation.
It would also be great to see a comment/opinion from current CEO Maryana 
Iskander on this state of affairs, and if there is some roadmap for improving 
it.

Best,
Paulo


Galder Gonzalez Larrañaga mailto:galder...@hotmail.com>> 
escreveu (terça, 23/01/2024 à(s) 11:03):
Dear wikimedians,
Nearly one year ago, the Graphs extension was disabled from all wikis, because 

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

[James Heilman]

Yes we see this sentiment regarding a number of issues in our movement. The
existing community wants to keep certain processes more difficult / time
consuming to make sure that those involved in the process are sufficiently
"dedicated".

Maybe we just need a flag which can be given to allow certain folks we
trust to use an easier process or only allow video upload by people with so
many edits which can be removed if they misuse it?

James

On Tue, Jan 23, 2024 at 2:38 PM Yaroslav Blanter  wrote:

> Specifically related to video uploads, we had discussions on Commons on
> different strategic issues recently, in particular, about this. The general
> sentiment was, to my understanding (pls correct me if I am wrong) that
> Commons has no ambition to become Youtube 2.0 and we do not have any
> resources for this. If video upload is encouraged, very strict policies
> must be in force concerning of what is in the scope of Commons.
>
> Best
> Yaroslav
>
> On Tue, Jan 23, 2024 at 10:05 PM Brion Vibber 
> wrote:
>
>> Converting them to suitably compact files in h.264/aac in .MP4 format
>> would be by far the simplest way. Use ffmpeg as we do on the server side
>> for online playback.
>>
>> Conforming to the arbitrary Wikimedia prohibition on h.264 you could use
>> mpeg-4 visual instead, still in .mp4 - afaik patents are expired and it'll
>> play in standalone files (not in HLS)
>>
>> If you jump through enough hoops you might get vp9 working in HLS
>> offline, but adaptive streaming may be irrelevant to offline use.
>>
>> -- brion
>>
>> On Tue, Jan 23, 2024, 12:52 PM James Heilman  wrote:
>>
>>> It would be amazing if one could play videos on iPhones when the videos
>>> are within ZIMs in an offline environment aswell. Brion not sure what
>>> barriers there are to this currently?
>>>
>>> James
>>>
>>> On Tue, Jan 23, 2024 at 12:48 PM Paulo Santos Perneta <
>>> paulospern...@gmail.com> wrote:
>>>
 Should read 2030 Strategy, not 2023 strategy, sorry.

 Paulo Santos Perneta  escreveu (terça,
 23/01/2024 à(s) 19:41):

> I wholeheartedly agree with this sentiment. We are currently grappling
> with rather rudimentary approaches when it comes to uploading and reusing
> video and music files...
> The incredibly useful Graph has been down for quite some time. The
> extensive capabilities of Wikidata query representations, particularly 
> with
> geolocated data on maps, appear to have barely scratched the surface.
> Listeria frequently experiences issues and underwent a major update that
> disrupted previous queries.
>
> On a personal note, I attempted to create a dynamic digital library of
> works under a free license using Wikidata for our Digital Humanistics
> centre. However, I discovered that with the available tools, I would need
> to code the presentation myself, as the options for reuse outside of
> Wikidata were very basic.
>
> On the whole, the Wikipedia experience remains challenging, especially
> for newcomers. The much wanted Visual Editor developments and improvements
> seem to have stopped years ago. The recent changes made by the 'Desktop
> Improvement' team to the default Wikipedia skin seem to be more geared
> towards readers than editors and have apparently worsened the overall
> experience, according to feedback I've received from newcomers.
>
> These are just a few instances that have underscored, and continue to
> underscore, my belief that we are likely not on the path towards achieving
> the objectives outlined in the 2023 Strategy.
>
> My personal impression is that the issue doesn't necessarily stem from
> a lack of funding to pursue these objectives but rather from the
> ineffective expenditure and allocation of those funds. I wish I knew how 
> to
> contribute to changing or improving this situation.
> It would also be great to see a comment/opinion from current CEO
> Maryana Iskander on this state of affairs, and if there is some roadmap 
> for
> improving it.
>
> Best,
> Paulo
>
>
> Galder Gonzalez Larrañaga  escreveu (terça,
> 23/01/2024 à(s) 11:03):
>
>> Dear wikimedians,
>> Nearly one year ago, the Graphs extension was disabled from all
>> wikis, because there was a security issue that should be solved (
>> https://phabricator.wikimedia.org/T334940). A wide team from the WMF
>> worked on a solution for some weeks, but after Northern Hemisphere spring
>> ended, summer came, then the monsoon season, and now it is again summer 
>> in
>> the Southern Hemisphere... and Graphs are still disabled. All the 
>> solutions
>> proposed have been dismissed, but every two months there's a proposal to
>> make a new roadmap to solve the issue. We have plenty of roadmaps, but no
>> vehicle to reach our destination.
>>
>> Seven years ago, we were discussing our 

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

[Yaroslav Blanter]

Specifically related to video uploads, we had discussions on Commons on
different strategic issues recently, in particular, about this. The general
sentiment was, to my understanding (pls correct me if I am wrong) that
Commons has no ambition to become Youtube 2.0 and we do not have any
resources for this. If video upload is encouraged, very strict policies
must be in force concerning of what is in the scope of Commons.

Best
Yaroslav

On Tue, Jan 23, 2024 at 10:05 PM Brion Vibber  wrote:

> Converting them to suitably compact files in h.264/aac in .MP4 format
> would be by far the simplest way. Use ffmpeg as we do on the server side
> for online playback.
>
> Conforming to the arbitrary Wikimedia prohibition on h.264 you could use
> mpeg-4 visual instead, still in .mp4 - afaik patents are expired and it'll
> play in standalone files (not in HLS)
>
> If you jump through enough hoops you might get vp9 working in HLS offline,
> but adaptive streaming may be irrelevant to offline use.
>
> -- brion
>
> On Tue, Jan 23, 2024, 12:52 PM James Heilman  wrote:
>
>> It would be amazing if one could play videos on iPhones when the videos
>> are within ZIMs in an offline environment aswell. Brion not sure what
>> barriers there are to this currently?
>>
>> James
>>
>> On Tue, Jan 23, 2024 at 12:48 PM Paulo Santos Perneta <
>> paulospern...@gmail.com> wrote:
>>
>>> Should read 2030 Strategy, not 2023 strategy, sorry.
>>>
>>> Paulo Santos Perneta  escreveu (terça,
>>> 23/01/2024 à(s) 19:41):
>>>
 I wholeheartedly agree with this sentiment. We are currently grappling
 with rather rudimentary approaches when it comes to uploading and reusing
 video and music files...
 The incredibly useful Graph has been down for quite some time. The
 extensive capabilities of Wikidata query representations, particularly with
 geolocated data on maps, appear to have barely scratched the surface.
 Listeria frequently experiences issues and underwent a major update that
 disrupted previous queries.

 On a personal note, I attempted to create a dynamic digital library of
 works under a free license using Wikidata for our Digital Humanistics
 centre. However, I discovered that with the available tools, I would need
 to code the presentation myself, as the options for reuse outside of
 Wikidata were very basic.

 On the whole, the Wikipedia experience remains challenging, especially
 for newcomers. The much wanted Visual Editor developments and improvements
 seem to have stopped years ago. The recent changes made by the 'Desktop
 Improvement' team to the default Wikipedia skin seem to be more geared
 towards readers than editors and have apparently worsened the overall
 experience, according to feedback I've received from newcomers.

 These are just a few instances that have underscored, and continue to
 underscore, my belief that we are likely not on the path towards achieving
 the objectives outlined in the 2023 Strategy.

 My personal impression is that the issue doesn't necessarily stem from
 a lack of funding to pursue these objectives but rather from the
 ineffective expenditure and allocation of those funds. I wish I knew how to
 contribute to changing or improving this situation.
 It would also be great to see a comment/opinion from current CEO
 Maryana Iskander on this state of affairs, and if there is some roadmap for
 improving it.

 Best,
 Paulo


 Galder Gonzalez Larrañaga  escreveu (terça,
 23/01/2024 à(s) 11:03):

> Dear wikimedians,
> Nearly one year ago, the Graphs extension was disabled from all wikis,
> because there was a security issue that should be solved (
> https://phabricator.wikimedia.org/T334940). A wide team from the WMF
> worked on a solution for some weeks, but after Northern Hemisphere spring
> ended, summer came, then the monsoon season, and now it is again summer in
> the Southern Hemisphere... and Graphs are still disabled. All the 
> solutions
> proposed have been dismissed, but every two months there's a proposal to
> make a new roadmap to solve the issue. 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).

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

[Brion Vibber]

Converting them to suitably compact files in h.264/aac in .MP4 format would
be by far the simplest way. Use ffmpeg as we do on the server side for
online playback.

Conforming to the arbitrary Wikimedia prohibition on h.264 you could use
mpeg-4 visual instead, still in .mp4 - afaik patents are expired and it'll
play in standalone files (not in HLS)

If you jump through enough hoops you might get vp9 working in HLS offline,
but adaptive streaming may be irrelevant to offline use.

-- brion

On Tue, Jan 23, 2024, 12:52 PM James Heilman  wrote:

> It would be amazing if one could play videos on iPhones when the videos
> are within ZIMs in an offline environment aswell. Brion not sure what
> barriers there are to this currently?
>
> James
>
> On Tue, Jan 23, 2024 at 12:48 PM Paulo Santos Perneta <
> paulospern...@gmail.com> wrote:
>
>> Should read 2030 Strategy, not 2023 strategy, sorry.
>>
>> Paulo Santos Perneta  escreveu (terça,
>> 23/01/2024 à(s) 19:41):
>>
>>> I wholeheartedly agree with this sentiment. We are currently grappling
>>> with rather rudimentary approaches when it comes to uploading and reusing
>>> video and music files...
>>> The incredibly useful Graph has been down for quite some time. The
>>> extensive capabilities of Wikidata query representations, particularly with
>>> geolocated data on maps, appear to have barely scratched the surface.
>>> Listeria frequently experiences issues and underwent a major update that
>>> disrupted previous queries.
>>>
>>> On a personal note, I attempted to create a dynamic digital library of
>>> works under a free license using Wikidata for our Digital Humanistics
>>> centre. However, I discovered that with the available tools, I would need
>>> to code the presentation myself, as the options for reuse outside of
>>> Wikidata were very basic.
>>>
>>> On the whole, the Wikipedia experience remains challenging, especially
>>> for newcomers. The much wanted Visual Editor developments and improvements
>>> seem to have stopped years ago. The recent changes made by the 'Desktop
>>> Improvement' team to the default Wikipedia skin seem to be more geared
>>> towards readers than editors and have apparently worsened the overall
>>> experience, according to feedback I've received from newcomers.
>>>
>>> These are just a few instances that have underscored, and continue to
>>> underscore, my belief that we are likely not on the path towards achieving
>>> the objectives outlined in the 2023 Strategy.
>>>
>>> My personal impression is that the issue doesn't necessarily stem from a
>>> lack of funding to pursue these objectives but rather from the ineffective
>>> expenditure and allocation of those funds. I wish I knew how to contribute
>>> to changing or improving this situation.
>>> It would also be great to see a comment/opinion from current CEO Maryana
>>> Iskander on this state of affairs, and if there is some roadmap for
>>> improving it.
>>>
>>> Best,
>>> Paulo
>>>
>>>
>>> Galder Gonzalez Larrañaga  escreveu (terça,
>>> 23/01/2024 à(s) 11:03):
>>>
 Dear wikimedians,
 Nearly one year ago, the Graphs extension was disabled from all wikis,
 because there was a security issue that should be solved (
 https://phabricator.wikimedia.org/T334940). A wide team from the WMF
 worked on a solution for some weeks, but after Northern Hemisphere spring
 ended, summer came, then the monsoon season, and now it is again summer in
 the Southern Hemisphere... and Graphs are still disabled. All the solutions
 proposed have been dismissed, but every two months there's a proposal to
 make a new roadmap to solve the issue. 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).
 Well, the situation is now worse than it was seven years ago, let me give
 some examples:


- Graph extension is used in thousands of pages, some of them
highly relevant, as COVID or Climate Change information. There are
thousands of graphs broken now, and the only partial solution give is
loading these graphs as images, instead of promoting an interactive
solution.
- Meanwhile, a place like Our World in Data has been publishing
data and interactive content with a compatible license for years.
(Remember, "*By 2030, 

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

[James Heilman]

It would be amazing if one could play videos on iPhones when the videos are
within ZIMs in an offline environment aswell. Brion not sure what barriers
there are to this currently?

James

On Tue, Jan 23, 2024 at 12:48 PM Paulo Santos Perneta <
paulospern...@gmail.com> wrote:

> Should read 2030 Strategy, not 2023 strategy, sorry.
>
> Paulo Santos Perneta  escreveu (terça,
> 23/01/2024 à(s) 19:41):
>
>> I wholeheartedly agree with this sentiment. We are currently grappling
>> with rather rudimentary approaches when it comes to uploading and reusing
>> video and music files...
>> The incredibly useful Graph has been down for quite some time. The
>> extensive capabilities of Wikidata query representations, particularly with
>> geolocated data on maps, appear to have barely scratched the surface.
>> Listeria frequently experiences issues and underwent a major update that
>> disrupted previous queries.
>>
>> On a personal note, I attempted to create a dynamic digital library of
>> works under a free license using Wikidata for our Digital Humanistics
>> centre. However, I discovered that with the available tools, I would need
>> to code the presentation myself, as the options for reuse outside of
>> Wikidata were very basic.
>>
>> On the whole, the Wikipedia experience remains challenging, especially
>> for newcomers. The much wanted Visual Editor developments and improvements
>> seem to have stopped years ago. The recent changes made by the 'Desktop
>> Improvement' team to the default Wikipedia skin seem to be more geared
>> towards readers than editors and have apparently worsened the overall
>> experience, according to feedback I've received from newcomers.
>>
>> These are just a few instances that have underscored, and continue to
>> underscore, my belief that we are likely not on the path towards achieving
>> the objectives outlined in the 2023 Strategy.
>>
>> My personal impression is that the issue doesn't necessarily stem from a
>> lack of funding to pursue these objectives but rather from the ineffective
>> expenditure and allocation of those funds. I wish I knew how to contribute
>> to changing or improving this situation.
>> It would also be great to see a comment/opinion from current CEO Maryana
>> Iskander on this state of affairs, and if there is some roadmap for
>> improving it.
>>
>> Best,
>> Paulo
>>
>>
>> Galder Gonzalez Larrañaga  escreveu (terça,
>> 23/01/2024 à(s) 11:03):
>>
>>> Dear wikimedians,
>>> Nearly one year ago, the Graphs extension was disabled from all wikis,
>>> because there was a security issue that should be solved (
>>> https://phabricator.wikimedia.org/T334940). A wide team from the WMF
>>> worked on a solution for some weeks, but after Northern Hemisphere spring
>>> ended, summer came, then the monsoon season, and now it is again summer in
>>> the Southern Hemisphere... and Graphs are still disabled. All the solutions
>>> proposed have been dismissed, but every two months there's a proposal to
>>> make a new roadmap to solve the issue. 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).
>>> Well, the situation is now worse than it was seven years ago, let me give
>>> some examples:
>>>
>>>
>>>- Graph extension is used in thousands of pages, some of them highly
>>>relevant, as COVID or Climate Change information. There are thousands of
>>>graphs broken now, and the only partial solution give is loading these
>>>graphs as images, instead of promoting an interactive solution.
>>>- Meanwhile, a place like Our World in Data has been publishing data
>>>and interactive content with a compatible license for years. (Remember, 
>>> "*By
>>>2030, Wikimedia will become the essential infrastructure of the ecosystem
>>>of free knowledge*"). Trying to add this data and graphs to
>>>Wikimedia projects has been done by WikiMed, and it is technically
>>>possible, but still blocked to deploy (
>>>https://phabricator.wikimedia.org/T303853).
>>>- Wolfram Alpha is like a light year ahead us on giving interactive
>>>solutions to knowledge questions, even the silliest ones (
>>>
>>> https://www.wolframalpha.com/input?i=how+many+oranges+fit+in+the+Earth%3F).
>>>We have good technical articles about a lot of things, but sometimes 
>>> "*becoming
>>>the 

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

[Paulo Santos Perneta]

Should read 2030 Strategy, not 2023 strategy, sorry.

Paulo Santos Perneta  escreveu (terça, 23/01/2024
à(s) 19:41):

> I wholeheartedly agree with this sentiment. We are currently grappling
> with rather rudimentary approaches when it comes to uploading and reusing
> video and music files...
> The incredibly useful Graph has been down for quite some time. The
> extensive capabilities of Wikidata query representations, particularly with
> geolocated data on maps, appear to have barely scratched the surface.
> Listeria frequently experiences issues and underwent a major update that
> disrupted previous queries.
>
> On a personal note, I attempted to create a dynamic digital library of
> works under a free license using Wikidata for our Digital Humanistics
> centre. However, I discovered that with the available tools, I would need
> to code the presentation myself, as the options for reuse outside of
> Wikidata were very basic.
>
> On the whole, the Wikipedia experience remains challenging, especially for
> newcomers. The much wanted Visual Editor developments and improvements seem
> to have stopped years ago. The recent changes made by the 'Desktop
> Improvement' team to the default Wikipedia skin seem to be more geared
> towards readers than editors and have apparently worsened the overall
> experience, according to feedback I've received from newcomers.
>
> These are just a few instances that have underscored, and continue to
> underscore, my belief that we are likely not on the path towards achieving
> the objectives outlined in the 2023 Strategy.
>
> My personal impression is that the issue doesn't necessarily stem from a
> lack of funding to pursue these objectives but rather from the ineffective
> expenditure and allocation of those funds. I wish I knew how to contribute
> to changing or improving this situation.
> It would also be great to see a comment/opinion from current CEO Maryana
> Iskander on this state of affairs, and if there is some roadmap for
> improving it.
>
> Best,
> Paulo
>
>
> Galder Gonzalez Larrañaga  escreveu (terça,
> 23/01/2024 à(s) 11:03):
>
>> Dear wikimedians,
>> Nearly one year ago, the Graphs extension was disabled from all wikis,
>> because there was a security issue that should be solved (
>> https://phabricator.wikimedia.org/T334940). A wide team from the WMF
>> worked on a solution for some weeks, but after Northern Hemisphere spring
>> ended, summer came, then the monsoon season, and now it is again summer in
>> the Southern Hemisphere... and Graphs are still disabled. All the solutions
>> proposed have been dismissed, but every two months there's a proposal to
>> make a new roadmap to solve the issue. 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).
>> Well, the situation is now worse than it was seven years ago, let me give
>> some examples:
>>
>>
>>- Graph extension is used in thousands of pages, some of them highly
>>relevant, as COVID or Climate Change information. There are thousands of
>>graphs broken now, and the only partial solution give is loading these
>>graphs as images, instead of promoting an interactive solution.
>>- Meanwhile, a place like Our World in Data has been publishing data
>>and interactive content with a compatible license for years. (Remember, 
>> "*By
>>2030, Wikimedia will become the essential infrastructure of the ecosystem
>>of free knowledge*"). Trying to add this data and graphs to Wikimedia
>>projects has been done by WikiMed, and it is technically possible, but
>>still blocked to deploy (https://phabricator.wikimedia.org/T303853).
>>- Wolfram Alpha is like a light year ahead us on giving interactive
>>solutions to knowledge questions, even the silliest ones (
>>
>> https://www.wolframalpha.com/input?i=how+many+oranges+fit+in+the+Earth%3F).
>>We have good technical articles about a lot of things, but sometimes 
>> "*becoming
>>the essential infrastructure of the ecosystem of free knowledge*"
>>needs to provide solutions to exact problems, like the answer to an
>>equation, and how to solve it. That's also "free knowledge".
>>- Brilliant (https://brilliant.org/) is brilliant if you want to
>>learn lots of things, like geometry or programming. Way better than
>>Wikipedia. But... you need to 

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

[Brion Vibber]

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

-- brion

On Tue, Jan 23, 2024 at 11:35 AM Brion Vibber  wrote:

> Also, note that Wikimedia can choose to ship h.264 files at any time, just
> like we use CPUs full of patented technology; not doing so is a choice the
> Commons community made in 2014 and we could revisit that choice in the
> light of the fact there's no actual downside of working with h.264 when
> we're not shipping the codec.
>
> -- brion
>
> On Tue, Jan 23, 2024 at 11:11 AM Brion Vibber 
> wrote:
>
>> (What I *have* been able to do, with the help of volunteers and a little
>> spare time from colleagues, is produce an iOS-compatible HTTP Live
>> Streaming packaging for video transcodes. This gets full-featured video
>> playback working on iPhones that are new enough to decode VP9, though may
>> still have compatibility problems with older phones. There is no funding or
>> ongoing work time assignment for this project beyond conforming initial iOS
>> compatibility.)
>>
>> -- brion
>>
>> On Tue, Jan 23, 2024 at 11:08 AM Brion Vibber 
>> wrote:
>>
>>> Agreed, there is a *lot* we could do if there were resources assigned to
>>> interactive media.
>>>
>>> -- brion
>>>
>>> On Tue, Jan 23, 2024 at 10:29 AM James Heilman  wrote:
>>>
 Thanks Galder

 As mentioned Wiki Project Med is working to improve some of these
 issues this year, supported by funding from the WMF.

 1) We are still trying to get OWID working on Wikipedia. Here is what
 it looks like on MDWiki .

 2) We are also working on a CT scan viewer that functions better than
 this .

 3) And are trying to get VideoWiki
  functional again
 after it died a few years back.

 Would love to see MP4s uploadable to Commons. Sure we can auto convert
 to open formats in the background and hide the MP4s until they are fully
 open, but this should be done by us and we should not be forcing our
 editors to use other websites to achieve this.

 James

 On Tue, Jan 23, 2024 at 10:47 AM Ivan Martínez 
 wrote:

> Hi Galder, I certainly share your sentiment. The world is undoubtedly
> moving at such a speed that other sites have invested millions to make the
> experience better. But ours has millions as well, and those of us who edit
> on a day-to-day basis still have the worst internet experience when it
> comes for an example to editing and uploading photos. Not to mention the
> long and tortuous road to video uploading (Commons has no decent
> support for this ),
> in the midst of the biggest generational shift in video consumption.
>
> There is a phrase in my country that if civil servants were on public
> transport, we would probably have faster improvements. Will it be the same
> for us, if we do not have staff who do not face our daily "challenges"?
>
> I don't know.
>
> El mar, 23 ene 2024 a las 5:03, Galder Gonzalez Larrañaga (<
> galder...@hotmail.com>) escribió:
>
>> Dear wikimedians,
>> Nearly one year ago, the Graphs extension was disabled from all
>> wikis, because there was a security issue that should be solved (
>> https://phabricator.wikimedia.org/T334940). A wide team from the WMF
>> worked on a solution for some weeks, but after Northern Hemisphere spring
>> ended, summer came, then the monsoon season, and now it is again summer 
>> in
>> the Southern Hemisphere... and Graphs are still disabled. All the 
>> solutions
>> proposed have been dismissed, but every two months there's a proposal to
>> make a new roadmap to solve the issue. 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 (
>> 

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

[Paulo Santos Perneta]

I wholeheartedly agree with this sentiment. We are currently grappling with
rather rudimentary approaches when it comes to uploading and reusing video
and music files...
The incredibly useful Graph has been down for quite some time. The
extensive capabilities of Wikidata query representations, particularly with
geolocated data on maps, appear to have barely scratched the surface.
Listeria frequently experiences issues and underwent a major update that
disrupted previous queries.

On a personal note, I attempted to create a dynamic digital library of
works under a free license using Wikidata for our Digital Humanistics
centre. However, I discovered that with the available tools, I would need
to code the presentation myself, as the options for reuse outside of
Wikidata were very basic.

On the whole, the Wikipedia experience remains challenging, especially for
newcomers. The much wanted Visual Editor developments and improvements seem
to have stopped years ago. The recent changes made by the 'Desktop
Improvement' team to the default Wikipedia skin seem to be more geared
towards readers than editors and have apparently worsened the overall
experience, according to feedback I've received from newcomers.

These are just a few instances that have underscored, and continue to
underscore, my belief that we are likely not on the path towards achieving
the objectives outlined in the 2023 Strategy.

My personal impression is that the issue doesn't necessarily stem from a
lack of funding to pursue these objectives but rather from the ineffective
expenditure and allocation of those funds. I wish I knew how to contribute
to changing or improving this situation.
It would also be great to see a comment/opinion from current CEO Maryana
Iskander on this state of affairs, and if there is some roadmap for
improving it.

Best,
Paulo


Galder Gonzalez Larrañaga  escreveu (terça,
23/01/2024 à(s) 11:03):

> Dear wikimedians,
> Nearly one year ago, the Graphs extension was disabled from all wikis,
> because there was a security issue that should be solved (
> https://phabricator.wikimedia.org/T334940). A wide team from the WMF
> worked on a solution for some weeks, but after Northern Hemisphere spring
> ended, summer came, then the monsoon season, and now it is again summer in
> the Southern Hemisphere... and Graphs are still disabled. All the solutions
> proposed have been dismissed, but every two months there's a proposal to
> make a new roadmap to solve the issue. 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).
> Well, the situation is now worse than it was seven years ago, let me give
> some examples:
>
>
>- Graph extension is used in thousands of pages, some of them highly
>relevant, as COVID or Climate Change information. There are thousands of
>graphs broken now, and the only partial solution give is loading these
>graphs as images, instead of promoting an interactive solution.
>- Meanwhile, a place like Our World in Data has been publishing data
>and interactive content with a compatible license for years. (Remember, 
> "*By
>2030, Wikimedia will become the essential infrastructure of the ecosystem
>of free knowledge*"). Trying to add this data and graphs to Wikimedia
>projects has been done by WikiMed, and it is technically possible, but
>still blocked to deploy (https://phabricator.wikimedia.org/T303853).
>- Wolfram Alpha is like a light year ahead us on giving interactive
>solutions to knowledge questions, even the silliest ones (
>https://www.wolframalpha.com/input?i=how+many+oranges+fit+in+the+Earth%3F).
>We have good technical articles about a lot of things, but sometimes 
> "*becoming
>the essential infrastructure of the ecosystem of free knowledge*"
>needs to provide solutions to exact problems, like the answer to an
>equation, and how to solve it. That's also "free knowledge".
>- Brilliant (https://brilliant.org/) is brilliant if you want to learn
>lots of things, like geometry or programming. Way better than Wikipedia.
>But... you need to pay for it. How could we even try if we can't add
>anything interactive to our platforms?
>- We can build interactive timelines using Wikidata, but we can't
>embed them at Wikipedia. Weird, because I can do it in any external page.
> 

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

[Brion Vibber]

Also, note that Wikimedia can choose to ship h.264 files at any time, just
like we use CPUs full of patented technology; not doing so is a choice the
Commons community made in 2014 and we could revisit that choice in the
light of the fact there's no actual downside of working with h.264 when
we're not shipping the codec.

-- brion

On Tue, Jan 23, 2024 at 11:11 AM Brion Vibber  wrote:

> (What I *have* been able to do, with the help of volunteers and a little
> spare time from colleagues, is produce an iOS-compatible HTTP Live
> Streaming packaging for video transcodes. This gets full-featured video
> playback working on iPhones that are new enough to decode VP9, though may
> still have compatibility problems with older phones. There is no funding or
> ongoing work time assignment for this project beyond conforming initial iOS
> compatibility.)
>
> -- brion
>
> On Tue, Jan 23, 2024 at 11:08 AM Brion Vibber 
> wrote:
>
>> Agreed, there is a *lot* we could do if there were resources assigned to
>> interactive media.
>>
>> -- brion
>>
>> On Tue, Jan 23, 2024 at 10:29 AM James Heilman  wrote:
>>
>>> Thanks Galder
>>>
>>> As mentioned Wiki Project Med is working to improve some of these issues
>>> this year, supported by funding from the WMF.
>>>
>>> 1) We are still trying to get OWID working on Wikipedia. Here is what
>>> it looks like on MDWiki .
>>>
>>> 2) We are also working on a CT scan viewer that functions better than
>>> this .
>>>
>>> 3) And are trying to get VideoWiki
>>>  functional again
>>> after it died a few years back.
>>>
>>> Would love to see MP4s uploadable to Commons. Sure we can auto convert
>>> to open formats in the background and hide the MP4s until they are fully
>>> open, but this should be done by us and we should not be forcing our
>>> editors to use other websites to achieve this.
>>>
>>> James
>>>
>>> On Tue, Jan 23, 2024 at 10:47 AM Ivan Martínez 
>>> wrote:
>>>
 Hi Galder, I certainly share your sentiment. The world is undoubtedly
 moving at such a speed that other sites have invested millions to make the
 experience better. But ours has millions as well, and those of us who edit
 on a day-to-day basis still have the worst internet experience when it
 comes for an example to editing and uploading photos. Not to mention the
 long and tortuous road to video uploading (Commons has no decent
 support for this ),
 in the midst of the biggest generational shift in video consumption.

 There is a phrase in my country that if civil servants were on public
 transport, we would probably have faster improvements. Will it be the same
 for us, if we do not have staff who do not face our daily "challenges"?

 I don't know.

 El mar, 23 ene 2024 a las 5:03, Galder Gonzalez Larrañaga (<
 galder...@hotmail.com>) escribió:

> Dear wikimedians,
> Nearly one year ago, the Graphs extension was disabled from all wikis,
> because there was a security issue that should be solved (
> https://phabricator.wikimedia.org/T334940). A wide team from the WMF
> worked on a solution for some weeks, but after Northern Hemisphere spring
> ended, summer came, then the monsoon season, and now it is again summer in
> the Southern Hemisphere... and Graphs are still disabled. All the 
> solutions
> proposed have been dismissed, but every two months there's a proposal to
> make a new roadmap to solve the issue. 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).
> Well, the situation is now worse than it was seven years ago, let me give
> some examples:
>
>
>- Graph extension is used in thousands of pages, some of them
>highly relevant, as COVID or Climate Change information. There are
>thousands of graphs broken now, and the only partial solution give is
>loading these graphs as images, instead of promoting an interactive
>solution.
>- Meanwhile, a place like Our World in Data has been publishing
>data and interactive content with a compatible 

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

[F. Xavier Dengra i Grau via Wikimedia-l]

Hard email to read, but Galder's are quite of indisputable thoughts and the 
harsh reality of Wikimedia's technological state of the art.

Yet this incontestability is, at the same time, the very profound problem: the 
WMF will not refute it, nor structurally change it, besides silences and 
inspiring words in progress and strategic reports. Such a change requires 
millions of dollars that the projects are actually able to annually fundraise 
for the institution, but that the institution prioritizes to maintain its own 
(questionable) corporative structure and not the digital one of the projects.

Hopefully someone else prove us wrong with data, factual progress and optimism.

Xavier Dengra
El dimarts, 23 de gener 2024 a les 12:02, Galder Gonzalez Larrañaga 
 va escriure:

> Dear wikimedians,
> Nearly one year ago, the Graphs extension was disabled from all wikis, 
> because there was a security issue that should be solved 
> (https://phabricator.wikimedia.org/T334940). A wide team from the WMF worked 
> on a solution for some weeks, but after Northern Hemisphere spring ended, 
> summer came, then the monsoon season, and now it is again summer in the 
> Southern Hemisphere... and Graphs are still disabled. All the solutions 
> proposed have been dismissed, but every two months there's a proposal to make 
> a new roadmap to solve the issue. 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).
>  Well, the situation is now worse than it was seven years ago, let me give 
> some examples:
>
> -  Graph extension is used in thousands of pages, some of them highly 
> relevant, as COVID or Climate Change information. There are thousands of 
> graphs broken now, and the only partial solution give is loading these graphs 
> as images, instead of promoting an interactive solution.
> -  Meanwhile, a place like Our World in Data has been publishing data and 
> interactive content with a compatible license for years. (Remember, "By 2030, 
> Wikimedia will become the essential infrastructure of the ecosystem of free 
> knowledge"). Trying to add this data and graphs to Wikimedia projects has 
> been done by WikiMed, and it is technically possible, but still blocked to 
> deploy (https://phabricator.wikimedia.org/T303853).
> -  Wolfram Alpha is like a light year ahead us on giving interactive 
> solutions to knowledge questions, even the silliest ones 
> (https://www.wolframalpha.com/input?i=how+many+oranges+fit+in+the+Earth%3F). 
> We have good technical articles about a lot of things, but sometimes 
> "becoming the essential infrastructure of the ecosystem of free knowledge" 
> needs to provide solutions to exact problems, like the answer to an equation, 
> and how to solve it. That's also "free knowledge".
> -  Brilliant (https://brilliant.org/) is brilliant if you want to learn lots 
> of things, like geometry or programming. Way better than Wikipedia. But... 
> you need to pay for it. How could we even try if we can't add anything 
> interactive to our platforms?
> -  We can build interactive timelines using Wikidata, but we can't embed them 
> at Wikipedia. Weird, because I can do it in any external page. 
> Hopefully,[Histropedia will do it better. 
> http://histropedia.com/](http://histropedia.com/)
> -  We could have something very special: inline links in video and audio 
> subtitles. We used to have them, but the new video infrastructure doesn't 
> allow it. Imagine a world where you can watch a video and link a link in the 
> subtitles just to know more about that.
> -  ...
>
> The list can go on an on ("which phase the moon is today?"), but I think that 
> the idea is clear. We could have interactive content, but we are going in the 
> opposite direction, and every year we are further from our goal, because 
> other platforms are doing it better, way better. And this seems like some 
> wild ideas, but then I read the 2023-2024 annual plan section called "Wiki 
> Experiences" 
> (https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2023-2024/Goals/Infrastructure#Bucket:_Wiki_Experiences)
>  and it looks like we should be going there. But we aren't.
>
> I'm sorry if this e-mail feels bitter. My experience in the last years is 
> that we are now further of what we need that we were before, even if many 
> chapters and volunteers are trying to 

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

[Brion Vibber]

(What I *have* been able to do, with the help of volunteers and a little
spare time from colleagues, is produce an iOS-compatible HTTP Live
Streaming packaging for video transcodes. This gets full-featured video
playback working on iPhones that are new enough to decode VP9, though may
still have compatibility problems with older phones. There is no funding or
ongoing work time assignment for this project beyond conforming initial iOS
compatibility.)

-- brion

On Tue, Jan 23, 2024 at 11:08 AM Brion Vibber  wrote:

> Agreed, there is a *lot* we could do if there were resources assigned to
> interactive media.
>
> -- brion
>
> On Tue, Jan 23, 2024 at 10:29 AM James Heilman  wrote:
>
>> Thanks Galder
>>
>> As mentioned Wiki Project Med is working to improve some of these issues
>> this year, supported by funding from the WMF.
>>
>> 1) We are still trying to get OWID working on Wikipedia. Here is what it
>> looks like on MDWiki .
>>
>> 2) We are also working on a CT scan viewer that functions better than
>> this .
>>
>> 3) And are trying to get VideoWiki
>>  functional again
>> after it died a few years back.
>>
>> Would love to see MP4s uploadable to Commons. Sure we can auto convert to
>> open formats in the background and hide the MP4s until they are fully open,
>> but this should be done by us and we should not be forcing our editors to
>> use other websites to achieve this.
>>
>> James
>>
>> On Tue, Jan 23, 2024 at 10:47 AM Ivan Martínez  wrote:
>>
>>> Hi Galder, I certainly share your sentiment. The world is undoubtedly
>>> moving at such a speed that other sites have invested millions to make the
>>> experience better. But ours has millions as well, and those of us who edit
>>> on a day-to-day basis still have the worst internet experience when it
>>> comes for an example to editing and uploading photos. Not to mention the
>>> long and tortuous road to video uploading (Commons has no decent
>>> support for this ),
>>> in the midst of the biggest generational shift in video consumption.
>>>
>>> There is a phrase in my country that if civil servants were on public
>>> transport, we would probably have faster improvements. Will it be the same
>>> for us, if we do not have staff who do not face our daily "challenges"?
>>>
>>> I don't know.
>>>
>>> El mar, 23 ene 2024 a las 5:03, Galder Gonzalez Larrañaga (<
>>> galder...@hotmail.com>) escribió:
>>>
 Dear wikimedians,
 Nearly one year ago, the Graphs extension was disabled from all wikis,
 because there was a security issue that should be solved (
 https://phabricator.wikimedia.org/T334940). A wide team from the WMF
 worked on a solution for some weeks, but after Northern Hemisphere spring
 ended, summer came, then the monsoon season, and now it is again summer in
 the Southern Hemisphere... and Graphs are still disabled. All the solutions
 proposed have been dismissed, but every two months there's a proposal to
 make a new roadmap to solve the issue. 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).
 Well, the situation is now worse than it was seven years ago, let me give
 some examples:


- Graph extension is used in thousands of pages, some of them
highly relevant, as COVID or Climate Change information. There are
thousands of graphs broken now, and the only partial solution give is
loading these graphs as images, instead of promoting an interactive
solution.
- Meanwhile, a place like Our World in Data has been publishing
data and interactive content with a compatible license for years.
(Remember, "*By 2030, Wikimedia will become the essential
infrastructure of the ecosystem of free knowledge*"). Trying to add
this data and graphs to Wikimedia projects has been done by WikiMed, 
 and it
is technically possible, but still blocked to deploy (
https://phabricator.wikimedia.org/T303853).
- Wolfram Alpha is like a light year ahead us on giving interactive
solutions to knowledge questions, even the silliest 

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

[Brion Vibber]

Agreed, there is a *lot* we could do if there were resources assigned to
interactive media.

-- brion

On Tue, Jan 23, 2024 at 10:29 AM James Heilman  wrote:

> Thanks Galder
>
> As mentioned Wiki Project Med is working to improve some of these issues
> this year, supported by funding from the WMF.
>
> 1) We are still trying to get OWID working on Wikipedia. Here is what it
> looks like on MDWiki .
>
> 2) We are also working on a CT scan viewer that functions better than this
> .
>
> 3) And are trying to get VideoWiki
>  functional again after
> it died a few years back.
>
> Would love to see MP4s uploadable to Commons. Sure we can auto convert to
> open formats in the background and hide the MP4s until they are fully open,
> but this should be done by us and we should not be forcing our editors to
> use other websites to achieve this.
>
> James
>
> On Tue, Jan 23, 2024 at 10:47 AM Ivan Martínez  wrote:
>
>> Hi Galder, I certainly share your sentiment. The world is undoubtedly
>> moving at such a speed that other sites have invested millions to make the
>> experience better. But ours has millions as well, and those of us who edit
>> on a day-to-day basis still have the worst internet experience when it
>> comes for an example to editing and uploading photos. Not to mention the
>> long and tortuous road to video uploading (Commons has no decent support
>> for this ), in the
>> midst of the biggest generational shift in video consumption.
>>
>> There is a phrase in my country that if civil servants were on public
>> transport, we would probably have faster improvements. Will it be the same
>> for us, if we do not have staff who do not face our daily "challenges"?
>>
>> I don't know.
>>
>> El mar, 23 ene 2024 a las 5:03, Galder Gonzalez Larrañaga (<
>> galder...@hotmail.com>) escribió:
>>
>>> Dear wikimedians,
>>> Nearly one year ago, the Graphs extension was disabled from all wikis,
>>> because there was a security issue that should be solved (
>>> https://phabricator.wikimedia.org/T334940). A wide team from the WMF
>>> worked on a solution for some weeks, but after Northern Hemisphere spring
>>> ended, summer came, then the monsoon season, and now it is again summer in
>>> the Southern Hemisphere... and Graphs are still disabled. All the solutions
>>> proposed have been dismissed, but every two months there's a proposal to
>>> make a new roadmap to solve the issue. 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).
>>> Well, the situation is now worse than it was seven years ago, let me give
>>> some examples:
>>>
>>>
>>>- Graph extension is used in thousands of pages, some of them highly
>>>relevant, as COVID or Climate Change information. There are thousands of
>>>graphs broken now, and the only partial solution give is loading these
>>>graphs as images, instead of promoting an interactive solution.
>>>- Meanwhile, a place like Our World in Data has been publishing data
>>>and interactive content with a compatible license for years. (Remember, 
>>> "*By
>>>2030, Wikimedia will become the essential infrastructure of the ecosystem
>>>of free knowledge*"). Trying to add this data and graphs to
>>>Wikimedia projects has been done by WikiMed, and it is technically
>>>possible, but still blocked to deploy (
>>>https://phabricator.wikimedia.org/T303853).
>>>- Wolfram Alpha is like a light year ahead us on giving interactive
>>>solutions to knowledge questions, even the silliest ones (
>>>
>>> https://www.wolframalpha.com/input?i=how+many+oranges+fit+in+the+Earth%3F).
>>>We have good technical articles about a lot of things, but sometimes 
>>> "*becoming
>>>the essential infrastructure of the ecosystem of free knowledge*"
>>>needs to provide solutions to exact problems, like the answer to an
>>>equation, and how to solve it. That's also "free knowledge".
>>>- Brilliant (https://brilliant.org/) is brilliant if you want to
>>>learn lots of things, like geometry or programming. Way better than
>>>Wikipedia. But... you need to pay for it. How could we even try 

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

[James Heilman]

Thanks Galder

As mentioned Wiki Project Med is working to improve some of these issues
this year, supported by funding from the WMF.

1) We are still trying to get OWID working on Wikipedia. Here is what it
looks like on MDWiki .

2) We are also working on a CT scan viewer that functions better than this
.

3) And are trying to get VideoWiki
 functional again after
it died a few years back.

Would love to see MP4s uploadable to Commons. Sure we can auto convert to
open formats in the background and hide the MP4s until they are fully open,
but this should be done by us and we should not be forcing our editors to
use other websites to achieve this.

James

On Tue, Jan 23, 2024 at 10:47 AM Ivan Martínez  wrote:

> Hi Galder, I certainly share your sentiment. The world is undoubtedly
> moving at such a speed that other sites have invested millions to make the
> experience better. But ours has millions as well, and those of us who edit
> on a day-to-day basis still have the worst internet experience when it
> comes for an example to editing and uploading photos. Not to mention the
> long and tortuous road to video uploading (Commons has no decent support
> for this ), in the
> midst of the biggest generational shift in video consumption.
>
> There is a phrase in my country that if civil servants were on public
> transport, we would probably have faster improvements. Will it be the same
> for us, if we do not have staff who do not face our daily "challenges"?
>
> I don't know.
>
> El mar, 23 ene 2024 a las 5:03, Galder Gonzalez Larrañaga (<
> galder...@hotmail.com>) escribió:
>
>> Dear wikimedians,
>> Nearly one year ago, the Graphs extension was disabled from all wikis,
>> because there was a security issue that should be solved (
>> https://phabricator.wikimedia.org/T334940). A wide team from the WMF
>> worked on a solution for some weeks, but after Northern Hemisphere spring
>> ended, summer came, then the monsoon season, and now it is again summer in
>> the Southern Hemisphere... and Graphs are still disabled. All the solutions
>> proposed have been dismissed, but every two months there's a proposal to
>> make a new roadmap to solve the issue. 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).
>> Well, the situation is now worse than it was seven years ago, let me give
>> some examples:
>>
>>
>>- Graph extension is used in thousands of pages, some of them highly
>>relevant, as COVID or Climate Change information. There are thousands of
>>graphs broken now, and the only partial solution give is loading these
>>graphs as images, instead of promoting an interactive solution.
>>- Meanwhile, a place like Our World in Data has been publishing data
>>and interactive content with a compatible license for years. (Remember, 
>> "*By
>>2030, Wikimedia will become the essential infrastructure of the ecosystem
>>of free knowledge*"). Trying to add this data and graphs to Wikimedia
>>projects has been done by WikiMed, and it is technically possible, but
>>still blocked to deploy (https://phabricator.wikimedia.org/T303853).
>>- Wolfram Alpha is like a light year ahead us on giving interactive
>>solutions to knowledge questions, even the silliest ones (
>>
>> https://www.wolframalpha.com/input?i=how+many+oranges+fit+in+the+Earth%3F).
>>We have good technical articles about a lot of things, but sometimes 
>> "*becoming
>>the essential infrastructure of the ecosystem of free knowledge*"
>>needs to provide solutions to exact problems, like the answer to an
>>equation, and how to solve it. That's also "free knowledge".
>>- Brilliant (https://brilliant.org/) is brilliant if you want to
>>learn lots of things, like geometry or programming. Way better than
>>Wikipedia. But... you need to pay for it. How could we even try if we 
>> can't
>>add anything interactive to our platforms?
>>- We can build interactive timelines using Wikidata, but we can't
>>embed them at Wikipedia. Weird, because I can do it in any external page.
>>Hopefully, Histropedia will do it better. 

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

[Ivan Martínez]

Hi Galder, I certainly share your sentiment. The world is undoubtedly
moving at such a speed that other sites have invested millions to make the
experience better. But ours has millions as well, and those of us who edit
on a day-to-day basis still have the worst internet experience when it
comes for an example to editing and uploading photos. Not to mention the
long and tortuous road to video uploading (Commons has no decent support
for this ), in the midst
of the biggest generational shift in video consumption.

There is a phrase in my country that if civil servants were on public
transport, we would probably have faster improvements. Will it be the same
for us, if we do not have staff who do not face our daily "challenges"?

I don't know.

El mar, 23 ene 2024 a las 5:03, Galder Gonzalez Larrañaga (<
galder...@hotmail.com>) escribió:

> Dear wikimedians,
> Nearly one year ago, the Graphs extension was disabled from all wikis,
> because there was a security issue that should be solved (
> https://phabricator.wikimedia.org/T334940). A wide team from the WMF
> worked on a solution for some weeks, but after Northern Hemisphere spring
> ended, summer came, then the monsoon season, and now it is again summer in
> the Southern Hemisphere... and Graphs are still disabled. All the solutions
> proposed have been dismissed, but every two months there's a proposal to
> make a new roadmap to solve the issue. 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).
> Well, the situation is now worse than it was seven years ago, let me give
> some examples:
>
>
>- Graph extension is used in thousands of pages, some of them highly
>relevant, as COVID or Climate Change information. There are thousands of
>graphs broken now, and the only partial solution give is loading these
>graphs as images, instead of promoting an interactive solution.
>- Meanwhile, a place like Our World in Data has been publishing data
>and interactive content with a compatible license for years. (Remember, 
> "*By
>2030, Wikimedia will become the essential infrastructure of the ecosystem
>of free knowledge*"). Trying to add this data and graphs to Wikimedia
>projects has been done by WikiMed, and it is technically possible, but
>still blocked to deploy (https://phabricator.wikimedia.org/T303853).
>- Wolfram Alpha is like a light year ahead us on giving interactive
>solutions to knowledge questions, even the silliest ones (
>https://www.wolframalpha.com/input?i=how+many+oranges+fit+in+the+Earth%3F).
>We have good technical articles about a lot of things, but sometimes 
> "*becoming
>the essential infrastructure of the ecosystem of free knowledge*"
>needs to provide solutions to exact problems, like the answer to an
>equation, and how to solve it. That's also "free knowledge".
>- Brilliant (https://brilliant.org/) is brilliant if you want to learn
>lots of things, like geometry or programming. Way better than Wikipedia.
>But... you need to pay for it. How could we even try if we can't add
>anything interactive to our platforms?
>- We can build interactive timelines using Wikidata, but we can't
>embed them at Wikipedia. Weird, because I can do it in any external page.
>Hopefully, Histropedia will do it better. http://histropedia.com/
>
>- We could have something very special: inline links in video and
>audio subtitles. We used to have them, but the new video infrastructure
>doesn't allow it. Imagine a world where you can watch a video and link a
>link in the subtitles just to know more about that.
>- ...
>
>
> The list can go on an on ("which phase the moon is today?"), but I think
> that the idea is clear. We could have interactive content, but we are going
> in the opposite direction, and every year we are further from our goal,
> because other platforms are doing it better, way better. And this seems
> like some wild ideas, but then I read the 2023-2024 annual plan section
> called "Wiki Experiences" (
> https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2023-2024/Goals/Infrastructure#Bucket:_Wiki_Experiences)
> and it looks like we should be going there. But we aren't.
>
> I'm sorry if this e-mail