Proposal:Editable Graphics

Status (see valid statuses)

---

The status of this proposal is:
Request for Discussion / Sign-Ups

Strategic Priorities

This proposal is associated with the bolded strategic priorities below.

1. Achieve continued growth in readership
2. Focus on quality content.
3. Increase Participation.
4. Stabilize and improve the infrastructure
5. Encourage Innovation.

Share this:

Summary

This is a proposal for a unified approach to editable graphics in MediaWiki. It is particularly relevant for particular domains of graphical image.

• It will increase quality of graphics. Images for a particular domain (chemistry, molecular biology, maps, electronics, graphs, charts, pedigrees, timelines, industrial processes) can be consistent and the work involved in making good 'templates' shared. Typically good results will happen without having to change default details, so less effort for contributors to get good quality results.
• It will increase participation in creation of graphics. More users will be able to create, modify and re-use graphics and with less effort.
• It encourages innovation. With images being easier to create and modify and directly from the browser, one barrier to experimentation with more images in Wikipedia will have been removed.

This proposal draws from and is inspired by a number of technology related proposals concerning graphics on this wiki and also from some proposals on structured data handling.

• WYSIWYG editing from within the browser is used to edit the graphics.
• Diverse types of graphics are supported with each type potentially having its own custom representation and component elements. For example maps represented in terms of roads, stave music in terms of notes, graphs in terms of numbers, genealogies in terms of relationships.
• The underlying data is used to generate the graphics. We may generate SVG or bitmap formats to show in the browser, but that need not be the underlying format. This promotes editability, verifiability and flexibility of the graphics. Updating a pie chart is easiest when you have the underlying numbers. There is little danger of wedge sizes not matching the numerical values. A map can be presented in different projections and with different levels of detail. This is easiest if it is represented as its underlying GIS data rather than as vector graphics.
• One toolchain is used to generate graphics of many kinds in spite of the diversity of types of graphic. The in-browser WYSIWYG editor is smart enough to customise itself to different graphics types. You'll have a different palette of elements to add if you're working with a road map than if you are working with a biochemical pathway.

The proposal concerns developing new technology and belongs in the graphics subsection. It also has a bearing on new technology plans for more general data handling going beyond text. That's because ideally editable diagrams will be represented in formats that allow automatic extraction of information, such as road names, proteins, genealogies. It's likely that general data handling will use a unified approach. So too should graphics.

Route to Implementing Proposal

One possibility is to use XML and XSLT technology to support the diversity of graphics types and their representations yet bring all the different types of editable graphics into the same toolchain. Enhancements to that toolchain benefit all graphics types supported.

However, rather than mandate a specific technology or computer language as the basis for the solution, this proposal instead proposes a collaboration initiative. The aim is to motivate existing wikimedia developers to collaborate more effectively in developing graphics code for wikimedia.

Steering by Wikimedia is needed to avoid fragmentation of effort. Wikimedia can encourage groups which are already working on technology for graphics in local Wikimedia installations to talk with each other and gain the benefits of sharing technology and ideas with each other. Steering may accelerate the process of development and may ensure that issues such as scaling are considered and addressed earlier rather than later in design. Steering done now is likely to be more cost effective than steering done later. If nothing is done to get groups talking incompatible solutions re-implementing the same features but for different types of graphics will likely be the norm.

Motivation/Existing projects

• There are many types of diagrams. The need for collaborative graphics is wide ranging, from map making to biochemical pathways to flow charts to genealogy to general charting. Each type of graphic has or could have a little language, XML or other representation to define graphics of that type succinctly. Whilst all can be presented as .pngs or .SVGs, the more succinct description is necessary for editability.

• The diversity of graphics types presents a similar problem to the diversity of types of structured data. If each type of data or type of graphic is supported through custom wikimedia code the work in supporting graphics is increased and the resources available for improving support for each type of graphic suffers. For structured data the natural solution is to use a common mechanism for supporting the data, whatever subtype it has. The same could be done for diagrams. Indeed data for production of diagrams is a special case of general structured data, with the additional requirement that there be a defined way to render it to an image.

• Groups are already working on technology for collaboratively editable graphics in Wikimedia. The groups are motivated to solve the problems their own specific domains present. They and not driven by the general goal of diverse types of editable graphics. Their specific project needs inform their design decisions.

• There are many deployment technologies. Images (bitmaps in .png and jpeg format) are the lowest common denominator and nearly universally supported medium for graphics. Other browser technologies available each have strengths and weaknesses. Experience is needed to create a good editing solution from these to make editing easy and accessible to the majority of potential editors.

• Technology refined in one context may be beneficial in others. Examples:
  • The 'slippy maps' in OpenStreetMaps gives a google-maps like interface for very large maps.
  • The use of Java for a WYSIWYG editor interface in WikiPathways shows one route to a no-install browser-agnostic visual editor.

• Whilst zoomable, SVG images may be larger than equivalent .png images. For charts and graphs the underlying data gzipped will be significantly smaller. The unified approach should reduce server load for such charts, at least for the browsers capable of rendering client side that cache the image generation code.

• Hard won Wikipedia experience could be invaluable in shaping the design of wikimedia embedded collaborative graphics. Wikimedia foundation understands the issues around vandalism, copyright, licenses, community building and norms. The current developers of graphics for specific uses understand the issues around graphics in their own domains of expertise.

Proposal

This proposal is a proposal for a route to a unified system for editable graphics. Communication between groups needs to be fostered, otherwise progress on a unified approach will be slow.

Short Term: Identification and Communication

• Identify the key organisations and groups that are already using diagrams in wikimedia and developing technology for it. (This process can be started on this wiki)
• Identify the key perceived technical requirements for editable graphics for them to eventually be deployed on Wikipedia. Scaling issues and universality of access are clearly important technical requirements, but a deeper investigation is warranted. (This process can be started on this wiki).
• Encourage the groups to talk with each other and unify their approaches. Encourage also communication with a pure data task-force, if such exists. This can be via:
  • Providing wiki space for discussion and interaction with wikimedia with an emerging graphics task force.
  • Graphics task force panels/workshops at wikimania conference.
• Individuals can be invited to come and provide seed content here that will then encourage other wikimedia developers to participate in a graphics task force within the technology group.

Medium Term: Targeted sponsorship

• Sponsor a standards-track for collaborative graphics based on the emerging standards.
• Sponsor publicity (kudos) through a public standards-compliance/completeness site for showcasing solutions that are progressing.
• Inviting and paying for travel and expenses for attendance at Wikimania for people working in these areas may help promote development.
• Sponsor development that is specific to mediawiki's needs. Hardening (security) and scaling are examples of those needs that might not otherwise happen in the smaller deployments.

Longer Term: Deployment and Refinement

• Trial and then full deployment on Wikipedia.
• Refinement...

Key questions

• What existing projects are working on collaborative graphics in wikimedia?
• Will these groups arrive at the best outcome or a good enough outcome without an initiative from Wikimedia Foundation?
• Is coordination with a data task force necessary or useful for developing editable graphics?
• Which browser technologies (both client and server side) have the right properties for an implementation? Is there one clear best technology?
• What are the technological and social barriers to developing a unified approach to graphics?
• What issues are there around internationalisation of text strings in graphics?
• What are the actual costs in time and funding for the short medium and longer term proposals? Are there more cost effective routes?

Potential Costs

• Potential cost is minimal in the first phase which mostly concerns establishing communication pathways.
• In the second phase financial cost are likely moderate and can in any case be tailored to the desired rate of progress and ambition of the initial planned deployment.
• Deployment of multiple types of editable diagrams would have significant costs on servers and support and cost in editor's time. One can look to OpenStreetMaps for an estimate of these costs.

Relation to Related Proposals

Structured Data

Representation of graphics types are (or can be) structured data. Going for a unified approach to graphics increases the opportunity to leverage general work on structured data.

Java Applets

The proposal could lead to an evolutionary approach to greater support for Java in wikimedia. A proposal for java applet support envisages one java applet for each animatable graphic. This proposal for unified graphics could suggest starting out with fewer java applets for standard graphics, perhaps just one even. The one java applet would then be configured for a particular graphic. This is essentially what happens in wikipathways. The java applet proposal proposes externalising the strings so that they can be localised. A unified approach would externalise more, so that chart data would for example be external.

The proposals are probably compatible.

Reference Material

Browser Technology For Images

• This is a comparison table of the technology available in browsers for rendering images.

Edit hint: Comparison table could be made into a new page 'Comparison of Browser Technology for Images' and linked to from here

	Syntax	Special Features	In-Browser editing	Open Source Throughout	Widespread Browser Support	Animation
Java	.jar (code)	???	possible	Yes	Yes	Yes
Flash	.swf (code)	???	possible	No	Yes	Yes
Silverlight	.scr (code)	???	possible	No	Only IE	Yes
ActiveX	.ocx (code)	???	possible	No	Only IE	Yes
Firefox Extensions	.xpi (code)	???	possible	Yes	Only Firefox	Yes
Vector (.svg)	.svg (XML)	???	possible (using Javascript)	Yes	Not IE	Yes
Bitmap (.png)	.png, .jpeg (binary)	Image maps.	No	Yes	Yes	partial (Javascript effects)

• All methods marked '(code)' in the syntax column can, with the appropriate programming (a non-trivial task), be used to render from XML or from custom text formats.
• In-browser editing marked as 'possible' indicates the method can potentially edit data if so programmed, but that's not a built-in feature.
• SVG can be added to IE 6 and above by using the Chrome frame plug-in and there is also an SVG->Silverlight adapter extension. However neither of these plug-in is commonly installed on IE. A third possibility is svgweb which uses flash.

Diagramming in Existing Wikimedia Deployments

• This is a comparison table for existing deployed implementations of collaborative diagrams within Wikimedia.

Edit hint: Comparison table could be made into a new page 'Diagramming in existing Mediawiki Deployments' and linked to from here

• AnyWikiDraw For SVG, png and jpeg editing.
• SVG-Edit For SVG editing.
• WikiPathways For biochemical pathways.
• OpenStreetMaps For mapping.
• WikiTex General framework for adding additional tags, e.g. <music> and invoking a server side special renderer to render to a .png. As well as requireing LaTeX server side it may require specific executables for the custom renders. For example to render schematic diagrams of circuits it uses GEDA and a frame buffer.
  • Maybe implement w:PGF/TikZ for MediaWiki-usage?
• Graph Plugin ?? Is this a particular special case of WikiTex?
• The DPL bundle of wikimedia extensions also provide data extraction facilities. See semantic-wiki for an alternative data only approach. Ploticus, treeview and wgraph are elements of the bundle.

	Syntax	Special Features	WYSIWYG In-Browser editing	Diagrams For	Written in	Open Source	First public release	Latest Stable version
AnyWikiDraw	SVG, PNG, JPEG	Also available in MoinMoin, PmWiki, TWiki, and Foswiki	yes (Java)	General	PHP + Java	Yes	???	???
SVG-Edit	SVG	???	yes (Javascript+SVG)	General	PHP + Javascript	Yes	???	???
WikiPathways	XML	???	yes (Java)	Biochemical Pathways	PHP + Java	Yes	???	???
OpenStreetMaps	XML	Slippy maps. Advanced styling options	No	Maps (also star maps)	PHP	Yes	???	???
WikiTex	Custom (Diverse)	???	No	Music, Graphs, Chem, Chess, Go, others...	PHP (+arbitrary plugin)	Yes	???	???
Graph Plugin	Custom	???	No	Flow charts	???	Yes	???	???
DPL Bundle	Custom	Data extraction from multiple pages	No	Charts	PHP (+arbitrary plugin)	mostly	???	???

<references \>

Other References

From a presentation at Wikimana 2009:

"Wikipedia has an initiative underway to integrate OpenStreetMap into article pages, as inline maps and/or as pop-up maps. With the infrastructure in place to allow this to happen, it paves the way for future innovative uses of maps beyond just OpenStreetMap. One such possibility is the addition of satellite imagery from NASA WorldWind, including Landsat and NASA's Blue Marble imagery, which may be feasible to implement in the short or medium term. "

Proposals this would help progress

Proposal:Infographic interactivity

Proposal:Markup for charts and graphs

Proposal:More Graphs and Less Math=More Approachable

Proposal:Text or Syntax driven Charts, Diagrams, Graphs and more

Proposal:Visualization methods

Map related proposals this would help progress

Proposal:Map conventions

Proposal:Markup for Maps

Proposal:OSM relate, Encyclopedic OpenStreetMap

Proposal:OSM relate, Online 2.0 SVG editor

Proposals this might help progress

Proposal:Java applet support

Proposal:Data-driven content

Proposal:Multimedia File Formats Standards to maximise bandwith efficiency

Somehow connected proposals

Proposal:Data.wikimedia.org

Proposal:A central repository of all language independent data

Proposal:WikiGIS -- Setup a GeoServer to Share Georeferenced Data

Community Discussion

Do you have a thought about this proposal? A suggestion? Discuss this proposal by going to Proposal talk:Editable Graphics.

Proposal:Editable Graphics

Want to work on this proposal?

1. Add a message on the discussion page if you're interested in helping make this happen.
2. OR if you want to modify or improve the proposal make that change here.