Usability Nightmares

37Signals apps are very mellow, visually appealing, but as one commenter on that post said: “most logical, usable on the planet”? That’s a bit of a stretch.

Campfire is an easy example. We wanted to try it out for coordinating the dev team on a project. I added a couple guys who didn’t have Basecamp logins yet. Then I had to jump through hoops giving them access. Then once we got access we quickly hit a 4 user limit for the chatroom. I closed the wrong window, and when I tried to get back into the room, it said it was full instead of kicking my orphaned login.

In the end we just created an IRC channel. Sure it’s lacking a few things, but it offers a few of it’s own as well, and at least we could hop right in and start getting things done.

I waited impatiently at my ASP-Classic/.NET job for the day I could join a Rails shop and start using Basecamp instead of the nightmare of a ticket-system that was developed in-house with (seriously) 50+ fields for a ticket.

Unfortunately, the shiny glow left Basecamp after a couple weeks of usage. It’s pretty simple, but can you search for content? Can you page through history in the overview if you were out of the office a couple days and need to catch up? Can you comment tasks? Is there even simple Textile formatting on tasks?

No. No. No. No.

So you have a work-flow/collaboration tool that’s lacking any kind of actual collaboration (outside of Writeboards anyways). Instead you have a bunch of messages and comments interspersed with random tasks created or closed with no cohesive threading to make on-going conversations easy to consume.

Hell, if it’s about “embracing constraints”, your average forum-system is probably a better collaborative tool than Basecamp.

That’s just my disillusioned perspective.

This extends to Rails. Not that I’m at all disillusioned with Ruby mind you. And Rails is a bunch of truly great ideas. But it’s wrapped up in a sloppy implementation. Thankfully we have frameworks like Merb with all the goodness of Rails, but with less magic, code you can actually read, accessible/helpful maintainers who trust the feedback they get from the community isn’t arbitrary and worthless.

Hey, it’s been a long week… I should be allowed a little rant now and again.

@Ben:

“put stuff” agreed. But can you really say pagination, search and formatting really falls into that category?

I certainly don’t condone 50 fields. That was an example of what *not* to do. Lighthouse has a Title, Description, Assigned-Users, Assigned-Milestone, and Tags fields. Nearly perfect aside from a missing Priority drop-down.

The whole “Embrace Constraints” argument strikes me as anti-Agile. I don’t get to tell my clients that they just need to figure out how to use the systems we deliver in the way we intended.

Regarding formatting, I could swear tasks or messages (one or the other) didn’t format as expected and I had to use BR tags to get them to line-break, but that was 6 months ago, so maybe things have improved.

APIs are nice, but frankly, I’m not going to sit down and try to figure that out. Just isn’t going to happen. Sorry. Things always take longer than “an hour”, and there’s always more important things to do on our own projects, nevermind developing work arounds for arbitrary lines drawn in the sand in a product we pay for. It’s offensive frankly.

So we use Lighthouse now. It’s much better suited to a developer’s work-flow. It’s annoying that it lacks priorities though. Let show you how “embracing constraints” breaks down:

The Lighthouse dev’s suggestion for replacing a simple priority drop-down is Tags such as “priority”, “low”, etc.

You can’t sort by the tags. They don’t display in a ticket-list. If you have typos you’ll have “priorty” and “priority” display in your tag-lists. There’s no visual cue for the developers to tell them which ticket is most important. There’s not even a simple number assigned to the ticket.

Because the Lighthouse devs don’t care about priorities, they suppose I don’t really _need_ it. They’re wrong. Because they won’t support them, when the pressure is on, we don’t use the tickets at all. Which is unfortunate. It makes project overview and lessons-learned more difficult. It makes miscommunication more likely.

When things are going well, Lighthouse is great. But because it’s difficult for my team to determine my priorities without constant feedback from me (which is exhausting), Lighthouse contributes to time wasted and putting us back into a situation when things aren’t going so well.

It’s a vicious cycle.

You might get the impression I’m not a fan of Lighthouse. Couldn’t be further from the truth. It’s the best ticket system I’ve ever used or seen. It’s just that the “Embracing Constraints” philosophy is just plain bad service, and it allows people who aren’t in the best position to determine value (developers aren’t known to be great at that) make decisions that negatively impact their clients.

“Embracing Constraints” is a cop-out. It’s a shift in responsibility. Instead of delivering the most value, developers are able to draw petty lines in the sand instead and claim they’re embracing constraints. It’s one of the most damaging things to happen to the developer community in years, right up there with syntatic-vinegar. Instead of measurable artifacts based on delivering value such as Agile, it’s rooted in developer ego and arrogance.