WikiRefactoringBrowser

MeatballWiki | RecentChanges | Random Page | Indices | Categories

A subfeature of the WikiBrowser idea.

One of my goals for TouchGraph is to build the ultimate tool for creating rewritable text. There are two ways in which text can be rewritten. The first is connoted in WhatIsReworking as correcting and adding to what is written on a page. The second method of rewriting is to move text around. When one starts talking about moving text, it is immediately necessary to get away from the linear document model of text, and talk about more of a wiki-like hypertext structure. In a linear document, moving text would involve moving paragraphs up and down within the document. With hypertext, we can also talk about moving text by creating new pages, or moving text between pages.

In theory, Wikis allow for both types of rewriting, but in practice it seems that moving text is done a lot less often then inline additions. I believe that this is the case because the WikiMedium?? (WhatIsaMedium, HyperMedium), is still closely related to the LinearDocumentMedium?? in that the interrelationships between paragraphs is kept implicit. More then that, interrelationships between pages (except for the immediate "page1 links to page2" data gathered from seeing a hyperlink) is kept implicit as well. One is not encouraged to reorganize the way text is distributed between pages because one can not see the similar themes in documents that are slightly further away then being directly connected by a link.

Visualizing the wiki (Wiki:VisualizeTheWiki) would encourage reorganization, because pages dealing with the same themes would naturally end up clustered together. This would happen because similar themes should entail similar references, and thus the pages will end up being displayed near each other, even if there is not a hyperlink that directly connects the two.

Wiki visualization would also have other benefits. For instance, a visual structure would allow links to be typed, with edge colors being an obvious way to display this typing. Also, a graph would allow users to vote on link relevance, with less important edges having less pull on the associated nodes, or not being shown all together. A visual structure could allow for other types of linking besides hyperlinks, for instance links could appear between pages without having to have one of them contain a reference to the other. Finally, perhaps nested hyperlinks (like in crit.org) could be better implemented with a graph.

My vision of the evolution of wikis with the aid of a graph-based interface is that page size would shrink down to a few paragraphs, since it would be possible to create new nodes for loosely related ideas. The reduction in page size should also bring down the number of edges emanating from any node, since all comments will be much more specific. I envision a slashdot style voting system for node proximity, as well as node importance.

Perhaps such a construct would reduce the need for large forums as well. The problem with slashdot is that after a few posts people start to repeat themselves, since the longer the thread, the less incentive there is to read all the previously posted information. (see also DiscussionBoardVsWiki)

Ok, well that's the gist of the idea, you can see the links below for more:

--AlexShapiro

I'm having too much fun with the browser. It's very cool. Thanks for writing it!

Typically when a thread is written on a wiki, months or years later, someone will come along to refactor it into something useful. While historically refactoring live discussions has proved, um, unpopular on WikiWiki, I can foresee in a positive environment that a tool like yours could be very effective, maybe even the beginnings of a WikiRefactoringBrowser? as Ward suggested on the WikiForum list.

I wonder if people will naturally tends towards decomposition though. Maybe it will encourage people to produce more linear documents simply by exposing the complexity of Wiki:RavioliWiki? Worth trying to find out. -- SunirShah

Thanks Sunir, I'm glad that you are impressed + having fun. I really think that the joy of looking at graphs comes from the fact that they are so much more intuitive then any other type of structure. It is like the difference between text based muds and 3d environments, the visual world is just that much more user friendly.

Could you please explain your point about decomposition? (My confusion is more about the sematics, then the meaning of what you are saying) Personally, the effect that I am going for is not the creation of linear documents, but that of focused writeups. Each page should talk about just one topic in a consise a manner as possible, with subtopics being created if the writeup gets too large. I believe that branching (or non-linearity) is the way to achieve such a state. --AlexShapiro

Excessive decomposition is a hindrence to comprehension. Studies have shown that readers incur stress trying to follow each link, as they instinctively wonder what they are missing. It's difficult for humans to put together a non-linear story line, as well, as we are hardwired to deal with linearity. A complex path will confuse people, not illuminate the subject. Also, as discussed on InterfaceHyperdepth, there's a time-delay penalty everytime you force a user to click. The user interface rule is respond within 150ms, and I'm afraid our server here just can't do that.

If you look around, some authors here decompose actively, making pages that are sometimes only two sentences long. Compare that to a more structured subgraph like SoftSecurity or even CollectiveIntelligence that were edited (more or--moreso--less) to allow the user to progress in a means they are comfortable with. It's clear what I am more comfortable with, but I merely pressure people to be more parsimonious, not force them. (When I did, Fridemar rightly kicked me in the ass. I'll try not to repeat that.)

The TouchGraph succeeds where we have failed, I think. If we have managed to make it difficult to read, the TouchGraph helps the lost readers find their way, but I think it would be better to make the pages easier to read in the first place. -- SunirShah

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?.

--DennisDaniels --

''"The combination of text and graphics" -- I'm trying to

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.

--AlexShapiro

I'll eventually (depending on my Ph.D. schedule) be releasing the source code of my project Ceryle, which includes a graph visualization based on a heavily-extended TouchGraph. It's a Topic Map-based knowledge organization and authoring tool that includes a composer that creates an XHTML document from a bunch of fragments. The fragments may be in plaintext, wiki text, HTML or XHTML. The ontologies used for organization are a hybrid of frame systems and FacetedClassification. There's a screenshot [available] and a [blog]. It's a bit too complicated to summarize entirely here, but it might be a good basis for a wiki engine. I'm hoping to build a functional plug-in framework to allow it to be extended for things like this. I'll be putting up more content about Ceryle as I get closer to a release. -- MurrayAltheim

Is CommunityWiki:WikiIsDocumentBased related ?

I think that page is trying to reach at the idea that wikis facilitate collaborative writing. It doesn't mention an ideal form for the page, although the highly loaded term document lends one to suspect formal writing. Just to break that idea here, wikis can be used for all sorts of communication, from messy notes, to poetry, to thread mode, to rapid exchanges, to patterns, to fiction, to a kind of very slow MultiUserDungeon. Refactoring is just reorganizing information towards some aim, but the author can choose that aim as she wishes. I would suspect that a WikiRefactoringBrowser would aim to help produce clearer writing, although another similar tool might make for more florid writing. -- SunirShah

How often do you take the text from two separate pages, and put it together to form a new page?

Quite often.

OK, so I rarely do "cut text from 2 different pages, create a new page, and paste both pieces there" all in a single session.

But the same net effect happens when

one person takes off-topic content from one page and creates a new page for it.
another person takes off-topic content from another page and creates a new page for it.
Someone notices that these 2 new pages are really about the same topic, and lists them on Wiki:RefactorByMerging
A helpful WikiGnome? merges the 2 pages he finds at Wiki:RefactorByMerging.

-- DavidCary

CategoryUnimplementedWikiTechnology [CategoryWikiTechnology]