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

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

 
OmniFocus and Mac User Interface Conventions Thread Tools Search this Thread Display Modes
Hi there,

I'm currently evaluating OmniFocus and Things and am currently only using OmniFocus so I guess the decision is already made ;-)

So, I really like OmniFocus a lot - there's only one thing I find extremely annoying about it: The user-interface. It seems to me that it doesn't really follow the usual user interface best practices on the Mac (or in some cases, computer-software in general). And that's one of the things I love about Mac: Most applications follow a simple logic which makes it much easier to switch between applications. Usually, only applications ported from Windows break this simplicity and OmniFocus is one of the few applications I have that "just don't really feel like Mac" (to me, YMMV ;-) ).

For instance: In the Finder, when I have selected any item, I can simply hit enter to get into "Rename" mode (which is usually done via F2 on Windows). However, OmniFocus will create a new action whenever I hit enter, no matter what I currently have selected. I either need to go through the inspector or context-menu.

When I'm in edit mode, instead of using enter to "enter" those changes, I have to use esc to save the changes and exit. What??? Esc is there for canceling any operation I'm currently involved in - not for saving. Maybe Apple Address Book does the same crazy thing - but that's certainly not something one should take as an example. I'll admit, though, that since Apple has already broken the usual convention for this, this one is not exactly "on-topic" … that one's already discussed in this thread anyways.

Another one that I find really annoying: Usually, when you double-click any item, you either open it or get the properties of that item (if that's what's getting closest to "opening" the item as the properties basically represent the item). In OmniFocus, when I double click a project another window opens with the double clicked item focussed, which I don't really feel makes any sense in most cases (I'd rather click "Focus" because if a second window opens, I'd have to close the first one which is much more work than just clicking that button - if double-clicking would just focus that item without opening another window, it would make some sense to me; but opening windows is just something I really don't want to do at all most of the time). If I want to open the properties, I have to select it, and then click "inspect" (or keep the inspector open all the time which I don't really want to do).

Also: Properties (inspector) should be available in the context menu when right-clicking on any item.

And: Very important - right-clicking should use whatever I clicked on as context, instead of using what I currently have selected (which is how the current implementation seems to handle it). To create a new folder / project / single-item list when another one is already selected (which is usually the case), I first have to click into the empty area (to "unselect") and then right-click for the correct context-menu (very cumbersome).

Drag and drop is another area that behaves in very weird ways: I'm starting to get used to the "I have to click that little dot / icon to do drag'n'drop" - but I don't really like this as it's not the usual way of doing things (in the beginning, I thought "oh, OmniFocus doesn't even support drag and drop" - until I started "playing around" with this "weird dot in the actions"). I see the benefit that I can multiselect without using a key - but so far, I had not a single use for multi-selecting projects but had hundreds of "drag'n'drop operations". So, I really would mind doing multiselections with the usual keys (Ctrl + click for selecting individual items, Shift + Click to select the range from the currently selected item to the one I'm clicking on with Shift).

I can see that changing all this is not only a lot of work for you guys but may also confuse users who are used to the current "style of UI" (and there's also the issue with other OmniApps following the same guidelines as mentioned in that other posting) … but to me, the current way that OmniFocus expects me to behave feels awkward and non-standard, and I'm pretty sure that will be the case for most new users.

One possible solution might be to have an option "Omni-style behavior" and "Mac-style behavior". I don't really like having options for everything because IMHO it just bloats the code but it may be the least painful solution for the users now that many are used to what I would call "the oddest UI behavior I can find on my Mac".

I hope this doesn't come across to negative or critical - I really do like OmniFocus and think it's a great piece of software; it's just that it forces me to learn a lot of stuff that's already hard-coded in my reptile brain which I think is where these things really do belong (which is why I like UI standardization across applications in an OS).

Sunny regards,
Jashan
 
Howdy Jashan,

Thanks very much for such a well thought out post. Believe me, the inconsistencies and difficulties in our apps' UI bother us more than they bother anyone else! You wouldn't believe the number of historical, practical, and technical factors that have led to the interactions we have now.

But one of our main priorities for the next round of major revisions to all of our apps is to reconsider, stabilize, and standardize the way our basic mouse and keyboard interactions work. We've already started moving in that direction by, for instance, making Enter confirm editing without creating a new row, so that you can use that instead of Escape. Ultimately, we may end up adopting the OmniPlan way across the board, where pressing Return confirms your edit, and then pressing it again creates a new item. Of course, we hope to also provide a reasonable set of preferences for matching the way you are used to working.

We can't wait to get the next generation of our apps into your hands. In the meantime, we truly appreciate your feedback about how to best improve them. Thanks!
 
Quote:
Originally Posted by jashan View Post
Another one that I find really annoying: Usually, when you double-click any item, you either open it or get the properties of that item (if that's what's getting closest to "opening" the item as the properties basically represent the item). In OmniFocus, when I double click a project another window opens with the double clicked item focussed, which I don't really feel makes any sense in most cases (I'd rather click "Focus" because if a second window opens, I'd have to close the first one which is much more work than just clicking that button - if double-clicking would just focus that item without opening another window, it would make some sense to me; but opening windows is just something I really don't want to do at all most of the time). If I want to open the properties, I have to select it, and then click "inspect" (or keep the inspector open all the time which I don't really want to do).
Many of us use and rely upon that double-click behavior you dislike so much and would be unhappy were it to disappear. What do you propose for a replacement? From context mode (where I use this feature 99% of the time), it takes much longer to focus, then switch to project mode to get the view I want (given to me automatically by double-clicking), and then I've got to do the whole painful switch back instead of just closing the new window. OmniFocus is no speed demon at those operations when you get enough actions and projects in your database, never mind the extra utility provided by being able to open those additional windows. Look at a view showing items due soon, double-click on the handful that are most critical, get windows showing them in their project context. Work those projects as appropriate, then close the windows.
Quote:
And: Very important - right-clicking should use whatever I clicked on as context, instead of using what I currently have selected (which is how the current implementation seems to handle it). To create a new folder / project / single-item list when another one is already selected (which is usually the case), I first have to click into the empty area (to "unselect") and then right-click for the correct context-menu (very cumbersome).
Why not use the keyboard or File menu options to do this? They work just fine, inserting the new item immediately behind the selected one, no need to deselect anything.
Quote:
Drag and drop is another area that behaves in very weird ways: I'm starting to get used to the "I have to click that little dot / icon to do drag'n'drop" - but I don't really like this as it's not the usual way of doing things (in the beginning, I thought "oh, OmniFocus doesn't even support drag and drop" - until I started "playing around" with this "weird dot in the actions"). I see the benefit that I can multiselect without using a key - but so far, I had not a single use for multi-selecting projects but had hundreds of "drag'n'drop operations". So, I really would mind doing multiselections with the usual keys (Ctrl + click for selecting individual items, Shift + Click to select the range from the currently selected item to the one I'm clicking on with Shift).
You get that right now, if you click on the row handles.

Have you watched the screencasts that Omni has provided on the OmniFocus product page? It sounds a bit like you're trying to learn the program just by experimentation, and that isn't necessarily the optimal way.
 
Quote:
Originally Posted by whpalmer4 View Post
Have you watched the screencasts that Omni has provided on the OmniFocus product page? It sounds a bit like you're trying to learn the program just by experimentation, and that isn't necessarily the optimal way.
Yes, I did (well, not all of them but at least some that showed many of these "oddities" - otherwise I probably wouldn't have found out about them). As I mentioned in my original post: A lot of those standards are just something that works across all applications I'm using, so only OmniFocus breaks it - which is unfortunate because the way OmniFocus usually is used makes it the last kind of application that should work "significantly differently" from all the other apps I use.

The point of those conventions is that you don't even have to learn any of the basic operations of a new application at all - all you need to learn are the specifics of the application (like "there's projects, and contexts, and actions").

That said: I fully understand that many of the things a new user might find a bit weird are things that existing users that got used to it may not want to live without, which is why I suggested keeping the old style (or at least parts of it) as an option. Btw, it's also the reason why I posted this to the forum in addition to filing a feature request via mail.

Quote:
Originally Posted by Bill Van Hecke View Post
But one of our main priorities for the next round of major revisions to all of our apps is to reconsider, stabilize, and standardize the way our basic mouse and keyboard interactions work. We've already started moving in that direction by, for instance, making Enter confirm editing without creating a new row, so that you can use that instead of Escape. Ultimately, we may end up adopting the OmniPlan way across the board, where pressing Return confirms your edit, and then pressing it again creates a new item. Of course, we hope to also provide a reasonable set of preferences for matching the way you are used to working.
That sounds like the perfect approach to me - thank you for going in that direction (well, I guess I should probably have a look at OmniPlan first - but I trust you ;-) ). And: I *do* believe that there is a significant number of historical, practical, and technical factors that have led to the interactions you have now (I also know projects with source code that tells such stories) ;-)

Btw, from my perspective, the UI doesn't look "random" - it does actually look like someone did spend some time thinking about it; it's just that these "well thought out custom solutions" are especially confusing in an application that I jump in and out of while using a lot of other applications. And, in some cases, it looks a bit like the wheel was re-invented ;-)
 
Quote:
Originally Posted by jashan View Post
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:

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

Click image for larger version

Name:	Text Completion.png
Views:	2467
Size:	27.7 KB
ID:	1343

-Dennis
 
When I am in the inbox processing my inbox items, I want to be able to enter the name of a new project easily. I tend to hit "Enter" when I have written the name of my project, but this deletes all that I have written and creates a new inbox item instead!
Why couldn't "shift-N" create a new item? According to conventions, when I hit Enter, the new project name should be saved, and by hitting Enter again (for example) it jumps to the next inbox item so I can start working on that one.

Instead I have to click "cmd-Enter" to save the project, which is counter-intuitive to me.

I am halfway in the trial-period, and although I love Omnifocus on the iPhone I am not sure if I am ready to pay for this quite expensive application.
 
I've just returned to OF after about a year of not using GTD and I'm keen to resume activity. This topic interests me because I always hate being forced to use the mouse - for anything. I just hate it! When a program has plenty of keyboard shortcuts, as long as you take the time to learn them you can get very efficient - but if you then occasionally have to stop, lift your hands, place a hand on the mouse, move it to the right point on the screen, click, go back to the keyboard and carry on - then for me it seriously impacts efficiency.

This is something I don't like in OF. As far as I know there is no way to switch focus to the inspector, for example, without using the mouse. Also, there seems to be no way to "Save" items in the quick entry box without actually clicking on "Save".

I wish these gaps (of which there are admittedly few) could be closed by providing keyboard shortcuts!
 
Quote:
Originally Posted by macronencer View Post
Also, there seems to be no way to "Save" items in the quick entry box without actually clicking on "Save".
How about Command-S?

-Dennis
 
Quote:
Originally Posted by Toadling View Post
How about Command-S?

-Dennis
Wow. OK, thank you! You've just reduced the stress in my life :)

Guess I should re-read the manual. I sometimes rely a little too much on intuition after a while, even though I generally read manuals when I start using something. I wouldn't have thought of Command-S because it's usually for saving files.

I still find the mouse-only access to the inspector annoying and I've mentioned that before, I think, a year or so back - but actually I've found that's a problem common to many Mac applications. This "inspector is a different window and can't be reached via keyboard" attitude is not helpful. I'd like to be able to change ALL action attributes, including repeat modes etc., with keyboard only. If that's possible, please enlighten me, and I'll owe you several drinks!
 
Quote:
Originally Posted by macronencer View Post
I'd like to be able to change ALL action attributes, including repeat modes etc., with keyboard only. If that's possible, please enlighten me, and I'll owe you several drinks!
Wish I could help (I certainly could use a drink right now :-), but I don't have a solution. Some of the functionality of the inspector can be replicated by adding columns to your outline, but the repeating options aren't among them. I don't think you're the only one looking for this capability either.

-Dennis
 
 


Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes


Similar Threads
Thread Thread Starter Forum Replies Last Post
New User Interface Ideas - what do you think? bafranklin OmniFocus 2 for Mac (Private Test) 29 2013-06-16 03:58 AM
User interface is very awkward! carlsson OmniFocus 1 for Mac 13 2012-01-16 11:29 PM
User interface... trash OmniFocus 1 for Mac 5 2011-04-02 02:28 PM
User Interface - Icon Design technomad OmniFocus 1 for Mac 1 2009-01-05 02:06 PM
Two user interface pleas (please!) alanterra OmniFocus 1 for Mac 9 2007-12-09 03:15 AM


All times are GMT -8. The time now is 04:47 PM.


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