Howdy,
I'd like to add some more about why we made the UI decisions we did for the controls in the main content area.
The reason the cells light up as you mouse over them is because we want to make it clear exactly where the cells are for the row you're interested in. The article claims that the column header is all that's necessary to find the cell you want, but we'd actually have to add a grid, and require the column titles to be visible all the time, in order to make every cell's position pinpointable. Those are both things that we thought would detract from the focus on the content that is necessary for an app we expect you to look at dozens of times a day, every day of your life. Personally, I'd like the controls to fade in after a fraction of a second, but we probably wouldn't do that until we're on CoreAnimation.
As for why we didn't use standard Cocoa controls in the content area, it's because it's a content area. A few controls carefully arranged on a preference pane, inspector, or sheet look fine. But those heavy Aqua controls stacked up among arbitrary amounts of user data can get pretty ghastly. And nobody expects Aqua controls to appear and disappear based on something as transitory as selection, so only showing them for the selected items wouldn't work either. So we made our own flat-looking controls. The Smart Match cells already needed to be custom controls in order to do our string guessing anyway. Everywhere else that it's feasible, we do like to use standard Cocoa controls.
A lot of the points in the TidBITS article, such as letting the user know that the view is filtered, showing more information in the main outline, and improving the way our completion cells work, are things we're already working on for future versions of OmniFocus. I think we've done a good job for version 1.0, and I'm really excited for how much better we can do in version 2.0.
I'd like to add some more about why we made the UI decisions we did for the controls in the main content area.
The reason the cells light up as you mouse over them is because we want to make it clear exactly where the cells are for the row you're interested in. The article claims that the column header is all that's necessary to find the cell you want, but we'd actually have to add a grid, and require the column titles to be visible all the time, in order to make every cell's position pinpointable. Those are both things that we thought would detract from the focus on the content that is necessary for an app we expect you to look at dozens of times a day, every day of your life. Personally, I'd like the controls to fade in after a fraction of a second, but we probably wouldn't do that until we're on CoreAnimation.
As for why we didn't use standard Cocoa controls in the content area, it's because it's a content area. A few controls carefully arranged on a preference pane, inspector, or sheet look fine. But those heavy Aqua controls stacked up among arbitrary amounts of user data can get pretty ghastly. And nobody expects Aqua controls to appear and disappear based on something as transitory as selection, so only showing them for the selected items wouldn't work either. So we made our own flat-looking controls. The Smart Match cells already needed to be custom controls in order to do our string guessing anyway. Everywhere else that it's feasible, we do like to use standard Cocoa controls.
A lot of the points in the TidBITS article, such as letting the user know that the view is filtered, showing more information in the main outline, and improving the way our completion cells work, are things we're already working on for future versions of OmniFocus. I think we've done a good job for version 1.0, and I'm really excited for how much better we can do in version 2.0.
Threaded Mode