In April, Matt Neuburg of TidBITS wrote a review of OmniFocus. For those who don't know Matt, he has some incredible credentials when it comes to reviewing productivity software, particularly in the outlining space: as early as 1993, he wrote some great reviews of Acta and Inspiration, IN CONTROL, and MORE. (And those reviews compare those outliners with the old Apple ][ incarnation of ThinkTank, so clearly it's a space he's been thinking about and working in for a very long time!)
In Matt's review of OmniFocus, he pointed out some of its version 1.0 interface quirks, then said:
With all these gripes, you might think my assessment of OmniFocus would be largely negative. It isn't. I would still insist that OmniFocus is the best expression of GTD on the Mac that I've ever used. Its existence has relieved me of stress and helped me accomplish more in less time.
But those interface quirks did keep him from recommending it without hesitation. We highly value Matt's feedback, and we immediately started reviewing the quirks he noted to see how we could improve OmniFocus in future updates.
Matt's review was great: it not only said what was good about the product now, but also talked about how we could improve it in the future—and at the time, I felt no need to comment on it. But in the last week or two Matt's accompanying screencasts of his frustrations with some of those quirks started getting a lot of additional attention (perhaps because Daring Fireball linked to them), and since lots of people have asked what we think about his feedback I thought I should comment on the quirks he presents in those screencasts. (Please forgive me if this is a bit longer and drier than our usual blogging fare!)
So, here's my summary of Matt's issues presented in his screencasts along with my response to each issue:
Matt's first concern is with the ghosted field labels which are displayed when the user moves the mouse over different rows. One of our design goals was to avoid relying on fixed column headers, because each row in OmniFocus has its own set of fields. (For example, rows representing inbox items have both a project field and a context field, but rows representing projects have neither.) For the first several months of the beta we didn't even have the option of headers, but we ultimately decided to introduce them as a way to directly resize fields. But they're still hidden by default because they change based on the current selection (since each row has its own set of fields).
Since we didn't have column headers, we started thinking about how to help the user understood which field did what (which is the start date and which is the due date?), and for inspiration we looked to iTunes. In iTunes, the selected row always has a ghost rating field visible so that you'll know where to click to assign a rating.
We've applied a similar model to our fields in OmniFocus, adapted to highlight whichever row is under the mouse because you don't have to select a row before you can edit it. So, when you move the mouse over a row, a ghosted light gray flag icon appears to indicate where you can click to flag an item—and if you show the optional Due date field, a ghosted “Due” label appears in it when it's empty so you'll know what that field is for. We've tried to tune this highlighting to be pretty subtle and yet still be visible when you are looking where the mouse is currently pointed, but we agree that it's not perfect and we're continuing to improve it.
Matt's screencasts expressed some concern that the user might be confused over whether the ghost flag was real or not, but they didn't show what happens when either of those fields actually has some content: the flagged column has a bright orange flag, and the due date column shows an actual date. (And, of course, the entire row turns red when something is actually due!)
We now have tens of thousands of customers using OmniFocus, and most of the feedback we've received seems to indicate that this arrangement is working quite well for most of them. But we're still working to improve it, and we're always willing to listen to alternative suggestions!
The next quirk was that we were using a non-standard combo box field for our projects and contexts. It's certainly true that it's not a standard field: we want the user to be able to type a few letters to quickly select a project or context: for example, unlike a standard combo box I can type “dofip” or “omnif” to select my “Develop OmniFocus for iPhone” project. This is an important feature when you're trying to get something out of your head quickly!
Unfortunately, as Matt points out, those fields do currently have a bug: there's no good way to cancel a selection if you change your mind about your entry. You can back out and empty the field using the Delete key, but as he suggests you should also be able to press Escape or click away from the field to cancel input—and unfortunately those actions currently accept your input. (You can undo your change, of course, but undo shouldn't be a replacement for cancel.)
<
p>
But other than that bug (which we're planning to fix), we've been very careful to emulate the standard Cocoa combo box behavior with respect to mouse activation, clicks, and drags. The other behaviors he described are the way standard Cocoa controls behave: when you drag down on a combo box, the highlight follows the mouse and releasing the mouse pointer selects whichever item is currently highlighted. But if you instead click on the combo box to open the list (which is what he did), mouse movements are ignored until you click on an item to choose it.
Similarly, Matt is concerned about issues with the calendar widget, stating that these problems are all caused because we've “designed these bad widgets” rather than just using the stock Cocoa widgets that “just work.” We totally agree with him about the misbehaviors of the widget itself, but the irony here is that we're actually using the stock NSCalendarView control. We didn't write our own; we have no desire to write our own. (But we do want it to work right, so perhaps we'll have to write one to fix some of those issues!)
(As an aside, he could have cancelled his selection by just clicking back on the same calendar icon he used to open that calendar, rather than moving the mouse first. But we still agree that clicking somewhere else should also have cancelled the calendar selection.)
- On to the second screencast! Matt's first issue in this screencast is that there's no visible focus when nothing is selected. (Matt didn't demonstrate this, but this is only an issue when there's no selection: if there's one or more items selected in either the sidebar or the main outline, you can tell which has focus because its selection appears in your highlight color rather than in gray.) Well, we agree, that's a problem, and unfortunately this is a common issue in Mac applications when there's no selection. (Mail has the same issue with its sidebar, for example.) I haven't yet seen a good solution for this, but if you have I'd love a pointer!
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 than the window and then narrower again, you'll find that it makes the whole window wider and then narrower.
Now, just because there's precedent in the Finder for a window resizing along with a column 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.
[EDIT: Expanding on this a bit to explain the problems with other approaches in more detail.]
We considered Finder's list view behavior (which we also use in OmniOutliner) of introducing a scrollbar, but that's not perfect either: in OmniFocus, everybody wants to see all the fields all the time, not some subset. (This is especially true because we have different fields on different rows.) If we hide some of those fields behind a scrollable area, the very next thing the user will want to do is to try to make the window fit the new width of the columns, which (as I mentioned above) can take a lot of fiddling. We were trying to save people this extra fiddly step by making the window fit at all times.
We also considered Mail's solution: Mail solves the “exact width” fiddling problem by taking the size away from another field. But with that approach, making the project field wider would make the context field narrower, which isn't usually what people are trying to accomplish. (If they finally got their Context field just the right size to fit all their contexts, they don't really want it getting smaller just because they now need to make their Project field a little wider!)
<
p>
[END EDIT]
Maybe a preference is in order here? Again, suggestions for how to solve this are welcome! Just remember, one important design principle is that the edge that you're resizing should stay under the mouse, not wander off somewhere else.
<
p>
- Next, Matt demonstrates a bug where a row beeps if you double-click on its handle—which, yes, is a bug. We'll fix it! (Double-clicking on a project opens it in a new window, but you can't open an individual action in its own window so that currently beeps. What it should do is fall back on the single-click behavior, not beep!)
Matt points out that it's very unclear exactly where to click to expand or collapse a row rather than selecting or dragging it. We agree that it's hard to tell exactly which pixels will do what, and I think the easy solution here would be for us to give better mouse pointer feedback (like we do when you mouse over the resize bars in the column headers).
(As an aside, you don't have to click precisely on the little black dot on the left to drag a row around: you can actually drag a row vertically from anywhere on the row: that handle, or the checkbox, or even the text itself.)
- Finally, Matt asks what you can do to select nothing. Well, good question! The way to select nothing in OmniFocus is exactly the same way as you select nothing in the Finder or iTunes or Mail: you either click on some empty space that isn't selectable (which isn't always easy to find, unfortunately), or you command-click on your current selection to toggle it. (I wish this were more obvious, but this is the standard Mac behavior.) [EDIT: Chris Campbell's comment below made me realize that OmniFocus does have a Deselect All command in the Edit menu, with a keyboard shortcut of Shift-Command-A.]
Let me conclude by saying once again that I have a lot of respect for Matt's feedback: he's been writing about this application category for a very long time, and he's pointed out some important issues which we hope to address as soon as possible. Our goal is to fully earn his final words from the review:
I've raved in the past about Omni's interfaces; OmniGraffle is brilliant for drawing diagrams, and OmniPlan is an astounding accomplishment, a triumph of interface ingenuity and the first project management application I've come even close to comprehending. I've little doubt, and much hope, that the same standards of excellence can be applied to OmniFocus; when OmniFocus has the fluid usability of Omni's other applications, I'll be eager to recommend it.
Thanks, Matt: we're working on it! (And thank you, reader, for taking the time to read all this; if you have any thoughts of your own, we always welcome your feedback! The best way to make sure the right people see your suggestions is to send them in email to omnifocus@omnigroup.com.)
