WikiWhiteboard

The idea of a WikiWhiteboard is to expand the wiki technique to at least visual images.

Almost all wiki engines have a distinction between how users can contribute text versus how they contribute everything else (video, audio, or image files). There are a number of reasons for this, not least the idea of MeatBall:ContentOverForm, but in particular there’s the fact that most browsers allow in-browser editing of text through HTML forms, but not of other data formats, except for file upload. In other words, it’s because browsers make the distinction that we have a separation between text and everything else.

The idea of a WikiWhiteboard is to expand the wiki technique to at least visual images. The word “whiteboard” is a little deceptive – having in-browser editing would make it easier to collaborate on diagrams, maps, or other visual language, without the Visual:LongImageIncorporationProcess.

Possibilities

Embedded editors

One possibility is using embedded editors, such as Java applets or `ActiveX` controls, to do the heavy lifting for the in-browser editing.

Scalable Vector Graphics and DOM

Recent developments of the Scalable Vector Graphics format (SVG), a vector image format implemented in XML, have made it possible to do in-browser editing of images using a combination of ECMAScript and XML DOM. The image files can be edited in the browser, and saved and versioned in the same way as Wiki text.

The SVG data can be stored on the server and served to the reader in an <object> or <embed> tag. Simple HTML controls (buttons, links, or whatever) can be used to create an in-browser editor, much as a WysiwygEditor works. ECMAScript and DOM are used to modify the image, and an HTML form is used to submit the data back to the server.

An article in xml.com describes this technique. The JSPWiki implementation is (supposedly) relatively easy to adapt to other wiki engines.

Easy Import & Export between SVG Editors and Image Servers

Make it so that programs like InkScape or SodiPodi can import from and export to wiki images, hosted on wiki, or some special purpose “image server.”

If you have an SVG graphic on a wiki, you may want to be able to edit it using a full-on SVG editor.

In the SVG editor, you would give some sort of URL. It would import the graphic from the URL, and export back to the URL.

The SVG editor would probably also have the option of sending a parallel PNG as well, since wiki may not be sophisticated enough to convert SVGs to PNGs. (Research this.)

The URL could identify:

• an XML-RPC interface point. (supporting “get_file”, “get_file_versions”, “get_file_with_version”, and “put_file”)
• a WebDav access point
• an address for using some conventions with GET, POST, etc.,.

InkScape has included open/save functionality in their InkScape:ExtensionArchitectureProposals. It should be pretty easy to write an extension module that could open up a URL, and save to the URL.

(I don’t know what SodiPodi’s capabilities or ideas are.)

Implementations

Activity

I saw that there was some interest at Inkscape in this sort of thing- InkScape:NetworkedEditing.

Also, Interwiki wiki’s InterWiki:MarkupSkins has implications on how to make it so you can edit wiki images with free software graphics editing tools.

Terminology

• SVG
• Whiteboard

Problems

• Not all browsers handle SVG well

See Also

Contributors

EvanProdromou, LionKimbro

CategoryFeature CategoryEditing CategoryObject