In OmniFocus 2, we use sidebar tabs for the top level of navigation:
This model offers clearer navigation than OmniFocus 1, but it doesn’t offer any way to view a list of items from one tab (such as the list of projects) while working in another tab (such as the Inbox).
Last year’s iteration of the OmniFocus 2 design did offer a way to see both at the same time:
The downside to that approach was that everything was overwhelmingly competing for your attention all the time.
Thank you for taking the time to post that explanation.
This may be laughed out, but I’ve just imagined an answer (not for 2.0!), but I’m not a photoshop expert and so words for now:
The inbox is currently different in that there is no second window where projects and other perspectives list their tree structures. This is fine, since the inbox is different to everything else by it’s very nature, and hence whilst keeping the shape and form of your well designed software, could it work as follows (this would also make the Inbox items operate in the same space as all other actions, so helping focus):
What people want, whilst sorting the Inbox, is to be able to see their Projects… or Contexts… or Forecast, or any other perspective. So, if wanting to sort into say, Projects, I select the Projects tab prior to selecting the Inbox. The projects stay where they are and the Inbox slides over the top to place the items inside the inbox in the same place as all other actions go in the other tabs (the visual animation could show the inbox sliding out like a drawer to place the Inbox items where the actions were of the last opened perspective). This gives an impression of a 3D superimposition of the Inbox over the top of whatever tab it was that you clicked last. The items are clearly in the Inbox, since you have the tab linked without the lines, and the shading is the same as all other tabs when open, being a lighter shade when selected. The linking space between the tab and the actions would be longer than other tabs, but clearly linking the inbox actions to the tab, but in the same space as actions are in other tabs. The only other thing that would have to happen is for the relevant tree structure to slide down below the Inbox section linking the tab to the space where the actions are. You would then be free to drag and drop into whichever perspective it was that you selected prior to opening the Inbox drawer.
Did any of that make sense? I’m fully aware that this wouldn’t be a 2.0 solution, but it would I think be quite elegant.
I very much appreciate the candid response. Always nice to know people are listening. Forgive me if what I say here is a bit harsh, but I can’t help but think this line of reasoning is a bit of a cop-out.
OF1 by default shows the Inbox and Projects list and always has. The only reason OF2 exists is because of the resounding success of OF1. That feature - Inbox/Projects viewable together is not new. It is and always has been the default. How can that be confusing if that’s the way it’s always been? Complex? Yes. Confusing? To the rank beginner OF1 or OF2 is confusing. So is every other program with a modicum of complexity until you learn it.
I am happy to be able to look and play with a pre-release version of your software. But part of me thinks the line of reasoning proposed here has more to do with justifying the omission than with usability.
I’d like to thank you for the candid response as well, and I also believe this is something you should sort out for 2.0, not 2.1.
When I process my inbox in OF1, inbox items usually become projects. I drag them to an appropriate place in my projects list, then add action items. An appropriate place might be as a sub-project of an existing project, or in a folder. It is probably also in a specific place in a folder, as I tend to order my projects in a sort-of order of importance. This makes the current “Drag to the projects tab” a real pain, especially because the second step of dragging the project from the bottom of the list to the appropriate place in the list doesn’t work very well if I have more than a screen-height of projects, (I have several screen-heights worth of projects).
I think, (and you might want to keep an open mind for this), that part of the problem is in the logic that you’re using to keep the Inbox in its own, isolated tab. There are a few other ways to look at this. Processing the inbox a project that we, (theoretically), do every day - so in that sense the inbox is a project, and would belong in a view with the other projects.
It would also be worth considering if the Inbox even deserves a tab of its own on the side. While the inbox is a major part of GTD, in reality we spend a lot less time using it than the Projects or Perspectives views. All we do with the inbox is add stuff to it or process it. If putting it in its own tab breaks inbox processing, (half of the purpose of the inbox), then maybe the tab should go, and there should be another, more processing-friendly, way to interact with the inbox. When I’m adding things to the inbox I use Omnifocus Mail Drop probably 90% of the time to start incoming mail messages on the road to becoming projects or tasks. I also use quick entry, and I rarely just go to my inbox in the OF app and add items. If I’m going to bring up the OF window to add something I’ll create it as a project, or put a single task where it belongs, skipping the inbox entirely.
So, in summary, the current situation breaks one of the two tasks that the inbox is used for, and it’s the task that I actually do in OF. The other task is usually handled outside of the OF app, via MailDrop or Quick Entry.
This post was flagged by the community and is temporarily hidden.
I’ve been using janwybe’s workaround, copying the contents of my inbox into a single-action project (I call it “Sort-Box”) at the highest position on my sidebar list of projects. That way, I can highlight the “Sort-Box” project and drag-n-drop items into individual projects. (You could do the same with a “sort-me!” context and then drag-n-drop into a context list.)
This suggests that one implementation would be to allow the choice of which panel would be displayed in the sidebar, when the inbox is selected: a side panel with all projects or a side-panel with all the contexts. I know that it’s better to assign both, but often it’s not really necessary, and I just want to clear out my inbox. If there are 5 steps in a task that are in my inbox, I just want to be able to cmd-click on each to select them, and then drop 'em in a project.
What about a Custom Pane View option, with drag & drop panels? You could tile, line up vertically, line up horizontally, or a combination of any combination views / lists.
THAT would be powerful and VERY helpful.
Continuing the discussion from Viewing the Inbox at the same time as Projects:
Fascinating solution.
I myself was thinking about having the Projects window appear as a semi-transparent overlay (so you can drag and drop into it, but also see what’s in the Inbox behind) animation.
The reasoning for having the Inbox separate to the Projects is quite simple – it’s following the paradigm and precedent that OmniFocus for iOS (iPhone and iPad) has.
I personally think this case (as opposed to checkboxes on the right) is a reasonable UX option, as it’d be slightly odd to have Inbox reappear in the Projects list.
That said, yes, the issue of dragging is quite a headache, and opening up another window and separately dragging (while trying to juxtapose the two windows on left and right (which could be helped by the use of Yoink – but then again the average user would be quite frustrated and shocked, as the Inbox is supposed to be the landing bay for tasks before they’re dragged or assigned a context and project)), which is rather inconvenient).
As said, I think the solution to this would be to have the Projects pane appear as a translucent overlay the moment you initiate a drag of a task (similar to how Yoink works in operation).
I’ve done a very rough diagram of how I think it should work.
The advantage of using such a solution is two-fold:
Miscellaneous comments:
Close-up:
I consider this a MAJOR problem too. This is not a small annoyance, but a huge deal breaker. It breaks the whole workflow and makes the app SIGNIFICANTLY harder to use for a lot of users.
As you have mentioned it is a difficult problem with the interface approach you have decided on and I think you should reconsider the whole approach if you cannot come up with a good solution for this problem. Noticing major flaws like this one is what a beta test is for.
I think it would be much better for you to delay the release until you can solve this.
One idea of how to solve it:
Why not leave the inbox as it is, but add another tap “Process”. Ideally I wouldnt just want to see the list of projects but be able to click on a project and see existing tasks so that I can insert tasks from the inbox at the appropriate place.
There fore a view like
| Projects | Selected Projects Tasks | Inbox |
This way I could easily drag items onto a project to add them to the bottom of the list or select a project and drag tasks into a specific place within a project.
Maybe even let this perspective switched off by default. If someone is skimming the web or help for a solution he shall find it there and be happy ;-)
It’s totally understandable to feel this way about an issue that impacts your workflow, but delaying the release would be doing a disservice to everyone who isn’t affected by this issue, or who’s okay with using one of the alternative methods. If those aren’t viable for you, there’s nothing wrong with sticking with version 1 for the time being.
Similar thing going on here: for someone who got over the hurdle of learning v1’s interface, doing it “the way it’s been done” probably seems fine. But we know a lot of people simply hit a wall of confusion in v1 and never got over it. Some of the changes in version 2 are meant to address the concerns of people like that.
Which doesn’t mean we’re ignoring or not planning to address the concerns being raised here. We’ll do our best to address both sets, but we’ll do so all the way between here and 3.0.
I have a suggestion that I don’t see already mentioned: what if there were a “No Project” list at the top of the Projects tab just like there’s a “No Context” list in Contexts tab? Then a person could just switch over to the Projects tab, select the “No Projects” list, and see anything that’s not in a Project. For many people, this would only be Inbox items. Then they could be dragged to whatever Project they belong to.
This doesn’t create the confusion of having Inbox show up in two places, and it creates consistency with the “No Context” item in the Contexts tab.
Even for people who have project-less actions that are already cleared out of the Inbox, this might be a useful view to have anyway.
Thoughts?
@ironicsans, that is exactly what I just thought while reading this. This actually works to make the interface more consistent.
One option could be that when you drag an inbox item over the Projects tab (and hover briefly?), the list of projects slides out from the left and allows you to drop the item in the appropriate spot, then it slides back out of view. That way you could drag and hover over projects, contexts, forecast, or any perspective, really. It would be a bit like dragging over a folder in Finder and having that folder temporarily open so you can “drill down” and put things where they really need to go.
I really don’t understand why this is complicated…
Just make it an option “Show project drawer on Inbox” and set it to OFF by default if you think it’s going to confuse new users.
If ON, just show the same Project Drawer on the left in the Inbox perspective. If the user clicks on any of the projects in the project drawer, then Omnifocus changes perspective to Projects > Selected project.
Remember that the issue is not only not being able to drag tasks from the Inbox to a certain project. For me, the main problem is not being able to see my overall Project Outline when deciding how to organize my tasks. It’s a matter of having a clear idea on what my projects are and how to organize my GTD.
Not being able to see that project outline during Inbox processing is a major design flaw that affects a lot of people, as seen by the popularity of this thread.
It’s shouldn’t be a technical challenge. It’s a “design battle”. It seems to me that the OmniFocus team doesn’t believe users should be able to see the project outline while processing their inbox (even if it’s just an option that users need to actively enable).
The rest of the app is shaping very well.
Hear, hear, hear!!! This is very important for me. Most of the time I can’t just drop a task from the Inbox into a project, I have to place it in the existing list of tasks. Any of the other solutions mentioned here that don’t allow for this don’t do me any good at all!
The current situation may not be ideal for everyone, but unlike some problems which we still need to solve before release (like crashes opening notes), this problem doesn’t affect everyone and it has a very easy workaround: you can open your Inbox in a separate window, which lets you see your project list and drag things to it. (The Mac supports multiple windows for a reason! It’s really useful to be able to decide how big you want each window to be and where things should be positioned relative to each other.)
But just because we think there’s a workaround doesn’t mean that our designers don’t think you should be able to do this in a single window. In fact, our design team has already proposed some changes to the Inbox which will solve this. We just didn’t have time to implement those changes for 2.0 (while finishing everything else we need to finish in order to ship on time).
Fortunately, 2.0 is just a (major) milestone, not the end of the journey. We’ll look at this again in 2.1.
