[Toadling]

Originally Posted by jashan

And, in some cases, it looks a bit like the wheel was re-invented.

I think some of the "oddities" you mentioned actually pre-date the "standard" behavior we've come to expect in other Mac OS X apps. So maybe it wasn't Omni that reinvented the wheel, but rather those that followed later. ;-)

Kidding aside, I think some of the interaction behaviors in OmniFocus are actually better than the standard Mac OS X fare for this type of app. The behaviors OmniFocus employs are specifically designed for *outlining* rather than rigid database interaction.

I'm not sure where or when Omni's outlining engine originally appeared, but I would guess OmniOutliner in the early '00s. Variations (subclasses?) of the design seem to have been adopted by many of their other apps (e.g. OmniGraffle, OmniPlan, and, of course, OmniFocus).

The beauty of this outlining engine is that clicking, selecting, and cursor movement when editing row content feels as simple and natural as editing lines in a text file:

• Single-click to place your cursor in a row's text for editing. By comparison, the standard behavior requires a cumbersome click to select the item followed by another click/return to go into edit mode.
  
  
• Single-click and drag horizontally to select a range of text within the row. You don't have to be in edit mode first, as is required by the standard behavior -- Omni's approach requires fewer clicks.
  
  
• Click and drag vertically to move the entire row elsewhere in the outline. Alternatively, select the row's handle (bullet on the left end) to manipulate the entire row.
  
  
• When in edit mode you can use the arrow keys to move the text cursor up and down *between* rows or backspace from one row right back through to the previous row. The standard behavior in most Mac OS X apps treats each row as a distinct entity and doesn't allow such seamless editing; you need to leave edit mode in one row and then re-enter edit mode in another row.
  
  
• Hitting return gives you a new row/item, just like adding a new line in a text editor.

These behaviors might seem unusual at first, but that's only because you need to think in terms of editing a *document* (e.g. as in a word processor) rather than manipulating a rigid database model with distinct, unrelated, individual items.

For an app like Finder or iTunes, where objects are conceptually separate, the standard model works well. But for a outline-based app like OmniFocus, where you often need to make large numbers of quick edits, Omni's approach works better.

As for the somewhat confusing behavior of the Return, Enter, and Escape keys, I agree there's room for improvement. I like Bill's suggestion that a single Return commits the edit, while a second creates a new row.

In the meantime, you can use this hidden preferences to disable the Escape key for exiting edit mode:

defaults write com.omnigroup.OmniFocus OOShouldToggleEditingWithEscapeKey -bool false

One advantage to doing this is that the Escape key can then be used to trigger Mac OS X's built-in text completion.



-Dennis