Brainstorming, interested stakeholders could advance Web standards to improve “snippets”, for example facilitating menus on “snippets”. With extensible menus on “snippets”, “snippets providers” could place hyperlinks, e.g., “view”, “edit”, and “discuss”, on each “snippet” provided for end-users.


With respect to a “view” menu option, end-users could navigate to a “snippet’s” source content in context. This navigation could make use of text fragments ( It is possible is that “source content providers” could specify other mechanisms, e.g., URL-query-based, to override this default behavior with respect to hyperlink URL’s provided to end-users to “view” source content in context.


With respect to an “edit” menu option, end-users could navigate to pages for editing source content, e.g., wiki edit pages.


With respect to a “discuss” menu option, end-users could navigate to pages for discussing source content, e.g., wiki discussion pages.


There are more options for extensible “snippets” menus. For example, “like”, “upvote”, and “downvote”. It remains to be explored whether these kinds of menu options, “like”, “upvote”, and “downvote”, should keep end-users on “snippets provider” websites, navigate end-users to “source content provider” websites, or open “source content provider” websites in a new tab. These indicated possibilities, “like”, “upvote”, and “downvote”, may involve multi-party user authentication and bot prevention considerations.


Yet other menu options include a “follow” option which could subscribe end-users to alerts when the information in a “snippet” changes or is updated.


Yet other menu options include the option to “share” a snippet.


I hope that these initial ideas show that there are opportunities to advance the definitions of what “snippets” are and may become.


Web-standards-based approaches to improving “snippets”, e.g., facilitating extensible menus on “snippets”, could involve defining relevant HTML metadata (uses of <meta> and <link> elements to provide information to “snippet providers”) and/or expanding relevant Web schemas. That is, “source content providers” could use HTML metadata or Web schemas to provide information to “snippets providers” to populate menu options as “snippets” from derived content are presented to end-users.



Best regards,



From: Adam Sobieski
Sent: Friday, January 7, 2022 7:31 PM
To: Wikimedia Mailing List
Subject: RE: [Wikimedia-l] Re: Are we losing our readers?





I wonder if Google maintains provenance for their “snippets” and whether developers and platform teams would be interested in requesting an API which includes features such as subscribing to pings (daily, weekly, or monthly) reporting usage data pertaining to derived data. The envisioned pings would say something like: 10,000 users this month asked questions which were answered by snippets derived from your content at: .


Brainstorming about the future of mobile computing and multimedia educational content, you might be interested in interactive video – video with menus (like Netflix “Black Mirror: Bandersnatch”, “Puss in Book: Trapped in an Epic Tale”, and “Minecraft Story Mode”). A tool for creating these videos is available at: . In my opinion, interactive video is better for educational content than video.


You might be also interested in a new project proposal:  .



Best regards,



From: Nathan
Sent: Friday, January 7, 2022 7:14 PM
To: Wikimedia Mailing List
Subject: [Wikimedia-l] Re: Are we losing our readers?


I think a lot has been said on this list over the last few years about a couple of major factors that probably still play a role:


* Shift to mobile device usage and how that affects Wikipedia usage and pageview stats

* Availability of more and more "snippets" in search engine results, which often makes it unnecessary for someone to click through into an article


My own sense is that the prevalence of snippets and smart search results is growing rapidly, I often skip clicking through to Wikipedia if my question is answered by Google.