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

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

Sat, Nov 24, 2007

Babble Voice Privacy System    #

KirstenJones recently pointed me to HermanMiller's Babble Voice Privacy System. Babble is a small device (about the size of a tape player) that takes sound within a certain radius and rebroadcasts it as nonsense. In other words, it allows you to have private conversations in open spaces.    (MQP)

Babble is being marketed as a privacy device, but it's actually an important productivity device. People are good at ignoring white noise. When our brains hear sounds they don't recognize, they ignore them. People are bad at ignoring recognizable sounds. Every ambient conversation we overhear is a concentration breaker.    (MQQ)

The list price for a Babble is $695, which is steep for most mortals. However, there's a simple trick you can use for similar effect: music. People do this all the time on their own: When they need to concentrate, they put on their headphones. However, you can do this for an entire space as well.    (MQR)

The added benefit of using music in this way for OpenSpace-style events is that you can use this as a transitional device. Raise the volume when you want people to move, and lower the volume when you've achieved your goal. MGTaylor does this all the time, but they're not the only ones. OpenSpace facilitators often use Tibetan prayer bells to signal transition. AllenGunn (Gunner) will often start singing when he wants people to transition.    (MQS)

/collaboration/tools | Posted at 12:04am

Fri, Nov 16, 2007

Online Tools As Space    #

It's late, I'm tired, and I have a workshop I'm hosting tomorrow. But, I've got to get this off my chest now. You can thank my old partner in crime, ChrisDent, for initially instigating this with his blog post entitled, People in Social Software Systems." What closed the deal for me was reading WendySeltzer's piece, "Facebook: Privacy versus cross-context aggregation."    (MOZ)

I've been playing with this metaphor of OnlineToolsAsSpace for about a year now, and I've been threatening to write an essay on it for about as long. The premise is simple. We have a natural intuition for space and how it affects the way we work. Whether or not we leverage that intuition is another problem entirely, but the fact of the matter is, we do a better job of leveraging that intuition in meatspace than we do in online space. And we can leverage that intuition in online space.    (MP0)

Online space is mostly equivalent to physical space, except the physics are slightly different. The folks at LindenLab have this saying about SecondLife: "It's just like real life, except you can fly." That's not quite what I mean when I say the physics of online space is different, and the statement itself is wrong in subtle, but important ways. (Yeah, yeah, I understand it's a marketing slogan.)    (MP1)

Time is essentially equivalent in both online and physical space. What's different are the notions of proximity and presence. There is still the notion of distance in online space, but it's fungible. I can bridge gaps by modifying the presentation layer or by linking content, and suddenly, distances disappear. Moreover, we can take an existing online space and munge into something that looks entirely different. Since we don't have the notion of physical presence, we have to create a digital representation -- essentially DigitalIdentity.    (MP2)

What are the ramifications of all of this? First the good news. Once we get past the mental roadblock that technology seems to create in all of us, we can find that -- for the most part -- our intuitions about space applies both to physical and online spaces. I can identify a good intimate or public space just by looking at it, whether it's a physical room or a web site. We just have to leverage this intuition.    (MP3)

Now the bad news. The fungibility of online space and DigitalIdentity creates social havoc, largely in the area of privacy. People's blogs feel like private spaces, and so people treat them as such, but they're not actually private. People make contributions to Wikipedia, not expecting these to reveal much about their identities, yet some researchers discover that if you aggregate all this data, you can create visualizations that reveal a startling amount about a person's identity. And all of this stuff is easy to do.    (MP4)

I've got a lot more to say on all of this, and perhaps one day, I'll be able to say it coherently. But now that I've gotten it off my chest, I'd love to hear people's feedback.    (MP5)

/collaboration/tools | Posted at 1:45am

---

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