OmniFocus review/critique from TidBITS

[dbyler]

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 (http://www.apeth.com/omnifocus/omnifocus.html))

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.

[Brian]

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.

[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.

[Brian]

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.

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.

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.

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.

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.

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.

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.

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!

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.

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.

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.

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.

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.

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.

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.

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. ;-)

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.

[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.

[Chris]

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.

[Brian]

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.

[Lucas]

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.

[Schlaefer]

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.

[Toadling]

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

[Bill Van Hecke]

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.

[Schlaefer]

I'm having a hard time imagining how this supposed sidebar/main view highlighting would look. I can't think a single application where this is done. Like Brian stated above, this seems to be a missing feature in the Cocoa framework. Can you explain how it would look, or better yet, name an example where you've seen it done?


From a quick glance it's hard to tell which area is active:

http://img.skitch.com/20080502-dr9d6ttj3dka7yj6fuxkqdjkkj.preview.jpg (http://skitch.com/schlaefer/kwhg/picture-2)Click for full size (http://skitch.com/schlaefer/kwhg/picture-2) - Uploaded with plasq (http://plasq.com)'s Skitch (http://skitch.com)

vs.

http://img.skitch.com/20080502-qyrs83pixaarbtr76f133yw532.preview.jpg (http://skitch.com/schlaefer/kwh8/picture-4)Click for full size (http://skitch.com/schlaefer/kwh8/picture-4) - Uploaded with plasq (http://plasq.com)'s Skitch (http://skitch.com)

So a good start would be to use the invers highlight in the sidebar when selected and active:

http://img.skitch.com/20080502-rsyjn9b9a39r23nny7bgybxni.preview.jpg (http://skitch.com/schlaefer/kwhk/sdf)Click for full size (http://skitch.com/schlaefer/kwhk/sdf) - Uploaded with plasq (http://plasq.com)'s Skitch (http://skitch.com)

<four image per posting limit, continue reading in next posting>

[Schlaefer]

The remaining problem is: what to do when nothing is selected (leaving out "selected but not visible") like this:

http://img.skitch.com/20080502-cs9inishng4htfsw848riwxgay.preview.jpg (http://skitch.com/schlaefer/kwhc/picture-1)Click for full size (http://skitch.com/schlaefer/kwhc/picture-1) - Uploaded with plasq (http://plasq.com)'s Skitch (http://skitch.com)

What happens when I hit ctrl+cmd+9 in this situation? It's Murphy's law in action.

At the moment I'm not aware of an application solving that issue in any way. But these applications unlike OF show nothing in the main view when nothing is selected in the sidebar, have a special root item for "everything" in the sidebar or don't allow to select nothing in the sidebar. That brings us to the question: do we need a sidebar with no item selected at all?

A visual clue I could think of would be a blueish halo around the active area when nothing is selected:

http://img.skitch.com/20080502-9it79fjegksqrxhua7swqnt7n.preview.jpg (http://skitch.com/schlaefer/kwh3/bluish)Click for full size (http://skitch.com/schlaefer/kwh3/bluish) - Uploaded with plasq (http://plasq.com)'s Skitch (http://skitch.com)


As for the collapse behavior of the disclosure triangles, I don't really have a problem with them. But then, I'd gotten used to them in OmniOutliner years before OmniFocus was even released. And usually, I navigate using the keyboard with right and left arrow of collapse/expand nodes. So maybe it's just a matter of familiarity.

The triangle itself is fine … but! ;)

I create a project and enter a name for it. After that most of the time I don't rename the project anymore but open and close it when reviewing and planing. But the triangle is really small and the rename function (clicking on the title) is huuuge. The function most in use gets the least screen estate and vice versa.

Related problem with Context, Folder, Due, … header rows: vast amount of space with no use at all, but to collapse or expand I have to target this tiny triangle instead of just a single click onto the row somewhere.

That doesn't mean there isn't room for improvement. But Matt Neuburg's fuss over them just doesn't seem like a real world issue. Who sits there toggling the triangle open and close over and over again (other than Matt Neuburg and us, that is)?

Hey, 10 sec a day for unnecessary complicated item toggling is 1 hour in your life this year you will never get back. Not to mention the endless hours on the internet spend talking about it. ;)

[Chris]

I have just the opposite problem from Matt: I often accidentally collapse or expand something when I'm just trying to select it. This was especially true for action groups before I realized that you can click far to the left of them (well outside the area that gets highlighted when the group is selected) and they'll still get selected.

[Toadling]

Schlaefer, thanks for the nice screen mock-ups! I agree that it can sometimes be hard to tell if the sidebar or main content area has focus. It's an issue that exists in many OS X apps but is particularly noticeable in OmniFocus because of its outlining capabilities with lots of collapsible nodes in both the sidebar and the content area.

I wonder if the "Collapse All" and "Expand All" options weren't available, would this issue have even come up? The only other app I can think of with similar capabilities is Apple Mail with its "Expand All Threads" and "Collapse All Threads" options. But those clearly only apply to items in the app's content area, so it doesn't matter where focus is. Consequently, it avoids the issue altogether.

So a good start would be to use the invers highlight in the sidebar when selected and active

Yes, I agree. And that seem to be what most apps are relying on these days.

But doesn't OmniFocus already do this? When I have something selected in both the sidebar and the main content area, and then toggle focus back and forth between the two areas using Command-4, I can see the active region has blue highlighting while the inactive region's highlighting turns gray. Isn't this what you're talking about?

Maybe the highlight color set via System Preferences -> Appearance also makes a difference. If you use the silver or graphite options, visibility may be reduced. I have mine set to the default blue.

So it seems like the only thing that might be done here is to increase the contrast of the current selection to increase its prominence. What do you think?

The remaining problem is: what to do when nothing is selected (leaving out "selected but not visible") ...

At the moment I'm not aware of an application solving that issue in any way. But these applications unlike OF show nothing in the main view when nothing is selected in the sidebar, have a special root item for "everything" in the sidebar or don't allow to select nothing in the sidebar. That brings us to the question: do we need a sidebar with no item selected at all?

This is actually something that was discussed on this forum last December (see posts near the end of this thread (http://forums.omnigroup.com/showthread.php?t=6073)). OmniFocus has a hidden preference to leave the main content area empty when there's no sidebar selection:

defaults write com.omnigroup.OmniFocus LeaveEmptySelectionEmpty -bool YES

I vastly prefer this behavior over the OmniFocus' default behavior of showing everything when there's no sidebar selection. Not only does it help you determine if the sidebar or main content area has focus, but it's also lightning fast when switching between planning and context modes with no selection (presumably because nothing needs to be rendered in the main content area). I think this behavior is also more consistent with other OS X apps (e.g. Apple Mail, Yojimbo, etc.).

A visual clue I could think of would be a blueish halo around the active area when nothing is selected

That possibility did occur to me, but can't think of any other app that does that. And I wonder if it would be too garish. But it's certainly something to consider.

I create a project and enter a name for it. After that most of the time I don't rename the project anymore but open and close it when reviewing and planing. But the triangle is really small and the rename function (clicking on the title) is huuuge. The function most in use gets the least screen estate and vice versa.

That's a really good point. But, at least in my case, it only holds true for the sidebar, where I do more toggling than renaming. But in the main content area, I think I'm more likely to do renaming.

Either way, you and Matt Neuburg are probably right in that it'd be nice if the disclosure triangle had a slightly larger target area.

Hey, 10 sec a day for unnecessary complicated item toggling is 1 hour in your life this year you will never get back. Not to mention the endless hours on the internet spend talking about it. ;)

Ha ha, you are so right about that!

[kaebot]

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.

One thing that might be worth mentioning is that this is actually normal window behavior in OS X. It's just that other applications add an extra column (Finder, for example), and we simply can't do that in OmniFocus when one of the main objectives is to elimate distraction.

[JKT]

One possible solution to the sidebar/content area focus issue would be to fade the text in the non-selected region (e.g. make it 60% grey if not selected). Alternatively, it is only really necessary to indicate if one or the other area is selected at any one time and not both, so why not just make it very obvious when the content area is not selected and forget about indicating whether the sidebar is selected or not.

[Toadling]

One possible solution to the sidebar/content area focus issue would be to fade the text in the non-selected region (e.g. make it 60% grey if not selected).

But wouldn't that reduce legibility of the content area as you browse your projects by clicking on their names in the sidebar? It seem like this proposal assumes that the user is concentrating on where the focus is, but that's not always the case.

[JKT]

Not necessarily - it would depend on how much fading was done - it only has to be a subtle shift to be noticeable - e.g. the entries in the Context area are already at a %grey and are not fully black, and they are easy to read still.

Alternatively, make the context area background a 10 or 20% grey instead.

[Toadling]

Not necessarily - it would depend on how much fading was done - it only has to be a subtle shift to be noticeable - e.g. the entries in the Context area are already at a %grey and are not fully black, and they are easy to read still.

Alternatively, make the context area background a 10 or 20% grey instead.

Hmm, that would be interesting to see. Those sound like some good ideas to try.

[Brian]

Just a heads up - we've got an item open in the development database that covers the need to address the sidebar/content outline focus issue.

I don't see one for a bigger expansion click target, so I'll make one for that.

Thanks, all!

[Schlaefer]

Schlaefer, thanks for the nice screen mock-ups! I agree that it can sometimes be hard to tell if the sidebar or main content area has focus. It's an issue that exists in many OS X apps but is particularly noticeable in OmniFocus because of its outlining capabilities with lots of collapsible nodes in both the sidebar and the content area.

I wonder if the "Collapse All" and "Expand All" options weren't available, would this issue have even come up? The only other app I can think of with similar capabilities is Apple Mail with its "Expand All Threads" and "Collapse All Threads" options. But those clearly only apply to items in the app's content area, so it doesn't matter where focus is. Consequently, it avoids the issue altogether.


The only app there I have such dynamic sidebar like in OmniFocus is my notekeeping app (Mori) and to be fair: the nested tree view sucks there too.

The main reason why OmniFocus stands out is that I try to navigate fast not only in the content view but in the sidebar with the keyboard. In other sidebar apps like Mail, iTunes etc. you make a selection in the sidebar and then work in the main view for some time.

When I look at the problem from a little higher level and I know this is totaly geek, but I would literaly pay for a quick navigate panel for projects. If you know TextMate for example: it has handy quick navigate panels for files (cmd+t) or symbols (cmd+shift+t). The whole sidebar/focus/navigation problem would be gone for me.


But doesn't OmniFocus already do this? When I have something selected in both the sidebar and the main content area, and then toggle focus back and forth between the two areas using Command-4, I can see the active region has blue highlighting while the inactive region's highlighting turns gray. Isn't this what you're talking about?

Maybe the highlight color set via System Preferences -> Appearance also makes a difference. If you use the silver or graphite options, visibility may be reduced. I have mine set to the default blue.

So it seems like the only thing that might be done here is to increase the contrast of the current selection to increase its prominence. What do you think?


Maybe it's my cheap monitor but this is to subtile for my taste. A real inverted badge (white text on dark ground) would imho be much better (and more consistent to the rest of the system).


This is actually something that was discussed on this forum last December (see posts near the end of this thread (http://forums.omnigroup.com/showthread.php?t=6073)). OmniFocus has a hidden preference to leave the main content area empty when there's no sidebar selection:

defaults write com.omnigroup.OmniFocus LeaveEmptySelectionEmpty -bool YES
I vastly prefer this behavior over the OmniFocus' default behavior of showing everything when there's no sidebar selection. Not only does it help you determine if the sidebar or main content area has focus, but it's also lightning fast when switching between planning and context modes with no selection (presumably because nothing needs to be rendered in the main content area). I think this behavior is also more consistent with other OS X apps (e.g. Apple Mail, Yojimbo, etc.).


Oh, thank you. I bought OmniFocus in the beta but didn't start actually using it as my main tool til four weeks ago. I wasn't aware and definitely will try it.


That possibility did occur to me, but can't think of any other app that does that. And I wonder if it would be too garish. But it's certainly something to consider.

Yeah, wouldn't be surprised if it looks awkward. Needs more time in @think_about. ;)

That's a really good point. But, at least in my case, it only holds true for the sidebar, where I do more toggling than renaming. But in the main content area, I think I'm more likely to do renaming.

A little bit related to that: the fear to change something without noticing it makes me always feel a little bit uncomfortable to see the cursor blink when I click on an item without intention to change that particular field.
But for the sake of speed is probably to the best solution. Just out of curiosity I would like to test a OF version where I have to double click an field to go in editing mode.

[jonwalthour]

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.
My "Someday/Maybe" list is a SAL and, while each action is itself a project, they are in the list simply actions, not sub-projects. Why make them projects now? Right now, they are just stuff to consider that I might someday, maybe do. If and when I do decide to take that around the world cruise or put in hardwood floors or remodel my kitchen, then I'll move them out of this list and make them active projects. Right now, they're not really projects b/c I can't DO anything in them to bring about their desired outcome. What I do to keep them out of any perspectives is to not give them any context and set their Start Date way out in the future, like "Dec 31, 4712".

[Toadling]

My "Someday/Maybe" list is a SAL and, while each action is itself a project, they are in the list simply actions, not sub-projects. Why make them projects now? Right now, they are just stuff to consider that I might someday, maybe do.

Actually, I do the same thing. But as those ideas on my someday/maybe SAL mature, and I become convinced that I'm actually going to do something about them (although, not now), I often promote them to full projects with some degree of planning inside. But like my someday/maybe SAL, I still keep the projects on hold, since I'm not ready to act on them.

One nice thing about this approach is that I can set independent review intervals for the projects (rather than for the whole SAL). Also, it's a little easier to plan my actions in the form of a project than on the SAL. But I agree, there's probably not much point in going that far unless you're pretty sure you're going to act on it at some time in the not-too-distant future.

My main point, though, is that I really like being able to leave items (whether they be SALs or projects) in their natural setting (i.e. in their folders, in the order I desire, nicely tucked in wherever it is that they belong) and still mark them as "someday/maybe" by putting them on hold.

Having to drag them into some other, separate container to indicate "someday/maybe", as Matt Neuburg suggested, just feels wrong and inefficient to me. You lose all sense of context (lowercase c) on the item.

[joelande]

I agree.

I actullay have more of a Someday/Maybe system:
(i) I use a On-Hold Single Action List list for general undeveloped Someday/Maybes
(ii) I have several On-Hold Single Action Lists for things like books, music, movies, and gifts that I may someday get around to
(iii) I have several more-developed projects that have place ON-Hold as a Someday/Maybe item

And I agree that for those projects that have already been developed, it is nice to keep their structure in tact.

Then you can place all of the above On-Hold Someday/Maybe items into a folder, to keep it all wrapped up ion a nice neat package.

[mcoad]

There’s an excellent, thought-provoking review of OmniFocus by Matt Neuburg in the current TidBits (#928, 12 May, http://db.tidbits.com/article/9594). Highly recommended. He’s a fan, loves much about OF, but discusses in depth a whole swathe of interface issues which will strike a chord with many users. And - vindication of a sort for some of us - he laments the lack of a calendar view, thus adding his support to those of us who have been arguing for some kind of timeline view. Matt’s a respected voice in the Mac community, so here’s hoping the Omni folks go through the piece with a toothcomb, as - IMHO - he reflects just the ambiguity, the mix of enthusiasm and frustration, that many of us feel.

[sfkeydel]

mcoad,

There's a ginormous thread about this already, with lots of comments from Omni staff:

<http://forums.omnigroup.com/showthread.php?t=7886&highlight=tidbits>

sfkeydel

[mcoad]

Whoa - apologies! I didn’t go back far enough in the list before posting. Good to see the response, though.

[Brian]

threads merged.

[mcoad]

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.


I had a lengthy exchange with one of the support ninjas recently about this and I’m glad Matt picked up on it. The handling of repeating actions is truly one of the oddest things about OF’s interface, IMO, and seems to be the product of a straight conflict between concept and the real world.

The problem can be seen most clearly by comparing the way these actions are managed in Context and Planning modes. If you have a list of several actions which repeat every day, for example, and check these off in Context mode they do exactly what you would expect: they disappear from the Due Today list and magically open up in the Due Tomorrow list. But in Project mode, if you sort by Remaining, they simply reappear further down the Today list, even though they are for Tomorrow! This is incredibly confusing and looks just crazy. It is really no answer to suggest, as Brian does here and as the ninja did to me, that if you have the date column open you can see that while the task appears in Today’s list it is really for Tomorrow. This is hardly a solution to visual confusion, and Brian’s use of “at least” here seems to indicate that he’s aware of the incongruity. Nor is sorting only by Available or Next Action the answer, as you may need to see what is Remaining.

The explanation I was given - and this is what I mean by concept getting in the way of visual reality - is that OF sorts by projects, and not tasks, and looks for the earliest date and uses that value. I never really understood this, but what it seems to mean is that for OF the task exists in the here and now even if it’s actually due in the future, so is included in Today’s list but with Tomorrow’s date. Given the way all this works in Planning View (which, incidentally, was once called Projects view, to mention another of Matt’s points) the possibility of flipping into a Tomorrow list, as in Context mode, is apparently not feasible.

There are doubtless good conceptual reasons behind this, even if they are hard for a non-tech user to grasp, but the bottom line is that you get Tomorrow’s tasks appearing as for Today, which is very weird indeed. I was told that while such results “look strange” they are “actually correct”. Which is not much comfort when you’re trying to get your stuff in order but are faced with something which flies so bafflingly in the face of just that.

[Brian]

But in Project mode, if you sort by Remaining, they simply reappear further down the Today list, even though they are for Tomorrow!

In planning view, we sort (or group) one project against another, but we do not rearrange the contents. We also won't separate the project out into multiple chunks, with some in the 'today' bucket and some in the 'tomorrow' bucket. To plan your project, you need to see the whole thing as a contiguous list.

We also assume that you put the tasks into an order that matters to you - list position is essentially an infinitely-deep priority system. To respect that, OmniFocus will not reorder items in the task list - if a repeating action is the third action in the list, the 'tomorrow' version of the task will also be the third action in the list.

In context view, projects are completely ignored. Actions exist as atomic bits, which you can sort or group regardless of which project they come from.

OF sorts by projects, and not tasks, and looks for the earliest date and uses that value. I never really understood this, but what it seems to mean is that for OF the task exists in the here and now even if it’s actually due in the future, so is included in Today’s list but with Tomorrow’s date.

If you have a project with twelve items due tomorrow, and one item due today, the whole project will appear in the 'today' group. The project will only move to the 'tomorrow' group when there's nothing in that project that's due today. The project is sorted (or grouped) on the basis of the earliest date that it contains.

I'm of the opinion that we either need to change the group headings to make this behavior clearer, or we need to set it up so changing your sorting or grouping collapses all the projects that are visible, then does the sorting/grouping. That would make it more obvious that we're only sorting projects, not the contents of projects.

The upshot here is that planning mode is meant to show you your whole project, not a filtered or chopped-up portion of your project. If you want the latter, you can switch to context view and sort/group your actions once they've been broken out of the project lists.

[mcoad]

Thanks for the explanation, Brian, which is good and clear. I see the logic. However, given the way the interface is designed at the moment the problem persists. Surely it is just an obvious nonsense to have a list called “Due today“ which may in fact be made up of a long list of tasks none of which are due today, and may be due over several dates perhaps well into the future. There’s no way this isn’t going to be mega-confusing.

I’d suggest there are two things here causing the confusion. One is the list heading in the main window as you mention. Changing this would help a lot, though I guess it’ll be hard to find a clear and succinct way of doing it. The other is reflected in the sidebar in Planning mode, and in what Matt says about preferring to see this called Projects mode. Originally, of course, it was, and was presumably changed precisely in order to emphasize what you say: that this is where you do your overall planning rather than dealing with the nuts-and-bolts of the project once planned. However, the sidebar and toolbar continue to talk about “projects” - inevitably, given that’s what they are dealing with - and the lack of some other way of emphasizing that this is a Planning space tends to encourage the piecemeal (“breaking into chunks”) way of thinking you describe.

In other words, I think this distinction between how you use the two modes is confusing for a lot of users - not the concepts themselves of Planning and Contexts, but the way they are implemented. As you say, Planning/Projects is for overall planning, and produces the problems I’ve described if you try to use it for dealing too closely with the detail (wanting it laid out by exact date, for example). But given that the whole point of Contexts is that tasks from different Projects can be carried out in the same Context, this mode easily becomes semi-divorced in the user’s mind from the idea of the Project as a whole. This leaves many in a quandary over just where they should record their processing of actions and do their rethinking about their Projects as such. Contexts work fine when you’re thinking and organizing yourself in looser, “contextual” terms. But when you’re thinking about the Project you naturally go back to the Planning mode, and there are times when you do indeed want to break it into chunks, see how it pans out over time, list things clearly by different dates, etc, not just see it in an undifferentiated list (except for the date column, of course). Hence the confusion I’ve been griping about.

I hope it’s clear what I’m saying. I don’t know what the answer is*, except to change some headings in Projects and try to persuade people to think of Contexts as where they actually get their stuff done. But it seems to me there is a real conceptual problem to be addressed if the app is to be as transparent as I guess we‘d all like it to be.

*Actually I do know what some will say is the answer: get OmniPlan, if you’re so worried about this kind of detail. I don’t think so, however. Apart from the question of overkill, this same confusion is going to persist as things stand at the moment in OF.

[Brian]

Surely it is just an obvious nonsense to have a list called “Due today“ which may in fact be made up of a long list of tasks none of which are due today, and may be due over several dates perhaps well into the future. There’s no way this isn’t going to be mega-confusing.


Yeah, I really want to change those headers to read "Projects with actions due today" (or whatever the heading should be). Right now, the interface doesn't make it clear what that grouping really represents, which does confuse folks.

But when you’re thinking about the Project you naturally go back to the Planning mode, and there are times when you do indeed want to break it into chunks, see how it pans out over time, list things clearly by different dates, etc, not just see it in an undifferentiated list (except for the date column, of course). Hence the confusion I’ve been griping about.

I don't know how we'll ultimately deal with this - but yeah, we're aware that the current setup doesn't work for some folks. This is definitely on our radar screen.

Actually I do know what some will say is the answer: get OmniPlan, if you’re so worried about this kind of detail. I don’t think so, however. Apart from the question of overkill, this same confusion is going to persist as things stand at the moment in OF.

I don't think the solution is to get OmniPlan - for one person, it really is overkill. We're definitely committed to making OmniFocus work for as many folks as we can; once we get the iPhone application done - or invent a developer-cloning process - we can start in on version 2 and re-examine stuff like this.

[mcoad]

Great - that’s all very good to know. Thanks Brian

Btw, I suggested in another thread that it might be helpful to have a section on the website dedicated to sample uses of OF - concrete, widely differing examples, redacted and well presented, rather than in the looser form usual when people are swapping experiences in the forums. More work, I know, but it would help folks see ways through such confusion.

[brianogilvie]

But when you’re thinking about the Project you naturally go back to the Planning mode, and there are times when you do indeed want to break it into chunks, see how it pans out over time, list things clearly by different dates, etc, not just see it in an undifferentiated list (except for the date column, of course). Hence the confusion I’ve been griping about.

I handle this in two ways, depending on my goals.

1. In Planning mode, I'll reorder actions and action groups to reflect my current sense of priorities or workflow.

2. I'll focus on a project and then switch to Context mode, where I can group and sort individual actions to my heart's content.

In other words, I think that OF provides the tools to do what you want, but the documentation might not explain how to do it. I've been using OmniFocus for over a year now, so it has become second nature to me, but I respect Matt Neuburg's views and I think that he made some good points.

By the way, as I recall the discussion in the forums, the switch from Project mode to Planning mode was made, at least in part, because the Inbox is also in Planning mode, and it's not a project.

[Toadling]

By the way, as I recall the discussion in the forums, the switch from Project mode to Planning mode was made, at least in part, because the Inbox is also in Planning mode, and it's not a project.

And single-action lists aren't technically projects either. To me, "Planning Mode" makes a lot more sense. I wonder if Matt Neuburg just didn't fully think that one out.

[D-Mac]

In addition to replying to Matt about his article (yeah, I don't know why there are no comments for the TidBITs articles --- the "Talk" posts are completely separate, which is weird for the content that is directly related to their articles), I would strongly encourage The Omni Group staff to read the comments/posts in the TidBITs Talk forum post area of their website (comments to Matt's original article).

Also, if you complain about the behavior of various Cocoa widgets/code, that's just an excuse (and almost tantamount to whining). If the OS X provided widgets/code don't work properly, are buggy, or don't do what you want, guess what... write your own code... geesh... Work around things... that's what programmers are for... And, saying that you need some new feature of Leopard to make the GUI work is absurd. Simply, simplify, simplify. I seriously doubt that OmniFocus needs anything more than what is currently available.

And, don't feel like you have to follow everything David Allen says, like he's some sort of god (he isn't). I'll bet anyone a dollar that the most important part of DA's GTD system is about getting things written down and then regularly managing those things. People who are organized already do that. People who aren't will benefit most by adopting nearly any system.

So, an application like OF should help automate things, and even, dare I say, improve on what DA himself has proposed. OmniFocus should strive to be compatible with GTD, not hamstrung or limited by its particular idiosyncracies (something will come along in a few years that probably wipes out GTD).

GTD is not the be-all, end-all of task management... ;-)

It's been said before, but apparently most people need to hear it like a mantra... If someone takes the time and effort to provide feedback about your products especially that which may be critical, you better listen and not react defensively or with conceit... most everyone who provides feedback actually cares a lot about your products... And, just because you've designed and programmed an application doesn't mean you know everything... unfortunately, that kind of vibe seems to be put forth to often...

I do like OF and would love to see the items that Matt, the commenters at TidBITs Talk, and others have suggested get added in the future... Thanks for the work on OF, so far...

[Brian]

I would strongly encourage The Omni Group staff to read the comments/posts in the TidBITs Talk forum post area of their website (comments to Matt's original article)

I've read them, and I've heard them mentioned in a couple of conversations, so you can rest easy. ;-)

Also, if you complain about the behavior of various Cocoa widgets/code, that's just an excuse (and almost tantamount to whining). If the OS X provided widgets/code don't work properly, are buggy, or don't do what you want, guess what... write your own code... geesh... Work around things... that's what programmers are for...

It wasn't my intention to whine or complain. Since the author was specifically taking us to task for writing our own controls and not using cocoa controls, I thought it was important to explain that the symptoms were there, but that his diagnosis was incorrect.

In general, we'd love to fix every bug that affects our code, even if we didn't write the code in question. We have developers, but not an infinite number of them, though. ;-)

The drawbacks to doing this are that it takes time away from adding features that customers want, it makes getting the issue fixed less likely (by masking the problem), and it doesn't help anyone affected by the bug in other applications that use the frameworks.

Even worse, there are some framework bugs that we just flat-out can't fix - there's a crashing bug in the Nvidia drivers that affects OmniGraffle, for example. We don't have the source code to the drivers; game over. When I discussed the the calendar control with the lead developers, they told me that it fell into the same category.

And, saying that you need some new feature of Leopard to make the GUI work is absurd.

I'm assuming you're referring to my original response to the screencast here? That was meant as a specific response to "why are these controls flashing so much?" Core Animation exists on 10.5, and makes it much, much easier to do some things than it is on 10.4. The UI works - but it could be better, and making that aspect better on 10.4 would eat up a lot of time.

While we could drop everything else and fix the issues pointed out in the review, we feel that our customers would be better served by working on the things we currently have on our plate, like machine-to-machine synching. We know this because of the amount of feedback attached to the bugs we have open on both sets of issues in our development database.

If the items mentioned in the review were at the top of that pile, it would be a different story. :-)

If someone takes the time and effort to provide feedback about your products especially that which may be critical, you better listen and not react defensively or with conceit... most everyone who provides feedback actually cares a lot about your products... And, just because you've designed and programmed an application doesn't mean you know everything... unfortunately, that kind of vibe seems to be put forth to often...


I'm in complete agreement with you here; if I have put forth that vibe, it wasn't my intention to do so and I apologize. We didn't get where we are today by ignoring customer feedback. ;-)

To turn it around, though, it's easy for folks to toss around words like 'obvious', 'futile', and 'absurd' when they post here. It makes for a more enjoyable read, but often doesn't cover all the nuance of the situation. I have to worry about the perception that could create for subsequent readers.

Software development is a fairly opaque process to most folks; my posts here are intended to make it more understandable, and to attempt to correct the misconceptions that folks have about it.

[sfkeydel]

Brian,

For what it's worth, I feel that your responses on this thread have been anything but defensive-- certainly not the vibe I've gotten.

Stefan

[D-Mac]

Brian,

I would like to thank you for the time you spent answering my mostly rhetorical post (and others' more succinct posts)...

And, thanks for the other explanations...

Please note that my comments were not meant to be very critical, nor were they necessarily aimed at you or anyone else at TOG (about being defensive, etc.). I did run into some difficulty back in December. Your posts in this thread have been terrific. I apologize if my (likely imprecise) comments earlier seemed to have been directed specifically to you.

I know all too well how difficult it is to develop software. I know it sucks when you find all sorts of system-related bugs, especially ones you can't work around. And, like you said, working around them often requires revisiting the workaround later on, which is fun for no one. The difficulty is compounded by resource issues, as it usually is... ;-) Hope you find that cloning machine...

I know that it didn't help anyone that Leopard was in such a state of flux right up until it was released. I have seen that fact mentioned by many developers. At least once Apple gets Leopard "debugged" a bit more, it will be a vast improvement over all other previous OS X releases.

Good luck with OF 2.0. I look forward to it.

-Dave

[ptone]

Matt Neuburg has a new review (http://db.tidbits.com/article/9594) up on OF. The review is pretty good, but he also has some screencasts (http://www.apeth.com/omnifocus/omnifocus.html) that point out some pretty valid beefs with the OF UI - several of which I remember bringing up and discussing during the betas.

I don't mind the hovering column hints - and my OF doesn't beep at me, but there are some pretty valid points made. I know the column resizing was well hashed out, and I still think it is bizarre the way it is done. I think reordering outlines would really benefit from some larger grab tabs, and some animated reordering (ala dock reordering).

Anyway - with DF pointing to this review, it will be many people's first intro to this app.

-P

[Johno]

Matt Neuberg's review of OmniFocus: http://db.tidbits.com/article/9594?rss

He highlights the quirks of the interface that hopefully will get fixed in the near future.

[Splinky]

I'm a paid up user of OmniFocus, but this review (notably the videos) highlights the things that bug me to tears about OmniFocus. Especially the date thing, and the select-drag stuff. That is annoying.

[Ken Case]

That date thing bugs all of us! Unfortunately, it's a bug in the standard Cocoa calendar widget that we're using. I think our best bet is to go ahead and write our own nonstandard widget instead (which, ironically, is what Matt thought we were doing!), but we didn't have time to do that for 1.0. (And our focus for 1.1 is on synchronization.)

I think we can make the drag points clearer by changing the cursor to indicate whether you're over the right point or not.

What else bugs you?

[Toadling]

This has been discussed in detail in a thread back in May.

http://forums.omnigroup.com/showthread.php?t=7886

While some of Mr. Neuburg's criticism are valid, I think others are ill-informed and sensationalized.

-Dennis

[Ken Case]

Double-clicking on a project normally opens it in a separate window; the beeps he was hearing come from double-clicking on a row that can't be opened in a separate window. (If we can't do the double-click action, it makes sense to fall back on the single-click action instead of beeping.)

[mpw]

As much as I love OF, I do have to agree with a lot of Mr. Neuburg's complaints. Many of the things bugged me until I found out how they work and how I need to interact with them. Many of the things still bug me.

Maybe some day some of the issues could be addressed? But until then, keep on concentrating on what you've been concentrating on because that is really hot stuff!

[iNik]

Some areas for improvement, especially around UI and expectations, and pardon the lengthy post...

FOCUSED REGION

Matt's point that focus (sidebar vs. content) is unclear is a major point of confusion for me. I've completely given up on the Expand/Collapse All menu items because it takes a click+command in order to be sure I'm doing the right thing. Not sure how best to accomplish this, but it would be nice if that were easier. Maybe just highlight the focused area? Dunno.

DROP DOWN SELECTION WEIRDNESS

Matt hit this one on the head. Escape backs you out. Period, end of story. Tabbing past a field, clicking an item on the drop down, hitting return, maybe even hitting space should enter the value, but that's it.

Another annoyance: When my cursor is in a "combo box" field (e.g. context/project), a click on the menu arrow isn't sticky. I have to click-drag (like an OS 9 menu) in order to select an item. If the cursor isn't in the field, it's sticky. It should always be sticky. (Aren't custom UI elements a bitch?)

While my cursor's in there and actively editing, I think a down-arrow should bring up the menu of choices. Maybe not, I dunno. I keep expecting it to, though.

WHERE DID ALL MY TASKS/PROJECTS GO?

It is unclear when I'm focused/filtered/whatever a lot of the time. This happens a lot, actually. I find myself stuck in a moment of confusion because what I EXPECT to find is not there.

The little filtery doo dahs at the top of the list are a step in the right direction. I can scan them and see what's what. But what if I'm focused? Hmm... All I have is the "Show All" button on the toolbar, and it's not terribly obvious that it's in a non-standard state.

It gets doubly weird when I have multiple windows with different focus.

Highlighting things (make the filter doo-dah "glow" or something when it's filtering maybe?) and noting focus somehow (maybe a little focus-eyeball next to the project names?) would be very helpful, especially with a quick click to get back to defaults ACROSS EVERYTHING, just like the (x) in the doo-dah section.

I'm aware that there are tons of indicators, but I have to look at ALL of them to know what's going on. That few seconds of confusion and frustration really breaks my MENTAL focus.

PERSPECTIVES

I love these things. One weirdness: If I click on a perspective button more than once, it changes my focus from the Inbox to the Library. Weird.

SEARCHING

Search defaults to searching my current branch of the tree. This is a pain. If I'm searching, I generally will want to search globally, because I'll be in, say, a context and be reminded of another task I need to look at.

Even worse, if I want to DO a global search, I need to select both the Inbox/No Context and the Library/Contexts sidebar items. Ugh!
My preference would be to have search default to a global search, and then have the option to restrict to visible items. (Ideally letting you filter after the search is entered, a la Finder searches)

Also, CMD+F should get you to that search box, not to the text search. VERY confoozling.

INSPECTOR

CMD+I. That's all. I'm inspecting a lot more than I'm italicizing.

PERSPECTIVES

I'd love the ability to multi-select criteria (e.g. show active and dropped) within perspectives.

Why just there? Because building the UI for doing that on the fly would be terribly hard, and probably very very confusing. Making an advanced Perspective interface would be less confusing and completely hidden from folks who don't need it. (Think of Word's style sheet definition window as opposed to "update to match selection")

CLEAN UP

Is this really necessary? Can it be automatic, maybe do it when I click out of the inbox? Maybe just as a preference? I sometimes get confused when I set a context and project for an inbox task, click to the appropriate perspective/context, and it ain't there.

DOCK THE INSPECTOR

I'd love to be able to attach the inspector palette to the window so it doesn't overlap stuff. Maybe I'm crazy.

Anyhoo, those are the thoughts off the top of my head. It's hard to write this because I've become accustomed to so many of OF's idiosyncrasies at this point. But the app IS confusing AND hard to learn, and these little weirdnesses are part of it. I'm sure there's other things that could be improved as well, and basic usability should really be a focus for the 1.5 or 2.0 release.

Which is a back-handed way of saying that I'm really glad you're soliciting our opinions and improving the software day by day. Thanks!

[Brian]

merged the new thread with the existing one.

[Toadling]

Matt's point that focus (sidebar vs. content) is unclear is a major point of confusion for me. I've completely given up on the Expand/Collapse All menu items because it takes a click+command in order to be sure I'm doing the right thing.

I think this is a problem common to many OS X apps. They all suffer from this deficiency, but it's more apparent in OmniFocus because of things like the Expand/Collapse All menu.

When my cursor is in a "combo box" field (e.g. context/project), a click on the menu arrow isn't sticky. I have to click-drag (like an OS 9 menu) in order to select an item. If the cursor isn't in the field, it's sticky. It should always be sticky.

Oh yeah, good one. That's been bugging me for a while too but I had kind of forgotten about it (usually access those fields by tabbing from the keyboard).


Also, CMD+F should get you to that search box, not to the text search. VERY confoozling.

No, that's standard OS X behavior. Command-Option-F goes to the search field in the toolbar (*when appropriate) and Command-F brings up the search dialog window (*when appropriate). Just about every app in my dock works this way: Mail, Safari, iTunes, Finder, NetNewsWire, Yojimbo, MarsEdit, etc.

*I say "when appropriate" because not all apps have/need both facilities.


I'd love the ability to multi-select criteria (e.g. show active and dropped) within perspectives.

Yeah, maybe we need smart folders and perspectives.


CLEAN UP

Is this really necessary? Can it be automatic, maybe do it when I click out of the inbox? Maybe just as a preference?

According to the documentation, it is automatic after an unspecified period of time; and I've seen it happen automatically. Maybe a preference to set that amount of time is in order?

For the record, I persoanlly prefer the current, mostly-manual clean up behavior. I don't want things disappearing from under my nose unless I explicitly ask the app to do it.


I'd love to be able to attach the inspector palette to the window so it doesn't overlap stuff. Maybe I'm crazy.

Yeah, I'd like that too.

-Dennis

[cashdollar]

Read the article and watched the screencast. wow. He makes some good points, much of which I'm sure the good folks at omni are aware, and anyway they've always been responsive and open to comments.

But come on how over the top can you get. Mr. Neuberg seems just a tad bit high strung. I could see him having a meltdown because someone bought him regular instead of jumbo paperclips.

Just a little bit of perspective. This is a 1.0 product, and it's very solid. It's well built enough that it can be that "trusted system" What if Apple built a GTD app, what would their 1.0 product look like? Consider past performance:

OS X.0 - glacial
Pages 1.0 - worst than glacial and bug ridden
Numbers 1.0 - more bug ridden than a Bolivian pleasure palace
I could go on but I'll leave you with the last image...

There are certainly oddities, but it's solid. I don't constantly worry about dumping or losing information. Overall it's a great 1.0 effort and more importantly, it's a really thoughtful approach to GTD.

[iNik]

Mr. Neuberg seems just a tad bit high strung. I could see him having a meltdown because someone bought him regular instead of jumbo paperclips.

As a long-time reader and member of the TidBITS community, I can assure you that Matt is more melodramatic than close to melting down. TidBITS in general is full of sometimes curmudgeonly but extremely smart people who have INCREDIBLY high standards. (You should read some of Adam's articles about keyboards -- he makes John Gruber look positively laid back on the subject!)

I think this kind of detailed critique is entirely apt for OmniFocus. It's a somewhat strange program, intended to support "maximizers" who want to streamline and customize every aspect of their workflow. For these people, having confusion or "congnitive dissonance" in one of their main tools is very frustrating.

And look at the great discussion Matt's criticism has created! I have no doubt that this particular forum topic will give Omni a wonderful laundry list of small and large tweaks to improve OmniFocus in the future months and years.

[iNik]

It is unclear when I'm focused/filtered/whatever a lot of the time... Highlighting things (make the filter doo-dah "glow" or something when it's filtering maybe?) and noting focus somehow...

Pardon me for quoting myself, but I had a little epiphany on a (seemingly simple) change that would make this easier: Keep the focus button "depressed" when focus in one, just like you do with Perspective buttons when you're in a perspective. Then there would be a nice visual cue in addition to the changed icon when you're focused on something.

standard OS X behavior [is that] Command-Option-F goes to the search field in the toolbar (*when appropriate) and Command-F brings up the search dialog window (*when appropriate). Just about every app in my dock works this way: Mail, Safari, iTunes, Finder, NetNewsWire, Yojimbo, MarsEdit, etc.

The standard OS X find dialog is great for textual find & replace operations on text. It's not very useful for searching lists of items -- that's better served by filtering. Applications that are less text-dependent, and especially programs that are lists or catalogs of large quantities of items, are better off filtering, rather than searching. Many applications, including a number of Apple's mainstay apps, eschew the Find/Replace dialog entirely, or limit its use to certain situations.*

OmniFocus is at heart a catalog/list program and has more in common with iCal than TextEdit. There are very few times I would ever want to do a mass find/replace operation in OmniFocus.** If all I want to do is find items, filtering is much more useful.

I admit that I'm picking nits here, but it's an important point. I'm not just complaining about the extra work of having to hold down option in order to do a filter/find.*** Filtering is at the very CORE of OmniFocus' design! Filtering (dare I say, "focusing?") is exactly what contexts, projects, view filters and grouping, perspectives and focus are all about.

OmniFocus may have its roots in OmniOutliner, but the two programs are very different. An outliner is a structured text editor, even if it is also used for lists. OmniFocus, on the other hand, IS a listing program. It lists tasks. Period.

Footnotes

* Here's a short (hah!) list of programs in my dock that choose their own method of handling a CMD+F find, many of which are Apple's own bundled applications.


The Finder (in Leopard at least) switches to/opens a search-style window and puts the cursor in the toolbar search field.
Apple's PIM apps, iCal and Address Book, both go straight to a filter box on a CMD+F.
Safari falls somewhere inbetween with its own weird little drop down that sort-of-filters (highlights) and also finds/find-nexts.
iTunes, frustratingly enough, doesn't do a darn thing on a CMD+F, but does go to the toolbar search on a CMD+opt+F.
iPhoto goes straight to the filter-search, as the text-based find/replace would be entirely useless.
Preview probably has the best Find method of any application. CMD+F filters the document to pages containing the search term, but ALSO highlights and CMD+G's through every instance of the term within the document.
1Password goes to the filter-search on a CMD+F, even though it's notes fields and items can contain a great deal of text.
And other apps (Yummy Soup, for example) only enable the textual find/replace when you're in a rich text editing mode/area.


** The only place there's any large amounts of text is in the notes area. These notes may be long, but they're generally clippings/references from other programs, and are not usually edited in any substantial fashion.

This is also an argument for binding CMD+I to show/hide the inspector palette, rather than italicize items. If you're spending your time formatting and perfecting notes, you probably aren't the target audience for a super-charged task management program like OmniFocus!

If you're making pretty presentations out of your task list, get OmniPlan with its gorgeous print layouts and Gantt charts!

*** Although this keypress is uniquely carpal-tunnel-inducing. On a MacBook keyboard (which lacks a right option key), a touch typist ends up contorting her hand into a painful claw, with her thumb and pinky holding down CMD and OPT while her pointer finger hits the final F. CMD+SHIFT combinations are infinitely easier on the fingers.

[Lucas]

*** Although this keypress is uniquely carpal-tunnel-inducing. On a MacBook keyboard (which lacks a right option key), a touch typist ends up contorting her hand into a painful claw, with her thumb and pinky holding down CMD and OPT while her pointer finger hits the final F. CMD+SHIFT combinations are infinitely easier on the fingers.

You can replace the key shortcut in the Keyboard & Mouse control panel.

[whpalmer4]

*** Although this keypress is uniquely carpal-tunnel-inducing. On a MacBook keyboard (which lacks a right option key), a touch typist ends up contorting her hand into a painful claw, with her thumb and pinky holding down CMD and OPT while her pointer finger hits the final F. CMD+SHIFT combinations are infinitely easier on the fingers.

Maybe all those years of playing the violin, piano, and Emacs paid off; I didn't even notice that CMD-OPT-F was awkward until you told me :-) Perhaps taking the option key with the ring finger would be easier? Or use the ring and pinky to hold the two modifier keys. Or the thumb right in the gap between the keys. I'm a rapid touch-typist and spend most of my time on my Macbook, often in the dark with nothing but screen backlight to illuminate the keys, and I use all of those "alternative" combinations depending on how the 'book is positioned. I find Option-shift and Control-shift combinations
to be the most inconvenient for me.

[iNik]

You can replace the key shortcut in the Keyboard & Mouse control panel.

Err... I knew that. :P

Thank you. My life has become one notch better.

[Toadling]

The standard OS X find dialog is great for textual find & replace operations on text. It's not very useful for searching lists of items -- that's better served by filtering. Applications that are less text-dependent, and especially programs that are lists or catalogs of large quantities of items, are better off filtering, rather than searching. Many applications, including a number of Apple's mainstay apps, eschew the Find/Replace dialog entirely, or limit its use to certain situations.*

OmniFocus is at heart a catalog/list program and has more in common with iCal than TextEdit. There are very few times I would ever want to do a mass find/replace operation in OmniFocus.** If all I want to do is find items, filtering is much more useful.

I agree, but that is beside the point. I'm simply trying to say that, for better or worse, the convention in Mac OS X seems to be Command-Option-F for moving focus to the toolbar search field, and Command-F to invoke the search/replace dialog. As you point out, some apps have customized behavior, but I think they're the exception rather than the rule.

And even if we can't agree that Command-Option-F is the standard shortcut for the toolbar search field, the key combination is at least commonly used in many, many apps. For example, I see Apple's Dictionary app works this way too.

So using those same shortcuts in OmniFocus should not be a big surprise or be particularly confusing for most users familiar with other OS X software. It feels natural to me.

That being said, I do agree that OmniFocus is more of "list" program and that most users are probably going to do a lot more filtering on rows than text-based searching/replace (although the search/replace dialog still has its place and should not be removed). So maybe OmniFocus should deviate from the convention, like iCal, and use Command-F for the toolbar search fields. But I'm not convinced there's any serious design flaw here.

The Finder (in Leopard at least) switches to/opens a search-style window and puts the cursor in the toolbar search field.

But the Finder also responds to Command-Option-F to place the cursor in the toolbar search field without entering any special modes, leaving the window in it's current state. So at best, this one's a draw. :) Besides, a text-based search/replace dialog doesn't make much sense in that context.

Apple's PIM apps, iCal and Address Book, both go straight to a filter box on a CMD+F.

Like the Finder, Address Book also places the cursor in the toolbar search field with Command-Option-F. So it's another draw. And, like the Finder, a text-based search/replace dialog doesn't make much sense in that context.

iCal, I grant you, seems to be an exception. If there's no use for a text-based search/replace dialog, I think it makes better sense to have both Command-F and Command-Option-F position the cursor in the toolbar search field (like Address Book and Finder).

OmniFocus, however, requires both the a search/replace dialog and the toolbar search field, so maybe iCal isn't a good comparison.

Safari falls somewhere inbetween with its own weird little drop down that sort-of-filters (highlights) and also finds/find-nexts.

But I disagree! That "weird little drop down" is just a reformatted text-based search/replace dialog (minus the replace capabilities since content is read-only), and it's invoked with Command-F. And Safari supports the standard convention of using Command-option-F for the toolbar search field

iTunes, frustratingly enough, doesn't do a darn thing on a CMD+F, but does go to the toolbar search on a CMD+opt+F.

Standard behavior. No practical need for a text-based search/replace dialog. In this case, Apple should probably make both shortcuts place the cursor in the toolbar search field, just like Finder and Address Book.

iPhoto goes straight to the filter-search, as the text-based find/replace would be entirely useless.

Yeah, this one certainly supports your claim. It seems they use Command-Option-F to go into fullscreen editing.

Preview probably has the best Find method of any application. CMD+F filters the document to pages containing the search term, but ALSO highlights and CMD+G's through every instance of the term within the document.

I really like Preview's search behavior - very well done. But I'll also point out that, like Finder and Address Book, Command-Option-F also places the cursor in the toolbar search field. Apple did the right thing in allowing either shortcut to work since there was no need for a traditional search/replace dialog window.

And other apps (Yummy Soup, for example) only enable the textual find/replace when you're in a rich text editing mode/area.

OmniFocus works differently here, though, because you can do textual search/replace across multiple row objects (database items). So it wouldn't make much sense to have it only enabled when in text editing mode.

The only place there's any large amounts of text is in the notes area. These notes may be long, but they're generally clippings/references from other programs, and are not usually edited in any substantial fashion...

If you're spending your time formatting and perfecting notes, you probably aren't the target audience for a super-charged task management program like OmniFocus!

I think that depends on what kinds of tasks you're managing in OmniFocus. For me, a big part of my usage is tracking bug fixes for my job. In those cases, I often write up several paragraphs in the notes field describing what happened so I can reference them later. Sometimes I even paste in snippets of code.

So for me, search and replace is very handy. And rich text formatting is not just to make things look pretty; it improves legibility by allowing me to make bold headings and display code in a fixed-width font, etc.

-Dennis

[iNik]

Toadling, your points and observations make good sense.

Personally, I'd hate to work in OmniFocus in such an information-heavy fashion; I see it as a quick task management application and not much more. But then, it's all too easy to think that I am the "normal" user, isn't it? :)

I've always found OF's notes fields to be pretty difficult to work with for large amounts of text since they're inline with everything else and often invisible. Do you find OF sufficient for handling all that text?

[Toadling]

I've always found OF's notes fields to be pretty difficult to work with for large amounts of text since they're inline with everything else and often invisible. Do you find OF sufficient for handling all that text?

Yes, I find OF to be quite capable in this area, especially with a bit of styling to help break things up (e.g. a sprinkling of bold text and a few carriage returns).

I suppose there's a practical limit to the amount of text you'd want to squeeze into the notes field, but I've found that it easily handles a few paragraphs, maybe even up to a full page in rare cases. If I have more information than that, I link in an external document (usually a plain text or OmniOutliner file).

For this situation, I actually prefer inline notes over notes in a separate pane. Inline notes allow me to view multiple entries at once and skim down the entire project, seeing everything in order (select all and hit Command-' to open all notes at once). It's also immediately clear which notes belong with which actions. It feels very much like a text editor with the ability to collapse/fold individual items. This is also how I've worked in OmniOutliner for years.

However, it would be nice to have the option to view notes in a separate pane like OmniOutliner allows. In cases with very large chunks of text (say, more than a single page), I think the separate pane format starts becoming more attractive. Such an approach works well for traditional database apps like Yojimbo. OmniFocus, on the other hand, feels more like a document than a database, even though it's clearly a database too.

-Dennis

[Lizard]

see also http://blog.omnigroup.com/2008/06/25/matt-neubergs-review-of-omnifocus/

[jasong]

see also http://blog.omnigroup.com/2008/06/25/matt-neubergs-review-of-omnifocus/

Ken says in that entry

Matt’s next issue was with our column resizing behavior: “Have you ever seen a Mac program where when you widen and narrow a column the entire window widens and narrows like that?” Well, actually, I’m guessing you have, since we borrowed that behavior from the Finder! If you open a Finder window and switch to Column view, then drag the last column wider and narrower, you’ll find that it makes the whole window wider and narrower.

I can't see to match his description. When I'm in Column view, dragging any column to resize keeps the window the same size, and adds a horizontal scroll bar when the width of the column exceeds that of the window.

This is under 10.5.3.

Anyone else seeing what I see?

Ken also asks

Now, just because there’s precedent in the Finder doesn’t mean I’m saying that this is the most desirable behavior. But what is? What exactly do you expect to happen when you make the title field wider or narrower? Should we just pick another field at random to make wider or narrower to compensate for that change? Or should the column widths no longer match up with the width of the window, leading to lost fields off the edge or to dead space on the inside of the edge? Most approaches we’ve seen lead to lots of fiddling to try get all the columns to add up to just the right width to fit within the window.

I'd prefer, in order:

* How Mail under 10.5 does it: you can resize columns so the total width can't go beyond the width of the window. This works great: I can set a desirable window width, then adjust column widths until they all fit as I want.

* How every other Mac application does it: when you resize columns, you get a horizontal scroll bar and columns which don't fit the window size scroll off the right. This is a well-established behavior on the platform, and I don't think it would confuse users.

[Ken Case]

I can't see to match his description. When I'm in Column view, dragging any column to resize keeps the window the same size, and adds a horizontal scroll bar when the width of the column exceeds that of the window.

Are you perhaps in List view rather than Column view? Or not dragging the column width past the right edge of the window?

I do think your suggestions are reasonable; we were trying to avoid the little time-wasting dance seen in every other app (including OmniOutliner) where you spend time trying to get the column widths and the window width to line up exactly right, but I think we could move that behind a preference and stop the debate. :)

[Toadling]

I can't see to match his description. When I'm in Column view, dragging any column to resize keeps the window the same size, and adds a horizontal scroll bar when the width of the column exceeds that of the window.

I think you need to grab the last, right-most column handle - the one on the right side of the last column. On my system (also 10.5.3), moving that handle back and forth does, indeed, resize the window.

That being said...


I'd prefer, in order:

* How Mail under 10.5 does it: you can resize columns so the total width can't go beyond the width of the window. This works great: I can set a desirable window width, then adjust column widths until they all fit as I want.

* How every other Mac application does it: when you resize columns, you get a horizontal scroll bar and columns which don't fit the window size scroll off the right. This is a well-established behavior on the platform, and I don't think it would confuse users.

I agree. I think Mail's approach is best.

-Dennis

[jasong]

Are you perhaps in List view rather than Column view? Or not dragging the column width past the right edge of the window

I see... drag a column wide enough to "push" the width of the window bigger.

That's not what OF does, though.

OF's window width is the total width of all the columns. Resize column A by 20 pixels, the window shrinks by 20 pixels. You never see a horizontal scrollbar.

Finder, though, shows a horizontal scrollbar when you resize a column unless and until you drag that column's width past the edge of the window. When you make the column narrower, the Finder window shrinks back, following this column's width until the Finder window is its original size, at which point, the Finder window locks to that width and the column continues to get smaller.

[Ken Case]

I hope you read past my first paragraph on the subject? I never claimed that our behavior matched the Finder's exactly, I just said that we weren't the first application to change the window size when resizing a column. And then went on to say that I wasn't sure that we'd come up with the best solution, but that we were trying to solve the problem of fiddling to try get all the columns to add up to the exact width of the window (which is the downside of OmniOutliner's approach).

Mail solves the "exact width" fiddling problem by taking the size away from another field. We considered that approach, but then making the project field wider would make the context field narrower, which isn't usually what people are trying to accomplish.

[iNik]

Mail solves the "exact width" fiddling problem by taking the size away from another field. We considered that approach, but then making the project field wider would make the context field narrower, which isn't usually what people are trying to accomplish.

Amazing how these seemingly-small details are such a bear to nail just right.

Resizing everything is awful, as is moving everything off the edge of the window. This is what I do ALL THE TIME in Excel, and SOMETIMES it does what I want, and SOMETIMES it drives me nuts and confuses me!

Resizing the window itself seems a bit goofy, but it fills the requirement of resizing the one column without affecting the other columns. Isn't that what you're trying to do in the first place?

[jasong]

I hope you read past my first paragraph on the subject?

C'mon Ken....


I never claimed that our behavior matched the Finder's exactly, I just said that we weren't the first application to change the window size when resizing a column. And then went on to say that I wasn't sure that we'd come up with the best solution, but that we were trying to solve the problem of fiddling to try get all the columns to add up to the exact width of the window (which is the downside of OmniOutliner's approach).

I can appreciate that. The window-resizes-when-moving-a-column happens only in one edge case (no pun intended). Your comments in various places led me believe that it happened always when resizing Finder windows, and thus you modeled it after that behavior; based on your clarification in the blog comments, I thought that was your believe also. I apologize if I misread that.

If OF implemented resizing similar to Finder's behavior, I would be happy.

[Ken Case]

Your comments in various places led me believe that it happened always when resizing Finder windows

Oh, sorry! I meant my comments in the more limited sense I just described, but as I review what I actually wrote I can see how it might be misinterpreted. (It seemed obvious enough to me in my own head!) I'll see if I can make the original post more clear so I don't confuse others about what I meant.

[jasong]

Resizing the window itself seems a bit goofy, but it fills the requirement of resizing the one column without affecting the other columns. Isn't that what you're trying to do in the first place?

That probably wasn't directed to me, but:

My approach is "set a window width, make columns fit that width".

Others prefer "set all the column widths, make the window fit that width".

Neither is "right" or "wrong", per se, but expectations make it so (with apologies to Shakespeare).

People gave feedback on this months ago, in a long thread (http://forums.omnigroup.com/showthread.php?t=6617) that has since been closed. Folks came down strongly on both sides of the discussion, so clearly there's no "right" answer.

If the goal is, as you say, "resizing the one column without affecting the other columns", the current OF way does that, but then, so did the Finder way and the Mail way.

So that couldn't have been the only goal.

(Kaebot from Omni offered his(?) opinion on why it was done this way:

One last thought related to the horizontal scroll bars and windows - with OS X window behavior, my understanding is that they implement extra, empty columns so that the window doesn't change size when you change the column width. (Check out Finder, iTunes, etc.) Part of the reason we'd rather not is because OmniFocus is about eliminating distraction and extra columns would be distracting!

I found that amusing; I assume kaebot was being funny because I'd hate to think that was the real reason!)

Here's where the current implementation is an issue, and why I'm glad the OF team is focusing (ahem!) on improving the behavior:

I keep the Inspector panel open on the right edge of my screen (OF is much more usable with it always showing).

I keep my main OF window open to the width of the rest of the window.

Upon first setting this up, I adjust the internal columns to be a particular usable width, fiddling with things so that they're readable, and at the same time making the window itself the right size.

Perfect!

Now, I open an unfortunately deep-nested action item, and the resulting content isn't readable. I widen the width of the column, which widens the width of my window, which obscures content in the window below the Inspector.

If widening the column simply added a horizontal scrollbar, all my content would remain a scroll away. Instead, I have to either resize the window or move the Inspector.

I know, I'm harping now. I apologize. The big issue for me is that for the year or so I've been using OF, this has never been considered a "problem" by the Omni team (at least, not that I recall). It's how it was designed, and works as designed.

I'm glad to see that this isn't (any longer?) the case, and that the team is looking at ways of making this better. I applaud them for doing that.

[Ken Case]

Now, I open an unfortunately deep-nested action item, and the resulting content isn't readable. I widen the width of the column, which widens the width of my window, which obscures content in the window below the Inspector.

If widening the column simply added a horizontal scrollbar, all my content would remain a scroll away. Instead, I have to either resize the window or move the Inspector.

That's an excellent use case demonstrating a problem with the design.

The big issue for me is that for the year or so I've been using OF, this has never been considered a "problem" by the Omni team (at least, not that I recall). It's how it was designed, and works as designed.

Oh, sorry if we ever came across that way! Just because it works as designed doesn't mean that the design is perfect, and I apologize if you ever felt like we weren't listening to feedback on the design.

We introduced this resizing behavior fairly late in the UI design cycle (in November), and simply hadn't had a chance to revisit it since then. We don't quite have time now, either, but we hope to have time to work on issues like this very soon (once we get synchronization out the door).

[joelande]

...we were trying to avoid the little time-wasting dance ...

I personally wouldn't mind OF's current column resizing behavior -
it would work for me, and I think is a reasonable approach to the issue...

*IF*
*IF*
*IF*
*IF*

OmniFocus wouldn't keep "forgetting" that I want the @#$%# dates fields enabled, and turning them off when clearing a perspective.

I have "reset" the supposed "default" settings following the instructions in the sticky, and following suggestions from the OF team after asking them for help with the issue.

Nothing works.

It is just hit or miss with the stickiness of my date columns, and is the single most frustrating experience of OmniFocus, by far.

[Brian]

Joe - if you're still having trouble with this, can you zip up your perspectives folder (from Application Support/OmniFocus) and your preferences file, then send those to the support ninjas?

We'll see if we can figure out what's going on here. I haven't seen that problem on my machine in quite a while, so I'd like to see what's going on here.

Thanks!