[Home]TouchGraphWikiBrowser

MeatballWiki | RecentChanges | Random Page | Indices | Categories
The TouchGraph WikiBrowser is a quick demonstration of how TouchGraph can be used to visualize a Wiki. The current demo renders the MeatBall Wiki, and EmacsWiki LinkDatabase s, but any database encoded in a similar format (see WikisWithLinkDatabases) could be displayed.

VERSION 1.02

The application with source code is [available for download.]

TGWikiBrowserScreenShots

June 11: Thanks to feedback and contributions from users of the WikiBrowser some minor changes have been made to V1.01. As suggested by BillSeitz, the LinkDatabase can now be read from a URL instead of a file. Thanks to a patch by ChristophDrieschner? the Browser-Launcher now works for Windows NT/XP.

April 21: The highly usable V1.01 release is finally out! There are lots of improvements over V1.00. A new type of node has been added to represent pages external to the wiki. Thus, if an external URL has been mentioned repeatedly on several wiki pages, one will see multiple incoming edges for the corresponding node. A Show BackLinks checkbox allows back links to be shown or hidden. A Stop button has been added for stopping the graph motion. [...and more...]

All these features really give one the ability to explore the structure of the Wiki.

The down side of the LinkDatabase being read from a fixed text file remains, though there are plans to resolve this issue by dynamically acquiring the link structure through calls to an XML based API. Some progress along these lines can be seen at JspWiki:TouchGraphWikiBrowser

One of my goals for TouchGraph is to build the ultimate tool for creating rewritable text. (See WikiRefactoringBrowser; some discussion was moved there).

It is too bad that SoftSecurity does not look good when visualized with the TouchGraphWikiBrowser. On the surface it seems that this is exactly the sort of data that should form a good graph. You do get usefull graphs when focusing on nodes related to SoftSecurity, for instance AuditTrail, but a graph around the SoftSecurity node ends up being too messy.

I think that fixing the "Hide Node" functionality of the WikiBrowser is essential for getting this graph into proper shape. For instance, it would be nice to be able to hide the selected node without having everything else disappear. Another enhancement would be to only display the forward links, which should only show the pages closely related to SoftSecurity.

--AlexShapiro

--

I bought the AtlasOfCyberspace a while ago. After looking through it, I began to appreciate how difficult this problem is. I think at a deep level the major conceptual block to destroy before we have any meaningful representation is the necessity to translate the graph to common experiences.

Still there are some things that need to be done immediately. As you suggested, it would be nice to somehow dynamically acquire the LinkDatabase. Excluding pages that are tagged with CategoryHomePage is also a must. What do you need from this side? -- SunirShah

I am starting to like the idea of adding the required dynamic LinkDatabase acquisition functionality to the XmlRpcToWiki interface.

I see the need to invoke the following function:

array wiki.getPagesWithLinks( String[] pagenames )

This function would return an array of the combined results of the wiki.listLinks() and wiki.getPageInfo() for each of the pages in the pagenames array.

Such a function would enable the retrieval of all the data required to display a localized subgraph of nodes with a minimum of requests to the server. For instance if a radius of 4 was selected, only 4 requests would need to be made, with each request asking for data about all nodes at radius x (the central node is at raduis 0).

To replicate the current functionality of the TGWikiBrowser? it would also be necessary for backlinks to each page to be returned along with the outgoing links. Another nice feature would be to group the outgoing links from each page by the horizontal sections that they appear in. These two tasks could probably be accomplished by adding wiki.listBacklinks() and wiki.listLinksInHSections() to the XmlRpcToWiki interface.

What do you think? We should talk more about what kind of other data should be returned by this function, and what the structures should look like.

... Having looked around, I am becomming more convinced that using XML-RPC is a good idea. Les, thanks for pointing it out.

--AlexShapiro

I too am very impressed with the touchgraph. It inspired me to create four new categories. The combination of text and graphics feels very natural. It got me thinking about JavaRefactoring? and the idea of a CodeNode and BrainStorming and MindMap and TextAnalyis?.

I'm trying to create a sequential set of nodes. I'm testing the Wiki Browser as an interface as a proto Wiki UML tool.

Wiki Browser left frame launches the browser so veiwing recent edits feels difficult.

I also had uneven reponses when using the search field. I kept trying TextAnalysis? so that I could get a linear visualization of nodes.

Of note, sometimes the TouchGraphWikiBrowser center node will 'jump up-n-down' presumably while it's finished populating the node data and the graphical algorithm makes room for the new nodes...

I did check out TinderBox below and it is very much in line with what a number of my friends have been asking me for... a graphical content management GroupWare.

In the not so distant future users of wiki and wiki like environments will be able to choose how they want content to be visualized. Makes my head spin.

Wiki Browser looks to have great potential to become just that. Controlling the node display is the key question. Structured node dispaly like a basic table of contents would be very cool...

One the things that I like about TouchGraphLinkBrowser is it's use of simple xml to generate the diagram. Some kind of mix of templating could be applied to the Wiki database. For example ShowE#25 ExpandE? then all of the nodes get sorted by number of child nodes in a tree or ladder.

The same kind of xml template that is used in Link Browser theoretically could be applied to the Wiki data. These could be very simple I imagine having seen the power of the current Link Browser interface.

And while thinking about it, how about a browse to... button so that links could be made to URLs? While editing the Wiki? If it's running through an applet it should to write to the DOM and pass the DOM on to the server...

--DennisDaniels

I see potential, but for now my overall reaction is "nice toy to play a few minutes with, but not something that helps me daily". The display is much too crowded for one purpose I could see, namely exploring the overall structure of a wiki. That'd mean to weed out pages with only one link to them and such things, i.e. have a display of the whole wiki that is as readable as a very local one. -- JürgenHermann

Definitely agree with you Jürgen. Again, I believe it's a question of the algorithm used to populate the Wiki Browser. Usage of ShowE and ExpandE? is a good start. Usage of LinkPattern might be the solution.

Example: getLinkPatternRecentChangesToday most recently edited (and retrieve the 14 or so nodes that were edited today not the whole RecentChanges structure)

Example: getLinkPatternAuthor display all authors on wiki (with little UmlActor? icons!) and color code the last edit with a link node to the last WikiName the author modified.

The last one is partially enabled but I find the results can be somewhat uneven and the display could be very difficult for someone who is colorblind. That's why an iconing system could really help. Dare I say /. like?

--DennisDaniels

LiveJournal gives each author their own icon. That's cool if you want to promote individuality (as does LiveJournal). If you want more of a BarnRaising atmosphere, maybe not so cool.

The reason that the TouchGraphWikiBrowser might not appear to be an every-day use sort of tool, is that the current nature of interaction with a Wiki does not involve enough reorganizational activity. How often do you take the text from two separate pages, and put it together to form a new page? I believe that a good wiki visualizer can make such changes a much more frequent occurence.

I agree with DennisDaniels that there are lots more filtering functions that need to be added to make the browser more practical. The author filter is a good one. The point about displaying recent changes is also good. Viewing recent changes must be the most frequent use of a wiki, and that is the functionality that the TGWB is worst at handling, in fact it wasn't even something that I was considering in this version.

--AlexShapiro

Two things:

  1. I think this would make a great client for XmlRpcToWiki, especially with that API's getAllPages() and listLinks() methods.
  2. Have you checked out TinderBox? Seems to me that something like this could be an interesting collaborative cousin to that thought managment app.

-- LesOrchard

Les, I wrote a very simple XML-RPC Application on top of MahlenMorris?'s Hula package. You can use it to query the JspWiki:Main (or any other Wiki using the XmlRpcToWiki interface) to make a visualization map for the current version of TouchGraphWikiBrowser. It's available on JspWiki:TouchGraphWikiBrowser.

-- JanneJalkanen

Another thought I just babbled about [over here]. Instead of a Java applet, how about something like: XmlRpcToWiki (or LinkDatabase) + [OPML to SVG] + ?? = TouchGraphWikiBrowser. I don't know enough about SVG yet, so maybe this is not an efficient or dynamic enough solution. --LesOrchard

I've though about reimplementing TouchGraph using Flash or SVG, but both of these methods are too low powered when compared to java. Perhaps with some work, the graph layout algorithm could be ported to these languages, but neither would allow the creation of a fully featured interface. See http://softwaredev.earthweb.com/java/article/0,,12082_881231,00.html (and I don't plan on using Batik either :)

--AlexShapiro

I've been playing with TwikiDraw? recently. It's quick to load and has decent drawing features. It's implented with JHotDraw? http://www.jhotdraw.org/ It uses the plugin architecture for Twiki so the user need only include a simple %DRAWING% tag in the wiki to call for the applet. The output.draw is NOT xml unfortunately. --DennisDaniels

Jürgen

not that i have any time to implement this myself, but i wonder what a TouchGraphWikiBrowser that used GeonDiagrams to display nodes would look like.

Or, even better, that but augmented with system integrated with the wiki that allowed a wiki page to specify its icon in the graph (this is already done on the web somehow, right? in the latest mozilla certain sites get their own icon if i put them in my personal toolbar). If the page did not specify its own icon, a unique geon with texture could be generated from some sort of summary of the page, in such a way that everyone saw the same auto-icon for the same page, and that the icon would not change much unless the content of the page changed radically (so that you could, over time, learn to associate each page's auto-icon with the page).

Because right now each page "looks" the same in the graph, and you have to read the names to tell them apart. Having pictures with each page might give parts of the graph more of a "feel". It may also let you navigate the graph quicker; your brain may be able to better ignore pictures that it isn't interested in at the time, whereas i bet it has to read through the words a lot because they all "look the same".

-- BayleShanks

A thumbnail along the lines of Wiki:SignatureSurvey would be perfect.

''This discussion inspired me to resurrect a section revised out of the original MacroScope paper: [Visualizing Repetitive Document Structures] --JonSchull'

--- John's document is well worth a read if you've any interest in visualizing of problem spaces! --DennisDaniels

How totally fabulous! I'd been wanting to work with this, and luckily someone else posted some Zope code to generate the input data. I have my file available from WebSeitzWiki:TouchGraph. --BillSeitz

CategoryWikiTechnology

Discussion

MeatballWiki | RecentChanges | Random Page | Indices | Categories
Edit text of this page | View other revisions
Search: