We want an Honest-To-God VisualWiki!

They don’t exist yet…

One where you can draw, and diagram, and have icons that link to pages, and so on.

When one comes, it’ll blow the world away.


…please excuse my… …enthusiasm… ;D

Hmm… MoinMoin has a ‘drawing’ attachment that uses a java applet to display you an simple graphical editor. They need a maintainer for it though. I think it’s a tiwkidraw applet, so I’d assume twiki also has it.

Alas, I doubt we would be satisfied using some crippled simplistic graphical editor, when every one of us is used to their own set of tools, including tablets, scanners, 3d rendering software, etc.

Sooo… a “download, edit and upload” button?

I already have the domain name .

Alas, currently it points to a text-oriented wiki talking about visual language. I want a Visual:VisuallyOrientedWiki?.

I want something that also illustrates visual language – analogous to the way Wikipedia:Edward Tufte‘s books simultaneously talk about and illustrate information display techniques.

Right now I’m picturing something like:

  • every page is a SVG diagram (or perhaps has a SVG diagram sandwiched between the standard textual header and footer)
  • “readers” can click on things in the diagram to jump to a new page. example1. example2. details.
  • Perhaps somehow automagically linkify certain kinds of text embedded in the image (supporting AccidentalLinking, avoiding unnecessarily difficult WysiwygIsntLinking)
  • Editors whose favorite editor is Inkscape can somehow get the SVG into Inkscape, edit it, and put it back. (We’re already doing something like this at SocialMapApril2006, but it seems like it takes too much effort to make a minor change). (perhaps using the OddmuseToInkscape utility).
  • Making normal small edits can be done rapidly, with a minimum of steps (see LongImageIncorporationProcess).
  • Edits can be reverted, like all other wiki.
  • Backlinks can find all pages that link to this page, like all other wiki.
  • Perhaps somehow show the differences from one version to the next.
  • Random brainstorm: perhaps a Visual:MapOfContents? is semi-automatically generated – the tiny clickable thumbnails of all (many?) of the pages on the wiki are automatically generated, but they are manually positioned on the Map.

As with any software project, I suspect it will be better to build something slightly better than what we have now, start using it immediately, and then refine it over a year or two. Better that than to try to specify everything with a Wiki:BigDesignUpFront that gets Wiki:ThrownOverTheWall.

Something better than what we have now, and definitely better than the MoinMoin drawing thingie, that I worked with for a long time way back when.

And: wot DavidCary said. (We have actually been talking about this for a long time.)

And I repeat and emphasize and underline: a truly visual wiki would be absolutely revolutionary.

I looked into SVG specifically because I was thinking about implementing VisualWiki.

The problem with SVG is that it’s implementation is very fragmented.

While FireFox “implements” SVG, it’s fragmentary. You just do not know what feature works, what feature works if you use it the wrong way, what feature appears to work but just consistently gives you wrong data & responses, though you do have a pretty good idea of what is simply not implemented.

As IE’s SVG comes online, it is unlikely to work with FireFox.

I regret to say it, but if we see an SVG wiki within the next 6 months, it is almost certainly going to be a flash app.

The other way to go (that I know of) is to make it an offline tool, that connects with a server, which then publishes graphics and clickable image maps to the web.

This actually seems more the way to go to me, since web browsers aren’t really made for drawing, anyways, even as you stack on a bunch of javascript.

I wrote InkscapeToOddmuse and OddmuseToInkscape to perform the essential ContentRouting, with our own wiki. Sadly, there is no way of connecting in image maps, so that you can click on the text. (We might be able to work with AlexSchroeder, if there is interest, …) There are some technical questions in there.

I think the easiest thing to do in the short term and with our immediate resources is:

  • locate a tiny & hackable wxPython drawing program
  • extend it with “publish” and “receive”
  • extend it with linking / image-maps
  • work on the text functionality, to be logical rather than painted
  • …and hyperlinking.

wxPython has limited text comprehension capabilities. (Yes, I’ve already looked into this.) For example, if you had CamelCase text on the 3rd row’s 20th column, 7 characters wide, you need to do quite a bit of coding to get the bounding box. You have to break up the text into one graphic per row, and then break up the line into 3 chunks (assuming one CamelCase instance in the middle,) and then get the bounding region for that chunk of text. That said, this is hardly impossible. It’s just an example of how irritating it can be to work with graphic text objects in wxPython, and most other drawing APIs…

This isn’t a show-stopper though.

DavidCary, you wrote in the summary, “more unnecessarily detailed description.” I don’t think that’s quite right, though; What I think we need right now are visions that do go into some detail.

Not because the details will be right, (they won’t be,) but because they will help flesh out in our minds the problem space, and make these things more real.

Hmm… I had once an idea (sadly, didn’t do much about it) to make a collaborative toy box – basically an application that would let you share a, let’s say, table surface, on which everyone can place and move around various tokens – icons, images, arrows, boxes, etc. I think I ranted about it on one of the tings.

Now I think that the idea could be possibly applied to a VisualWiki. I will describe one possible implementation, I hope this will show the idea better:

A visual wiki page would consist of a number of elements: images and divs with text. These elements are just a normal HTML page, except that all the elements are positioned using style’s “position:absolute” or similar technique. Both images and parts of text can be linked to other pages. So, for viewing the pages, you need a browser with CSS support, and obviously you need to see it. Not too high demands for a visual wiki, I think.

When you hit “edit”, all the links are disabled and the text divs are replaced with text areas and images have added input field for entering their links. There is also displayed a form for adding new elements (they would be best treated similar to wiki pages). So, for editing the text and links you still are good with normal CSS-supporting browser.

In the edit mode a JavaScript script is also run, that allows you to drag the elements around and adds their coordinates as hidden form fields just before posting the page. So for moving the elements you need additionally JavaScript support.

RecentChanges page would normally list changed pages, diffs would outline the objects that moved and the text that changed.

That’s about the technology, now what it gives:

  • you can easily make minor changes on the pages, directly in your browser
  • you can prepare high-quality graphics for the elements in whatever tool you like to use
  • you can easily rearrange and refactor the pages
  • once you put an element on any page, it enters the “visual vocabulary” of the wiki – others can re-use the same element without effort – similar to how entered text works in traditional wikis
  • you still have an ‘edit mode’, so no accidental page edits
  • I think it’s doable with current technology and even not so modern browsers

Pushing the element<->page similarity further, you could have a third kind of elements: other pages. Those elements would always link to the page they represent, and would just show a miniature image of that page – kind of a zooming interface. Or maybe better, just like wiki pages have text and title, the visual wiki pages could have content and icon.

So, lets say that on one of the pages you have this great and really complicated graph, with lots of graphical elements that don’t really have that obvious meaning. Lets say one of the elements represents a piece of paper with some text on it. So you click on it, and you immediately are taken to another diagram that explains what a wiki page is – probably with aforementioned piece of paper in the middle and some arrows and symbols and text all around it. You click on one of these, and are again taken to the appropriate page for that symbol. Kind of like a zooming interface.

Yes, that sounds great. So is this demo pretty close to what you wanted the collaborative toy box to do?

Well, the toy box was supposed to be real-time collaborative, so it would use AJAX and all the users would see in real time how other users move objects. This is, however, not necessary for the wiki.

I’ve made this really quick mockup of how the page editor could look like: you can rearrange the elements thanks to the javascript and when you hit ‘save’, another javascript will traverse all the elements and save their positions into your form, so that they are saved on the page. The ‘upload’ button is for adding new elements to the page – not sure how that would be best done.

I played with the mockup a little, and I think it starts to resemble something potentially useful. At the moment you can move text fields and images around, add new images and text fields, and then save the whole thing – I made it use GET instead of POST, so that you can see what it saves. Of course, the server-side part that is supposed to actually store and render the pages is missing, so you can’t really save it.

I have had a chance to look at these “toy box” ideas yet, but it strikes me that there are similarities in what I’ve studied at I’s be happy to kick this around further if anyone is interested.

Hans, so far I’ve been interested in everything you’ve offered to expand on here at CommunityWiki, and I think at least a few others are, too. So, I’d say please don’t hesitate to lay it all out.

Just found another link that appears to be in the trend:

TheSheep, did you happen to have the code for your mockup mentioned above available online somewhere? I am learning JavaScript, and JQuery, and thought I could learn from your example.

There is no more code than in that HTML file, except for the scriptaculous library which is available from their website. I haven’t integarted it with a wiki – it just sends a POST with all the coordinates and urls of the images. What is needed is two wiki plugins: one that would take that post and save as text to a wiki page, and another that would read that page and display the html as in the mockup. Precisely for this purpose I allowed to use different viewer and editor plugins in Dandelion, based on the MIME type of the page.

Come to think of it, it could be integrated with a MoinMoin wiki using one parser plugin for displaying and action plugin for saving. I will have to come back to it.


Define external redirect: VisuallyOrientedWiki MapOfContents

EditNearLinks: MoinMoin AccidentalLinking JavaScript CamelCase


The same page elsewhere: