I moved 2 posts to a new topic: Cleaning up Inbox after assigning a context
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:
- Maintain the current paradigm of a separation between Inbox and Projects.
- Yet at the same time create interoperability between âInboxâ and âProjectsâ.
Miscellaneous comments:
- Translucency to ensure that you are able to view what is behind. The translucency effect also implies that the pane is non-permanent (as it belongs to âProjectsâ).
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.
No software is ever perfect, nor all things to all people. What I read into your comment kcase is âWeâre pretty sure weâll provide a solution, just not right now. Too little time and too many higher-priorities that donât have workarounds.â
Which is fine.
What sounds like an easy change (show the projects list in a pane or whatever solution you like), is probably a good sized structural alteration under the hood. Meaning bugs, user testing and general refinement⌠This late in the 2.0 dev cycle?
Ainât gonna happen.
The problem with having the âShow project drawer on Inboxâ option is that you start to get into Option Creep, kind of like Feature Creep, where there ends up being tons & tons of options, and a million ways for them to interact with each other in terrible ways, and much more code to maintain. Omni is right in making this problem face rigorous debate & a lot of brainstorming before coming up with a solution.
That said, want a single-window way to make this work, thatâs why Iâm hanging out in this thread. An additional option may be what ends up happening, weâll see, but apparently not until after 2.0.
Thanks for letting us know, (sort of), the situation @kcase. Iâm glad to hear youâre working on solving this problem for everyone, even if it isnât going to happen RIGHT NOW like we insatiable internet masses demand ;)
@enriquefernande Yes, this is a âdesign battle.â But design is a big part of why we use OmniFocus instead of some shell script or something in a terminal window somewhere. Hopefully, when the time comes, Omni will figure out a better solution than any of us have imagined, (heck, this yearâs OF2.0 is a lot better than last yearâs OF2.0 was!)