Summary: @TheSheep is your mockup code online somewhere? | That's all there is for now.
> 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.
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 http://visualwiki.org/ .
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:
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.
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:
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.
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:
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 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 http://www.protopage.com/. 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: http://www.wetpaintpleasetouch.com/
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.