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 s**t?
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.
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 here…lol] 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.
- I *think* she thinks you can freakin have useful without usable!!!
- 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.