eekim.com: EEK Speaks

Tue, May 30, 2006

Angry Rant on Wikis #

Earlier this month, JonasLuster invited me to speak at WikiWednesday. I didn't have anything prepared, and I didn't feel particularly motivated to prepare anything, so, I told Jonas that I was just going to rant. Jonas, being Jonas, loved the idea. So after IIW wrapped on May 3, I headed up to PaloAlto. I promised folks at IIW that I was going to give an angry rant on Wikis, and so several people decided to come watch, including PhilWindley, who blogged it. Feedback was great, except for a few complaints that I wasn't all that angry. I promise to get more worked up next time, folks. (KK2)

I've made all the points I made in my rant before in some form or another, often on this blog. Nevertheless, it was the first time I shared these ideas as one semi-cohesive thought, and so it's worth rehashing the points here. (KK3)

Overview (KK4)

There are two things that make Wikis cool: (KK5)

Open access (KK6)
SharedLanguage (KK7)

Lots of folks have latched onto the open access part, and there's been some interesting exploration in this area. Very few folks know about or understand the SharedLanguage aspect. I think this is a huge loss, because it's what makes Wikis truly transformational. (KK8)

Open Access (KK9)

Since I had just come from IIW, I started with digital identity. First, I said that all Wikis should support some form of distributed SingleSignOn, be it OpenID or something else. Implementing SingleSignOn does not imply loss of anonymity. Most Wikis give you the choice of logging in or not; implementing SingleSignOn would give you the additional choice of using a single identity across multiple sites. (KKA)

Why would this be useful? Consider Wikipedia. As my friend, ScottFoehner, commented in a previous post on this topic (to be visible again when I turn comments back on), Wikipedia actually consists of a number of different Wikis, one for each language plus a number of special Wikis, such as its community site. Each of those Wikis require a separate user account. Not only is this a huge inconvenience, it effectively prevents you from having a single digital identity (along with your associated reputation) across each of these sites. (KKB)

Simply having SingleSignOn across all of the Wikipedia Wikis would be valuable. More importantly, the identity community has converged to the point where it doesn't make sense to roll your own protocols. There are several good existing protocols to choose from, and many of those are in the process of converging. (KKC)

Reputation is closely associated with identity, and it's also been one of the most popular topics in the Wiki community over the past year. However, most people have a misguided notion of what reputation is and what we should do about it. Reputation is what others think about you. Reputations exist in every system, whether or not they are explicitly represented. Reputation cannot be quantified. However, you can identify the factors that determine reputation and make those factors more explicit. (KKD)

In Wikis, this could manifest itself in a number of ways. For example, one way to determine the quality of a page is to view the number of people who have edited it. You could make that number explicit by subtly changing the background color of that page -- slightly yellowed for a page with few contributors and bright white for a page with many contributors. (KKE)

The important point here is that you are not making a value judgement on reputation. You are not saying that a page that has many authors is better than a page that does not. All you are doing is making it easy to see that a page has many authors. Readers can determine for themselves how much weight (if any) to place on this factor for the reputation algorithm in their heads. (KKF)

The most important button on a Wiki page is the Edit button. That button implies PermissionToParticipate. It should be one of the most visible buttons on any Wiki. If a Wiki looks too good, that discourages participation. Who wants to edit something that looks like a finished product? WardCunningham used to suggest sprinkling typos across a Wiki page to encourage others to participate. (KKG)

At this point in the rant, I plugged both Ward and MeatballWiki. The Wikis success is no accident. A lot of the fundamental design features that make Wikis powerful were completely intentional, a testament to Ward's brilliance. Additionally, most of what I ranted about is not new to the Wiki community. A lot of it -- and more -- has been discussed on the venerable MeatballWiki. If you really want to get a deeper understanding of how to improve Wikis, you should be on Meatball. (KKH)

SharedLanguage (KKI)

Last September, I wrote: (KKJ)

What really makes the Wiki's LinkAsYouThink feature special is that it facilitates the creation of SharedLanguage among the community that uses it. As I've said so often here, SharedLanguage is an absolute prerequisite for collaboration. The lack of SharedLanguage is the most common roadblock to effective collaboration, be it a small work team or a community of thousands. T (KKK)

It bears repeating over and over and over again. Wikis are transformational because they facilitate SharedLanguage. This is a feature that should be propagated far and wide, both in Wikis and other CollaborativeTools. (KKL)

I noted two possible convergences. The first is Wikis and tagging. They both share a similar principle, namely namespace clash, and we should look at ways of combining these two concepts. For example, where's the tag cloud view of a Wiki's page index? Another idea: Clicking on a tag should also return Wiki pages of the same name. Technorati should be indexing Wiki pages and treating their titles as tags. (KKM)

The second is implementing LinkAsYouThink in all tools. Blogs that are built on top of Wikis (such as TWiki and JotSpot) have these features, but you don't have to build a tool on top of a Wiki for this to work. This blog runs on blosxom, but it has LinkAsYouThink. ChrisDent's blog runs on MovableType, and it has the same feature. It shouldn't just apply to blogs, either. It should work in web-based forums and other CollaborativeTools. (KKN)

/tech/wiki | Posted at 2:25pm

Making Change Safe #

My buddy, JustinLin, has a company that recently migrated from J2EE to RubyOnRails, and he's been thrilled by the results. This morning, we were IMing about AgileProgramming, and something he said about UnitTests? really struck a chord. He said that their tests softened their fear of change, which changed the team's entire attitude about change in general. (KJX)

I've written about UnitTests? before in a coding context, and of course, their importance is well understood in the AgileProgramming community. What struck me about Justin's comments was that he was describing how a tool in a very specific context was catalyzing a cultural shift within his company. While he didn't say this explicitly, I can imagine that shift extending beyond the technical component of the company. (KJY)

The lesson: Tools that make change safe facilitate a culture of adaptation. An adaptive organization is a strong, effective organization. (KJZ)

What are some other tools that make change safe? I saw KellanElliottMcCrea yesterday (welcome back to California, Kellan!), who reminded me of a suggestion I had made for SocialSourceCommons a while back: Wiki-style editing works because the revision history is visible. A visible revision history encourages change in the form of PermissionToParticipate, and that in turn can lead to a larger cultural shift within your team and even your organization as a whole. (KK0)

/collaboration | Posted at 11:15am

HyperScope Jam Session Tonight #

For those of you in the BayArea interested in learning about the HyperScope, we're going to be doing a public jam session tonight (Tuesday), 6-8pm at SRI in MenloPark. 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 ChordingKeysets? and Augment if you're lucky. Let me know if you plan on making it. Looking forward to seeing many of you there! (KJW)

/events | Posted at 10:51am

Wed, May 24, 2006

A Lynne Truss Moment #

For once, my infrequent blogging will work to my advantage. I had a LynneTruss moment at a talk I gave the other day, and since I've given a bunch of talks over the past month -- all unblogged -- I can write about the incident here without revealing too much about who the offender was or where or when it happened. And no, it had nothing to do with punctuation. In LynneTruss's preface to Eats, Shoots & Leaves, she tells a story about how she was autographing books and a woman in line started talking about how little she knew about punctuation, and how she wished there were some way for her to learn. Apparently, she went on and on as Truss dropped several not-so-subtle hints that this was what her book was for. The woman finally walked away without purchasing a book. (KIT)

Recently, I gave a talk about collaboration that was fairly well-received. It's a fairly common pattern -- people come expecting to hear me talk dreamily about the latest online tool, but instead, get an earful on process, engagement, culture, and the bottom line. Because their expectations are low to begin with and because I surprise them, people enjoy the talk. (I also like to think that I'm a better than average speaker, but I'll let others speak to that.) (KIU)

In any case, I told several stories about transforming organizational culture and ways to think about collaboration. I talked about how fear is a huge barrier to adopting technology, and how peer-to-peer learning is the best way to overcome that fear. I mentioned tools a few times, but mostly at a high level. (KIV)

After the talk, a woman in her 50s approached me and just stared for a while with this creepy-looking smile. Then she started telling me about how she couldn't log into her bank's web site. I thought she was reinforcing my earlier point about fear, but I slowly realized that she was asking me for tech support. I was stunned at first, then I actually tried to help her, but there was nothing I could do, and when I explained this to her, she gave me this very annoyed look and stalked off. Amazing. (KIW)

Just to end this post on a positive, my friend Cindy, who gave me Eats, Shoots & Leaves, turns 29 for a second time this Thursday. Happy birthday, Cindy! (KIX)

Oh, and Lloyd, I will eventually post my notes from my WikiWednesday talk earlier this month, I promise. (KIY)

/personal | Posted at 12:23am

Tue, May 23, 2006

URI Syntax for the HyperScope #

At last Tuesday's HyperScope meeting, JonathanCheyer 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 InternetExplorer 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 PurpleNumbers, 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 PurpleNumbers). (KI5)

You can also embed ViewSpecs 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 ViewSpec 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 InternetExplorer). (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. PurpleNumbers 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)

/tech/hyperscope | Posted at 4:40pm

Tue, May 02, 2006

Speaking at Wiki Wednesday #

JonasLuster recruited me to speak at WikiWednesday tomorrow (May 3) at 6pm at the SocialText offices in PaloAlto. My topic: A No-Holds-Barred Techie Manifesto on How to Make Wikis Truly Kick Ass. Truly. So come. You will not regret it. (KI1)

/talks | Posted at 11:56pm

Talk on User-Centric Identity #

I gave a talk on user-centric identity at the Internet Identity Workshop today. I was going to give a stock talk on how to rejigger your software architecture to incorporate this new breed of identity systems, but because of a last-minute shakeup of the schedule where I ended up first on the schedule, I decided to give a higher-level talk. I'll hopefully post the gist of the talk soon; the slides are available, but not that helpful. For now, check out brief summaries from Phil Windley, Tom Maddox, and Christine Herron. (KHQ)

In other news, I unexpectedly met two long-time members of the BlueOxen CollaborationCollaboratory face-to-face: DennisHamilton and MarkSzpakowski: (KHR)

(KHS)