2008 – Page 4 – Eugene Eric Kim

The Technology Understanding Gap

Published February 28, 2008 by Eugene Eric Kim

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 Packard Foundation gathering on the future of network impact in philanthropy. On the first evening, Clay Shirky 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, Linus Torvalds‘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 Angus Parker. 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 Blue Oxen Associates‘ 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)

The Chandler Project

Published February 28, 2008 by Eugene Eric Kim

Almost 20 years ago, in my old stomping grounds at Dr. Dobb’s Journal, Mitch Kapor published an article on software design. He wrote: (MU0)

The lack of usability of software and poor design of programs is the secret shame of the industry. Given a choice, no one would want it to be this way. What is to be done? Computing professionals themselves should take responsibility for creating a positive user experience. Perhaps the most important conceptual move to be taken is to recognize the critical role of design, as a counterpart to programming, in the creation of computer artifacts. And the most important social evolution within the computing professions would be to create a role for the software designer as a champion of the user experience. (MU1)

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 Mimi Yin and Katie Capps Parlante, 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 User-Centered Design, which was totally unique for an Open Source project. In many projects, Open Source 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 David Allen‘s Getting Things Done 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 Knowledge Workers 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 Knowledge Workers 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 Open Source project in existence that aggressively integrates Open Source development principles with user-centric design. What we’re seeing right now is a spike, a product of Release Early And Often. But if you follow the design discussions — and you can, because it’s Open Source — you can see the ethos of User-Centered Design 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 Open Source 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 Ted Leung and the development team’s active participation. Chandler is definitely a project to watch. (MUI)

Twitter, Facebook, and Social Boundaries

Published February 27, 2008 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)

The Artist in All of Us

Published February 27, 2008 by Eugene Eric Kim

Howard Rheingold‘s tweet last week about his mother reminded me of a story Charlie Dunton told me last fall. There was a guy who used to go around elementary school classrooms to talk about art. After introducing himself, he would ask all of the artists in the room to raise their hands. What he found was that, up until the third grade, almost every student would raise their hand. Everyone saw themselves as artists. After the third grade, however, almost no one would raise their hands. The artist in each of them had been socialized away. (MTI)

I wonder what the world would be like if more of us viewed ourselves as artists. (MTJ)