From Dream to Reality

Hands-on museums are fun because they turn observers into participants

Here I would like to discuss the ways to achieve the Rich Content Vision.

Wiki is One, Data is Many

The human cost of maintaining multiple copies of the same templates or code across multiple wikis is prohibitive, resulting in a significant community and content fragmentation. Just like with images and videos, it should be possible to have a common repository of data, templates, and Lua code in one place. Thus, I believe we should start with the rework of the cross-wiki content support (T66475, T1238, T41610).

Implement cross-wiki template transclusion (T6547)
Implement cross-wiki Lua module usage (T52329)
See also - Global-Wiki

At the same time, Commons should support the ability to store more variety of data than just images and video:

Add support for generic data type storage as files (JSON, CSV/TSV)
Add support for domain-specific data type storage as files like GeoJSON, TopoJSON, KML, 3D models, and other multimedia
Add ability to process data files with Lua
Add ability for Lua code to return data via API in the "raw" format (e.g. as JSON/CSV/...)

One Image = Thousand Words

Animations require JavaScript, yet giving untrusted authors a way to modify Wikipedia site's JavaScript is a major security threat. Sanitizing or sandboxing JavaScript to the point of being safe is not an easy task, but there is Vega visualization grammar - a declarative interpreted language that we already use for the graphs, and that supports interactive usage in version 2.0. Vega is good for producing data-driven charts and colored maps with overlays, but might need some work to support other visualization types, e.g. 3D or generic animations. Unlike charts which only require the data, visualizing maps also requires a model to draw on, e.g. the outline of the countries/regions/city districts. The OpenStreetMaps database has that data, and our new maps service could be made to provide it.

Where in the World is Map?

At present, adding a map to an article requires substantial investment of resources and time - a person with GIS experience needs to look at an article, decide what needs to be shown, construct a map using some specialized GIS software, and upload it as an image. On the other hand, our new OSM-based map service can show a generic map, but without the article-specific data and not conveying enough useful information. There are several community-lead projects that attempt to address this, such as WikiMiniAtlas which show article-related map when an icon at the top is clicked, but this relies on WMF labs, not very stable, does not scale, and cannot be inserted inside an article for security and privacy reasons. A good map should be tailor-made for the specific usecase, but easy enough for the majority of wiki contributors to edit it. Kartographer extension is a rough draft of this functionality, offering a <map> tag with additional article-specific geographic content.

One Tool to Rule Them All ...

... is a bad idea, and foundation should always help the community to drive multiple tools innovation. Community developers tend to know well what functionality is needed, but should not be required to produce a production-quality code from the start. Getting started extending Visual Editor seems non-obvious, so I think we should help with building more user-JS-based and labs-based Visual Editor gadgets by providing guides and tutorials. This way someone could set up a labs instance with a complex 3D editor or animation builder, integrate it into VE for testing, share it with others, get it adapted by a single wiki, and, once ready, get it into production code. This route should be encouraged for all new VE features, instead of spending a lot of time building a production-quality tool without feedback only to realize that it does not fit the need and needs to be rewritten.