Blog | Wiki | Photos | Publications | Software | Talks | About

---

Thu, Feb 28, 2008

The Technology Understanding Gap    #

Technology is insidious. It has a way of dominating a problem the way nothing else can. If you understand technology, it's hard not to see everything in that light. If you don't understand technology, it's hard not to be overwhelmed by what you don't know.    (MUK)

I've known these things for a long time, and I often talk about these things, but I saw the latter phenomenon in a way that really affected me last month at the PackardFoundation gathering on the future of network impact in philanthropy. On the first evening, ClayShirky gave a preview of his book (available now), Here Comes Everybody: The Power of Organizing Without Organizations (which sounds like it's a real winner; can't wait to read it).    (MUL)

One of Clay's contentions was that projects that worked in large-scale networks shared a happy medium between a Promise, a Tool, and a Bargain. In the case of Linux, LinusTorvalds's Promise was to build "a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones." (Note how small and concrete the original Promise was, compared to what Linux has become.) The Tool was source code control (specifically diff and patch in the early days). The Bargain was the GPL, which stated that if you contributed your work, others would as well.    (MUM)

A lot of my work centers around facilitating collaboration in large-scale networks, so I found this contention particularly interesting. The following day, I co-led a session on this topic with AngusParker. Two of the participants were dealing with the specific challenge of connecting members of a national network of leaders in reproductive health, so we used that as a case study. We decided to use Clay's contention to frame the problem, resulting in this whiteboard:    (MUN)

   (MUO)

What do you notice about this picture?    (MUP)

Obviously, the Tools column is completely empty. That's a dead giveaway that I'm facilitating this discussion. (That and the horrific handwriting.) Figure out the basics first. Don't let the question about technology drive the discussion.    (MUQ)

During the discussion, one of the participants asked, "What tools can we use?"    (MUR)

I responded, "Let's not worry about that now." So we kept talking and talking, and I noticed the two non-technical participants in the group squirming like crazy.    (MUS)

So I stopped, noticed how gaping the Tools column looked, and said, "You're uncomfortable about not having discussed the tools, aren't you."    (MUT)

She nodded.    (MUU)

"Don't worry about it," I responded. "The tools part will be easy, once we figure everything else out."    (MUV)

"Easy for you, maybe," she said. "You already know what goes there."    (MUW)

That was not quite true, but I got her point, and the force of it struck me so hard, I had to stop for a moment. I looked at the gap, and I saw possibilities. She looked at the gap, and she saw a void. That was upsetting for her. It made it hard for her to think about the other aspects of the problem.    (MUX)

It made me realize how much I take my technology literacy for granted. But it also created an opportunity to discuss how easily we are sidetracked by technology. "Tool" does not have to mean software, and making that assumption prevents us from exploring other viable, possibly better solutions.    (MUY)

I had two takeaways. First, I had previous explored doing a basic technology literacy workshop as part of BlueOxenAssociates' Tools for Catalyzing Collaboration series, but I was not particularly motivated to do it. I'm now rethinking this. Second, if I ever do this exercise again, I'm not going to include the Tools column initially. We can throw that in later.    (MUZ)

/collaboration/tools | Posted at 4:31pm

The Chandler Project    #

Almost 20 years ago, in my old stomping grounds at DrDobbsJournal, MitchKapor published an article on software design. He wrote:    (MU0)

His manifesto stuck with me over the years, and when I started organizing the first FLOSS Usability Sprints with Aspiration, one of the first people I contacted with Mitch. Mitch not only agreed to sponsor our event, but he put me in touch with MimiYin and KatieCappsParlante, two of the leads of the Chandler project. Both Mimi and Katie were enthusiastic about working with us, and Chandler became one of our first participating projects.    (MU2)

At the time, Chandler was a lot of design and very little code. What intrigued me, though, was their design approach. They were aggressively committed to UserCenteredDesign, which was totally unique for an OpenSource project. In many projects, OpenSource or otherwise, interface design plays a secondary or worse role in the overall project. The interface is often designed after the fact. With Chandler, interface design played a core role in the overall design.    (MU3)

Last fall, Chandler participated in the fifth incarnation of our sprints, and it was amazing to see how much progress the team had made. Not only was there working code, but there was an active developer and user community, and there was an ongoing commitment to their design approach. The project was also about to face a major transition, having reached the end of its incubation phase under Mitch.    (MU4)

After reconnecting with Mimi and Katie, I decided it was time for me to start using Chandler. The timing for me was good. I had been a very happy user of todo.txt for personal use and a reluctant user of Basecamp for group projects. I wanted something that could replace both. The fact that it was a cross-platform desktop application was also appealing, because I regularly use three different platforms (Linux, Mac, and Windows) and because some of the people I'm currently working with do not have consistent access to the Internet.    (MU5)

The Why of Chandler    (MU6)

At its core, Chandler is a task manager in the spirit of DavidAllen's GettingThingsDone methodology. You have items that you can organize into collections and prioritize as "Now," "Later," and "Done." If you add a date to an item, it will appear on your calendar. And you can assign items to others.    (MU7)

You can view your list of "To Do" items by collection, in a calendar (if they have dates), or in a dashboard view that provides an overview of all the different things you have to do.    (MU8)

Simple, right? Well, yeah. That's a good thing. But if you dig a bit deeper, you can see that this simple design has some very powerful consequences, and it all centers around this notion of the item.    (MU9)

Items have titles and descriptions, which are free-form text. They have priorities and possibly dates. Items can belong to as many or as few collections as you'd like. Items can be shared with or assigned to others.    (MUA)

The notion of an item is pretty generic, and in fact, you can see it in a lot of other applications as well. Email is the classic example. An email message can be thought of as an item. In fact, many people use their email as task managers. If they want to share an item, they email it to others (which is how Chandler works as well). If they want to categorize an item, they move it to a folder. If they're lucky (for example, if they use Gmail), they can give an item multiple tags.    (MUB)

But email has downsides. The interface is not optimized for task management, although there are plugins that help. Most clients do not support tagging, which means that you have to copy items to multiple folders, and those items do not stay in sync. And email messages are static, whereas an item should be able to evolve over time.    (MUC)

Other applications that use this exact concept of an item are, well, other task managers: Basecamp, Remember the Milk, Bugzilla, RT, Trac, etc. In many ways, these are competing products, but in the Chandler world, they are actually complementary products.    (MUD)

This is the hidden beauty of Chandler. Chandler recognizes that people will be using a lot of different tools, from email to RSS to other task managers. It doesn't try to be The One Tool. Instead, it is designed to be interoperable. You can write plugins that synchronize items in other applications with items in Chandler, so that you can use Chandler to do what it does best, and other applications to do what they do best, and all the data stays in sync.    (MUE)

Chandler essentially becomes a dashboard for knowledge work, a place where KnowledgeWorkers can live and get things done. Right now, email fulfills that role for most people. A tool like Chandler has a very good chance of supplanting email in this department, because it offers an interface that is more in line with what KnowledgeWorkers want to do. More importantly, it works with email rather than trying to replace it.    (MUF)

Chandler works right now. I use it every day, and I'm productive in it. However, its great potential is still largely unfulfilled. The interface is still rough, and there are very few plugins that take advantage of the synchronization capabilities. Every once in a while, I find myself longing for todo.txt (although it should be relatively straightforward to write a command-line based interface to Chandler that emulates it).    (MUG)

However, I believe that this roughness still works in Chandler's favor. Why? Because as I noted earlier, Chandler is perhaps the only OpenSource project in existence that aggressively integrates OpenSource development principles with user-centric design. What we're seeing right now is a spike, a product of ReleaseEarlyAndOften?. But if you follow the design discussions -- and you can, because it's OpenSource -- you can see the ethos of UserCenteredDesign come through. The interface for the upcoming 1.0 release is going to be significantly better than the current design (0.7.4.1), and that will merely be scratching the surface of what is to come.    (MUH)

Chandler has the potential to be a really great tool relatively soon. It's not there yet. But if you're excited about the idea that an OpenSource development process can actually result in better software for real people, you should take a look now. More importantly, you should participate in the community, which is fantastic, thanks largely to the expert guidance of TedLeung? and the development team's active participation. Chandler is definitely a project to watch.    (MUI)

/collaboration/tools | Posted at 11:19am

Wed, Feb 27, 2008

Twitter, Facebook, and Social Boundaries    #

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 VisiblePulse 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 PatternLanguages 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: ConstrainedSpace. 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 SocialNetwork 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 SocialNetwork 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 SocialNetworks are not frictionless. You can't just mix them all up and expect everything to be wonderful. A while back, PamelaDingle 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 SocialNetwork 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 SharedLanguage 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 IdentityCommons 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)

/collaboration/tools | Posted at 2:15pm

Wed, Nov 28, 2007

barx: A Ruby XRI Resolver    #

Last month, VictorGrey and KermitSnelson announced barx, the first full implementation of the XRI 2.0 draft specification (working draft 11, for those of you keeping track). I finally downloaded and started playing with it tonight; it's very nice. Most OpenID implementations are using a proxy hack to support i-names, but as real XRI implementations start to come out, we'll start seeing many more interesting applications.    (MS5)

I've started to port barx over to Perl and will hopefully have it completed by IIW next week. Yes, I'm coding again. I've been sitting on a slew of year-old ideas that need to get implemented, and I'm tired of being a preacher instead of a do-er (at least when it comes to code). It's against my instincts, and I don't have enough of an audience to leverage the LazyWeb.    (MS6)

Besides, I was starting to miss it. Over the last few years, I've built a reputation as someone who knows a bit about collaboration, not just about tools, and that's been really gratifying. It's also helped me feel okay about reminding people that I still know a bit about tools as well. Plus, a lot of things have been stoking the fire recently. I was managing the HyperScope project last year and the GrantsFire project this year, both of which are conceptually and technically interesting. I never stopped reading code, and a lot of my friends are developers. What really kicked things into gear for me, though, was stepping in as an emergency developer for GrantsFire and watching LinusTorvalds's git talk.    (MS7)

I started playing with a bunch of ideas at once, but I'm focusing on GrantsFire and the DigitalIdentity stuff now. Stay tuned, and if you want to hack with me over the next few weeks, either face-to-face or remotely, ping me.    (MS8)

/collaboration/idcommons | Posted at 2:51am

Sun, Nov 25, 2007

Tools and Culture    #

Tools reinforce power relationships. If you want a more emergent power model within a group, you have to make sure your tools support that. Git is a beautiful example of how a tool can support the right power relationships.    (MRK)

However, just because a tool has affordances doesn't mean people will pay any attention to them. LinusTorvalds alluded to an example in a software development context: Giving everyone commit access to a centralized repository. He refers to this happening in companies, but there's precedent for it happening in OpenSource communities as well. For example, TikiWiki gives commit access to anyone who asks. The underlying philosophy behind this policy is very Wiki-like: Empowering everyone to make things better offsets the risk of giving everyone the opportunity to screw things up. By not imposing a power structure, the right model can emerge.    (MRL)

In the case of git, the tool explicitly supports an emergent power model. In the case of the TikiWiki community, the tool's inherent model is overridden by the community's culture.    (MRM)

What can we learn from this? Tools have the potential to transform culture, but transformation never comes easily. In the Wiki community, the classic case of this is when users email an administrator about a typo in a Wiki rather than fixing it themselves. We in the Wiki community use this behavior as a leverage point to explain that they have PermissionToParticipate and can change the content themselves. Once people start modeling this behavior, transformation becomes a possibility.    (MRN)

When I saw MichaelHerman last month, we talked about how tools do and don't encourage emergent models of behavior and how often we need to catalyze this process by other means. Michael brought up the phenomenon of a few people gathering at a circle of movable chairs, then sitting on opposite sides of each other with many chairs between them rather than moving the chairs they needed into a tighter circle. Even though the environment was adaptable, people chose to go with the default rather than optimize it for their needs.    (MRO)

I saw a similar phenomenon a few weeks ago at TAG, where I sat in on EugeneChan, LucyBernholz, and SukiOKane's session on Web 2.0 and philanthropy. They had a very interactive design, which in the context of TAG (a very traditional conference format for a very conservative community), was highly unusual. They kicked things off by doing a spectrogram.    (MRP)

   (MRQ)

Not only did this establish a sense of self-awareness and SharedUnderstanding among the participants, it also got people moving (and laughing), which was especially important since the session was right after lunch. Without saying anything, it was clear that this was not going to be your traditional talking heads session. Smart, smart, smart. Then they led a discussion. They gave people PermissionToParticipate by explicitly setting expectations, catalyzed the discussion by asking broad questions, then held space and exercised self-restraint whenever there were awkward silences. Again, very nice.    (MRR)

But they also did something dumb. Look at the space:    (MRS)

   (MRT)

Whereas the leaders of the session were saying, "Please talk! Participate! Learn from each other!", the space was saying, "Look at the leaders! Keep quiet! Check your email while pretending to listen!" And the space was really, really loud, much louder than the leaders.    (MRU)

In fairness to Eugene, Lucy, and Suki, it would have been a major pain in the rear to rearrange the space, and there were strong disincentives to doing so (specifically, the wrath of LisaPool). But space makes a huge difference, and even super smart people don't account for this as much as they should. Even people who are in the business of collaboration and are constantly preaching about this sort of thing (i.e. me) make these mistakes all the time. Old habits and thinking die hard.    (MRV)

The online tool space is rampant with these examples. How often do you see Wikis where the "Edit this page" button is impossible to find?    (MRW)

Tools can encourage or discourage certain types of behavior, and it is in our best interest to choose and adapt our tools to encourage the behavior that we want. That's not always enough, but it's generally a good start. Eliminating obstacles can be as much of a catalyst as a good kick in the pants, but a combination of both is even more effective.    (MRX)

/collaboration/tools | Posted at 1:33pm

Imposed Stupidity, Emergent Intelligence    #

In The Restaurant at the End of the Universe, DouglasAdams wrote:    (MR5)

I recently watched LinusTorvalds's talk at Google on git, the distributed version control system he wrote a few years ago. There are a bunch of gems in his talk, and it's well worth watching. My favorite had to do with git's views on decision-making in OpenSource communities:    (MR8)

Someone in the audience asked Torvalds whether the distributed model simply shifted the political questions of access rather than eliminated them, to which Torvalds replied:    (MRC)

Power relationships exist everywhere there are groups of people. And if you don't believe they should, you're kidding yourself. CollectiveIntelligence, CollectiveLeadership, and more specifically, emergent self-organization are not about eliminating power relationships. They're about empowering the right people at the right time.    (MRF)

/collaboration | Posted at 10:49am

---

Copyright © 2001-2007 Eugene Eric Kim. Some rights reserved.