The Chandler Project Blog

Yesterday I lamented that I wasn’t seeing any discussion about how email overload is fundamentally a collaboration problem (as opposed to a personal information management issue).

Then of course, I immediately ran into this one.

So, is it true? Will a new generation of collaboration tools help us wean ourselves off email? (The same way IM and social networking have already weaned us off email for social interactions.)

We hope so.

Chandler is most useful when used as an alternative for all the important stuff you used to do with email.

This should be true if you’re just using Chandler for yourself. This is doubly true if you’re sharing with others because at its best, Chandler opens up an alternative, more ergonomic channel for collaboration that results in fewer bits of information to keep track of and allows the group to leverage individual efforts to manage and organize information.

However, any collaboration medium that attempts to supplant email needs to retain what’s great about email while avoiding the pitfalls that have us all reeling from overflowing inboxes.

Here are some lists of email characteristics we want to emulate and avoid in Chandler.

What we want to keep: Email doesn’t get in the way of your ideas!

1. Every new message is a blank slate. Unlike other collaboration mediums (CMSes, Wikis, Project Managers, Shared Documents) composing new email doesn’t require you to first figure out how this “new thing” fits in with everything that’s come before.
2. Email lets you tackle issues in bite-sized pieces.

   Bite-sized means it’s easier to get started on tackling hard problems.

   Bite-sized also means you can manage email like a task list (as many people do). This in turn helps you multi-task. You can start, develop, fork and resolve dozens of threads at the same time. You keep track of it all by flagging/filing individual messages. With email, big, intractable problems are conveniently broken down into bite-sized next actions.

3. Email lets you tackle issues from multiple angles. You can formulate and reformulate what you’re thinking in a dozen different ways, addressed to a dozen different groups of people. Again, unlike other collaboration mediums, there’s no pre-existing structure to get in the way of what you need to do. Each new message/thread exists as it’s own, independent topic of discussion.
4. Email is free-form. Email messages are all about the wide-open field of unstructured data we call the message body. It allows you to focus on what you need to communicate! Whom you need to communicate with, is the only unavoidable decision you need to make. However, with the advent of aliases (everyone@wholeoffice), even that decision is avoidable.

What we want to keep: Email is still our best collaboration tool.

1. Email is universal. Not everyone is on your Exchange server. Not everyone has access to your company’s intranet. But everyone (for all intensive purposes) is on email these days. Email is the one communication medium where you’re guaranteed to get through (except when overzealous SPAM filters get in the way). Whether someone will actually absorb your communication is a separate issue.
2. Email is asynchronous. You can continue to make progress on other work as you wait for responses. This means you can work independently of your colleagues without losing touch.
3. Email keeps you up-to-date on what’s new. Every “new” piece of information is pushed to you as a new message. You never have to remember to “check-in” to find out what’s going on. You also never have to go hunting through an edited document wondering, What’s changed? Did something change?
4. Email encourages discussion. Email is linear. Each person gets their say. (However, while talking on top of one another is no longer a problem, no tool can prevent people from talking past each other.)

What we want to avoid and improve on: Email begets more email!
The very qualities that make email the defining tool of the information workplace are also its Achilles heel. Email is too easy to send. Each email in turn spawns more email to the point where you can no longer see the forest for the trees and you need to create more bits of information to keep track of the bits you’re losing in email.

1. There’s no way to “silently” make information available on an “as-needed” basis. To get information out, you have to send the email, thereby actively pinging every recipient with a message, regardless of whether you need their active attention. Ergo, we all get a lot of FYI mail, which in turn, dilutes the pool of mail that actually requires a response.
2. You can’t edit email. Once you’ve sent it, it’s done. If you forgot something, if someone else wants to add something to your list, if there’s been a change in plans, you’ll have to send a separate email. Ergo, we all get a lot of “update” emails.
3. When a mail goes out to 1 or 200 people, every recipient has to do the work of processing that email. Oftentimes, we process it in exactly the same way: Received a notice to hand in your benefit forms? Add it to the calendar. Put it in your “HR” folder. Yet, there’s no good way to distribute that work across the group. Ergo, we all spend a lot of time managing email.
4. There’s no way to add structure to email. The unstructured, blank slate that email offers when you’re initially composing the message is great for unblocking the free-flow of information. However, once you do have enough of a clue to add a bit more structure, you can’t. Ergo, email results in the creation of even more bits of information to manage as each email creates new calendar events and task items.
5. There’s no source of truth. Decisions are amended and reversed over multiple, forking threads. People are added and removed from conversations. Uncovering “the truth” in email turns out to be subjective and hard-won.

There are a dozen different ways in which Chandler strives to meet the ideal described above. We’ve already begun to see success stories of users moving their work from email into Chandler and we’re using them to help us become a better alternative to email!

Lately, a number of users have asked about auto-filling in Chandler on the Users-List. Rule-based filtering is an email feature many people can’t live without and it’s definitely something we’d like to see in the product.

Then, I came across Chris Brogan’s How I tamed my inbox. I’ve seen write-ups like this before, but this post really resonates with how Chandler is meant to be useful as a companion to email. Namely: Get important stuff out of email into a trusted system that has better affordances for managing the things you need to do. Chris Brogan’s trusted system consists of a lightweight filing system, a to-do list/project manager (Things) and a calendar (Google Calendar).

With Chandler, you get the to-do-list and calendar in one, integrated package

To quote Chris:

If any of my projects are time specific, I put that information into Google Calendar. I then set up the reminders along the way. Further, if the project is large or lengthy, I set up little milestone time frames such that I will remember to work periodically on projects all the way up to their due date.

Takeaways: Nothing gets done in a single sitting. The ability to see to-dos on a calendar is critical.

I have notes and details on a new conference I’m launching for marketers for September in the Boston area.

Takeaway: Keeping track of “notes about what I need to do” is just as important as keeping track of what I need to do.

However, I haven’t seen much discussion of sharing as a way to deal with “email overload”. Instead, too-much-email is most often portrayed as a personal information management problem.

Yet, email is first and foremost a communication tool, a way for groups to collaborate. If there’s a problem with email, it’s a group information management problem.

Ergo, sharing is very relevant to “email overload”. In addition to helping people deal with “too much email”, we can and should also be looking for ways to:

1. Reduce the amount of email we send and receive by restructuring the way information is disseminated and developed over time; and
2. Reduce the amount of time we spend managing email by sharing and distributing the work of putting information into the right contexts. (Only 1 person should ever have to do the work of putting things onto the right task lists and calendars!)

To be clear, I’m not saying that the solution is as simple as: Don’t email, just share! The point I’d like to make is more precise: Sharing is an important part of how we fix email, provided we don’t create yet another collaboration medium that simply generates more email!

Chandler attempts to walk this line and while there is always more work to do, we’ve already seen success in reducing email for our users. I will follow up with a more detailed blog post on how you can “Send less email” and “Spend less time managing email” with Chandler.

In Part 1 of this post, I described the dilemma we face in the design, trying to balance “avoiding the futility of time management” with a need to keep the LATER section somewhat under control.

In Part 2, I will walk you through some of the discussions we’ve had on the list and my reasoning for not going down the path of providing more granular LATER sub-sections defined around time.

With users piping up about how their LATER sections were becoming unmanageable, we revived discussions around adding LATER sub-sections defined around loose timeframes:

• LATER-Next week
• LATER-In 2 weeks
• LATER-This month, etc…

and improving the sub-sort order so that items in LATER are ordered by when they’re going to happen:

• “LATER-Imminently”
• “LATER-Far in the future”
• “LATER-No date at all”

The latter (improve sub-sort) was always part of the design and is on the short list of bugs to fix after we ship 1.0.

But I worry about going down the path of more granualar LATER sub-sections. I worry about falling into the trap of over-planning, over-emphasizing the importance of defining timeframes and inadvertently pushing users to assign dates they have no intention of holding themselves to, which again, results in big piles of items getting dumped into NOW when they’re not ready to deal with them.

Instead, I think it will be more effective to automatically collect all LATER items that don’t have a specified time frame (items with no alarm, no event dates) into a separate section called “LATER – No date assigned”.*

This smaller, hopefully more manageable “LATER-No date assigned” section acts as a reminder that there are deferred items that need to be reviewed and re-evaluated on a regular basis because they’re not going to magically re-appear in NOW on their own.

To make this list even smaller, we could provide a “LATER-Not really” option for items we create for peace of mind, but actually have no intention of doing, ever.

*Being an open source project that supports plugins means that of course doesn’t stop anybody from implementing an add-on for more granular LATER sub-sections. What I’m discussing here is the out of the box experience.

Chandler has gotten a lot of attention because of its association with David Allen’s Getting Things Done methodology.

That was part of our “Be all things to all people.” past.

2 years ago, we started the long process of paring down our goals and zeroing in on a single focus so that we could deliver a 1.0 product. GTD is not our single focus. Supporting knowledge work is. (Blog post coming soon.)

This doesn’t mean Chandler is somehow the anti-thesis of GTD. Given the overlap in problem space, I imagine that as we pursue our single-minded goal, Chandler will continue to improve for GTD practitioners as well.

We also welcome and will actively help volunteers who want to write a GTD plug-in. Come find us on the Chandler Development List!

However, many of our users already find Chandler to be useful for practicing GTD today. They define collections around the GTD projects list and @contexts, use the Dashboard collection as a centralized Collection Box and assign ticklers and calendar dates.

For these users, Chandler is still a better tool for GTD than say Palm or Paper, the original David Allen GTD tools.

Some of the features our GTD users have put to good use include: 

• The ability to organize items into multiple collections means you can have next actions live in multiple contexts and you can organize next actions by project *and* by context.
• Chandler’s integrated calendar and list views mean tasks you’ve put on your calendar can still show up on your next action lists as scheduled tasks or events.
• Sharing! Not something covered in GTD, but Chandler helps you implement GTD as a household or a workgroup.

Still, Chandler shouldn’t be construed as an implementation of the GTD methodology or any other methodology for that matter. We don’t believe software can teach systems the way David Allen can. 

Chandler also can’t teach users how to turn Goals into Next Actions or even to appreciate that there is a difference between the two. These are things people need to come to terms with on their own, in their own way.

As Rick Rawson explained on the Users List:

“I am finding that Chandler does not organize my life. It only helps ME organize my life. And that takes time and work. There are any number of different strategies within Chandler that can be used to be sure I don’t forget all those “things” to “research” and “think about.” None of those methods is magic; all require MY brain and my time. I have to take the time to figure out what works for ME in MY context and with MY personality and deficiencies. What I like about Chandler is that it provides me with some tools so that I can devise my own solutions.”

This is consistent with user feedback we’ve received that the GTD label actually scares people away. Even though there isn’t any GTD terminology in Chandler, people who knew about Chandler’s past association with GTD assumed they needed to subscribe to a particular way of doing things in order to succeed with the product.

This intentionally provocative statement could be construed as self-defeating, given our goal to help people be more productive. Presumably, part of being more productive is actually meeting your deadlines.

But “deadlines” are one of the big downers of task managers because they are overused and misused, applied to everything as if everything could be managed in terms of time.

You enter a task. You studiously assign timeframes: deadlines, start dates and alarms. The dates are often meaningless, but you fear that if you don’t, you’ll completely forget about it. Then, when the dates roll around, you end up with a big pile of overdue tasks. You clearly cannot deal with all of them now and you still don’t have a good way to ensure that you won’t forget about them. So instead, you constantly carry around the baggage of a long list of overdue tasks. Oftentimes, overdue tasks turn into moot tasks. Stuff you never got to and then it was too late and well, looks like it wasn’t really that important. (This is perhaps the most common reason people give for why they just don’t need a task manager.) But when you first thought of the task, it would have been like pulling teeth to admit that, so you dutifully entered it and set a due date anyway.

Trying to guestimate when you’ll actually do things and how long it will take you and by when you’ll have them done, aka time management is an exercise in futility…as far as “knowledge work” is concerned.

It’s absolutely essentialy for things like dentist appointments and paying your rent. But the benefits are less clear for tasks that start with verbs like Brainstorm…Look into…Evaluate…Think about…Follow up on…

This is not to say that there aren’t hard deadlines for the end-goal of all your Brainstorming and Looking into.

And a “responsible” person would leave themselves plenty of time to brainstorm before the product of that brainstorm needs to be handed in as a concrete deliverable. But the reality is, trying to quantify how much brainstorming (3 hours) you need to do and when you’re going to do it (2 days before the write up is due) is an exercise in futility.

Which is why many people don’t bother trying to record and track these random one-off thoughts in any kind of an organized system (unless you count email as organized.) Instead, they’re strewn across desks on little bits of paper, desktops in text files, emails, sticky notes, napkins and last but not least, your brain.

The problem for a growing number of people is, there is too much of this “stuff” to keep track of in your head and still no good way to keep track of them outside of your head. Traditional task management solutions designed for “concrete” tasks are too structured. Not very structured solutions like paper notebooks and text files are well, not very structured.

Chandler attempts to walk the line by offering just enough structure to get you “organized enough” without imposing so much structure that managing the solution becomes a task in and of itself.

“Avoiding the futility of time management” is precisely why the LATER section in Chandler does not offer more granularity. It was intentionally missing options for designating more granular sub-sections like Tomorrow, Next Week, in 2 Weeks. You can always assign alarms to items so that they automatically pop back into NOW on a particular date. But unless you have a very specific date in mind, the idea is that really, you have no idea when you’re going around to thinking about this again.

On the other hand, we have seen that users quickly accumulated so much stuff in LATER that they begin to see the LATER section as a black hole. If you want to forget about something, put it in LATER.

In Part 2 of this post, I will get go into more detail about how we might reconcile these two opposing forces in the user experience.

Mimi and I were checking out Things the other day, which appears to be a thoughtfully designed task manager for OSX (similar space to Chandler). One of the developers had a recent post that I thought captured something important about good design:

Of course both Jobs and Schiller know that there are times when you listen to users and times you better not. And the interesting thing is, even when developers don’t listen, they might do it for the best of their users. But how is that?

By all means developers need to follow their vision without asking anybody. They need to think out of the box and innovate. How else could they surprise and ultimately delight?

One of the main responsibilities of a developer is to keep guard over the gestalt of a program. It is all too easy to let your application burst into a universe of hardly connected little features. We have all seen it happen. But it is equally easy to ignore your customers’ needs and to embark on a journey where nobody is following you.

It is not about listening or not, it is about what to do with all the things you have learned from listening. And that is integration. The best feature is worth nothing when not integrated properly. When we read a feature request, we don’t think about doing it or not doing it. After all, if software development is not about satisfying users, then what is it? We are thinking about how we could nicely integrate it with the rest of the application without diluting its identity.

Of course, as an open project, we’ve sort of given up the element of surprise.

One of the project goals has been to experiment with involving users, developers, and other interested parties throughout the design process, making design decisions in conversations on public mailing lists. During that process it can be tempting to use “what the user has asked for” as an objective criteria for making decisions. The quote above does a nice job articulating that doing so can be dangerous for the integrity of a design, without writing off the importance of paying attention to what users are saying.

Mimi did a writeup on OSAF’s open design process last summer in preparation for a presentation she did with Ted Leung at OSCON. She goes into some detail describing how we manage conversations and make design decisions in a way that tries to preserve both the “gestalt” of the design as well as the continued interest of developers who might be pursing individual passions and concerns. Getting this process right continues to be one of the more interesting challenges of the project.

In refining our product message, one question we want to answer well is: What kind of information does Chandler help you manage?

The short answer: Chandler helps you manage all the notes you write to yourself.

The long answer: Chandler helps you Collect, Share and Follow-through all the “stuff” you:

• Email yourself,
• Scribble on napkins,
• Stick in random text files and electronic sticky notes, and
• Put down in paper notebooks.

“Stuff” includes anything from ideas you need to develop and questions you need to follow-up on to things you forgot to do, things you can’t forget to do, meetings, appointments and the odd flash of revelatory inspiration.

In short, your day-to-day life is overflowing with ideas, thoughts and questions you need to Develop, Follow-up on and Get back to and you don’t have a good way to manage it all.

Traditional task managers are too rigid. But you need something more structured than your paper notebook.

Also, almost everything you do involves other people and you find that just managing the communications about what you’re doing as a group is a second job in an of itself.

Some more specific examples:

1. You come out of a meeting with a dozen new “things” to “research” and “think about”. You’ve scribbled them into your notebook. But now you don’t have a good way to develop and track those things as you make progress on them: Follow up with X about Y. Where do you keep track of what X tells you about Y while you figure out what it is you need to do with Y?

2. Pulling a meeting agenda together always generates an algae bloom of email. Once everyone’s input has been gathered and re-gathered over email, you’re the one that has to do the work of collating everybody’s responses.

3. You keep making the same lists all the time and every time, you forget something that you would’ve remembered if you had seen the last list you’d made. But you don’t have a good way to manage all these lists! e.g. Travel packing lists, grocery list, present ideas, thank you notes.

4. When working on drafts with others: Write-ups, status reports, proposals etc., you’re always torn between just sending out what you’ve got so far or wait a little longer. In the meantime, everyone else is unaware of the work you’ve done and working blind.

5. You tried sharing a calendar with others, but you’re the only one who ever looks at it! Whenever you add or change something, you end up having to send email out to get people’s attention anyway. The same thing happens when you try to collaborate on tasks or brainstorming ideas with a wiki. In the end, you always go back to using email.

Why is “What kind of information does Chandler help you manage?” a tricky question to answer?

In a previous post, I talked about using the phrase “personal information manager” to describe Chandler. Taken literally, yes, Chandler is a variant of personal information manager. But, using the PIM label confuses people in the software industry because it’s associated with specific software products that Chandler does not resemble.

The general population doesn’t have such specific product associations, so they might take PIM at face-value. However, the phrase “personal information” is now understood in the vernacular as shorthand for “information about me” (e.g. name, address, social security number, bank accounts, health records, etc.) This is especially true amongst computer-literate, white-collar workers, aka, our target audience.

In case there was any confusion, Chandler is not optimized to manage “information about me”.

Going forward, our task is to re-craft our product message with this in mind, both so we attract the users Chandler was designed for and we set expectations for new users trying out Chandler for the first time.

We often get the question: Is Chandler first and foremost a personal information manager or a collaboration tool?

The latter has groupware connotations we don’t want.

The former makes some people think of Outlook and then begs the question: Why don’t you have Contacts? Why aren’t you an email client?

At the end of the day, Chandler is first and foremost a personal information manager. Not in the way the software industry understands the phrase (Email, Scheduling, Calendar, and Contacts Suite), but in the civilian English sense of the phrase; you put information that is personal in Chandler and it helps you manage it.

(We may yet shy away from using “Personal Information Manager” as a way to market the product, but I find it helpful to think about what Chandler is in terms of the “plain” English meaning of the phrase.)

However, today, no personal information management tool is effective unless it has collaboration baked into its core. For “traditional” PIMs, collaboration means email plus scheduling.

For Chandler, collaboration means full-on, read-write, equal-access sharing. Chandler is for full-time, high-bandwidth collaborators; people who are working so closely together that email and traditional scheduling with it’s formal, moderated process of accepting and declining invitations feels like too much overhead and not enough bandwidth for true collaboration on ideas, goals, open issues and decisions.

Takeaway: Chandler is for personal use and it is effective for personal use because it is an individual-centered way to collaborate intensively with others.

We’ve decided to remove the notion of Task entirely from Chandler and add the notion of a ‘Star’.

The Star isn’t so much a replacement for Tasks. Tasks are nouns, they are a Kind of item, like Notes, Messages and Events. By contrast, the Star is simply an adjective, a *way to describe* Note, Message and Event items, similar to Triage Status. Below is a discussion of how we arrived at this decision.

One of the more common pieces of feedback we get from users who use Chandler daily is:

I have trouble figuring out how to use the ‘Add to Task list’ button at the top of the item details. I take this to mean: I have trouble figuring out when to call something a Task.

This dilemma is a reflection of how information work has evolved. More and more, the distinction between a task or todo and the substance of the task itself (ideas, thinking, writing) has becoming increasingly blurred and it’s unclear that it helps people to expend a lot of energy drawing that distinction.

I believe this is why for many people, text files, outliners, paper notebooks and email are generally preferred over more structure task / project management tools. None of these things require you to decide what’s a task and what’s a thought *about* a task.

If you want to maintain a list of “Ideas for new charter for company blog”, is that just a note-to-self? Or is it a task? It depends on how you choose to frame it: “Brainstorm ideas for new charter for company blog” (Task) or “Ideas for new charter for company blog” (Note).

What about “Write up proposal for new charter for company blog” versus “Proposal for new charter for company blog” The first is a task. The second is the substance of the task: the proposal itself. At the end of the day, both amount to the same thing.

For more details about what this conceptual change means for the user interface, see:

• Chandler-Dev list proposal for a ‘Pared down UI’
• Bug 11771 to change the Task Stamp to the Star Stamp.

Over the past 2 weeks, we’ve been plugging away at a
Work Queue for Chandler Desktop. By we, I mean Grant.

The thinking behind the work queue is to isolate the half-dozen or so usability issues we feel are the biggest blockers to new users understanding what Chandler is, and how to set about using it. In that sense, the bugs in the Work Queue are not necessarily the most egregious bugs. For example, several serious crash bugs and the false-positive pop-to-NOW bugs were omitted from the list. They are also not necessarily the most ‘oft-requested’ features from our current users. For example, the ability to spawn sub-tasks, aka clusters and Print were omitted from the list.

Instead the focus is to remove the hurdles that all users run into within 30 seconds of downloading and launching the application. Many of the hurdles are conceptual. I’ve sent a number of messages to the Chandler-Dev list dissecting these conceptual barriers:

• Pared down Desktop UI – Part 1
• Next Usability Hurdle: Answering the question: What should an item be?

1. New users are confused by the abundance of email functionality in the user interface. Is Chandler meant to replace your email application or not?
2. New users are confused by what genre / category of software Chandler falls into. Is Chandler meant to replace Outlook? Apple iCal? My journal / notebook? Email, Tasks and Calendar functionality makes Chandler look like a traditional PIM. But there’s a lot of missing functionality typically associated with PIMS (e.g. contacts, full-blown support for email, scheduling, etc). You could also *try* to understand Chandler as a super-duper Task Manager, but again, there’s a lot of missing functionality typically associated with robust Task Managers (e.g. dependencies, assignees, %done, milestones, etc).
3. New users don’t understand what an ‘item’ is supposed to be, as a result, they have difficulty getting started putting data into Chandler. It’s not that mechanisms for creating new items are hard to learn. It’s that the concept of an ‘item’ is too abstract. When faced with the question: Do you have any items to put into Chandler, many users simply go blank.
4. New users have trouble understanding Chandler’s mental model for sharing. In particular, there appears to be a lot of cognitive hoops to jump through just to get your data up on Chandler Hub. This problem can be entirely addressed from the Desktop side. I’ve started a separate thread on establishing a similar Work Queue for the Chandler Hub UI.

We are addressing these issues by:

1. Doing a better job of introducing the product to new users (e.g. better demos; better, more accessible quick start guide);
2. Smoothing out crucial workflows (e.g. guiding users through sharing set-up);
3. Simplifying the user interface, removing concepts that might mislead users into thinking Chandler is a PIM / Task Manager when it’s not (e.g. removing superfluous email buttons from the toolbar; removing the concept of a task);
4. Tweaking Chandler concepts to be more immediately understandable (e.g. changing the concept of an item to a note; changing the task stamp into a star stamp – I will be posting a more in-depth discussion of this issue);
5. Doing a better job of communicating Chandler’s core value through the user interface (e.g. improving the Notes field in the item details to encourage users to think of Chandler as *the* destination for dumping ideas, stray thoughts and questions; providing visual feedback when a shared collection has unread edits to showcase the power of Chandler’s collaboration workflows.

That being said, it is still important for us to keep track of critical bugs, bugs getting in the way of day-to-day usage and features that would greatly enhance the Chandler experience for current users.

I’ve included a list of these bugs and feature requests at the bottom of the Work Queue. If any of these are expedient to take on and/or we end up with extra time on the Desktop side before we’re ready to declare 1.0 for the project as a whole, it would certainly be worthwhile to tackle some of these bugs.

There is also the larger issue of performance, in particular start-up time. There isn’t a lot we can do in the short-term to address performance. We *have been* working on a rearchitecture project that would address many of the performance problems people run into today, but a completely re-architected Chandler Desktop is not going to emerge in the next 3-6 months.

I *can say* that we hope to alleviate some of the pain caused by slow start-up time with strategically placed web widgets. For example, we hope to deliver a Quick Entry web widget in the next month or so that would allow users to quickly get ideas and notes into Chandler via Chandler Hub without having to fire up the Desktop app. These are the kinds of things we can realistically accomplish in the next few months.

In the meantime, our first and foremost priority is to turn the Chandler Desktop interface into an effective communicator of what it’s useful for and how it’s useful.