The Chandler Project

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)

Getting Things Done

Last year, I reached a point where I wasn’t managing my time and tasks to my satisfaction, so I decided to check out the Getting Things Done bandwagon. I went to Green Apple to buy David Allen‘s book, but I couldn’t find it in the business section. I asked a salesperson for assistance, and to my horror (and amusement), they suggested I check the self-help section.    (LPB)

Getting Things Done is indeed a self-help book of sorts, but it’s also full of good advice on information management. More importantly, the philosophy it espouses not only has important implications on task management but also on collaboration.    (LPC)

The problem it seeks to address is, how do we manage our day-to-day, overcommitted lives in this age of information overload? Allen’s solution is simple. Keep your mind in a relaxed, ready-for-action state, which he compares to the “zone” that athletes often experience. In martial arts, if the body is tense, it will not react quickly or powerfully. Keeping your body relaxed is what separates the masters from the novices.    (LPD)

Easier said than done, right? Allen’s method for getting your mind into this state is two-fold. First, get things out of your head into a system you trust. Second, frame tasks as something actionable. Starting with managing the nitty gritty in your life will free your mind to do the higher-level thinking we all wish we had more time to do.    (LPE)

The ready-state and trust are critical concepts. Much of our day-to-day tension is the result of trying to balance all of the things we need to do in our head. The brain is not good at this sort of thing. Once you move all those tasks into a system you trust, you relieve your brain of that stress.    (LPF)

Allen cited one of his clients, who said that she never stressed about forgetting about a meeting, even though she had a lot of them, because she knew that information was in her calendar. Whenever she scheduled a meeting, she immediately off-loaded it into her calendar, so she knew that it was always current. She wanted a similar trusted system for managing other types of tasks.    (LPG)

Allen also noted that just as we feel guilty about breaking agreements with others, we also feel guilty about breaking agreements with ourselves. If you tell yourself you’re going to eat a salad every day, but you keep eating cheeseburgers, you’ve broken an agreement with yourself, and you’re going to feel bad about it. Even worse, you’ll lose trust in yourself, or at least, your system, and so continued use of that system will make you even antsier.    (LPH)

How do you resolve this? By acknowledging that you are in fact making an agreement, and treating it as such. Just as you would call a friend to reschedule, you need to explicitly renegotiate the agreements you make with yourself.    (LPI)

Explicitness is critical. The act of framing a task as an action is an important, but oft-neglected step. “Eat better,” is not actionable. “Eat fish three times a week,” is. The act of writing down an action item makes it both real and subject to renegotiation.    (LPJ)

In keeping with his philosophy, Allen’s book is full of concrete actions you can take to improve your information management. These have been covered in great detail elsewhere, so I’ll just point out a few that I’ve found useful:    (LPK)

  • Keep your file cabinets two-thirds full.    (LPL)
  • Use a label-maker on your file folders.    (LPM)

(For a more comprehensive list of my GTD implementation and some other tips and tricks, see Life Hacks.)    (LPN)

These sort of tips sound trivial, but when performed with the larger framework in mind, they are extremely effective. One of the things I really like about Allen’s book is his emphasis on environment, which parallels my philosophy on collaborative spaces. How you structure your workspace will have a great effect on whether or not your work processes are successful.    (LPO)

Allen doesn’t spend much time on the implications of Getting Things Done on collaboration, but he does reiterate the importance of trust in groups. When you have a list of action items, and you’re not getting them done, others who are depending on you are going to lose trust. Since trust is the foundation of good collaboration, it behooves you to to be good at Getting Things Done.    (LPP)

This is essentially the Personal Information Hygiene point that I made last year, although I like how Allen explicitly incorporates trust into his explanation of its importance. However, I also think it’s an oversimplification. One of the inherent advantages of a team over an individual, is that you can compensate for individual weaknesses. I’ll write more about this in a later post on Group Information Hygiene.    (LPQ)

Good Personal Information Hygiene

Chris Dent and I were chatting about my recent forays into David Allen‘s Getting Things Done, which led to this classic line from Chris:    (KXN)

Someday someone, maybe one of us, will poop out a “collaboration requires good personal information hygiene” thing.    (KXO)

Consider this post a poop.    (KXP)

When we founded Blue Oxen Associates, we were supposed to be a place for those on the cutting edge of collaboration. I quickly discovered that most people who want or claim to be on the cutting edge are held back by poor Personal Information Hygiene. People need to start with themselves before they worry about the group if they want to improve their ability to collaborate. (This is a general theme that extends beyond Knowledge Management.)    (KXQ)

Signs of poor Personal Information Hygiene:    (KXR)

  • Not keeping track of action items. (Not delivering on them is a sign of poor work discipline.)    (KXS)
  • Constantly asking questions that have been answered before. (This is also a great sign of poor Collective I Q.)    (KXT)
  • Asking to resend an email rather than looking things up yourself.    (KXU)
  • Losing track of email (including not responding quickly).    (KXV)

I have good Personal Information Hygiene, with two exceptions: I don’t answer email promptly, and I have a poor paper filing system (hence my recent foray into GTD). My digital information repository, on the other hand, is excellent — well linked and decently refactored. I generally find what I’m looking for and sometimes even find things I’m not looking for. I’ve started collecting some of my habits on my public Wiki at Life Hacks.    (KXW)

(Bill Seitz has often strongly expressed a similar view — that good organizational Knowledge Management needs to start with good Personal Information Hygiene. See his Wiki page on PersonalKnowledgemanagement.)    (KXX)