The Story of Glormf: Lessons on Language and Naming

Jack Park recently asked about Link As You Think on the Blue Oxen Collaboration Collaboratory. I’ve written several blog posts on the matter, but there’s not much else out there. This was a great excuse for me to tell a few vignettes about Shared Language and the importance of names.    (KMO)

Glormf    (KMP)

This is Glormf, courtesy of the uber-talented cartoonist, Brian Narelle.    (KMQ)

(KMR)

Fen Labalme coined the term (originally spelled “glormph”) at an Identity Commons retreat in July 2003. We were strategizing about next steps, and we found that we were all struggling to describe what it was that we were all working on. Although we all had different views of the proverbial elephant, we were also convinced that we were talking about the same thing. In an inspired moment of clarity, Fen exclaimed, “It’s Glormf!” Much to our delight, Brian was listening to the conversation and drew Glormf for all of us to see.    (KMS)

Glormf’s birth lifted a huge burden off our shoulders. Even though Glormf was mucky, it was also real. We knew this, because it had a name and even a picture, and we could point to it and talk about it with ease. The name itself had no biases towards any particular view, which enabled all of us to use it comfortably. Each of us still had a hard time describing exactly what Glormf was, but if anyone challenged Glormf’s existence, any one of us could point to Glormf and say, “There it is.”    (KMT)

We had created Shared Language, although we hadn’t rigorously defined or agreed on what the term meant. And that was okay, because the mere existence of Shared Language allowed us to move the conversation forward.    (KMU)

Ingy’s Rule and Community Marks (KMV)

Ingy dot Net‘s first rule of starting a successful Open Source project is to come up with a cool name. I like to say that a startup isn’t real until it has a T-shirt.    (KMW)

Heather Newbold once told a wonderful story about how Matt Gonzalez’s mayoral campaign buttons galvanized the progressive community in San Francisco and almost won him the election. As people started wearing the green campaign buttons, she described the startling revelation that progressives in San Francisco had: There are others out there like me. A lot of them. I was amazed to hear her speak of the impact of this recognition, coming from a city that has traditionally been a hotbed of activism.    (KMX)

There’s a pattern in all of these rules and stories. I struggled to come up with a name for this pattern, and the best I could do for a long time was Stone Soup (courtesy of the participants in my 2004 Chili PLoP workshop). I loved the story associated with this name, the parable of how transformational self-awareness can be. But, it wasn’t quite concrete enough for my taste.    (KMY)

I think Chris Messina‘s term, “Community Mark“, is much better. Chris has actually fleshed out the legal implications of a Community Mark, which I recommend that folks read. Whether or not you agree with him on the details, the essence of Community Marks is indisputable: Effective communities have Community Marks. Community Marks make communities real, just as the term “Glormf” made a concept real. That’s the power of Shared Language.    (KMZ)

Pattern Languages and Wikis    (KN0)

Pattern Languages are all about Shared Language. Much of Christopher Alexander‘s classic, The Timeless Way of Building, is about the importance of names. In his book, Alexander devotes an entire chapter to describing this objective quality that all great buildings have. As you can imagine, his description is not entirely concrete, but he does manage to give it a name: “Quality Without A Name.” Call it a copout if you’d like, but if you use the term (or its acronym, “QWAN”) with anyone in the Pattern Language community, they will know what you’re talking about. Shared Language.    (KN1)

Ward Cunningham was one of the pioneers who brought Alexander’s work to the software engineering community. He created Wikis as a way for people to author and share patterns. Not surprisingly, an important principle underlying Wikis is the importance of names. Regardless of what you think about WikiWords, they have important affordances in this regard. They encourage you to think of word pairs to describe things, which encourages more precise names. They discourage long phrases, which also encourages precision as well as memorability. The more memorable a term, the more likely people will use it.    (KN2)

Ward often tells a story in his Wiki talks about using Class-Responsibility-Collaboration Cards to do software design. One of the things he noticed was that people would put blank cards somewhere on the table and talk about them as if there was something written there. The card and its placement made the concept real, and so the team could effectively discuss it, even though it didn’t have a name or description. (Ward has since formalized leaving CRC cards blank as long as possible as a best practice.) This observation helped him recognize the need and importance of Link As You Think, even if the concept (or Wiki page) did not already exist.    (KNG)

Open Source: Propagating Names    (KN3)

One of Blue Oxen‘s advisors, Christine Peterson, coined the term, “Open Source.” In February 1998, after Netscape had announced its plans to open source its browser, a few folks — Chris, Eric Raymond, Michael Tiemann, Ka-Ping Yee, and others — gathered at the Foresight Institute to strategize. At the meeting, Todd Anderson complained that the term, “Free Software,” was an impediment to wide-scale adoption. After the meeting, Christine called up Todd and suggested the term, “Open Source.” They both loved it. But, they didn’t know how to sell it.    (KN4)

So, they didn’t. At the followup meeting a few days later, Todd casually used the term without explanation. And others in the room naturally picked up on the term, to the point where they were all using it. At that point, they realized they had a good name, and they started evangelizing it to the rest of the community.    (KN5)

Names change the way we think about concepts, and so propagating names widely can shift the way people think about things. This is what happened with “Open Source.” This is what George Lakoff writes about in Moral Politics.    (KN6)

The mark of a good name is that people naturally start using it. A name can come from the top down, but it can’t generally be forced onto people.    (KN7)

Angry Rant on Wikis

Earlier this month, Jonas Luster 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 Palo Alto. 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 Phil Windley, 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)

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 Shared Language 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 Single Sign-On, be it OpenID or something else. Implementing Single Sign-On does not imply loss of anonymity. Most Wikis give you the choice of logging in or not; implementing Single Sign-On 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, Scott Foehner, 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 Single Sign-On 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 Permission To Participate. 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? Ward Cunningham 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)

Shared Language    (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 Shared Language. This is a feature that should be propagated far and wide, both in Wikis and other Collaborative Tools.    (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 Link As You Think 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 Link As You Think. Chris Dent‘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 Collaborative Tools.    (KKN)

Usability and Encouraging Expert Usage

I was at SuperHappyDevHouse last Saturday with the rest of the Hyperscope crew. At around 2am, a group of us started having this great conversation about usability. Late night serendipity — you’ve got to love it.    (KCT)

Tony Chang asked us what we thought the most frequently pressed button was in Microsoft Office. We all guessed wrong. The correct answer is “Paste.” It turns out that practically no one uses Ctl-V to paste in Office. This, of course, was stunning news to all of us developer types, because we all use Ctl-V regularly.    (KCU)

Tony’s point was that real-world data trumps so-called expertise, a point that was hammered into all of us over and over again at the FLOSS Usability Sprints.    (KCV)

Microsoft’s response to this data was to enlarge the Paste button. (See Jensen Harris‘s Bay CH I talk for more on Office usability.) This response troubles me. On the one hand, it enhances the usability of the application for novices, which is a good thing. On the other hand, it does nothing to encourage users to learn the keyboard shortcuts.    (KCW)

Doug Engelbart often decries the misguided notion of “user friendliness everywhere” by saying that we would not want a world where everyone rode tricycles. Tricycles serve their purpose, but eventually, most people upgrade to bikes.    (KCX)

How can we design our apps that are usable for novice usage, but that also encourage expert usage? In other words, How do we design bikes with training wheels rather than bicycles? In the Office example, I would argue that there’s value in encouraging expert behavior and that emphasizing the Paste button is counter-productive in this regard.    (KCY)

Pie Menus are an excellent example of usable design that encourages expert usage. They address a novice need, but they also encourage expert behavior, because calling commands is associated with a physical gesture that becomes part of a user’s muscle memory.    (KCZ)

At RecentChangesCamp, Ward Cunningham talked about one of his challenges at Eclipse Foundation. He observed that the core Eclipse developers used the tool much differently than most users, an experience that was far more powerful and hence, far more gratifying. In typical Ward fashion, he’s trying to create a social space in which the core developers share their “aha” experiences with Eclipse as a means to encourage expert usage.    (KD0)

There are definitely cultural aspects of encouraging expert usage, but I also wonder if there are affordances that we should be encouraging in the design of the technology itself.    (KD1)

The Pete Paradox

Peter Kaminski has a great maxim, which those of us who know and love him commonly call The Pete Rule:    (K8N)

“Time together in person is too important to spend working.”  T    (K8O)

I think it’s a great rule, but there’s a corollary, which I’ll call The Pete Paradox:    (K8P)

Time together in person is the best time to work.    (K8Q)

I actually had a specific experience with Peter last October that led me to think about this paradox.    (K8R)

At RecentChangesCamp earlier this month, I faced this paradox first-hand. On the one hand, I didn’t want to waste the opportunity to really get to know some of the excellent folks in the Wiki community who aren’t local to the Bay Area. On the other hand, I had some specific things I wanted to work on — namely SisterSites with Ward Cunningham and other Wiki developers and a YADIS implementation with the good folks at JanRain. Working on these projects meant breaking away from the larger group, popping open the laptop, and focusing on the work at hand.    (K8S)

The paradox resolved itself to my satisfaction. I got both projects done. We implemented SisterSites in PurpleWiki and a bunch of other Wikis, and Brian Ellin and I wrote a YADIS library in Ruby. I met several interesting and cool people for the first time, including Brian, and, I got to know folks like Bayle Shanks a lot better. On the second night, after the conference party, I decided to go to the main ballroom to check my email, even though I was exhausted. The ballroom was empty at first, but about half an hour later, Bayle showed up. We had met at WikiSym, but this was the first time we had a chance to sit down and really talk, and we stayed up past 3am. That was excellent. I had already known that Bayle had done some cool stuff, but it was great to dig deeper into his ideas as well as to talk about non-Wiki stuff.    (K8T)

I even got to discuss The Pete Paradox with Pete in person. (How’s that for meta?!) And here’s how I finally resolved it in my head. Both The Pete Rule and The Pete Paradox are about maximizing engagement. When you are working closely together, you are engaging in a way that is not only more productive, but more meaningful. Face-to-face time spent working can be a waste, but face-to-face time spent truly working together usually isn’t.    (K8U)

The Brilliant Essence of Wikis

Over the past few weeks, I’ve had an unusually large number of discussions about the essence of Wikis — why they are so beautiful and important as Collaborative Tools. I realized I’ve never posted my thoughts on the topic, so I’m correcting that here.    (JTE)

Wikis have this brilliant feature, a feature that’s so simple and obvious, it’s often overlooked, yet it’s largely responsible for the success of Wikis. Incidentally, it’s also an intentional feature, which is yet another reflection of Ward Cunningham‘s design genius.    (JTF)

In a nutshell, that feature is the ability to Link As You Think by writing the name of the page, even if the page you want to link to doesn’t currently exist.    (JTG)

While you’re letting that sink in, let’s look at a measurable way this feature is valuable. A lot of folks view Wikis as a crude CMS. I don’t dispute this perspective — you can certainly use Wikis that way — but it’s not what makes Wikis interesting. Nevertheless, I see queries all the time on various nonprofit technology lists asking to compare Wikis to other CMSes, so here goes. It takes at least three steps to link to a new page with most CMSes (create new page, go to old page, create link), whereas it only takes only one with Wikis (write page name). That’s significant.    (JTH)

What really makes the Wiki’s Link As You Think feature special is that it facilitates the creation of Shared Language among the community that uses it. As I’ve said so often here, Shared Language is an absolute prerequisite for collaboration. The lack of Shared Language is the most common roadblock to effective collaboration, be it a small work team or a community of thousands.    (JTI)

Look at the page index of any Wiki, and you’ll see the vocabulary of that community. Thanks to the other affordances of the tool, that vocabulary accomodates multiple definitions while encouraging convergence where appropriate. Most importantly, that vocabulary is Shared Language that has emerged from the community itself and that continues to evolve.    (JTJ)

Here’s a real example. At the AdvocacyDev Wiki, which Blue Oxen Associates hosts, the top six most linked-to pages (out of 363 total) are:    (JTK)

From this very small sample, we can see that VoIP (and Asterisk in particular), IndyVoter, and CivicSpace are all much discussed tools among folks working on online advocacy tools. We can also see that Carl Coryell-Martin is an active member of this community (or at least one of the more diligent members when it comes to documenting).    (JTR)

The Wiki’s ability to facilitate Shared Language — a direct consequence of Link As You Think — is what makes it so important as a Collaborative Tool. In the future, when enough developers recognize this, we’ll see widespread integration of Wiki functionality in other Collaborative Tools, such as blogs, online forums, and more. It’s already started. Blog-Wiki integration (such as what I use) is not uncommon, and software like TWiki and JotSpot are showing the benefits of custom applications that use Wikis as the fundamental data structure.    (JTS)