Matt Neuburg's review of OmniFocus

The Blog

by Ken Case on June 25, 2008

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

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!)

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

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

Comments

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

The OS X 10.5 Finder doesn't seem to exhibit this behavior - was this observation valid for 10.4?

Shawn Medero

06.25.08 5:31 AM

Team Member

Hmm, no, it works that way for me in 10.5 in Column mode—I just double-checked!

Oh, I see: if the window is full of columns and you drag the right column wider and then narrower it resizes the window along with it. Or, more precisely, it happens whenever you resize a column to extend past the edge of the window.

Ken Case

06.25.08 5:50 AM

I didn't mind so much his criticism, as

1) I'm a keyboard-centric user and didn't even know those bugs existed.

2) It'd only serve to make the product better

What I _did_ mind, however, was his attitude. He was whiny and petty in his screencasts—you handled his criticism very, very well.

I applaud you.

MacDork

06.25.08 6:12 AM

I agree with MacDork. It wasn't so much the content of the original review, but rather the sensationalized presentation (particularly the screencasts) that turned me off.

Anyway, this post is a welcome response. And, of course, it's good to see that the Omni Group is addressing these concerns.

Dennis

06.25.08 6:22 AM

Ken, I'm glad you addressed the concerns he brought up since they've been getting so much discussion lately. I can't say I think about them much now that OmniFocus has been out a while but there's always room to improve.

I have to admit also being turned off by his attitude. I remember a while ago asking him about something in one of his O'Reilly books that wasn't clear and (while I appreciate his taking the time to respond to me) found him to be short with me as well, so it's hard for me to look at his criticisms with an unbiased eye. And I still don't get his “snarky” help doc complaints: David Spade is snarky; the help doc was just humor that wasn't to his liking.

joecab

06.25.08 6:32 AM

I'm glad you are addressing Matt's criticisms and I'd just like to contribute my own collection of “visual bugs”.

Here they are:

http://img252.imageshack.us/img252/5631/omnifocusdg5.jpg

I was quite surprised that Matt didn't mention any of them.

I am paying customer for several apps from you guys at OmniGroup. (Web, Graffle, Outliner) I really like OmniFocus. But I definitely won't buy it with these “bugs”. They simply make by eyes bleed. (Matas will feel an even bigger pain, I guess)

Guys, please don't neglect the details of GUI design.

Vincent

06.25.08 8:23 AM

I had watched the screen casts before and immediately opened OmniFocus and tried to reproduce the problems reported by matt and I was amazed that none of them have crossed my way because I use OmniFocus in a different way always. For example never enter the date control when I don't want to pick a date.

The answer from OmniGroup is what I expected, they accept the critics from Matt and say they will improve OmniFocus. I'm a very happy customer of OmniGroup software (Focus, Graffle, Outliner and Plan).

Jorge Carreira

06.25.08 8:51 AM

Ditto Vincent's post on these annoying visual bugs.

Ghibertii

06.25.08 9:02 AM

I thought his delivery is of a man who is genuinely frustrated, not sarcastic or haughty. His feedback was incredibly detailed so he obviously cared. It's those little things that kept him from enjoying the product.

As he went through them, I realized I had the same issues when I demo'd and did not buy OmniFocus. The interface learning curve is too steep and too unique. OmniOutliner/Kinkless suffers from the same quirks that make it frustrating to use on a daily basis, for me. OmniOutliner is the best one of its kind out there but I don't enjoy using it as much as I do other programs [Excel, iCal, Evernote]

The precision thing drives me nuts when I work on planes and trains. You just can't be as precise as you can at home, on a desk, with a mouse. And if you dim your screen to preserve battery life, elements of the screen can be hard to see. I travel a lot so these issues prevent me from using the program in key scenarios.

mitchprnzstr

06.25.08 11:46 AM

Good feedback, and a good response.

In general, I'd say fix the things you acknowledged as bugs and don't worry about the rest of Matt's gripes.

One thing to consider, though: the clickable regions for many things are just too small - namely, the checkbox to mark an item complete and the “handle” button to the left of the checkbox.

FWIW, I like the ghosted field labels - particularly when you have a lot of skinny columns, it's hard to tell which column you're hovering over; the labels really eliminate this problem.

Geektronica

06.25.08 12:31 PM

I'd like to put in a vote for a “deselect all” command, perhaps with a command-D shortcut. I realize that wouldn't be “standard Mac behavior,” but OmniFocus is a specialized app, like Photoshop. The ability to easily deselect all items using only the keyboard (command-click is too slow) would help me “unfocus” my attention from the selected items and take in the big picture.

Scott

06.25.08 2:20 PM

Wow, Mac users are really getting greedy. Complaining about the icons being off by a few pixels? Who cares, as long as it works, right?

Let's let the developers worry about what matters: iPhone syncing, browser access, better support for attachments (a must for the iPhone-compatible update), and better exporting capabilities.

It's quirky, sure. I just started using it yesterday, though, and I think I have every feature and process in OF mastered. I don't have much free time, either.

The developers are doing a great job. Keep giving suggestions, e-mail them, and discuss those suggestions in the forum, but quit crying about the things that matter the least.

Derek Conjar

06.25.08 3:24 PM

> you can tell which has focus because its selection appears in your highlight color rather than in gray

If you set your highlight color to Graphite (as the most people I know of do when they opt for Appearence in Graphite instead of Blue) it is barely distinguishable.

Why not do what every other app does: choose two usable color schemes for the sidebar based on the Appearence and not the Highlight Color?

Sebastian Siedentopf

06.25.08 5:55 PM

[...] habe ein wenig in den Kommentaren des OmniGroup Blogs herumgestöbert und bin auf folgendes Bild [...]

Typische Kritikpunkte eines Mac-Users - apfelquak

06.25.08 7:35 PM

Derek, the interface is actually the only part of an application that you actually see when using it.

This makes it a very important part of the app.

If a user doesn't like unfinished unaesthetic look of an app he simply won't use it.

No user = no customer.

One other thing, Derek: how come you know that icons are the tings that matter the least? You're just one small user who hasn't even used the app any longer than one day (as you said by yourself).

I for one don't give a damn about iPhone synching, attachments and exporting. But I wouldn't call those features “unimportant” just because I don't give a sh*t about them.

Vincent

06.26.08 12:31 AM

If your eyes bleed and software is made unusable because of one-pixel differences, well… wow. Oversensitive doesn't begin to describe it.

The software works; quit obsessing over meaningless details. You'll get more done, which is kind of the point.

Steve

06.26.08 3:37 AM

This is a pretty weak defense of OF's non-standard window-resizing behavior when columns are resized. I'll note a few differences/problems.

(1) The Finder NEVER makes the window smaller than its original size. If you drag a column to the left in the Finder, it adds more columns; it doesn't shrink the window. OF immediately makes the window smaller if the user makes a column smaller.

(2) The Finder only makes the window bigger if the drag point itself moves past the right edge of the window. OF makes the window bigger from the get-go.

(3) The Finder doesn't exhibit this behavior at all in list view mode, which is the mode that is most similar to OF's display.

The Finder's behavior makes sense to me. It's reasonable to increase the window size if the drag point goes outside the window. It's pretty surprising to increase the window size when the user is dragging completely inside the window.

Chris

06.26.08 3:58 AM

Team Member

Vincent: Thanks for the detailed notes! Those sorts of alignment and padding issues bother us too, and we'll see what we can do to fix them. (Working at that scale is always challenging, as I'm sure you know! You need to make icons large enough to give clear detail, but small enough to leave appropriate padding. And icon details like the faux outline rows can't be scaled up or down easily: one pixel closer together and they suggest something totally different.)

Scott: I wouldn't want to the default binding of Command-D to be Deselect All rather than its standard meaning of Duplicate, but if we add the menu item (which seems reasonable) you could certainly bind it yourself using System Preference.

Sebastian: Apple defines a standard list selection background color, so rather than make up a color of our own we're trying to follow the user's color preferences. (When the user chooses graphite to tone down the color in the interface, would they really want us to ignore that request and just apply our own colors anyway?)

Chris: The reason for the current behavior isn't that Finder resizes windows when resizing a column, the reason is that the user usually doesn't want either dead pixels or lost pixels which is what usually happens if you leave the window size alone. (You can solve the dead pixel problem by using a horizontal scrollbar, but then you lose vertical pixels to an unnecessary scrollbar and also spend time trying to futz around to get things to align perfectly so that the scrollbar will disappear.) Did you have a suggestion as to how one might solve that problem?

Ken Case

06.26.08 5:05 AM

Steve: “one-pixel differences” aren't important for a medium sized icon of say 128px. No doubt about that. But in case of 16px icons a one-pixel difference can have a huge impact. It's the relation of the difference to the total icon size that matters, keep that in mind. And I'm not talking about one single mispositioned icon. I'm talking about like two out of three icons in OmniFocus.

Ken: Yes, I understand the problem here. I just hope you get it fixed. I just wanted to point these out as long as the attention to this thread is as strong as it is right now. ;-) I only want your best, guys :D

I'd like to quote Mike Matas, as he just speaks out of my heart:

“When I say “It makes me nauseous thinking how low Omni has fallen” I am not talking about their icon design. I am talking about their complete disrespect for the importance of all aspects of UI design (that is everything from icons to windows to button layout to drag and drop interaction). I worked at Omni for two years as a UI designer along with Wil and Rick and over that period there was an accelerating amount of disregard towards our work. Over the past year Omni has fired all 3 of it's UI designers, the only people at Omni with a real passion for that part of software. In the same way it is impossible to make great software with out great coders it is impossible to make great software without great designers. You need booth pieces to make it work. What I am saying her is ilconceived arrogant rebelling, it is what I know about the situation after working Omni for 2 years.”

http://www.mikematas.com/2005/02/omnioutliner-3-replacement-icons_17.html

Vincent

06.26.08 5:22 AM

Team Member

Vincent: Our best icons of that era (as measured by awards won and user popularity) were designed by Rick rather than Mike, but we've always placed a high importance on the contributions made by all our UI designers. (Obviously it might not feel that way to someone who had recently been let go, but the reasons for that had nothing to do with the value we placed on their design work. The quality of that work is why I hired them in the first place!)

I think we have a great UI team in place now, though they're sometimes stretched a little thin! (I believe these particular glitches slipped through the cracks because they were busy updating every part of the OmniGraffle 5 interface. And, of course, since then they've been busy working on the iPhone version of OmniFocus—which just won its own Apple Design Award a few weeks ago.)

Ken Case

06.26.08 5:29 AM

Another way to “select nothing” in the Finder is to type Command-Option-A, for Edit > Deselect All. In iTunes, it's Command-Shift-A, for Edit > Select None.

Chris Campbell

06.26.08 7:00 AM

Team Member

Chris: Command-Option-A! I had no idea (go hidden menu items), thank you for pointing that out. Of course, now that I think to look in Edit menus, I realize that OmniFocus already has Deselect All with the same keyboard shortcut as iTunes (Shift-Command-A).

Ken Case

06.26.08 8:43 AM

I love Ken's lengthy response to the critique, and the dialectic that may have emerged to improve the product.

I don't particularly understand Dennis's comment, though: “It wasn’t so much the content of the original review, but rather the sensationalized presentation (particularly the screencasts) that turned me off.”

I thought that it was extremely useful to see precisely what Matt (a close colleague and fellow editor of mine, for disclosure's sake) was commenting on. Without it, I'm working on mapping his description of the behavior to the behavior.

Matt is pretty funny, and I don't say that just because I work with him. He's using rhetorical principles to illustrate his frustration with things that act in a way that don't conform to his expectations, nor the expectations he thinks most people will have.

I don't see that it's sensational to use a screencast to explain one's views. In fact, as I read in the comments, the screencasts allowed people to more easily agree or disagree with the points Matt made.

Glenn Fleishman

06.26.08 9:33 AM

Vincent, I see that Ken already replied, but I'd like to chime in. The three people you mentioned certainly did a lot of great work here, but I strongly disagree with Mike's (now dated anyway) characterization of Omni as a place where no-one other than those three had real passion for the user experience. Even at that time, we cared greatly about the user experience as a company, and we have individuals here who are extremely passionate about user interface work.

We agree that single pixels _are_ important, and are constantly working hard not only to improve our apps in brand new ways, but also to address any issues that we missed the first time around. We always appreciate constructive criticism, so thanks to everyone for the detailed feedback, and keep it coming!

Andrew

06.26.08 9:46 AM

from the article:

Matt’s next issue was with our column resizing behavior […] (I’m personally inclined towards picking the next resizable field and adjusting its size to compensate, but what if you’re trying to resize the last column? […])

No! Please don't! I've used Windows apps that work like this and it leads to nothing but frustration, where you intend to resize two columns, but resizing the first screws up the size of a third, and then you adjust the second one, but that messes up both the first _and_ third, and then… I strongly suggest you use the behavior exhibited by the iTunes library. Each column resizes completely individually. If you shrink a column such that the total area used takes up less than the full window, it leaves empty space on the right. If you expand a column so the total area extends beyond the window, a scroll bar appears. If you resize the window, it doesn't mess with your perfectly sized columns. Every other approach I've used ends up feeling like an unwanted game of Resize-a-Mole.

Harold

06.26.08 11:22 AM

Nice report. I never noticed most of these bugs, but I use my keyboard mostly.

For me the biggest problem with omnifocus is not having it on my iPhone yet. i care about that a lot more then these tiny bugs. Glad to hear people have been working on that. I will be the first in line to buy it.

Brian

06.26.08 1:28 PM

Glenn Fleishman wrote:

“I don’t see that it’s sensational to use a screencast to explain one’s views.”

Oh, I agree completely. Using the screencasts was a brilliant idea. Matt really brought clarity to some issues that would have been difficult to adequately explain with words alone.

However, it was the *way* the screencasts were presented that I remembered as being sensational. To be fair, I just now went back and watched them again to refresh my memory.

I must admit that on second viewing, the screencasts aren't as “over-the-top” as I had remembered. Maybe “sensationalized” is too strong, but there's still a certain mannerism that I find irksome.

Maybe Matt is just very passionate, or maybe the style is meant to be funny and I just don't get it. But to my ears, the “rhetorical principles [Matt used] to illustrate his frustration” come across as a little too much. I think it hurts the credibility of the review.

For me at least, a more dispassionate stance would have yielded a more balanced critique. Of course, such a screencast might also be less entertaining.

Anyway, it looks like Matt's work will likely bring about positive change, so I'm happy.

Dennis

06.26.08 1:49 PM

Vincent, you can try to justify your opinions however you want. Sixteen pixels is .0007% of my monitor. You'd need hundreds of icons to come even close to anything that matters in my opinion.

Fine; you care about it. I don't. I'm being more productive with OmniFocus. You're not. That's your right, and that's your loss.

(I won't even touch the issue of using blog posts from disgruntled ex-employees to try and grant your argument any legitimacy. Blog posts which the author himself states are “ilconceived” (his spelling) and “arrogant”.)

Glenn: The original review and screencasts were posted back in April. There's a forum thread about it on Omni's forum. They corrected the 'custom controls' mistake back then - why wasn't there a correction on TidBITS?

Sure; he's your friend. How would you feel if he came over to your desk and delivered a critique of your work in the same breathless style he's using in the screencasts? Would you still find it 'funny'?

Vincent and Neuberg both like to toss around terms like 'years of futility' and 'make my eyes bleed' because they think it's funny and/or makes them sound smart. Personally, I just think it's mean, and if they do 'want the best', they have a funny way of showing it.

Steve

06.26.08 4:28 PM

How about I paid $80 for Omnifocus, and I don't own an iPhone. Why do I feel left out of things like computer syncing so that everyone can get their iPhone app?

It makes me sad. It was a large expense and I'd really like to see Omnifocus grow quicker then I'm sure it's iPhone app will.

Kenny

06.26.08 4:36 PM

Team Member

By the way, I've edited my notes on the resizing window quirk to clarify that I didn't mean that the Finder had the exact same behavior as we've adopted, just that there was some precedent for resizing a window with a column.

I've also expanded on the problems with the other approaches that we considered. (The new paragraphs are marked with “EDIT: Expanding on this a bit”.)

Steve: Some people do express themselves more dramatically than others, but no worries: I found Matt's feedback to be edifying, and Vincent's feedback has already resulted in some updated designs for our internal builds of 1.1. They're dramatic about their feedback because they care, and we'd much rather write software people are passionate about. (We feel that way about software ourselves!)

Ken Case

06.26.08 4:55 PM

Team Member

Kenny: Computer sync'ing has been where the bulk of our effort has gone over the last six months, and it's almost done. We'll be shipping that in sneaky peek builds of 1.1 within the next week.

Ken Case

06.26.08 5:13 PM

Vincent, thanks for the diagram of icon positioning issues you found! It's reminiscent of the reports I attach to internal bug records here at Omni. And I'm happy to say that all of the problems you pointed out have already been fixed for OmniFocus 1.1! I hope you'll be pleased when you see it.

wvh

06.26.08 5:44 PM

> Sebastian: Apple defines a standard list selection background color, so rather than make up a color of our own we’re trying to follow the user’s color preferences. (When the user chooses graphite to tone down the color in the interface, would they really want us to ignore that request and just apply our own colors anyway?)

Ken: That's true and I am certainly pro choice if possible, but in the sidebar case you a) already came up with an arbitrary background color (that renders a Highlight Color that works beautifully on white background useless) and b) you have a second state: highlighted, but not active, and the user can't define the color for that either.

I hate the inconsistent coloring in the sidebar (esp. Apple apps) as much as everyone else, but yes: after several years I'm totaly used to broken sidebars with random color schemes now. And at least it can't lead to a situation where the functionality (i.e. to highlight an item) is broken.

Sebastian Siedentopf

06.26.08 6:19 PM

It's Neuburg, by the way.

The Rizland Observer

06.26.08 8:48 PM

I want to back up Vincent's critiques of the placement of icons (although not buying the app on those grounds might be a bit extreme!) but also say that most people who aren't designers don't see these things and get turned off when we talk about them as if they're the end of the world. (clients in particular - try having a conversation about why a project's delayed because you spotted a bit of bad kerning between a W and an O!)

Details matter, but not as much as getting something working. You can always address the details later, as it seems Omni have done. True crafstmanship is evident in knowing when something is good enough, not in knowing when it's perfect. In my experience (as a former pixel-obsessive) if you refuse to release something until every last detail of the interface is correct, you'll never release anything ;-)

Jonathan

06.26.08 9:42 PM

Team Member

The Rizland Observer: Woops, thank you for the correction! I've edited the page to use the correct spelling of Matt's last name. (Unfortunately it's still in the URL itself; I'm not yet sure how to correct that.)

Ken Case

06.27.08 1:15 AM

Ken: Re the resizing “problem”, I don't have a problem with the behavior of Mail.app. It seems perfectly reasonable to me to have the sizing of the columns be independent of the sizing of the window. If there's too much white space, I can make the window smaller; if there's not enough room for the columns, I can make it bigger. I've never had the “futzing” problem you refer to.

It seems to me that OF is being too clever by half and ends up coupling two things together that should be independent.

Chris

06.27.08 7:28 AM

re: column resizing and resultant issues this causes with window size, isn't this precisely the issue the standard “size to fit” window button solves nicely? (Something missing from Windows, btw.) No fuzting required.

I'm surprised no one has mentioned it, which is perhaps an implicit commentary on Apple's UI design. :-)

Joe B

06.27.08 2:26 PM

Glenn: The original review and screencasts were posted back in April. There’s a forum thread about it on Omni’s forum. They corrected the ‘custom controls’ mistake back then - why wasn’t there a correction on TidBITS?

TidBITS archives its articles; they aren't all malleable. They represent information that was current on the date they were posted. I (and other editors) don't agree with changing posts to reflect any change in the content.

If there's an error in what we wrote, or something changes quickly, we correct that and mention it in an Editor's Note. Sometimes, if it's quite useful or important, we'll add that note months or even years later. But we treat published articles as published articles, using our forums (TidBITS Talk) and newer articles linked to the old ones to provide refreshed information. (Whenever we reference an old article, we note this in the text of the article, and then have referral links in both directions in a couple places in the article's interface, too. The older article also gets a link forward automatically, even if we don't change its text.)

Sure; he’s your friend. How would you feel if he came over to your desk and delivered a critique of your work in the same breathless style he’s using in the screencasts? Would you still find it ‘funny’?

Somebody, and it's neither me nor Matt, is a bit too close to this. Matt is damned funny, and fully passionate. And, yes, in fact, he does use the same style among friends and close colleagues, and it's generally funny, appreciated, and results in change!

Glenn Fleishman, Seattle, WA

06.27.08 3:09 PM

The iPhone integration is a big deal; it is a major reason that I am considering purchase of an iPhone or an iPod touch. That said, I think many of the criticisms are really on-target. The fiddlines of the mouse targets is particularly irksome. I'm sure that at least some of the folks know about the human factors work on this problem; if they do, then they know that the %&$^&#% targets are too small. Window resizing behavior may mimic the Finder, but that is faint praise indeed.

As someone said upthread, we only want your best, folks!

Alex Merz

06.28.08 6:24 AM

I agree with Harold who stated that the iTunes column resizing behavior would be the ideal choice for OmniFocus. All of the other comparisons (Finder, Mail, etc.) that have been put forward do not fit because they have different window styles than OmniFocus. The fact is that the current behavior is VERY STRANGE and disconcerting to anyone that has been using a Mac for any significant amount of time.

I use OmniFocus every day because at its core it is a useful application, but I would love to see improvements that will make the app easier to use. It is the type of app that should do its job and then get out of my way. These quirks can slow me down when using it, which takes away a little bit from the time it saves me otherwise.

1) Please make it easier to check an item as done.

2) It makes no sense whatsoever that if I have projects grouped under folders and when I am entering a project in context mode it displays in this manner

Foldername : Projectname

that when I enter a new project as

Foldername : NewProjectname

and then press Command-Enter to create a new project that project is not created in the folder Foldername but instead is created as a new project named

Foldername:NewProjectname

and NOT placed in the Foldername folder.

This is the type of interface inconsistency that allows OmniFocus to slow me down. I don't mind you doing a few custom things but at least make your custom things work consistently.

Frank

06.28.08 6:40 AM

Glenn, you just spent a whole lot of words to say “when we make mistakes in our reviews, we either don't correct them”. Mistakes were made, they were pointed out to the author (the proof is on Omni's forums) and none of the things you describe were done.

That's all I need to know. When reading in the future, I'll take it all with a giant grain of salt.

steve

06.29.08 9:38 AM

I hit post when I shouldn't have, but ultimately, you're probably right. I don't know why your correction policy didn't get followed, but it's really none of my business.

I am taking a break from the internet, starting right now.

Steve

06.29.08 10:08 AM

Two suggestions:

A big problem I have with OmniFocus is that there is no focus ring on the sidebar. A focus ring would make it much easier to see that the sidebar has focus, and therefore keyboard commands would affect the sidebar.

The Deselect All keyboard shortcut would be useful if there was a keyboard command to switch focus to the sidebar. If the content pane has focus, I don't see any use for it.

Consider this search scenario:

I'm about to enter something, but I want to do a quick search to see if I've already entered it elsewhere.

I currently have a project selected in the sidebar, and a text selection in the content pane, so the content pane (rather than the sidebar) has focus. Also, there are enough projects in open folders in the sidebar that there is no 'empty' space to click on in the sidebar, and the Library is scrolled out of view.

To do the search and then get back to where I was:

1. Change sidebar selection so that the entire document is searched: Scroll up the sidebar so that Library is visible, and click on it. This is what I have been doing, but now that I know about Deselect All: Click on any item in the sidebar and choose Deselect All. The later is better because searching will include the Inbox.

2. Click in the search field, and type my search text.

3. I'll see all projects, actions, and groups that match. Note that I can't see which folders they are in.

4. To get back to where I was: scroll the sidebar back down and click on the project I was in before the search. Click in the content pane.

David A

06.30.08 5:23 AM

This response to Matt's review frustrated me. It never gets out of the details, and so I can't find any response to what I took as his big-picture message: It's hard to quickly and intuitively see what tasks you need to do after you've entered them!

As someone who bought OF, tried to work with it a lot, and now is using it as a glorified someday/maybe bin (just throwing stuff in the inbox), I agree completely with him. That's why I don't use it. I didn't get much benefit out of sculpting my data into projects. It didn't help me see and think about (and forget about) what I need to do. I *do* think pixels are important too! But how about some responses to the comments about general workflow.

Josh

06.30.08 5:35 AM

One other random note: Matt says that when you complete all the tasks in a project, that project should automatically get marked as complete.

I disagree - usually, when I complete the last task in a project, it's because I've only defined a few next actions, not every action I'll need to take to complete the project. If the project disappeared from view when I checked off my last task, I'd be confused and frustrated.

I like the current system of how projects are marked as complete (manually, and irrespective of the tasks they contain).

Geektronica

07.01.08 3:43 AM

David: Command-4 will move your focus into the sidebar. Then you can do the Command-Shift-A to deselect all, and hit Command-Option-F to get into the search field. If your normal view has grouping by folder turned on, that's one way you could see the hierarchy for the results.

Of course, another way is to open another window (possibly on an “All” perspective that already has no sidebar selection). Then you can do your search there and leave your current workflow intact.

wvh

07.01.08 4:17 PM

For the focus on the sidebar or the main panel, i suggest a simple line frame around the active zone.

gamov

07.01.08 5:53 PM

[...] wheel. As a company, they also seem to care about the users of their products given that they went out of their way to cite a review on their blog which contained both praise and [...]

The Omni Group Gets “Sneaky” With Omni

07.02.08 7:59 AM

The comment in the review of the application that most resonated with me is one you fail to address. Where is a calendar interface, and/or a way to sync items with due dates to iCal's calendar rather than iCal's tasks, so one can better visualize when a bunch of projects are due, relative to each other?

Marshall

07.06.08 4:22 AM

Commenting is not available in this channel entry.

The Blog

RSS

Related Articles

Recently Featured

Articles by App