a) You have stuff in your Inbox and you want to create a project from it. This is accomplished by hitting Cmd-! or Edit-> Convert to Project. Or you can now drag the action from the Inbox over the Project tab it will glow blue and get moved over as a project.
b) You have stuff in the Inbox you want to add to an existing Project. This is accomplished by dropping to the second line in the action on the far left there is what looks like a small right facing triangle and document just start typing the project name in select the one you want and it will get assigned to that project.
Admittedly the actions are added to the bottom of the projects list of tasks which in the old drag drop method you could select where you wanted it but so far this is not a massive issue in my workflow I catch these in review and ensure the project tasks themselves are accurate.
I have tried using the two window solution, because, well, it is the only Drag and Drop solution available. And while it pales in comparison to a single -window approach, there are two things that Team Omni could do, which would make such an approach at least tolerable - and they are:
Restore state when launching OF2. Meaning that if I quit OF2 with two windows open, arranged nicely to meet my Inbox processing requirements, OF2 should restore the state of the application when I re- launch. Two windows should be opened, and in the same size and position - and with the same state for the sidebar and toolbar and inspector - that I left the application in. Else I have to open the second window, re-size it, close or open the sidebar and/or toolbar and/ or inspector, etc.
Closely related to the above requirement, allow us to restore the above through the activation of a perspective. In other words, perspectives should also save the state, and that should also include all of the elements detailed above (window size and position, sidebar and toolbar state, etc.).
If Omni supported the above, I could at least establish a view of the Inbox designed to reduce friction as much as possible with a two window approach for processing it. Not my ideal solution, but at least something that is more viable than what we have now.
Replying to my post to note that I tried the two window solution on my 15" MBP (Retina display). It was really difficult sizing and aligning the windows in such a way that it was useful. It was much more trying and time-consuming than attempting the same task on an external monitor (which is where OF2 normally “lives” for me).
Add to that the fact that, having done all of that fiddling around to re-size and align the two windows (not to mention hiding or displaying the sidebar and inspector), I lost all that just from quitting and re-starting OF2. Only one window was retained, meaning that I had to / need to go through the same process all. over. again.
And so I realize I am not adding much new to the discussion, other than to say that my experience with a single monitor setup, even when the monitor is a 15" retina display, amply demonstrates the need to retain state of windows and to support saving (and reloading) state from perspectives. /end rant
EDIT: OR of course it demonstrates another good reason why a single window, four pane, setup for processing the Inbox should be supported. Because then I could tolerate that state (of multiple windows) is not restored with a re-start - because I wouldn’t need multiple windows any longer. I would, however, still maintain that state should be included / supported in our perspectives.
Since Omni watches these for urgency/need I wanted to chime in.
Having downloaded the beta just yesterday, I happily jumped in. The look and feel is fantastic. The forecast and review perspectives are very welcome indeed.
The loss of a combined Inbox/Project view took under a minute to identify. What was so simple and intuitive became a “Now what?” moment. The loss of drag and drop between the inbox and projects cannot be overstated for me.
The workaround is fine for the moment I suppose.
I’m a fan of the idea that when you click the inbox, the projects outline remains with drag and drop capability. I mean, the inbox is the only sidebar view that doesn’t have the 4 pane layout. Adding it would simply make the inbox consistent with everything else.
MOCKUP IN PHOTOSHOP: Omni could do this and make everybody happy, it’s necesary and the simplest way of doing it.
Display the inbox at the top of the projects with a separator line. Same as OF1
The inbox tab can still be used as a focused inbox view, to capture lots of stuff or wharever.
It would also allow us to hide the inbox tab using the stars in the perspectives list, in case we just want to use the inbox entry in the Projects tab.
The relationship between Inbox and Projects is fundamental to how we use this product, and how the GTD system is designed. Inbox items are simply Projects (or actions; children of Projects) in a transitory state (between your mind and your Projects). The product should be great at completing that transition.
Using two windows does provide a functional option, but it creates an unintuitive “power users tips & tricks” class of solution to a first-order workflow function of the product.
We strive to improve the design of our products to push them further and further out of sight, out of mind- until we can use them without thinking of them, without noticing them.
I’d love to see a design that harmonizes the Inbox and Projects, and nails the Inbox processing workflow (as has been done with Reviews), getting closer to that ideal. It’s a defining attribute of the product.
I’m a bit puzzled by the Omni stance on this. Presumably when 2.0 launches, you want lots of new users to enthusiastically recommend to friends. If they find it difficult, or have to be a pro user when they are a beginner, I can’t see a super glitch free launch and reviews on the App store will reflect this.
I presume that at an early design stage there is something fundamentally difficult to now undo about allowing users to see their projects to which they want to process actions into. Otherwise I can’t see the benefit in asking users to do a workaround solution for a fundamental basic use of a to do program.
What I´ve done as a temporary workaround, is create a top level (and top priority) project with the following name:
“Empty OmniFocus Inbox”
When the time comes to clean up the Inbox, I select all items and assign them to the project “Empty OmniFocus Inbox”. All the items are also assigned to the context “Any”. That way, they are automatically cleared out of the Inbox.
After that it is a question of sitting down to execute the project “Empty OmniFocus Inbox”.
This seems to be working fine, but of course it is just a workaround. Hopefully the column with the project list will soon be made visible and accessible in the Inbox view again.
Additionally, what would make cleaning up the inbox easier for me, would be that the folders to which I drag an item, not automatically open every time something is dropped there. That is because I prefer to sort the Inbox items in phases. First the very rough dumping into broad categories, and then sorting them into finer and finer categories.
The best thing I’ve managed to come up with is a context perspective that launches in a new window with only “No Context” selected.
This is fine IF all the items in your inbox have no context AND all items not in your inbox typically have a context.
Grouping things by added date at least means items newly added to my inbox float to the top and old chaff that happens to have no context is more easily ignored.
Editid: Fine. I’m a jerk for stating the obvious and trying to be funny: it’s not broken, it’s just missing an element that I would like to see too. Other alternatives to drag-n-drop that I use:
When you are brain-dumping into the inbox, could you select multiple items via Cmd-Click and assign the project in the inspector?
When you are brain-dumping about a project, could you do that with the respective project so the majority of the work is done for you? (I primarily do this in OF2 iPhone, but it works the same on the Mac)
I would like to see it a listing of projects within my inbox too; I personally like the one-window focus, so it would help my workflow (vs. two window).
For two window people: Have you tried any window managers? Toss the inbox to the left to split the app on the screen and toss the projects widow to the right (or top/bottom, etc)? I do this with other apps. One note of caution, there is a thread about crashes that might have something to do with window management software. Tread lightly here.
I’m sure you would get umpteen replies to your post with regards to your “enlightenment” to other peoples work flows, if your post wasn’t mildly facetious.
Replying to this post - again - to say that @Kristina with Team Omni clued me in to an important preference which governs the state of OF2’s windows after a re-start. In System Preferences, using the “General” Control Panel, simply ensure that the checkbox signifying “Close windows when quitting an application” is not selected. If that box is checked, then a re-start will not restore state. However (and channeling Ross Perot), “here is the beauty part” - if that box is not selected, the state of the OF2 windows will bounce back to their previous state when re-starting. One problem solved!
Unfortunately, we still cannot save state in a perspective (which would include all aspects of a saved state) - however, judging from some recent comments per Ken, there may be a movement supporting it).
And so - happy though I may be with the new features, I am eagerly awaiting that (promised?) future build which saves and restores our state in a perspective.
To add my voice to this thread, I agree. Not being able to view the inbox in the project view, or project list in the inbox view is a step backwards. The suggested “work arounds” obviously do just that but it is difficult to see how making a common process more complicated is a good thing.
The ability to file from the inbox by dragging into projects is something I use daily in version 1, its omission is a big issue for me and many others, and will undoubtedly effect reviews if version 2 is released without it being addressed to be at least as usable as v1.
We’ve been thinking about this problem, it’s just not an easy one. We’ve provided several mechanisms for filing inbox items (SmartMatch in the projects field, or the popup list in the projects field, or dragging to the project list in another window), and we’ve added some mechanisms which make it easier to turn an Inbox item into a new project (dragging onto the Projects tab, or using the “Convert to Project” toolbar or menu items), but obviously quite a few of you still aren’t finding the current state of affairs in v2 as efficient as the workflow from v1 where Projects and Inbox were all in a single view.
OmniFocus is a complex app, and our best tool for keeping it from getting confusing is to make the navigation as clear as possible. As part of this we split up the Inbox from other views and gave it its own tab: listing the Inbox inside the Projects tab leads to confusing navigation, because Inbox items aren’t really projects. But now that it has its own tab, putting the list of projects inside the Inbox tab would also leads to confusion because they aren’t really part of your Inbox. We just want to be able to drag stuff to them easily.
So, I’m not sure what the answer is. For now, the closest approach to the v1 workflow seems to be to open the Projects tab in the main window, then opening the Inbox in a separate window, hiding its sidebars and making it smaller so it’s more like a floating window, then dragging stuff from the Inbox onto the projects.
But, like many of you, we’d love to see a solution that works well in a single window. (Maybe when you start to drag an Inbox item, we could swap out the right-hand sidebar for a list of droppable projects that you could drag stuff onto? We wouldn’t want to do that on the left, because your Inbox items are already in that space—but there isn’t any reason to drag an item onto the Inspector.)
I’m not sure what the ultimate solution should be, but I do know we didn’t manage to find that solution in time to build it into the initial 2.0 release. Hopefully we’ll figure something out in time for 2.1.
