Thanks for starting this Jon, the end result is going to be awesome. So here's how I see things, it's roughly along the lines of what you've been saying: Server-side rendering and scaling is important. This is one of the main reasons I picked Vega [2] for my hack. The same visualization grammar can be used to generate png or svg [2]. I see the approach to visualization as being similar to Parsoid: * user creates a visualization (with a visual editor) and saves * Vega parses that server side and generates an image, then refreshes the caches accordingly * a transcluded visualization renders the image from cache as a link to the interactive version * when the link is clicked, something like MediaViewer shows the interactive visualization * alternatively, we can allow editors to show the interactive version in the transclusion itself, but that has performance implications until browser caches are filled. Now a little bit about where I see the Map namespace. A visualization in the world of Vega has three parts: * Data (one or more sets of data, can be geojson, topojson, tsv, csv, layers from OSM [3], OHM [4], etc.) * Transformations on that data (scales, normalization, etc.) * Marks (visual representations) Transformations and Marks can be written by hand or by a visual editor that introspects the specification to show what's possible. Data to me is the tricky part. We may need to restrict Vega to only consume open data that's hosted and curated by us, and that could be done in a few different ways: * Namespaces like the Maps namespace that enables awesome collaborative editing of geojson * Datasets in WikiData using an alternative data model * File namespace serving raw data from Commons (where people are familiar with take down notices and have the infrastructure to deal with that) But yes, I do see the Maps namespace as one of the sources of data that we could visualize with Vega. And recent developments in Vega make me feel that it's really a solid choice for generic visualization. We have interactivity, headless mode, a seemingly clear path to a visual editor via introspection of the grammar specification, and pretty much everything I can think of needing from such a tool. For the short term, I think further exploration of the Map namespace is great, but I think generic visualization work could go into the Visualization namespace. My suggestion for a name for this namespace may seem a bit obscure. It's a word that means "to illuminate": Limn [5]. There's an old project by that name of which I'm not very fond (despite writing some of it myself), but I've always thought the word was beautiful and fit. To what Antoine was saying earlier, we should illuminate the world's knowledge with beautiful visualizations. [1] https://github.com/trifacta/vega [2] https://github.com/trifacta/vega/wiki/Headless-Mode [3] OSM - Open Street Maps http://wiki.openstreetmap.org/wiki/Main_Page [4] OHM - Open Historical Maps http://wiki.openstreetmap.org/wiki/Open_Historical_Map [5] Limn - depict or describe in painting or words: https://github.com/wikimedia/mediawiki-extensions-Limn On Wed, May 14, 2014 at 9:43 AM, Jon Robson <jrobson(a)wikimedia.org> wrote: