WikiWhiteboard

Many moons ago, Danny Ayers reported the successful prototype of WikiWhiteboard, a simple tool for creating editable SVG images on Wikis. Motivated by the simplicity of the design and a little subtle prodding by Danny, I ported it to PurpleWiki. (See PurpleWiki:WikiWhiteboard.) Danny’s writeup on WikiWhiteboard, “Creating an SVG Wiki”, appeared last month at XML.com.    (K4)

The WikiWhiteboard code will be released in the next version of PurpleWiki, although I will be happy to release code early to anyone interested.    (K5)

Blog-Wiki Integration Turned On

Long-time followers of this blog have undoubtedly noticed my habit of smooshing seemingly harmless words together. I often do it with people’s names — for example, Eugene Eric Kim. Some of you may have guessed why I did this, but most of you probably figured my space key was broken.    (GB)

Starting today, my reasons should be more clear. Notice that “Eugene Eric Kim” is not only improperly written, it is now also a link. Browse through my older blog entries, and you’ll notice that all of the smooshed words are either links or are followed by a question mark link. This is blog-Wiki integration at its finest.    (GC)

Why I Turned WikiWord Integration On    (GD)

My purple plugin for Blosxom always had this WikiWord feature, but I kept it off until today. The main reason for this was that I wasn’t sure how I wanted to use it.    (GE)

I already use several Wikis quite actively — the Blue Oxen Wikis as well as a private one for my personal notes. I try to use the Blue Oxen Wikis for my ideas on collaboration whenever possible, so that they would become part of a collective repository of ideas rather than a personal one. Even though a personal Wiki is publically editable, the individual’s name can act as a kind of branding. Because this blog acts as a work log (my occasional food entries aside), my ideal would have been to integrate this Wiki with the Blue Oxen Collaboration Collaboratory Wiki. Unfortunately, that feature is not available.    (GF)

At minimum, I knew a personal PurpleWiki installation would be useful as a support glossary for this blog (more on this below). Nevertheless, I decided to write as if I had Wiki integration, but to wait a while before actually turning it on. This wasn’t hard for me: using WikiWords is practically second nature. Most of my entries ended up chockful of WikiWords, leading many to question my competence with the keyboard. These questions reached critical mass recently, and so I decided to turn the feature on.    (GG)

More importantly, I decided how I wanted to use my new Wiki overall: as a support structure for this blog, and also as a place for publishing essay drafts, design notes, and other random thoughts. Stuff I publish there will be implicitly labelled, “Work In Progress.” This will serve as a disclaimer that will make me more comfortable publishing my half-baked ideas, while also encouraging others to contribute while the ideas are still half-baked.    (GH)

Response to Marc Canter

I meet a lot of interesting people in this business, but a few stand out more than others. Anyone who’s met Marc Canter knows what I’m talking about. Marc is a big, boisterous fellow, mostly good-natured, and very outspoken. The guy is sharp and passionate, and has a proven track record of getting things done in the Valley, including cofounding MacroMind (which became Macromedia). He’s also got an incredibly cute baby daughter, which is a bit unfair, because it makes it difficult for me to get mad at him.    (B5)

Marc recently complained about Blue Oxen Associates. Among his complaints were:    (B6)

Now I have nothing againist Eugene Kim and his stalwarts, but what they created and what they do is pretty lame – compared to what’s going on out there – for free, everyday. What was it about Blue Oxen that Socialtext, Phil Pearson, Dave Winer, Paolo Valdemarin, Clay Shirky, Cory Doctorow, Danny Ayers, Dan Brickley, Lisa Rein, Mitch Kapor, Mark Pilgrim, Aaron Swartz, and hundreds more aren’t doing everyday?    (B7)

Why did we need a white paper on why open source is a good thing? Why do we need yet another Wiki – ever if it is purple?    (B8)

I just really think that Pierre’s money could be put to better use.    (B9)

There are lots of problems with what Marc says, the biggest being that he’s got most of his facts wrong.    (BA)

First, Omidyar Foundation has not invested in us. They funded our first research report on the open source software community. We are completely self-funded (by me), surviving on my initial investment and on clients.    (BB)

Second, we are not in the business of open source software development. As a company that uses, evangelizes, and works to better understand collaborative tools, we naturally do some development. Our policy is that everything we produce is open source, be it software or research. PurpleWiki happens to be the first of those tools, and so we make it available.    (BC)

Is PurpleWiki the Wiki to end all Wikis? That’s not our intent. Our intent is to understand and explore ideas that will help us improve collaboration, and then to disseminate those ideas as widely as possible. PurpleWiki is more than a bunch of purple hash marks spread out on a page. There is a lot of deep thinking behind its architecture, much of which was inspired by Doug Engelbart‘s earlier work. The Purple Numbers are the most visible manifestation, but there are others that will become more apparent eventually. The point is, we want to make those ideas accessible, and if they are useful, we want to help spread those ideas. That goes for all collaborative tools, not just Wikis.    (BD)

We’ve done this. For example, we worked closely with Mike Mell who worked closely with Simon Michael to implement Purple Numbers in ZWiki. We host an active community of tool developers who are working together to make their tools more useful and interoperable. We’re always exploring new ways to make a difference.    (BE)

Third, our research report was not about why open source software is a good thing. It was a preliminary exploration into why open source communities work. We’re not the first to explore this question, but I think we are especially qualified to explore it for a number of reasons. More importantly, our target audience is not open source developers. These folks don’t need persuading. Our audience is people who know nothing about open source software, except perhaps that it exists. There is an enormous language and experience barrier that prevents these folks from understanding what makes open source communities tick. Our thesis is that all communities — independent of their domain — could benefit from understanding and emulating open source communities. In order to test this thesis, we first have to overcome the language barrier.    (BF)

Fourth, Marc listed a bunch of people doing great work in this space as if they were our competitors. They are not. I know several of these folks, have worked with some of them, and hope to work with many more. Our goal at Blue Oxen Associates is to better understand collaboration, so we can help improve it. In order to do that, we need to put our money where our mouths are and collaborate with others working towards the same goal.    (BG)

When I founded Blue Oxen Associates, I consciously avoided seeking seed money and going for the big splash up-front. Some of the things we’re trying to accomplish are not obvious, and require further thinking and development. Starting small and growing slowly means we have to focus, sometimes at the expense of interesting projects and work, often at the expense of attention.    (BH)

Nevertheless, I’m surprised and flattered by the attention we’ve received thus far. The participants in the communities that we host are incredibly supportive. We have an amazing advisory board. I constantly run into people who know about us and compliment us on our work. And, the blogging community has said some great things about us as well. I’m even flattered that Marc thought enough of us to devote some space on his blog to call us “lame.” Like I said, it’s hard to get mad at a guy who means well and has a cute baby daughter. I hope he’ll continue to follow our work; perhaps “lame” will evolve into something better once he actually understands what we do.    (BI)

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)

A Brief History of Purple Numbers

A few weeks ago, Chris Dent posted a brief history of Purple Numbers, noting, “This is likely full of errors as the story as I’ve heard it is incomplete and I was unable to check some things because the network path to California was busted while I was writing.” His account is pretty good, but there are a few holes here and there. Most of my clarifications are nitpicky. In case you, my dear readers, haven’t realized it yet, I am very anal.    (7W)

Chris differentiates NLS from the mouse, hypertext, GUIs, and so forth. NLS was actually the totality of all of these things. Chris also says that NLS had a “graph based document storage model.” This is somewhat of an ambiguous description, and depending on how you read it, is not strictly true. Finally, NLS did not have transclusions, although its architecture could easily have supported them.    (7X)

In between NLS and the first appearance of Purple Numbers on the Bootstrap Institute’s web site, there was a graphical Augment client written in Smalltalk. The first Augment PC client was MS-DOS-based. Doug still uses this! In the early 1990s, a contractor wrote a GUI client for Windows, which displayed statement IDs (what we call node IDs) in purple. According to Doug, the choice of color was either his daughter’s, Christina, or the author of the client. In any case, this is why Purple Numbers are purple.    (7Y)

Bootstrap Institute first used Purple Numbers to display structural location numbers (what we call hierarchical IDs) for Augment documents converted to HTML. Soon afterwards, Frode Heglund suggested making the numbers a live link, so that it would be easy to copy and paste the node’s address.    (7Z)

On January 31, 2001, I released the first version of Purple, which was a collection of Perl and XSLT scripts for adding node and hierarchical IDs to documents and generating HTML with Purple Numbers. I believe my most important contribution at the time was recognizing that node IDs were more useful in a Web context, where documents were largely dynamic, than hierarchical IDs. On April 24, 2001, Murray Altheim released plink, a Java program similar to Purple, except that it worked on XHTML files.    (80)

My OHS Launch Community experiment (June 15 – November 9, 2001) proved to be a fruitful time for Purple Numbers. Murray and I agreed on a standard addressing scheme for Purple Numbers. I implemented a MHonArc filter for adding Purple Numbers to and extracting Backlinks from mailing list archives, and tool that generated HTML with Purple Numbers from Quest Map files.    (81)

I also started thinking about PurpleWiki for the first time, and hacked a first version based on TWiki. This experience gave me a better understanding of the right way to implement PurpleWiki, and it also gave me a healthy distaste for TWiki. When Chris joined Blue Oxen Associates, we made PurpleWiki a priority, and the rest is history. Chris’s account from there is pretty complete.    (82)