Mailing List Archive

[Wikimedia-l] Re: We need more interactive content: we are doing it wrong
Hi Galder, I just did this fix
<https://eu.wikipedia.org/w/index.php?title=MediaWiki:Gadgets-definition&diff=prev&oldid=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 <
galder158@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 <schenonef@gmail.com>
> *Sent:* Friday, March 22, 2024 10:39 PM
> *To:* Wikimedia Mailing List <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 <danboy12342@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 <gnangarra@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 <bustrias@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 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 <bvibber@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 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 <mmiller@wikimedia.org> 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 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 how our community members see the evolution of the
> reading experience on our projects. I’d like to have some small
> conversations with many of you so that we can get into the details and
> ideas, joined by some of my colleagues. I’ll start reaching out to see who
> is interested in talking – and please let me know directly if you’d like to
> talk.
>
> Thank you for weighing in so far, and let’s keep talking and planning
> together.
>
> Marshall
>
> [1] https://meta.wikimedia.org/wiki/User:MMiller_(WMF)
> [2] https://phabricator.wikimedia.org/T334940
> [3]
> https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2023-2024#Our_approach_for_the_future
> [4]
> https://en.wikipedia.org/wiki/Wikipedia:Page_Curation/2023_Moderator_Tools_project#October_20,_2023:_Final_update
> !
> [5]
> https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/iOS/Watchlist#October_2023
> [6]
> https://www.mediawiki.org/wiki/Wikimedia_Apps/Team/Android/Anti_Vandalism
> [7] https://www.mediawiki.org/wiki/Reading/Web/Accessibility_for_reading
> [8]
> https://commons.wikimedia.org/wiki/Commons:WMF_support_for_Commons/Upload_Wizard_Improvements
> [9]
> https://meta.wikimedia.org/wiki/Future_Audiences#Sign_up_to_participate!
> _______________________________________________
> 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/CPYNFK3PDTP6YVLZU3SLOJOXYJMOQHM5/
> To unsubscribe send an email to wikimedia-l-leave@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/OZC7KCXVZAUWPCNNALLEIV26DIRNKPX7/
> To unsubscribe send an email to wikimedia-l-leave@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/SNF5D5KQLWQUORTYKI6PWAUWYEC2VAXH/
> To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
>
>
>
> --
> Boodarwun
> Gnangarra
> 'ngany dabakarn koorliny arn boodjera dardon nlangan Nyungar koortabodjar'
>
> _______________________________________________
> 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/LVN6QVPTHMBA7ZIHMHMAFTH3ZMSUUISM/
> To unsubscribe send an email to wikimedia-l-leave@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/RYKSAANL64KJU73KUMIDWHXAI2VBBFGT/
> To unsubscribe send an email to wikimedia-l-leave@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/63IA5KIDV3QZXCB3I6GFUIW7UQXDXHUF/
> To unsubscribe send an email to wikimedia-l-leave@lists.wikimedia.org
>