It's always a tough call in these situations whether the improvement is worth all the work (and the time spent away from other, bigger issues). Zooming out a little, though, it's hard to imagine how you could develop a well-designed, elegant product without occasionally pulling your hair out over little things. It's just nice knowing that other people go through the same thing.

>And we ended up writing our own very faux-toolbar from scratch.

It SHOULDN'T be a tough call in a situation like this. There shouldn't even be a call to make. I literally got goosebumps when I read that paragraph in the article.

This is a textbook example of goldplating. No, actually... this goes beyond goldplating. It's goldplating combined with reinventing the wheel.

There is NO WAY the extra effort this requires will be worth it. The initial effort to implement it - maybe. The initial effort plus the extra effort to maintain their own faux-toolbar - no way. I'm willing to bet that in version 2 - or at most version 3 - it will be replaced with a standard toolbar.

What happened to KISS? Like I've said in another post - if something is getting more and more complicated as you work on it, it's time to backtrack because there's a good chance that you're doing it wrong.

I'm happy that the designer got nice-looking buttons, but I think the rest of the team dropped the ball on this one by allowing it. I'm not usually this vehement about something, but there's no conceivable way I can be convinced that this was the right decision.

i am inclined to agree with you, but. panic is a well-respected software developer, and they make really good user interfaces. i was at apple's wwdc this year, and in one session, a guy from apple put the icon from coda up onscreen, as an example of how to do things right. so i kind of have to give them the benefit of the doubt.

It's a shame I can only vote you up once. I agree 100%. The old "if this concerns you, you're done - ship it" doesn't really cover what's going on here.

If this was the most attractive potential feature from an ROI perspective, you're not just done, you sold the company years ago and you're sitting on the beach sipping cocktails, thinking up crazy side projects with the sole purpose of reassuring yourself how pitiful the burn rate is compared to the interest on your vast piles of cash.

I've got to disagree here. Touches like this are what elevate software from merely functional to great.

Maniacal attention to detail is what separates the great from the merely good enough. Examples? Dyson vacuum cleaners, the original Macintosh, the iPod, probably any product you really like.

The thing about effort like this is that the few days of extra time invested will be shared by every user of the finished product.

I'm not saying it's a bad idea because it's too much attention to detail. I'm saying it's a bad idea because it's misplaced. They're talking about taking considerable effort to reskin a standard OS GUI component here - they are standard for a _reason_. I would consider this not just wasted effort, but a negative, if I found it in any of the applications I use day to day.

I'm 100% for maniacal devotion to attention to detail. I live it and breathe it in the games I make. I don't tolerate a single frame of object behaviour being out of place. But you've got to focus it in the right place, and that's what I'm saying is the problem with doing something like this - there are just too many improvements that you could be working on that your users will find much more helpful. I've definitely been too fanatical about what I wanted versus what my users have wanted in the past.

That said, the app in question won a user experience award at the Apple Design Awards, so maybe they're right and I'm wrong. They can certainly make amazing software. But even with that in mind, I stand by what I'm saying.

Frankly, even if the improvement is worth the work, I think this is the wrong kind of work. Writing a custom toolbar (that doesn't, according to the article, work the same as all the other toolbars the user is used to seeing) seems like the wrong call. Better to alter the design to be (a.) spiffy and (b.) compatible with the technical limitations of the system.

I think it's often better to work within the constraints of a system than to fight against them. Sometimes, of course, it's a Big Win to fight them, and sometimes it's fun, but you gotta pick those battles. (As I'm sure everyone agrees. Sounds like Hamming's talk, in a different context, actually.)

Very true. Spending a lot of time getting the toolbar to look great is good. Doing that by tossing out the system toolbar and hacking together your own is very questionable, though.

The link they put in at the bottom suggests that Leopard might adopt their selection style. Gruber linked to it, citing it as a situation where some good can come of a company's bucking a standard. So it turned out well, if only by luck.

I doubt it took 'forever' to create; I interpreted the article to mean it was low on the priority list, not hard to do. Drawing the custom toolbar was likely as straight-forward as it gets.

First, in the desktop programming world, where you may only have about a dozen gadgets to choose from, you must extend a control, use a third-party control, or draw your own. This wasn't about three pixels, this was about making the program look the way the designer intended it to. There is more to programming than just adding features and avoiding bugs.

If you're a startup, you must focus on programming. If you have customers with high expectations and need to make nice screenshots to impress Mac enthusiasts, you should make the software look as special as you can.