perlIBIS: The Virtue of Thinking Out Loud

Read Danny Ayers‘s blog this morning, and saw an entry describing Ken MacLeod‘s recent experiment with IBIS Dialogue Mapping. I took a look, and was surprised and thrilled at what I saw. Ken had used (and improved) perlIBIS, which I had written and last released two years ago.    (JU)

I note this not just because I’m pleased (I am), but because it also shows the importance of knowledge capture and thinking out loud. I had announced this work to members of the small Dialogue Mapping community, and had received some positive feedback but little else. That was fine; my motivation in writing the tool was to Scratch Your Own Itch and experiment with some ideas, and I accomplished that. That said, it was gratifying to see that the ideas and the tool had propagated outside of that community, and that someone else was doing something valuable with it.    (JV)

Perhaps this will be the kick in the pants I need to finally write up some of my notes on Dialogue Mapping, both for synchronous and asynchronous collaboration.    (JW)

Blue Oxen’s One Year Anniversary

Today is Blue Oxen Associates‘ one year anniversary. Many thanks to all for your support and goodwill, especially those who have worked with us this past year. Special thanks to Chris Dent, our advisory board, and members of the Blue Oxen Collaboration Collaboratory. It’s been a great year; looking forward to another good one.    (J6)

Today, not coincidentally, is also the 35th anniversary of Doug Engelbart‘s Mother Of All Demos.    (J7)

Tonight, a small group of us are celebrating at the Foresight Institute in Los Altos, California. After that, back to work!    (J8)

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)

Ross Mayfield on Social Software, Social Networks

Last Friday, I finally got a chance to meet Ross Mayfield, who was speaking at the November meeting of the Bay Area Futurist Salon, held at SAP Labs in Palo Alto. Ross is CEO and founder of Socialtext, a company that is selling social software to companies. Some people have compared Blue Oxen Associates to Socialtext, which is apt in some ways, but is not quite right, as I’ll discuss below. Christine Peterson (one of our advisors) had said great things about Ross and Peter Kaminski (Socialtext‘s CTO), and Ross and I had exchanged some pleasant e-mails. The meeting confirmed Chris’s judgement. Not only is Ross a good guy, he had some interesting things to say about Social Software and Social Networks.    (D8)

Social Software    (D9)

I mostly agreed with what Ross had to say about social software, and I especially liked his overall philosophy about what makes a good tool. I did have a few nitpicks, though. Ross defined Social Software as follows:    (DA)

  • Software that supports group communication    (DB)
  • Software that adapts to its environment, rather than requiring its environment to adapt to it    (DC)

I asked him to clarify the latter statement, and he explained that most collaborative software tries to enforce too much structure. These tools force users to figure out how to fit the data into the tool, whereas the tools should fit the data. In this vein, Ross spoke highly of Wikis and blogs, and also of human filtering (such as Google’s technique of measuring backlinks) as a way of organizing information.    (DD)

I strongly agree with Ross’s philosophy, although I don’t like how he worded it in his slide. His statement is equivalent to the first part of Doug Engelbart‘s philosophy of coevolution of tools and processes; however, it leaves out the second part, which is equally important.    (DE)

Doug says that tools ought to augment human processes. However, as we learn more about the tool, we also must evolve the processes to adapt to the tool. An example that Doug often cites is the bicycle. Riding a bike is not intuitive, but it offers significant performance advantages over a tricycle. (To illustrate this point, Doug likes to show this picture.) “User-friendly” tools can be useful, but they should not be the end-goal.    (DF)

One “semistructured” tool that Ross does not like is e-mail. In predicting its demise, he cited several statistics regarding the amount of time required to deal with e-mail, especially but not exclusively due to spam. Ross introduced a cute term that I had not previously heard: “occupational spam” — e-mails from “legitimate” sources that have no bearing on your life or work whatsoever. This often manifests itself as being cc’d on threads of little or no relevance. Ross claimed that 30 percent of our inboxes consist of occupational spam. I should have asked for a citation on that stat, because it’s an interesting one.    (DG)

One of his main arguments against e-mail as a collaborative tool was that it encourages discursive discourse, and that it’s hard to make any sense of the sum product. I agree entirely with this argument, but would use it as an argument for how to use e-mail effectively rather than against e-mail entirely. Internally at Blue Oxen, our e-mail and Wiki usage complement each other quite nicely. We kick off the discussion using e-mail, and we synthesize the resulting thoughts into the Wiki, with links back to archived e-mail.    (DH)

Social Networks    (DI)

Ross’s presentation on Social Networks was outstanding. He’s obviously thought deeply about these issues, and he’s collected quite a bit of interesting research. He first described his and Valdis Kreb’s Blogmap Project, which mapped relationships between members of Ryze‘s Blog Tribe.    (DJ)

He then discussed the power law of blog space, which states that the distribution of links to a blog is inversely proportional to the blog’s rank. In other words, the number of links to the most popular blog is exponentially greater than links to the next-most popular blog.    (DK)

Ross then proposed three types of collaboration: the publishing model (one-to-many, where the power law applies), the individual’s social network, and small teams. He cited the primatologist Robin Dunbar’s work to suggest that social networks generally numbered about 150, and said that people’s interactions with their social networks generally followed a normal distribution. (Interestingly, he showed his RSS aggregator, which had 146 subscriptions.) Finally, he suggested that the optimal size of teams is about 10, and that the number of interactions between team members tends to be about equal.    (DL)

Socialtext Versus Blue Oxen    (DM)

Socialtext and Blue Oxen are similar in that we both are interested in collaborative tools, and that we both share similar philosophies about tools. Socialtext sells these tools as enterprise applications, however, whereas Blue Oxen is focused on understanding how best to use and improve these tools and on disseminating that understanding widely.    (DN)

In that vein, we both have embarked on similar projects, but with different goals. Ross talked about Socialtext‘s experiences with Social Software supporting face-to-face events, and those tools were available during his talk. We did a similar project with the PlaNetwork 2003 Conference, for which we set up a Wiki, RSS aggregators, and an IRC channel.    (DO)

We host collaboratories, and plan on charging for membership to those collaboratories once our infrastructure is up to snuff. However, we’re not an ASP, although we will make (and already have made) ASP-like services available to communities. Our infrastructure is meant to be cutting-edge and rough around the edges. It’s a way for people to experience first-hand what it’s like to use those tools, an opportunity to learn (and share) how best to use them, and a platform for coevolution. Despite our intentions, we’ve already discovered that even with promises of little/no “official” support, people enjoy using our tools for their real-world collaborative needs. As members, they’ll have free access to these tools for their groups. When they start needing better support and enterprise-level features, we will happily point them towards Socialtext and similar companies.    (DP)

“Turn Off Your Computer” and Other Pattern Ramblings

As I mentioned previously, Blue Oxen is finishing up its second research report. We spent several hours developing a survey for the report, and all of us were quite satisfied with the final draft. Then we e-mailed the surveys. Almost immediately afterwards, the three of us thought of several more questions we would have liked to have asked.    (CR)

The experience struck a chord in Josh Rai, who suggested there was a force there that manifested itself in several patterns. Last Thursday, he came up with a pattern as an example: Turn Off Your Computer. It’s both a pattern for good living — or as Josh called it, a “Martha Stewart” pattern — and also a pattern for knowledge work. I think the underlying force is one that crops up constantly, and is worth discussing. I also think explaining this particular pattern is a useful way of demonstrating the difference between a pattern and a force.    (CS)

Turn Off Your Computer    (CT)

Problem: You can’t remember whether you’ve finished all of your tasks.    (CU)

Context: You think you’re done with your tasks for the day — scheduling a meeting, sending an e-mail, etc. — but you have a sinking feeling that there was something else you were supposed to do.    (CV)

Forces: ?    (CW)

Solution: Turn off your computer. You’ll remember what you were supposed to do after the computer is off.    (CX)

Resulting Context: There is a sense of finality in turning off your computer that helps unclutter your mind, making it easier to remember whatever it was that you forgot.    (CY)

Rationale: You can always turn your computer back on. Remembering what you forgot before it’s too late more than makes up for the five minutes wasted in restarting the computer.    (CZ)

Related Patterns    (D0)

All of the Think Out Loud patterns tend to have a similar effect. For example, I often find that I discover all sorts of new insights and ways to express ideas after I submit a paper for publication. One way to trick yourself into thinking of these ideas ahead of time is to show your drafts to people. I’m generally reluctant to do this — as are many others I know — because I’m self-conscious of my writing. However, the payoff always makes it worth it.    (D1)

The software analog of this is Commit Early And Often. Checking in code not only allows others to review your work, it often frees your mind into solving previously unresolved issues.    (D2)

When I’m having trouble thinking through a problem, discussing it with other people often helps. In fact, I often figure out the solution myself right after explaining the problem. Sometimes, just formulating the problem in my head prior to explaining it leads to the solution. Nevertheless, I find it vital to have the person physically present.    (D3)

Pattern Ramblings    (D4)

In this particular case, we recognized the force before coming up with the pattern (although I still haven’t managed to describe the force usefully). I think of the difference between patterns and forces as analogous to the difference between patterns of language and the rules of language. Infants (and perhaps most adults) learn languages by recognizing and repeating patterns. We know nothing about syntax and semantic rules until we are taught them, at least not consciously. Nevertheless, while knowing the rules are not necessary for learning the language, they are valuable for understanding and evolving the language.    (D5)

Furthermore, we are good at recognizing patterns, but we’re not necessarily cognizant of them, and hence, are often not good at synthesizing them. Writing a good pattern is hard; recognizing a good pattern is much easier.    (D6)

We don’t necessarily have to be cognizant of patterns in order to apply them. However, it certainly helps. Comedians, for example, are applying patterns of humor. Most of these comedians are probably aware of these patterns, although they probably weren’t when they were merely funny people. People who aren’t natural comedians can learn to crack jokes once they are aware of these patterns.    (D7)