[Toadling]

I saw the article and screencasts this morning as well. And I must say that, for the most part, I agree with the author. Particularly, this passage, while perhaps a bit too harsh, rings mostly true:

Much of OmniFocus's interface is non-standard. Instead of using standard Cocoa "widgets" within the window, the Omni folks, for no reason that I can see, have invented their own - and they don't work very well. The result, for me, is that the interface is largely unpredictable, intransigent, or annoying.

Personally, I'd like to see more standard behaviors where possible. On the other hand, I haven't had too much difficulty in adapting to OmniFocus' idiosyncrasies. Still, I look forward to future UI refinements.

Here are some of my other issues with the article (sorry for the long post):

Alas, some actions ("try to take over the world") are worthy but not currently feasible. I'd like a place to put such actions, so they are off my mind but still, somehow, on my plate. Thinking Rock lets me move such actions into simple lists of "future items" and "information items"; OmniFocus doesn't. I tried creating an "Unfeasible" project; but its actions showed up inappropriately among do-able actions. My workaround is to mark the "Unfeasible" project as being "On Hold".

I don't see the "On Hold" state as a "workaround", but rather as a more elegant solution for marking items as someday/maybe. It's far more flexible than some kind of static container where you dump future or unfeasible projects. By only changing the project's status label, it can remain in its original organizational structure, where it makes the most sense. That's extremely useful, and would be entirely lost if OmniFocus required you to drag the item off to some separate container.

To me, actions in the Inbox are actions; but OmniFocus doesn't agree. For example, I might assign an Inbox action a context, but then leave it untouched, uncertain what more to do with it. In Context mode, such an action is not displayed at all. That seems wrong, somehow.

I strongly disagree here. Anything in the Inbox is unprocessed, meaning it's not ready to be acted upon. Having Inbox items show up in context view pollutes your list of truly actionable items. If you've processed items in the inbox, assigning context/project as necessary, just hit the clean up button to see the items in context mode. That seems perfectly logical to me.

So, then, wouldn't you expect that when you've checked off all actions in a group, the group would automatically be checked, and that when you've checked off all groups and actions in a project, the project would automatically be marked Complete? Well, neither of those things happens.

As with many other topics in the review, this one has been debated ad infinitum on this forum. I can understand why some people desire this approach, but Omni's position makes more sense: just because a project has no more actions does not mean it's complete. Instead of assuming the project is done and trying to think for the user, OmniFocus should provide the means for the user to review the project to determine if anything further should be added or if it is indeed completed. Maybe this process needs to be made more transparent and accessible, but for the most part it's already there today.

There is no way to find groups or projects all of whose actions are completed, so how on earth are you supposed to know?

Contrary to the author's claims, there is a way: filtering on stalled projects. Unfortunately, that doesn't help with action groups, but it's a solution that handles the more serious issue of dealing with incomplete projects.

As for action groups, I'm still thinking the best approach would be to make the action group name become the next action once all of it's contents have been checked off. That way it would show up in context view. I guess you would then need to be able to assign a context to the action group as well, but maybe that's not such a bad thing.