User:JamesCrook/sandbox
This page was a draft. Please see the final proposal there: Proposal:Editable Graphics.
Summary
This is a proposal for a unified approach to editable graphics in MediaWiki. It draws from and is inspired by a number of technology related proposals on this wiki. Rather than propose a specific technological solution it proposes a process for arriving at a unified solution. In a unified solution essentially one body of code handles editable graphics of many kinds.
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 also be needed to accelerate the process of development and to ensure that scaling issues are considered and addressed earlier rather than later in design.
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, geneologies. It's likely that general data handling will use a unified approach. So too should graphics.
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 geneology to general charting. Each type of graphic has or could have a little language or other method to define graphics of that type succinctly. Whilst all can be presented as .pngs, the 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 the types generally is increased and the resources available for improving quality of support for each individually 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 by their own specific domain's needs, and not by the general goal 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 that makes 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 large maps.
- The use of Java for a WYSIWYG editor interface in WikiPathways shows one route to a no-install browser-agnostic visual editor.
- 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
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.
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 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.
References
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 and linked to from here
| Syntax | Special Features | In-Browser editing | Widespread Browser Support | Animation | |
|---|---|---|---|---|---|
| Bitmap (.png) | .png, .jpeg (binary) | Image maps. | no | yes | partial (Javascript effects) |
| Vector (.svg) | .svg (XML) | ??? | maybe (using Javascript) |
Not IE | yes |
| Flash | .swf (code) | ??? | maybe | yes | yes |
| Silverlight | .scr (code) | ??? | maybe | Only IE | yes |
| Java | .jar (code) | ??? | maybe | yes | yes |
| ActiveX | .ocx (code) | ??? | maybe | Only IE | yes |
| Firefox Extensions | .xpi (code) | ??? | maybe | Only Firefox | yes |
- 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 'maybe' indicates the method can potentially edit data, but that's not a built-in feature.
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 and linked to from here
- OpenStreetMaps For mapping.
- WikiPathways For biochemical pathways.
- WikiTex General framework for adding additional tags, e.g. <music> and invoking a server side special renderer to render to a .png.
- Graph Plugin ?? Is this a particular special case of WikiTex?
| Syntax | Special Features | In-Browser editing | Diagrams For | Written in | Open Source | First public release | Latest Stable version | |
|---|---|---|---|---|---|---|---|---|
| WikiPathways | XML | ??? | yes (Java) |
Biochemical Pathways | ??? | yes | ??? | ??? |
| OpenStreetMaps | XML | Slippy maps | no | Maps (also star maps) |
??? | yes | ??? | ??? |
| WikiTex | Custom (Diverse) | ??? | no | Music, Graphs, Chem, Chess, Go, others... | PHP (+arbitrary plugin) |
yes | ??? | ??? |
| Graph Plugin | Custom | ??? | no | Flow charts | ??? | yes | ??? | ??? |
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
Contacts
Name : email : job
- Erik Moller : erik on wikimedia.org : now responsable of the Greenspun project fund.
- Cragg : cn on cloudmade.com : Senior Product Manager at OSM .
(need to ask abstract of the situation)
Community Discussion
Do you have a thought about this proposal? A suggestion? Discuss this proposal by going to Proposal talk:JamesCrook/sandbox.
Proposal:Editable Graphics