[Brian]

RE: the screencasts - In general, we use the standard cocoa interface elements whenever possible. We didn't just replace them because we felt like it.

The OmniFocus 1.0 interface is an attempt on our part to keep compatibility for 10.4 users. Once we go to OmniFocus 2, and can go leopard-only, we have a lot more options. (Core Animation, for example, which would let us do more to reduce the flashy you didn't like.)

We do the 'flashy stuff' on hover because during the beta we got feedback from folks that *didn't* know they could click there. I'm sorry it's distracting to you, but the stuff that's 'obvious' to you really isn't obvious to everyone. Remember, you're a pretty experienced mac user - we have to design for folks like you, and for folks that are sitting down to the mac for the first time.

Re: smart match boxes - you didn't get a scroll bar because we're showing all the smart matches that are available - if we're showing everything, you don't need one. We're not using pop-up menus like in the inspectors because you can't type new items into those. (You should be comparing this behavior with the address bar in safari, in other words - it doesn't track mouse events, either.)

The escape key is *supposed* to work there, though. It looks like using the arrow keys causes a bug though, producing the behavior you saw. I'm writing that up. I have no idea how we (and 20k beta users) never noticed that over the last year or so, but there you go. Are you available for contract work? ;-)

The calendar widget actually *is* the standard cocoa calendar control - the failure to escape cleanly is a bug in cocoa, not a bug in our code.

Similarly, the complaint you're making about sidebar selection vs. main content window selection is a general cocoa complaint. If you click in dead space on either side of the divider in Mail.app on 10.5, you'll have the same problem. (If you click *on something* in either app, of course, then there is visual indication of where the selection is.)

I'm personally not a fan of the window-widening behavior, but I can tell you it was implemented in preference to having a horizontal scroll bar in OmniFocus windows.

Double-clicks on disclosure triangles: If you click, pause, then click again, Cocoa sends us two click events. We open, then close (or close, then open) the item you clicked on.

However, if you click twice, and do so faster than your system 'double-click speed' preference is set to, we get a single 'double-click' event from the system. We respond to that by opening the new window.

The beeps are a little mysterious. I'm guessing that's some debug code - it only happens when I click at a very specific speed. Click slower, we open/close. Click faster, we open a new window. Again, not sure how we missed it, but so did over 20k beta users, for what that's worth.

Click to the left of the disclosure triangle and you'll get selection instead of dragging. Click on the drag handle, and you'll get dragging. I see your point there, but at the same time, fitting 'select nothing', 'select-and-start-dragging', and 'drag-select' into 30-ish pixels is a tall order. The other option is to take room away from your actual content for a bunch of mouse-specific controls that differentiate between the three behaviors.