The Omni Group
These forums are now read-only. Please visit our new forums to participate in discussion. A new account will be required to post in the new forums. For more info on the switch, see this post. Thank you!

Go Back   The Omni Group Forums > OmniFocus > OmniFocus 1 for Mac
FAQ Members List Calendar Search Today's Posts Mark Forums Read

 
OmniFocus review/critique from TidBITS Thread Tools Search this Thread Display Modes
Article here:

http://db.tidbits.com/article/9594

I agree with the following critiques:

- No "Date completed" column
- No way to identify repeating actions without looking at inspector
- UI frustrations (see screencast here)

I also agree with his assessment that OmniFocus is still the best GTD tool available for Mac.

Would be interested to see what others think.
 
Good lord they make it tough to actually email them - I really want to tell the author how to show the start and due dates in the main app window, but I can't for the life of me find a way to email them or comment on the article. :-/

Much of the other stuff he's bothered by is stuff we want to improve as we continue work on the app.
 
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:

Quote:
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):

Quote:
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.

Quote:
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.

Quote:
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.

Quote:
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.

Last edited by Toadling; 2008-05-01 at 12:07 PM..
 
Here's the response I ended up sending, split into two posts due to size.

Thanks very much for the review! I had a couple thoughts, wanted to offer a bit of help, and had a few corrections.

Quote:
unfortunately, there is no outline column for the completion date, which means that you can't easily learn what actions you completed on a certain date.
We've got a feature request open on this - I'll add you to the list of users that would like to see it added.

Quote:
when you check off a repeating action as completed, it simply reappears unchecked, ready for the next repetition, and unless you consult the inspector, you don't understand why.

One thing that might make OmniFocus make a bit more sense with respect to repeating actions:
Select View -> Columns -> Start Date (and/or Due Date)
that'll add the respective columns to the content outline. Now when you complete an action, you'll see the next one appear, but at least the dates will be different.

We were worried about folks finding the app too visually confusing when they first started it up. I think we may have overcompensated for that, though, and are hiding some things that would actually be useful.

Quote:
After years of futility, Omni finally did what they should have done all along: they hired Ethan to write a full-fledged GTD application
I would question the 'futility' bit - it's not like Ethan sent us a resume on day one, and until we saw the size of the response to kGTD, it wasn't obvious that there was support for a full-fledged app there. You have an engaging writing style, but just because something is obvious in hindsight doesn't mean it was always obvious.

One additional correction: we brought Ethan on board, but in Marketing - he's not actually a developer on OmniFocus.

Quote:
unfortunately, there is no outline column for the completion date, which means that you can't easily learn what actions you completed on a certain date. Even worse, there is no indication in the outline that a repeating action is repeating;
Completion date column, and visual indication of repeating tasks are both on our feature request list, as well. Adding votes for those features on your behalf.

Quote:
some sort of reminder alert system
We actually support Growl, so if you have that installed, you'll get notifications when your actions become available/overdue, etc.

Quote:
OmniFocus can sync with iCal, but actions become iCal To Do Items, not Events, so they don't appear on iCal's calendar; syncing is thus fairly pointless.
We don't sync actions to iCal as events because we didn't think folks wanted an action that starts on Monday and ends on Friday to cover up their entire week. I'm waging a quiet campaign to get that changed in a future version, though. Thoughts about how you'd like this handled would be welcomed; I haven't used In Control.

Quote:
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".
Yep, this is our suggested solution for items like this - I'll double-check that we have a feature request open on adding at least one project in that state to the default configuration as a breadcrumb that it's possible. If we don't, I'll create one. Thanks!

Quote:
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.
This is a perfect example of why we behave the way we do, actually - we want to keep your context view full of items that you are sure what to do with, so you can spend time getting things done. We don't want to interrupt you with implicit 'figure out what I need to do with this' actions for the stuff in the inbox...

We wanted to give you the ability to work along in another app, have a thought, and stick it in quick entry without needing to fully think it through. If we treated items in the inbox the same as items in your projects, you could clutter up whatever project you're working on with half-thought-out notes.

This way, when you get to a good stopping point, you can come back to the inbox, fill out the rest of the info on your inbox items, clean up, and everything will show up where you want.

Quote:
For a parallel project, you see just the first action. (Why, if the actions are parallel?)
Re: next actions - according to David Allen, all projects have exactly 1 next action - that's why parallel projects behave that way. You discovered the workaround, but yeah, this does confuse folks at first. We're chewing it over; this pops up regularly on our user forums, so you're not alone in your thinking.

Quote:
But for a parallel group, you see all its actions. (Fine, but why this difference from a project?)
I'm not actually able to duplicate this behavior - we only show the first action in the group on my machine. If you're still seeing this, can you send me a screenshot or screencast so I can try to figure out what's going on? It sounds like a bug.

Quote:
I worry still more that users won't even realize they are viewing a filtered version of the outline.
Yep, this has definitely been proven to be a problem; we're chewing over this one, as well. Adding your suggestions to the item we have open on this in our development database.

Quote:
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?
Completing all the actions in a group or project doesn't automatically imply that the parent item is complete. There's an implicit last step there that we're enforcing - 'think about everything I've done and make sure it's actually done'. In addition to helping you *do* more, we want OmniFocus to help you *plan better*; that's the 'do regular reviews' bit that DA talks about.

Quote:
There is no way to find groups or projects all of whose actions are completed, so how on earth are you supposed to know?
View -> Sidebar Filter -> Stalled does what you're looking for here.

Quote:
But in that case, what's the point of having a computer? A pencil and a notebook would be a more helpful interface.
You can't sort pen and paper as easily as you can software data. Short of folding the page, you can't really filter all that well, either.

Quote:
After a moment of heart-stopping panic, I realize that for some inexplicable reason, Context mode has appeared with all the context headers collapsed
It can be a bit confusing, but it's something folks learn their way through. Given that we have to compute the state of the tree on the fly, defaulting to closed gives you much better performance, and still lets you drill down to the actions you care about. With a couple hundred actions visible in your context view, you'd have a different opinion if the app worked the other way. ;-)

Quote:
The online help is poorly presented, with inadequate navigation, and without "breadcrumbs" to show you where you are; the style is unnecessarily snarky ("click the kinda arrowy-looking button").
I'll definitely write up the suggestions for better navigation and breadcrumbs. We've had folks thank us for making the help content more approachable/entertaining to read; I'm sorry that came across as snarky to you. Other users disagree.
 
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.
 
I agreed with a lot of Matt's review and found the screencasts spot on and highly entertaining. Some of these things are things I've complained about on the fora or sent feedback about.

And as for the weird window-widening behavior, it's not true that the only alternative is a horizontal scrollbar. Mail.app doesn't have a horizontal scrollbar and it doesn't have OF's behavior.
 
Quote:
Originally Posted by Chris View Post
And as for the weird window-widening behavior, it's not true that the only alternative is a horizontal scrollbar.
Sorry - didn't mean for it to come across that way. True, there are other solutions. Though, personally, the way mail deals with it - not having a scroll bar, but letting you narrow your window until the columns are essentially useless - doesn't seem good, either.

We're also not the only app that makes the window wider - Finder does so in column mode, when you edit the rightmost column.

In geneal, we were trying to find a good solution to a common problem, and if feedback indicates that it's not a good solution we're certainly listening.

Last edited by Brian; 2008-05-01 at 04:23 PM..
 
I thought that the screencast was actually kind of unintentionally silly. Here's this grown man getting so upset over this application. I mean, take it a little more seriously please. Particularly ironic is when he's getting upset over this flashy behavior and saying, "obviously I would know where to click for the flag, the headings are right up here!", when the flag happens to be a particularly narrow column and it's not like there are a checkerboard of column guides.
 
Quote:
Originally Posted by Lucas View Post
I thought that the screencast was actually kind of unintentionally silly. Here's this grown man getting so upset over this application. I mean, take it a little more seriously please.
Sometimes I end up in this place too. It's a sign of passion and love for a program. You just can't get how they could do such, in your eyes obvious, UI-stupidity to that beautiful peace of software. Don't judge him to hard. ;)

And while I haven't thought about it thoroughly, I have to agree that there is a substantial kind of interface resistance then working with OmniFocus. For example the missing area highlight (sidebar/main view) and the collapse behavior or the little tiny triangles drive me crazy too.

Last edited by Schlaefer; 2008-05-01 at 08:54 PM..
 
Quote:
Originally Posted by Schlaefer View Post
For example the missing area highlight (sidebar/main view) and the collapse behavior or the little tiny triangles drive me crazy too.
I'm having a hard time imagining how this supposed sidebar/main view highlighting would look. I can't think of a single application where this is done. Like Brian stated above, this seems to be a missing feature in the Cocoa framework. Schlaefer, can you explain how it would look, or better yet, name an application where you've seen it done?

As for the collapse behavior of the disclosure triangles, I don't really have a problem with the current implementation. But then, I've used OmniOutliner for years, so maybe I'm just used to it. Anyway, I usually navigate using the keyboard, using right and left arrow to collapse/expand nodes.

There may be room for improvement, but a large part of Matt Neuburg's fuss over the triangles just doesn't seem like a real world issue. Who sits there toggling the node open and close over and over again like that? I mean other than Matt Neuburg and us, that is. :D

Last edited by Toadling; 2008-05-02 at 08:14 AM.. Reason: Fixed grammatical errors – must have been tired
 
 


Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes


Similar Threads
Thread Thread Starter Forum Replies Last Post
Review mode and how it changed the review process for me StevenMay Applying OmniFocus 1 2011-10-07 07:51 AM
OmniFocus Review (For iPhone) Nspa32 OmniFocus 1 for Mac 6 2011-06-12 01:14 AM
Review of "Creating Flow OmniFocus"? ajr OmniFocus 1 for Mac 7 2011-03-15 05:19 AM
Want Review Perspective showing just 'Review Today' djb21au OmniFocus 1 for Mac 7 2010-01-21 05:16 PM
Next review date not corresponding with grouping by next review Paul Hoadley OmniFocus 1 for Mac 2 2007-07-21 03:12 PM


All times are GMT -8. The time now is 02:53 AM.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2024, vBulletin Solutions, Inc.