Friday, January 11, 2008

Mitch Kapor's Weekend at Bernie's

My last post on Chandler somehow just really doesn't capture the flavor of watching the Chandler design mailing list. It has been like watching a train wreck in slow motion after having had a sip of Scalosian water. Indeed it was incredible to me that so much could be invested with so little resulting usable value.

Hey Mitch, are you watching this?

As background, Chandler is an open source project, and so it has mailing lists. And though there is a corporate office, I get the feeling that most of the discussion between the employees happens through the mailing lists. I never saw Mitch post anything to the lists. I'm not saying that he didn't, and certainly I was not always watching, but I never saw it. And so I kept thinking to myself, isn't there some adult I can call and tell what is going on? I always had this urge to drop Mitch a line and say "hey dude, are you watching this s**t?"

He (me) said

From a practical perspective, perhaps my biggest beef was that the Chandler design team had an apparent lack of understanding of a *really* basic user interface principle.

To encapsulate, what I said on the mailing list was this:
The interface designer's critical task is to support and reinforce the user's understanding of the data model.

The essence of my point is you need to be able to visualize the model of the system, which is the only way a user can predict outcomes of the actions he/she takes.

She said

The Chandler interface design lead responded. Because I don't want this to be personal I will refer to her as DL. DL responded to that statement with the following:
Thank you Hank for articulating this. I think this may be at the core of issues you are running into. [Note: *its my* issue]

In my mind, the purpose of design is to understand how people work (which goes hand in hand with figuring out what problem it is you want to solve). 'How people work', the problems they run into and pain points they have in turn drives how the software should function. Usability (which I think of as conceptually distinct, though in practice, hopelessly intertwined with design) is the work of re-presenting how the software works to the user in a way they will recognize as helping them. In other words, usability is the 'language' by which the intent of the design is communicated to the user.

Another way to think about it is: The difference between design and usability as the difference between 'use-ful' and 'usable'. Useful is about getting the workflows right and anticipating user needs. Usable is about making it easy for people to figure out how to get the most out of the hopefully 'useful' product.

More often than not, aiming for 'useful' results in concepts and functionality that are 'ambiguous' and 'inconsistent' in the way it works. [Note: you certainly acheived your goal] I believe this is because user workflows are complicated and full of exceptions. Surprisingly and fortunately however, workflows are often twisted and gnarly in highly consistent ways.[Note: WTF] In the end, I think it boils down to how you're looking at the problem: From the perspective of trying to understanding the inner workings of the tool; or from the perspective of trying to understand the workflows.

Excuse me, but I *am* going to inhale

First of all, if you understand what DL means I need a hit of whatever you are smokin'. Well ok, after much review I was able to tease out two points.
  1. I *think* she thinks you can freakin have useful without usable!!!
  2. She doesn't believe that it is important that the user have a model of the system in his/her head. Instead you can just worry about "workflows" whatever the f**k that means. This is, well, honestly, insane. But don't just believe me. One of the most interesting articles on this issue for a more learned perspective check out Bruce Tognazzini's views on this.
Can anyone tell me what that menu over there does?

Think of it this way. If you have a tool and you can't predict what the behavior of that tool will be, it will *never* be useful.

I couldn't believe she couldn't understand or didn't believe this. And so I issued a challenge to the entire OSAF team. I challenged anyone to explain to me what the "View" menu did.

No takers. It's so complicated even the designers couldn't explain it.

I made the challenge again on the list because I thought maybe in the email melee my challenge had been missed. Still, no takers. Once again I raised it in a private email with one of the engineers.

No one ever responded directly though I did have a conversation with another engineer who agreed that it was nearly impossible to understand what the view menu did. I understand from other sources that the code that drives the view commands is incredibly hard even for the programmers themselves to follow the logic. That oughta be a clue.

Ok, I just have to say it again because it is so hard to believe: NO ONE COULD EXPLAIN WHAT THE CHANDLER'S VIEW MENU DOES!!!!

Weekend at Bernie's indeed

If you let the fact that no one could explain a core menu bar function sink in, you might get a clue as to why, despite what had to be 10 to 20 million dollars of Mitch's money invested, Chandler still, well, sucked.

And so, the ten Chandler team members remaining will work one more year until the last of the cash runs out. They have propped up Chandler's dead body, put some sunglasses on it, doused it with some Axe body spray/cologne, seated it in the living room, and are pretending that they are all not sitting around the, um... dearly departed.

Now *that* must suck.


  1. Disclaimer: I've worked on Chandler.

    I think you are being overly negative, but rather than repeating my comments you may want to check out my response on Robert Accettura's blog.

    I'll address the additional points here.

    Mitch was very much involved in the day to day operations and design and management of Chandler when I joined in 2003. Early on most discussions happened in face-to-face meetings, so you won't see that many posts by Mitch. But he has participated on the lists as well, for example here.

    Chandler has a UI designer. Not many open source projects do. My experience of UI designers is that they have a vision, and are going to take the project to that direction no matter what. On one hand this kind of attitude can be good if the vision is correct, otherwise... Firefox also happened because of strong vision, and it splintered the project into Firefox and Seamonkey - but most people have adapted to Firefox, even if they have issues with it.

    I think Chandler has some cool UI ideas, but there is also a lot that I don't agree with. Some of my early objections were about features that use non-standard UI components, which makes development and maintenance harder and in my opinion only buys a little eye candy. But then again, I am not a UI designer, so I am not sure how much weight you'd put on my opinions.

  2. Heikki,

    Thanks for the comments. I appreciate them. I was really not trying to say that Mitch wasn't involved, but just that I didn't see his presence (particularly later) and so it made me want to tell him what was going on. It was hard to believe with proper supervision, that some of these decisions would be made. But obviously since I wasn't there I would not have the scoop on that.

    It is good that chandler had a UI designer. Its unfortunate that she was not more learned in her craft. It made because she made some horrific mistakes.

    Regarding eye candy, its great, but its really all about getting the logic, and the model down, and really figuring out who the target is. You cant build the product and then figure out who it might be for. Pretty buttons don't help if users dont know what to do with them.

  3. LOL!!! Love the Trek reference!

  4. Great column. I tried using Chandler and find the interface klunky, with little bits of inspiration sprinkled about. I decided it didn't work the way I needed it to for tracking my personal and professional responsibilities. I can't imagine how they could spend so much time and money (especially with open source help) and never actually deliver a V1.0 product! I'll stick with my PalmPilot, thanks!

  5. Thanks for the insight and the laughs! Plus the Tog link.

    Having an interest in PIMs, Python, and open source, I too have been following Chandler off and on for years. But each time I downloaded a release, I found Chandler too buggy and baroque to bother with. When I checked the mailing lists, it seemed the discussions were mired in jargony grail quests for the ultimate workflow paradigm.

    For myself, I use myLifeOrganized which is based on David Allen's Getting Things Done and is oriented towards solo, not collaborative, use.


Note: Only a member of this blog may post a comment.