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)

Welcome, Jonathan!

Posted on Published by Eugene Eric Kim

Jonathan Cheyer has joined the blogosphere. In addition to being a great guy, a friend, and sometime basketball partner, he’s a longtime member of the Collaboration Collaboratory, a core HyperScope contributor and the Open Source Community evangelist at Solid. And as the tech lead for the Computer History Museum‘s NLS/Augment Restoration Project, he’s indisputably the most knowledgable person about Doug Engelbart‘s Augment under the age of 40. Welcome, Jonathan!    (KXZ)

HyperScope Jam Session Tonight

Posted on Published by Eugene Eric Kim

For those of you in the Bay Area interested in learning about the HyperScope, we’re going to be doing a public jam session tonight (Tuesday), 6-8pm at SRI in Menlo Park. We’ll update y’all on the status of the project, and you’ll have the chance to meet and interact with the team. We may even break out our Chording Keysets and Augment if you’re lucky. Let me know if you plan on making it. Looking forward to seeing many of you there!    (KJW)

URI Syntax for the HyperScope

Posted on Published by Eugene Eric Kim

At last Tuesday’s HyperScope meeting, Jonathan Cheyer and I spent an inordinate amount of time debating the syntax for HyperScope URIs, much to the amusement and chagrin of our peers. Although the topic may seem insignificant, it is actually quite layered with no easy answers. I’m going to summarize the issues here. Most of you will probably not care about the intricacies of the argument itself, but at minimum, it should reveal a bit more about the project itself.    (KI2)

HyperScope is meant to be a transitional tool that will enable people to play with Augment‘s more sophisticated capabilities within their existing environments. In the immediate future, that means the Firefox web browser (and probably Internet Explorer as well). In the not-to-distant future, that could extend to a range of applications, from Eclipse to OpenOffice and beyond.    (KI3)

This intent strongly informs our requirements. In particular, we need to make sure we are bootstrapping the system on top of existing technologies (such as URIs) effectively and correctly, and we need to make sure the system is evolvable. Both of these requirements play a big role in our debate.    (KI4)

So what’s all the fuss about? One of Augment‘s coolest (and most fundamental) features is its sophisticated addressability. The example most folks know about manifests itself as Purple Numbers, namely the ability to reference a specific node in a document in a standard way. But Augment can do much, much more. It can do path expressions, similar in spirit to XPath, which allows you to reference some subset of nodes in a document. (See my notes on transcluding a subset of nodes via Purple Numbers).    (KI5)

You can also embed View Specs in an address. For example, suppose you decided that the best way to view a page was the first level of nodes only. You could specify that as a View Spec in the link itself, so that when someone followed that link, they would see only the first level of nodes rather than the entire document.    (KI6)

With the HyperScope, we’re bringing these capabilities to the plain ol’ World Wide Web — that is, assuming your client knows how to interpret these addresses properly. With our initial release (due September 2006), this will require loading a JavaScript library. All document addressability will happen entirely on the client-side. This is a good thing for a lot of reasons, the most important being adoptability. It will be easy for people to play with the HyperScope. All they’ll have to do is click on a link in Firefox (and probably Internet Explorer).    (KI7)

However, the fact that we’re doing a client-side only version of the HyperScope does not preclude the creation of a joint client/server version or even a mostly server-side version where the client is essentially a dumb web browser. In fact, we’d encourage the creation of both. We don’t care some much about implementation as we do capabilities and interoperability.    (KI8)

Here’s the question: How should we include these extended addressing capabilities in real-life URIs?    (KI9)

There are three possible solutions:    (KIA)

  • Embed them as a fragment address (i.e. following a hash mark at the end of the URI).    (KIB)
  • Embed them either as part of the path or query string parameters (i.e. following a question mark at the end of the URI).    (KIC)
  • All of the above and more.    (KID)

I side with the first and third solutions. Jonathan thinks it should be the second.    (KIE)

Fragment Address    (KIF)

Pros:    (KIG)

  • These extended capabilities seem to belong here semantically. Purple Numbers are an obvious example of this. XPointer is another.    (KIH)
  • The URIs will be bookmarkable as the user manipulates the document from the HyperScope. We can do this, because we can change the fragment identifier from within JavaScript. We can’t do the same with any other part of the URI.    (KII)

Cons:    (KIJ)

  • These URIs cannot be used for a server-side only solution, because HTTP does not pass the fragment identifier to web servers.    (KIK)

Path or Query String    (KIL)

Pros:    (KIM)

  • Can be used for client-only or server-only solutions, or anywhere in between.    (KIN)

Cons:    (KIO)

  • You’re still left with the problem of a standard addressing syntax that doesn’t interfere with any other kind of addressing. For example, if you’re going to use a query parameter, what do you call it? Granted, if you namespace it correctly, the likelihood of namespace clash is tiny, but it’s still there.    (KIP)
  • No one’s building a server-side only solution right now.    (KIQ)

Why Limit Yourself?    (KIR)

This is ultimately my argument: Go with the first syntax for now, because it best suits our current needs, and don’t worry about the fact that it won’t satisfy all potential future needs, because nothing will. What’s important is that we standardize the conceptual semantics, and then standardize the syntax to the extent possible. In all likelihood, most people will be passing these links around by copying and pasting them anyway, so the actual link syntax isn’t completely critical.    (KIS)

Recent Dialog Mapping Lessons

Posted on Published by Eugene Eric Kim

On the HyperScope mailing list, Jeff Conklin recently asked how we were using Compendium for the project. We’ve been using it for the design phase of the project, walking through scenarios, capturing requirements, and developing specifications. I started the process by developing a template for the project — loosely based on previous projects — and by seeding the map with content from asynchronous sources.    (KFU)

I first presented the map at our weekly face-to-face meeting two weeks ago, and it’s continued to be the centerpiece for our discussions ever since. Other than the initial seeding and nightly refactoring, all of the content was generated during these group meetings. After each refactoring, I would post new versions of the map to the web.    (KFV)

Now that we’ve basically completed the scoping process, I’m going to convert the map into a design document (on Augment!). Compendium isn’t scheduled to make a reappearance at our meetings anytime soon, but you can be sure that if the need arises, I won’t hesitate to break it out.    (KFW)

A few years ago, I published a case study on Dialogue Mapping that described my early work in this area. I’ve continued to apply a lot of the lessons learned from those very early experiences. Here are some standbyes:    (KFX)

  • Take breaks    (KFY)
  • Avoid Yes No Questions    (KFZ)
  • Multiple maps are your friend. When a map grows too large, (take a break and) make a new one.    (KG0)
  • The map should be another participant in the meeting. The physical location of the map is critical to its success.    (KG1)

Here are some new and old thoughts on Dialogue Mapping based on my most recent experience:    (KG2)

  • The fact that so many early lessons are still relevant should be further encouragement for people to give Dialogue Mapping a try. The first few times I did it, it was hard. Once I took those first lumps, however, I shifted into an expert usage very quickly. Once you’ve gained this experience, the tool is invaluable.    (KG3)
  • In that early paper, an observation I made without comment was that I rarely used Argument nodes (Pros and Cons) in my early maps. Over the past five years of using Compendium, that pattern has held true. However, when I have used Arguments, they tend to be Pros rather than Cons. With the HyperScope map, I used Cons much more frequently. This reflects the circumstances of the project. We’re replicating an existing implementation that all of us agree is fantastic. We also have a very tight schedule. Most of our discussions have centered around implementation difficulty and desired constraints, and so naturally, things tend to be framed as Cons.    (KG4)
  • I think that a low percentage of Argument nodes in a map indicates expert usage. In meetings, Arguments are often a reflection of group politics rather than of logic. Reframing Arguments as Questions and Ideas depoliticizes the discussion.    (KG5)
  • When I first start using Compendium with a group, I never explain the tool. I just use it. People find it very natural to follow (assuming you’ve positioned your Shared Display properly), and they often take ownership of the map very quickly. The one thing I do find myself explaining on occasion is that an Idea is just an Idea. It is not a decision, and its presence indicates no value other than that someone in the group proposed it (which is not to be underestimated).    (KG6)
  • You know the process and tool are working when participants start saying, “Make sure you capture that,” or, “Can you put that there?” It’s a sign that they consider the map a participant and that they are taking ownership over its content. It also makes the facilitator’s job easier.    (KG7)
  • The resulting map is an artifact of the discussion, and as such, it’s more useful for participants than it is for nonparticipants. Folks like the fact that the maps are available, but they don’t recognize the value until I walk through the map with them. More importantly, those who have participated in the meetings (and hence, the map’s development) have found it extremely useful.    (KG8)

Here are some new and old thoughts on Compendium, the tool:    (KG9)

  • Compendium calls Idea nodes “Answers.” I understand the logic behind this, but I think “Idea” is a superior framing. This is partially captured by the fact that the node is represented by a light bulb, but I’d still like to see the name changed back to “Ideas.”    (KGA)
  • I used Decision nodes a lot for this project, which was natural, since this was a scoping exercise. I also made a big show every time I created a Decision node. This shifted us away from discussion mode, which may sound obvious, but it had a powerful effect on group participation. It was a group acknowledgement that we had captured the relevant issues and that we were ready to move on.    (KGB)
  • After the last Compendium workshop, I resolved to add some Visual Modeling techniques to my Compendium usage. I’ve managed to incorporate it a bit in other projects, but it hasn’t been useful at all for this project. I love the idea, but Compendium isn’t optimized enough for this kind of usage for me.    (KGC)
  • Compendium still has some subtle but annoying bugs, mostly related to layout. Michelle Bachler has done a great job of stabilizing and improving the code, but the project could definitely use more development resources.    (KGD)
  • My number one most desired feature: A slider bar that cycles through previous versions of your map. It should work with exported maps too.    (KGE)
  • Speaking of exports, using Compendium to work on the HyperScope really emphasizes the utility of things like granular addressability and applying viewspecs on a single document, features that don’t currently exist in exported maps.    (KGF)