User:Yurik/From Dream to Reality
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
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.