Twitter, Facebook, and Social Boundaries

Posted on Published by Eugene Eric Kim

Speaking of tweets and Twitter, I finally succumbed and activated my Twitter account a few weeks ago. Come follow me! I had many reasons for doing so, but the kicker was probably learning that Twitter is in fact for old people. Seriously, my main reason was that I’ve been blog-free for many months, and I wanted to maintain a lighter-weight Visible Pulse for sharing ideas and letting people know that I was still alive.    (MTL)

Unlike my experience with this blog, I initially found it hard to start tweeting. I love to share ideas, but I don’t like talking about myself. My blog has been great for that, and I figured I’d use Twitter the same way. But it’s hard to do in 140 characters. It’s much easier to mention what I had for breakfast than it is to share some brilliant new insight, although simply tweeting “Eureka!” probably fulfills the latter need quite nicely.    (MTM)

So to get going on Twitter, I used a trick that I never had to use with my blog. I built an audience. I started following people, and many of them reciprocated. Now tweeting was about having a conversation with the people in my network. I didn’t have to do this with my blog, because I was motivated enough to start sharing my ideas without it. Getting that audience simply furthered that motivation (the past few months not withstanding).    (MTN)

This is obvious stuff to people who already blog or tweet regularly, but it’s not obvious to those who don’t, and when it’s explicitly understood, it can be used to your advantage. This is why Pattern Languages are so useful.    (MTO)

It would be interesting to do some analytics on tweeting based on size of social networks. For example, do people with larger social networks tweet more?    (MTP)

Another nice Twitter pattern is the character limit: Constrained Space. Many people have told me that they find blogging intimidating, because they feel a lot of pressure to actually write something. The character constraint relieves that pressure. It’s easier to come up with a 140 character message than it is to fill a blank slate. Size of space matters.    (MTQ)

The issue I’m now having with Twitter is with social boundaries, and not surprisingly, the cause of this isn’t Twitter at all. It’s Facebook. My close colleagues know that I am obsessed with Facebook, not because of some deep seeded need to feel like I have a lot of friends, but because I think it is one of the most well-designed online tool I have ever seen. There are all of these well thought out social patterns deeply embedded in the tool.    (MTR)

Because of this, it’s no surprise that so many people across so many different networks use it. My pattern for studying Social Network sites has always been to only connect to people who connect to me first, then to watch what happens. With the vast majority of sites, it’s the same group of people end up pinging me. In other cases, certain niches become apparent. Facebook is the first Social Network tool I’ve used where people across almost all of the different communities of which I’m a part have found and reached out to me.    (MTS)

The problem is that Social Networks are not frictionless. You can’t just mix them all up and expect everything to be wonderful. A while back, Pamela Dingle told a great anecdote that wonderfully portrayed some of the unsavory consequences of these boundary issues.    (MTT)

One of the things that exacerbates Facebook’s challenges with Social Network friction is its open API. For a lot of reasons, Facebook has encouraged people across many different networks to intentionally come together in a shared space. However, its API allows people to bring new networks to the same shared space unintentionally.    (MTU)

I enjoy the status updates on Facebook, and so when I started tweeting, I decided to sync Twitter with my Facebook status. By doing so, my audience went from a somewhat closed community of folks who speak the same Shared Language to a much larger community of folks, many of whom think I’ve gone nuts. These include people like high school friends, most of whom find the idea of posting a picture that’s not hidden behind a password absolutely ludicrous.    (MTV)

Those of us who have been part of Identity Commons for a long time have been talking about these issues for ages, yet it’s fascinating to experience them firsthand. I don’t find them that big a deal, because I have well-defined boundaries that I think work with my different networks. I don’t mention people by name unless I know they’re comfortable with it or I’m attributing an idea to someone. I’ll happily write about what I had for breakfast (Tartine bread and gruyere this morning), but I won’t write about my dating life.    (MTW)

I don’t know how long the Twitter experiment will last. It still feels a bit uncomfortable, but it’s been fascinating, and I probably won’t stop anytime soon.    (MTX)

Leave A Trail: Stigmergy and Effective Large Group Collaboration

Posted on Published by Eugene Eric Kim

One of the challenges with large group collaboration is keeping track of what others are doing. With a small group, the project manager or group leader can take on the responsibility of keeping others informed. If it’s a single organization, you can theoretically mandate a communication strategy from above, although in reality, this doesn’t work effectively when the organization is large and diverse. For large-scale collaboration between different groups, neither of these are realistic options.    (KCB)

How can large groups communicate most effectively? The answer is stigmergy, a term Chris Dent first introduced to me about four years ago. Stigmergy is a form of indirect communication where organisms react to signs left by others. Ants communicate by stigmergy. They leave a trail of pheremones that other ants pick up and react to. Stigmergy — not centralized command-and-control — is responsible for those amazing anthills.    (KCC)

There is an equivalent pattern in effective large group collaboration: Leave A Trail. I’ve called this pattern Think Out Loud and Visible Pulse in the past, but I like “Leave A Trail” better, because of its association with stigmergy. (Obligatory karma reference: I first heard this name from Peter Kaminski, who in turn credits Chris Messina for explaining it as a principle of Bar Camp.) MGTaylor calls this pattern Ship Product and often describes it in the context of Stuart Kauffman‘s work and patch theory.    (KCD)

The idea is simple. When you work, leave an artifact somewhere where others can find it. An artifact doesn’t have to be comprehensive; in fact, it’s often better when it isn’t. A brief meeting summary is usually more useful than a full transcript. A brief summary with links to specific instances in the transcript is even more useful.    (KCE)

When you Leave A Trail, you’re communicating to whomever wants to listen, which may effect how you express yourself. This can be disconcerting to some. People often point to the lack of response as a sign that tools like online forums, blogs, or Wikis aren’t working. That’s not necessarily the case. There may be a whole slew of lurkers who are reacting to the signs that you are leaving. (That said, Immediate Feedback is also an important pattern in Online Communities.)    (KCF)

This can also be difficult when determining what kind of trail to leave. Because you don’t know who will be reacting to your signs, you can’t target them. The solution is to Scratch Your Own Itch.    (KCG)

Emergence can’t happen without Leave A Trail. However, Leave A Trail is just one of many conditions for emergence. You can’t dictate whether emergence will happen, and when it does, you can’t control what actually emerges. The best you can do is create conditions for emergence and hope that good things happen. This is disconcerting to many, and folks often react by trying to assert more control, which makes things worse.    (KCH)

Leave A Trail and other principles are helpful in designing community spaces. For example, if you are trying to integrate blogs or Wikis into a community’s practice, the best way to do that is to apply the tool in such a way that it scratches an individual’s itch while also leaving a trail. For example, many good project leaders are good at doing meeting summaries. Instead of having them email a small subset of individuals, have them email a public, archived mailing list. Better yet, have them blog their summaries and email links to the blog. You’re not significantly changing individual behavior in these situations, but you are significantly improving your chances for large-scale collaboration.    (KCI)

Patterns at WikiMania 2005

Posted on Published by Eugene Eric Kim

When I first met Christine Peterson (now a Blue Oxen Associates advisor), she told me the story about coining “Open Source.” The sign of a good name, she explained, is when people naturally start using it on their own. At a meeting of developers and evangelists in early 1998, rather than argue strongly in favor of the term, she introduced it subtly. Although the response wasn’t enthusiastic at the first, everyone in the room found themselves using the term, and by the end of the meeting, they all agreed to evangelize it.    (JMS)

Similarly, my strategy for introducing and identifying patterns of high-performance collaboration is to subversively introduce patterns into various communities and then to listen. If people naturally use a pattern in conversation, the name is probably good and the pattern itself is probably real and repeating. As people become familiar with the concept, they are more likely to identify and name other patterns. Over time, the language shifts your thinking, giving you a cognitive framework for thinking about, talking about, and improving collaboration and collaborative tools. Moreover, the process itself is iterative and collaborative, which is both the right way to develop Pattern Languages and also another application of collaborative patterns.    (JMT)

I’ve been giving some variation of a stock talk on patterns for over a year now, including last week at Wikimania 2005. It usually consists of a quick introduction, a few examples, and an interactive portion where I tease out patterns from the audience. The audience banter is always the best part. It’s always different, and it’s provided me with entertaining anecdotes, new patterns, and better pattern names.    (JMU)

Last week, I mentioned four patterns that Wikis facilitate: Permission To Participate, Shared Display, Visible Pulse, and Working Draft. Tim Starling followed my talk with an overview of Mediawiki development, and when he mentioned their IRC channel, he said, “This is our community’s Visible Pulse.” I love it when the process works!    (JMV)

The discussion teased out other patterns, especially Celebration and Initiation. (Linda Rising and Mary Lynn Manns mentions both of these in their book. They have a better name for the latter, but I don’t remember it off-hand.) One person told a great story about both. His team met for the first time in Australia, and before embarking on their project, they brewed beer that they planned on drinking after they finished their project.    (JMW)

Other patterns observed and not observed at the conference and within the community:    (JMX)

  • The Celebration at the end of the conference was great, but the Initiation wasn’t particularly remarkable. This isn’t unusual for conferences, where Initiation tends to be in the form of a keynote.    (JMY)
  • One pattern closely related to Initiation is Introductions. At conferences, this generally comes in the form of name badges, which we had at Wikimania. I think there’s a huge opportunity for further facilitating this pattern at conferences, which is something Blue Oxen Associates is working on. Hacking Days also would have been significantly more effective if we simply went around the room each day and quickly introduced ourselves. It’s one of those patterns that sound obvious when you hear about it, but is often forgotten when actually designing an event.    (JMZ)
  • Conferences usually do Water Cooler well, and Wikimania was no exception. We had long lunches, a party on the last night, an IRC channel, and some organized activities in Frankfurt am Main for stragglers following the conference. In particular, the organizers did two things really well. The Haus der Jugend was an excellent choice of venue, because it was an intimate space where social interaction was practically unavoidable. Most of the participants stayed at the hostel, which meant that there was always an interesting conversation to be had by simply going downstairs and hanging out in one of the common rooms. Plus, most of us who stayed there also had roommates, which is not typical for the conferences I attend. The restaurants and bars — touristy though they were — were in very close proximity, which made it easy to grab a beer and talk. (Food is a closely related pattern.) Finally, Hacking Days served as an unintentional Water Cooler, at least for those of us who were not Mediawiki developers. Coming early is something the organizers should encourage more widely next time.    (JN0)
  • I’m very biased towards highly interactive event design, and it seemed like it would have been especially appropriate for a Wiki conference. That said, the panel format worked better than at most conferences, and I think the Wiki culture of Permission To Participate had a lot to do with that. The audience interacted easily with the presenters at all of the talks I attended, and most of the speakers did a nice job of incorporating feedback into their presentations. One thing they did not do well was actively promote and integrate the conference Wiki as a place to take notes and have additional discussions. Again, this seemed surprising for a Wiki conference — yet another indication that making patterns explicit is a good thing.    (JN1)
  • Another favorite — also found in Linda and Mary Lynn’s book — is Spotlight On Others. This runs rampant throughout the Wikipedia community, which is wonderful. Tim cited me when mentioning Visible Pulse, and by the next morning, Sunir Shah had incorporated Permission To Participate into his talk on conflict resolution. I found this time and again in people’s talks. One reason it occurred so often during the conference is that the organizers used a Wiki to develop the program transparently. People watched other people’s talks develop and incorporated their content even before the conference began.    (JN2)
  • A critical pattern, especially for inter-organizational collaboration, is Neutral Space. Wikipedia would not have been successful if it did not have an open content license (which facilitates Neutral Space) and, to some extent, if it were a for-profit company. At the board panel on the last day, several people brought up the question of online ads. On the one hand, ads have the potential of bringing in a tremendous amount of revenue, which could be put to good use for the community. On the other hand, it breaks the Neutral Space pattern that has served Wikipedia so well. The community was more or less split on this issue. My vote: No ads!    (JN3)

One last pattern that I both observed and missed was Users Talk To Developers, a pattern I first described in, “An Introduction to Open Source Communities.” Previously, I criticized the Mediawiki developers for not practicing it enough. With the whole conference finally behind me, I want to both soften and and strengthen my statement.    (JN4)

Many of the Mediawiki developers came to the project as Wikipedia contributors. Brion Vibber, one of the leaders of the project, probably never would have joined had it not been for the Esperanto Wikipedia, of all things. After having more time to interact and observe the developers, I think that on average, community interaction is more prevalent among the Mediawiki developers than it is with many other projects.    (JN5)

That said, it’s still not nearly what it can and should be. During the sessions on politics and developing countries, several panelists complained that the tools had a way to go to meet their needs, and yet, none of the developers were attending their sessions. Hossein Derakhshan noted that techies are generally not interested in issues outside of their sphere.    (JN6)

Not all the blame falls on developers, however. As great as it would have been to see more developers abandoning the technical sessions in favor of the more social ones, it would have been fantastic to see more Wikipedia contributors attend some of the technical sesssions. Both communities need to learn and respect each other’s language if they truly want to engage collaboratively. Bridges are critical to make this work. Note that this applies not only to Mediawiki, but to all Open Source projects.    (JN7)