Granular Editing

Posted on Published by Eugene Eric Kim

I’ve been working with Doku Wiki a lot recently — it was what we used for the St. Louis Collaboratory workshop — and it reminded me of yet another reason why Granular Addressability is more important than we think it is.    (LFO)

My biggest takeaway from working with Doug Engelbart on the HyperScope this past year: Addressability is for more than linking. Indeed, HyperScope takes advantage of addressability to support some powerful navigation capabilities.    (LFP)

Well, addressability can also be used for editing. And in fact, it is. Both Mediawiki and Doku Wiki support granular editing. The reason? Mediawiki is designed for encyclopedias (specifically, Wikipedia. Doku Wiki is designed for authoring documentation. In both cases, you end up having long pages. Editing long pages in your browser is a major pain in the rear. It’s much easier to edit specific sections.    (LFQ)

Augment, of course, also supports granular editing, except the granularity supported is much finer.    (LFR)

This is yet another example of the following law of Collaborative Tools, which I first mentioned in my manifesto:    (LFS)

Good ideas get reimplemented over and over and over again, often independently. It behooves us to identify these ideas, name them, and implement them interoperably.    (LFT)

(This is also the fundamental principle underlying Pattern Languages.)    (LFU)

Scanning Large Texts with HyperScope

Posted on Published by Eugene Eric Kim

Speaking of capabilities, while digging up relevant passages in 1984, I really wished I had a digital version of the book so that I could use HyperScope on it. Specifically, I wanted to find the passages that contained the word, “dictionary.”    (LEH)

With a standard Web browser and an HTML version of the text, I would have hit Alt-F, typed “dictionary,” and scanned the surrounding paragraphs of each found instance, most likely scrolling up and down to examine the context.    (LEI)

With HyperScope, I would have changed the View Spec to wi;"dictionary";. This would show me only paragraphs containing the word, “dictionary.” I would then scan each paragraph, and if I found something that piqued my interest, I would Jump to that Item with the View Spec lj, which would show me only that paragraph and its sibling paragraphs (a “plex” in Augment terminology) with the previous content filter turned off.    (LEJ)

If HyperScope had multiwindow capabilities (which it will eventually), I could do each of these operations in its own window, which would allow me to jump back and forth easily between different views of the same document.    (LEK)

This is a great example of how View Specs and Granular Addressability allow you to navigate through a large text easily and effectively in ways that aren’t possible with today’s everyday tools.    (LEL)

WikiMania Hackfest Day 4

Posted on Published by Eugene Eric Kim

Bits and tids:    (JM7)

  • I didn’t plan my Hacking Days schedule very well. I missed most of the first day, when the Mediawiki developers apparently made progress on a new metadata design. Days 2 and 3, from which I based most of my criticism, focused on servers and reliability, an area to which I really couldn’t contribute, not because I’m ignorant, but because I’m powerless. This morning, they discussed Single Sign-On and usability, two areas that I do know something about. Sadly, I missed these sessions, because I was too busy spouting on and on about how we really can save the world. Owen Davis, Fen Labalme, Kaliya Hamlin, and the rest of the gang will undoubtedly kick my butt when they read this. In my defense, I managed to talk a bit about Identity Commons later in the day. I also plugged the FLOSS Usability Sprint, and met Zeno Gantner, who’s done some usability studies on Mediawiki.    (JM8)
  • I was one of the featured participants for the afternoon “Wiki developers informal discussion,” along with Ward Cunningham, Sven Dowideit, Christophe Ducamp, and Brion Vibber. Domas Mituzas, Wikimedia Foundation‘s head of operations, asked Ward, “Why Camel Case?” I won’t go into the explanation here — I have a long interview with Ward, to be published eventually, that explains this in detail — but you should know that hating Camel Case is a running joke among this community. I laughed along with everyone else, but when Sven mentioned his desire to remove Camel Case from TWiki, I felt compelled to pipe up. I gave a balanced defense, describing Camel Case’s advantages over free links, but also acknowledging the appropriateness of free links in Wikipedia. Then I got a very amusing introduction to Erik Moeller, one of Mediawiki‘s core contributors and the Wikimedia Foundation‘s chief research officer. Erik had a strongly worded response. It got a bit heated, but never overly so, and I closed by saying that we were in violent agreement. We laughed about it over dinner, but then we got serious again. We also talked about Purple Numbers. I’ve explained many times why I may seem like a poor evangelist, but I think Erik was one of the few people who appreciated my perspective. He was clearly not a big fan of Purple Numbers — as it turns out, he was somewhat familiar with my work — but after hearing my explanation, he responded, “Only intelligent people are going to understand what you just said.” Fair enough. Fortunately, regular folks don’t need to get Granular Addressability for Granular Addressability to become ubiquitous.    (JM9)
  • A group of us broke out into a small group to discuss a Wiki Interchange Format, knowing full well that this is an issue that’s been discussed many times before (Wiki:WikiInterchangeFormat, MeatBall:WikiInterchangeFormat). Nevertheless, I think our discussion was not only constructive, it has a high chance of succeeding. See my summary.    (JMA)
  • Magnus Manske, the original creator of Mediawiki, participated in our Wiki Interchange Format discussion. He also mentioned a clever idea: a “shopping cart” where people could aggregate and possibly export Wiki pages they were interested in.    (JMB)
  • Sven Dowideit demonstrated the prototype WYSIWYG editor for TWiki, based on Kupu. He also showed a WikiText editor with real-time preview, which was pretty slick. Also, Ross Mayfield showed me a prototype editor for KWiki in response to my previous post. Very good to see these things.    (JMC)
  • So many people have come to this gathering to learn from others with different experiences. Granted, all of these experiences center around Wikipedia, but I’m still envious. My neverending quest is for folks interested in collaboration to look beyond their own narrow domains for deeper insights.    (JMD)

Taking Over the World

Posted on Published by Eugene Eric Kim

Ulises Ali Mejias wrote about various projects that support his vision of “distributed textual discourse.” One of the projects he mentioned was Purple Numbers. One of Ulises comments caught my eye:    (IRF)

While the approach is relatively simple, I guess it was not widely adopted.    (IRG)

It was an interesting comment to make, especially as he didn’t make it about any of the other projects. Perhaps he was surprised by this?    (IRH)

As far as I’m concerned, it doesn’t matter. My goal is for the ideas to take over the world, not for particular manifestations of the idea to win. I want tool builders to realize the importance of Granular Addressability and to incorporate it into their tools, whether or not they’re purple in the end. And there’s still plenty of time for that to happen.    (IRI)

Purple Numbers: Optimized for Synthesis

Posted on Published by Eugene Eric Kim

Chris Dent has been having some good exchanges about Purple Numbers with Adina Levin and Phil Jones. I don’t have much to add, as I think Chris is spot on. Two comments struck me, though.    (IQV)

First, Phil claims that Purple Numbers are optimized for reading at the expense of writing. His point is that Purple Numbers, as currently implemented, add overhead to the writing process, whereas the pay-off comes for the reader. I emphasize as currently implemented, because we just haven’t gotten around to making them mostly transparent in the writing process. Hacking one of the WYSIWYG JavaScript text editors to support Purple Numbers should do the trick.    (IQW)

However, I really liked Chris’s response:    (IQX)

Yes, purple numbers do try to favor the reader and the act of reading, but not just for reading. They favor the reader so the reader may more easily do more writing. The whole point is for purple numbers and tools like it to be a generative force in the synthesis of new understandings.    (IQY)

Phil can write all he wants, and I can read all I want, but until I write down something that builds on what Phil says, while making chains of reference back through the many layers of context, there’s been no synthesis, at least not any that is available outside the confines of my own mind.    (IQZ)

Granular Addressability enables synthesis. Wanna know what makes blogs conversational? Permalinks, which are a form of Granular Addressability.    (IR0)

A lot of people don’t get this. I read The Sports Guy over at ESPN.com all the time (despite the fact that I hate all Boston sports teams with a passion), and at the past two Super Bowls, he wrote what ESPN.com called a “blog.” It sure looked like a blog, but in reality, it was just one-way publishing. Folks couldn’t comment on his entries, because they couldn’t link to any of them. I see this all the time with other major media outlets trying to jump on the blog bandwagon.    (IR1)

Which brings me to the second comment that jumped out at me. In his response to Adina, Chris wrote:    (IR2)

Clearly I am in far too deep with purple stuff: I need a translator. The above can be so much meaningless noise and I find little time to make things cogent.    (IR3)

I’m not the best proselytizer of Purple Numbers, not because I’m not proud of them (I am), not because I don’t value them (I do), and not because I can’t explain their value clearly (I can). There’s a tremendous amount of deep thinking underlying these little purple critters, and the implications are fascinating. But before you can understand any of this, you’ve got to care. And unless you’re one of those strange individuals who just gets it, you’ve got to try them before you’ll buy them.    (IR4)

A lot of folks think I invented Purple Numbers. Not true at all. I was one of those folks who didn’t care, one of the first in fact. Purple Numbers are an HTML manifestation of Augment’s granular addressability scheme, invented by Doug Engelbart and made purple years later by his daughter, Christina Engelbart. When I first started working with Doug, he kept insisting that all of our knowledge products on the Web have Purple Numbers. I didn’t think it was a priority, but I knew I could easily whip up a tool to generate them, so I wrote Purple to humor him. Then a funny thing happened. Once I had them, I used them, simply because they were there. Then I started missing them when they weren’t there. Then it dawned on me: These little purple thingies sure were darn useful. And I started thinking about why.    (IR5)

The point of my story is this: I’m perfectly happy to have a deep, convoluted discussion about some esoteric aspect of Purple Numbers. If you don’t believe me, try me. Or read my blog entries on the matter. But if you really want to understand why they’re so important, just give them a try for a month, then try living without them.    (IR6)