Blog Backlinks Enabled on PurpleWiki

If you view the Backlinks on any of my Wiki pages, it will now display Backlinks from both the Wiki and also this blog. For example, if you view the backlinks to “DougEngelbart”, you will see a list of all of my Wiki pages and blog entries that mention Doug.    (SG)

The beautiful thing about this feature is that it maintains context for all of the different concepts described on my Wiki. I list several Patterns on my Wiki, with some level of detail on each page. But when you look at the Backlinks to those Patterns, you see a list of all the stories where the Patterns are mentioned. I tell the stories as I have before, and the tool explicitly ties the concept to the stories that describe the context. That’s augmentation! As Chris Dent said, it “makes the universe bigger.”    (SH)

My essay, Wikis As Topic Maps, describes this phenomenon in further (and slightly more technical) detail.    (SI)

Open Source At Work    (SJ)

How this feature finally became implemented is a wonderful example of what makes Open Source so great. We’ve wanted it for a while, but didn’t have time to implement it. Last month, I started thinking more seriously about implementing the feature, because I wanted to demonstrate it to some potential clients. Unfortunately, I was swamped, and didn’t have time to do it myself.    (SK)

David Fannin to the rescue. David had installed PurpleWiki and the MovableType plugin, and liked it. However, he also wanted the Backlink feature. So, he wrote it, and contributed it back to us. Neither Chris nor I nor anyone else in the small PurpleWiki community knew David beforehand, but as you can imagine, we welcomed his contribution.    (SL)

David’s patch was just a hack. Chris had some ideas for refactoring the PurpleWiki code to better integrate this feature. So, he implemented them, and released a preview of the code. Chris’s refactoring made it very easy for me to write a similar plugin for blosxom. Suddenly, we had the feature I had been pining for.    (SM)

As an aside, I had grander plans for how to implement this feature, and those plans haven’t gone away. (See my notes on TPVortex for a preview.) The important thing is, David and Chris’s approach worked. It may not do all of the whiz bang things I eventually want it to do, but it does what I want it to do right now. More importantly, it may very well inspire others to implement some of the grander ideas. Release Early And Often is an extremely important pattern of Open Source development, because it enables collaboration, which accelerates the implementation and dissemination of ideas.    (SN)

Precedence    (SO)

Ours is not the first integrated Wiki and blog. Notable precedents include Kwiki and Bill Seitz‘s Wiki Log. These tools all had the integrated Backlinks feature before we did.    (SP)

The key difference between these tools and ours is that they require you to use a single tool. You have to use Kwiki as both your blogging tool and Wiki to get all of the features. Our approach integrates PurpleWiki with MovableType, blosxom, and conceivably any other blogging tool. This is consistent with our overall philosophy of improving interoperability between tools using Doug Engelbart‘s ideas as a unifying framework.    (SQ)

We’ve only taken baby steps so far. We plan bigger and better things. More importantly, we want to encourage other tool developers to adopt a similar approach, and to collaborate with each other to do so.    (SR)

Battling Group Think

Geoff Cohen asked:    (PM)

As we build different kinds of groupware/social software, what’s the role of consensus, and how powerful is it? Does software make reaching consensus easier or harder? For purely message-driven systems like email lists or USENET, consensus is much harder to reach than it would be in a real-life meeting. But once consensus is reached, breaking that consensus often brings down the flames of wrath. All of this is somehow invisibly coded in the interstices of the software architecture and human nature.    (PN)

…    (PO)

Could we architect social software that fought groupthink? Or does it just make the gravitational attraction of consensus, even flawed consensus, ever so much more irresistable?    (PP)

Seb Paquet responded:    (PQ)

I think the key to avoiding unhealthy levels of groupthink has to do with designing spaces that consistently exert pull upon outsiders (or social hackers or community straddlers), so as to keep the air fresh.    (PR)

…    (PS)

I think the blogosphere exhibits this kind of “outsider pull” much more than topic-focused forums.    (PT)

…    (PU)

But what about action? A diverse group has fewer blind spots, but on the other hand, agreement in such a group can be harder to establish, so there is a real possibility that the group will go nowhere beyond conversation. Is a core of agreed-upon ideas necessary for group action to take place? I think so. Does this mean that group action requires groupthink? Not necessarily, because some people are able to act upon ideas without believing in them so strongly they can no longer challenge them.    (PV)

Ross Mayfield added:    (PW)

He [Seb] is right that groupthink is avoided by a social network structure that allows a dynamic and diverse periphery to provide new ideas, but the core of the network needs to be tightly bound to be able to take action.    (PX)

That’s the main point of Building Sustainable Communities through Network Building by Valdis Krebs and June Holley.    (PY)

…    (PZ)

The ideal core/periphery structure affords a densely linked core and a dynamic periphery. One pattern for social software that supports this is an intimacy gradient (privacy/openness), to allow the core some privacy for backchanneling. But this requires ridiculously easy group forming, as the more hardened the space the more hard-nosed its occupants become.    (Q0)

Finally, Bill Seitz commented:    (Q1)

I think a shared mission is necessary. Whether that amounts to groupthink is a fair question.    (Q2)

There are a goldmine of ideas here, and the discussion is highly relevant to issues currently faced by the Collaboration Collaboratory. I’ll address them one at a time.    (Q3)

Group Think Versus Group Action    (Q4)

Bill’s comment points to the crux of the matter. What qualifies as Group Think or Group Action? We’ve discussed this question a lot at Blue Oxen Associates. In our upcoming research report, we draw a distinction between bounded and unbounded goals, and individual and collective goals. Generally, having shared unbounded goals is enough to constitute group alignment, but having shared bounded goals is required before you can call an effort “collaboration.”    (Q5)

The larger the group, the harder it is to define a shared, bounded goal that every group member will endorse. A good example of where this happens are elections. In the case of Howard Dean supporters, for example, the community is defined by a universally shared, bounded goal — voting Dean for president in 2004. As we’ve seen in the Dean case, having that universally shared, bounded goal was a galvanizing force for a previously unseen community of progressives in this country.    (Q6)

For large groups, I don’t think it’s necessary to have universally shared, bounded goals, although it’s nice when it happens. It’s enough to have small subgroups sharing different bounded goals, as long as they do not conflict with the unbounded goals, which must be universally shared.    (Q7)

The Intimacy Gradient Pattern    (Q8)

An aside on terminology: Intimacy Gradient is an excellent name for the phenomenon I first tried to describe in a previous blog entry, where I introduced the Think Out Loud and Whine In Private patterns. The problem I had in describing the Whine In Private pattern was that some spaces — blogs being the best example — felt like private forums, but were actually public. So people whining on their blogs are not actually Whining In Private; they just feel like they are.    (Q9)

Ross also used the term Backchannel, which I had also recently noted in my Wiki as a good name to describe this mostly private, but partially public space.    (QA)

Community Boundaries    (QB)

One of the founding principles of the Blue Oxen Collaboratories is that the products of the discussion and interaction should all be freely available to everyone. This is why the mailing list archives are publically available, even if participation is restricted to members.    (QC)

There is an Intimacy Gradient pattern involved here. There is a small barrier to entry to participate in tight-knit discussions, which makes the environment more conducive to parlor-style conversations. On the other hand, anyone can benefit from the resulting knowledge, which is our ultimate goal. Our hope is that the collaboratories act as a substrate for a much larger conversation.    (QD)

This has already begun to happen, and blogs play a key role. Bill Seitz, Chris Dent, Danny Ayers, and I have all blogged about discussions on the Collaboration Collaboratory, which expands the conversation to a larger group. The side effects include countering Group Think, as Seb suggests, and also attracting new members who want to participate more directly in the lower-level interactions. Similarly, we mention these blogs on the mailing lists, so the collaboratory members are aware of the larger conversation, thus completing the circle.    (QE)

Are there hidden costs to these Intimacy Gradients? Absolutely. Examples of blogs being read by the “wrong” audiences abound. Gregory Rawlins became a victim when he made some choice comments about another programmer’s software on a private, but publically archived list. (Sorry, Greg, but I always get a good laugh when I reread this.)    (QF)

Nevertheless, I think the benefits outweigh the downsides. I recently joined Howard Rheingold‘s Brainstorms community, and have wanted to link to some of the discussions there, but couldn’t. It’s unfortunate, because those linkages are lost, but it’s a tradeoff I understand. Finding the right balance is tricky.    (QG)

How Open Should Wikis Be?    (QH)

Our original intention with the Wikis on the Blue Oxen Collaboratories was to treat them the same as the mailing lists — restrict writing to members, but allow anyone to read the content. However, we did not configure our Wikis that way, mainly because we couldn’t — UseModWiki doesn’t have this feature — and it was low on list of things to hack. (See PurpleWiki:RoadMap.)    (QI)

Based on our experiences with this configuration and further examination of other Wikis, I’m reluctant to change this model now. One potential compromise is to require registration to write to the Wikis, but to make registration free. The difference between this and simply allowing anyone to click on “Edit This” is subtle, but significant. I’m still a bit undecided on this issue, although I seem to be leaning in favor of extreme openness. The reason for this is simply that we’ve had some interesting contributions and comments to the Wikis that probably would not have been made if there were even the slightest barriers to entry. Again, it’s a good safeguard against Group Think.    (QJ)

This issue recently cropped up again, because both the PurpleWiki and Collaboration Collaboratory Wikis were vandalized for the first time. Chris Dent discovered the act first and quickly fixed it, noting, “In a way this is sort of a good sign. Infamy is almost as good as fame….” My reaction was, “Good catch, by the way. A good sign of a healthy Wiki is how quickly the community fixes vandalism.” Notable in both of our reactions was that we simply fixed the problem and moved on, instead of rushing to implement access control.    (QK)

John Sechrest, however, suggested that access control was exactly what the Wikis needed, which led to some interesting philosophical debate about the openness of Wikis. My response to John wasn’t very deep, but it does sum up my feelings on the matter: “Wikis are successful because the cost to contribute are zero. There are downsides, but there are also upsides. Get rid of one, you also lose the other.”    (QL)

Church of Purple: The IDs the Thing

Some interesting posts in the blogosphere today that are relevant to Purple Numbers. First, Seb Paquet pointed to Matt Mower‘s recent “Show Anchors” bookmarklet, which displays named anchors on an HTML page. It’s a good hack, and it will hopefully encourage people to do more fine-grained linking, which is one reason for Purple Numbers.    (NW)

Second, Bill Seitz referenced Bob Du Charme’s article earlier this year on the deprecation of the “name” attribute for the new (but optional) “id” attribute in HTML, and asked whether this is relevant to Purple Numbers. It’s very relevant. Widespread use of ID attributes will hopefully make people understand the value of stable IDs for addressing (as opposed to the relative addressing enabled by things like XPointer).    (NX)

Purple Numbers are about two things: Making people aware of fine-grained addressability, and assigning stable IDs to each of these chunks. The former is what most people see, but good UIs will eventually (hopefully) make this feature irrelevant. The latter is the truly important contribution.    (NY)

Church Of Purple    (NZ)

As an aside, earlier this month, what started as an innocent question about blogging on the Collaboration Collaboratory turned into a massive discussion about many things, including Purple Numbers. At one point, I casually threw out the term, “Church Of Purple,” which Chris Dent and I had often used in our private conversations. Woe was me.    (O0)

We have a lot of smart members and some great discussions. The truth, however, is that half of our members are crazy. Peter Jones embodies our group’s split personality, mixing in profound comments with witticisms that usually leave me shaking my head and holding my sides. Peter decided that all good churches require a T-shirt, hymn, and Bible, and he proposed a few candidates for the latter. Chris has already blogged Peter’s Church Of Purple hymn (a merciless parody of Jimmy Hendrix’s Purple Haze). Here’s Peter’s excerpt from the Book of Purple:    (O1)

And lo, Engelbart looked down upon the text and saw that there were unidentified paragraphs, and that the lack of identifiers was a pestilence upon the augmentation.    (O2)

Perhaps deciding that Peter wasn’t being silly enough, Chris concocted a logo for the Church Of Purple, which I have dutifully added to this blog.    (O3)

Out of the silliness emerged perhaps the best example for why we need Purple Numbers, courtesy of Matt Schneider (and also blogged by Chris). Matt recounted an encounter with his then 82-year old father:    (O4)

I handed him a Bible and Hawaii (he’s a big Michener fan). I asked him to quickly turn to paragraph 536 of Hawaii. He looked over the top of his glasses at me. I smiled and then asked him to turn to Psalm 23:4. Light went on.    (O5)

Blue Oxen’s One Year Anniversary

Today is Blue Oxen Associates‘ one year anniversary. Many thanks to all for your support and goodwill, especially those who have worked with us this past year. Special thanks to Chris Dent, our advisory board, and members of the Blue Oxen Collaboration Collaboratory. It’s been a great year; looking forward to another good one.    (J6)

Today, not coincidentally, is also the 35th anniversary of Doug Engelbart‘s Mother Of All Demos.    (J7)

Tonight, a small group of us are celebrating at the Foresight Institute in Los Altos, California. After that, back to work!    (J8)

PurpleWiki v0.9 Released

PurpleWiki v0.9 is now available. Chris Dent‘s announcement covers the basics. A few words on how we got here, and where we’re going.    (83)

The Wiki Experiment    (84)

When we launched Blue Oxen Associates last December, we made Wikis a core part of our infrastructure. We had two reasons for choosing Wikis. The first was practical. We needed a system for sharing documents and collaborative authoring, and Wikis fit the bill quite nicely.    (85)

The second reason was more philosophical. We wanted a knowledge management system like Doug Engelbart‘s Open Hyperdocument System (OHS), and felt that Wikis already resembled the OHS in many ways. It was immediately usable and useful, while also offering the perfect platform for coevolution.    (86)

PurpleWiki fulfills the following OHS requirements:    (87)

  • Backlinks. This is a core feature of all Wikis, but also one of its most underutilized. In a future version of PurpleWiki, we will create an open API to its Backlink engine, so that other applications (such as blogs) may use it.    (88)
  • Granular Addressability. PurpleWiki‘s site-wide, automatic Purple Number management had the additional benefit of enabling us to quickly experiment and evolve the feature. Node IDs are now document-independent, which has improved usability and enabled features like Transclusions.    (89)
  • Link Types. We’ve added a syntax for specifying link types, and have implemented our first new link type: Transclusions.    (8A)
  • View Control. We can easily add new or customize existing output formats, thanks to PurpleWiki‘s modular architecture. More importantly, we can implement dynamic views, such as a collapsible outline view, of any document on PurpleWiki.    (8B)

PurpleWiki‘s most visible feature is Purple Numbers, but its most important feature is its data architecture. In general, Wikis view the world as a graph of linked documents. PurpleWiki views the world as a graph of linked documents with a unified data model. The data model is sufficiently general and simple to apply to any kind of document. When you use this data model in other applications, you automatically inherit PurpleWiki‘s features. Integrating PurpleWiki with blogs was a piece of cake as a result, and we’ve only begun to explore the ramifications.    (8C)

Next Steps    (8D)

Our roadmap lists several enterprise features we plan on implementing: templates, pluggable database back-ends, mod_perl controller, etc. I consider these important, but relatively mundane. Blue Oxen Associates isn’t in the business of software development; we’re implementing these features because we need them.    (8E)

Blue Oxen Associates is in the business of research and improvement, and of facilitating coevolution. PurpleWiki is an amazing platform for this. One of Chris’s pet projects is to create universal ID space for nodes, possibly based on handles. Think of this as persistent URIs for nodes. Among other things, this will enable us to support Transclusions of content from other sites, not just the site on which PurpleWiki is installed.    (8F)

My long-term interests lie in three areas: the aforementioned open Backlink engine, Wiki page types, and Wiki namespaces. I’ll discuss the latter a bit here.    (8G)

One of the reasons I dislike TWiki is its notion of “webs.” You can partition your Wiki into multiple webs, and each web is contained in its own namespace. The problem with this is that it encourages people to balkanize their Wiki content. That, in my opinion, runs counter to the spirit of Wikis. Early balkanization prevents evolution.    (8H)

Several months ago, Richard Gabriel passed along some insight he had learned from Ward Cunningham: In computer science, you want to keep namespaces separate. With Wikis, you want namespaces to clash. Ward’s idea for SisterSites is one way to create namespace clash. This idea could be taken a step further by allowing site administrators to establish a system of namespace resolution. For example, if a certain page doesn’t exist on a local namespace, the Wiki would search another namespace for that page. If it existed there, the Wiki would simply take the user to that page.    (8I)