When I organise tasks and projects in OmniFocus, I often have a problem with the limiting hierarchical organisation into folders and projects. The reason: Projects can be relevant to different areas of focus and tasks can be relevant to different projects – in both cases I don’t know where to put things. The “artificial” and unsatisfying decision I have to make here has a major negative impact on my workflow and often causes tasks that are difficult to categorise to clog up my inbox for a long time.
A recent example of a task belonging to different projects in my area of focus “Farming”:
I have the task “Learn how to interplant several crops in one bed” (not just using one bed in the garden for one crop, but putting another crop or several crops into the gaps between the plants of the first crop). This is relevant for the project “Learn how to grow vegetables profitably” (space is used more efficiently, plant health and yields have the potential to increase), but also for the project “Learn how to improve soil health” (according to the principles of soil health, it is better to have a diversity of plants in one bed than just one kind, to have more living plants/root mass in a given area and to cover more soil).
This is just one example, I often have similar problems. In general I’m moving more and more away from organising digital content into categories/folders and instead use tags and/or full-text-searches that allow much more flexibility. I can see that projects/tasks have a “natural” hierarchical structure which makes them a bit special, but the software should still allow overlaps (tasks belonging to different projects or projects to different areas of focus) – just because I think these actually exist in life. Forcing users to keep projects entirely separate and non-overlapping just creates unnecessary work/friction that from my perspective doesn’t have any benefits (except from possibly being easier to implement)…
Allowing tasks to be part of different projects would of course require some thoughts (e.g. about where tasks inherit defer and due dates from if there are several options), but I think that would be worth it.
What do you think about this? Have you had similar problems?
TBH No I do not experience this problem but here are a couple of ideas…
Make “Learn how to grow vegetables profitably” a folder within" farming", then add projects such as “Learn how to improve soil health” within that which is where IMO it belongs.
Use action groups within projects to break down tasks into logical hierarchies. For example project: Learn how to grow vegetables profitably > action group: Learn how to improve soil health > task: Learn how to interplant several crops in one bed (which I think is far to vague to be an actual task)
Your problem as I see it is that you have not really defined what a projects outcome is or the actual tasks associated with it, “Learn how to grow vegetables profitably” is really a nice idea not a project, hence it is better IMO as a folder with projects with clearly defined outcomes inside. I usually create a reference SAL within each folder to store thoughts which do not initially obviously fit anywhere, and I find that if I come back and process that SAL later I can usually break down/refine those thoughts into actual actionable tasks or new projects.
Given that OF allows both of these already, I’d think it would be better to leave the more conventional hierarchical structure in place for users who prefer that way of working.
I should have expected suggestions like your 1. and 2. from what I wrote – a bit more explanation on my side would have been appropriate.
Basically, I don’t think hierarchies like the ones you suggest with folders, projects, action groups and tasks work properly in my case, because there are too many overlaps. The big project I am working on at the moment is to set up my own farm. Currently (and until at least the end of this year) I am in the planning stage, which partly means to figure out what farming methods I want to choose – for that I have to learn more about how to reach different goals:
What do I have to do in order to farm profitably?
What do I have to to in order to keep soil fertile in the long-term instead of exploiting it in the short-term?
What do I have to do in order to minimise the use of plastic?
What do I have to do in order to grow nutrient-dense food?
…
At the moment, I have one project called “learn how to…” for each of these goals within a folder called “Farming” / “Set up a farm”. Of course there are many alternatives to this (adding more hierarchy levels in between with subfolders, to make them action groups in a project instead of projects in a folder, etc.), but I decided against these alternatives for mainly two reasons:
Folders, projects and action groups are treated very differently in OmniFocus: Only projects can be given review dates, folders can’t be given dates or tags, perspectives are either task-based or project-based, etc. Capturing these goals as projects seemed the best way to go for me overall.
Adding more hierarchy above these projects didn’t seem necessary, since it’s clear enough in my head and additional levels of hierarchy sometimes just make navigating more fiddly and things more difficult to find.
When it comes to more specific tasks like learning about interplanting crops in a bed, those can be relevant to several of the above mentioned goals/learning projects. Interplanting can make farming more profitable in the short- and medium-term (goal 1) because of the improved use of bed-space, but it also helps building and improving soil in the long-term (goal 2), which might not have any short-term benefits regarding cash-flow. So which goal/project do I assign this task or action group to? The fact that I have to decide between two projects just creates completely unnecessary friction. Why not just allow me to add the task/action group to two projects?
The fact that the outcomes of the mentioned tasks/project are a bit vague (I’ve completed them when I feel that I know enough about the topics to actually choose my farming methods) doesn’t really make a difference to the problem I want to address here – with much more concrete projects/tasks overlaps can also occur. The task could be to read a specific book about how to improve/maintain soil health – still I wouldn’t know where to put it. Another example: I could be writing two papers (–> two projects), both of which rely on me finding an appropriate definition for the concept “health” – so where to put this task? Why not in both projects?
I could of course make this a project on its own, but then the relation to the papers would not be represented in OmniFocus.
Regarding the relationship between actions and projects: the project and action hierarchy is the fundamental structure of OF, on which sequential/parallel behaviour, deferrals, etc, depend. It think it would add a lot of complexity if an action could have multiple parents.
Instead, you could create special actions which point to another project or action in the database. For example, in each of ‘Project A’ and ‘Project B’ create an action called ‘Complete Project X’ (which has an omnifocus:/// link to Project X in the notes field). Then, by convention, Projects A and B are linked to Project X. You won’t automatically see the detail of Project X under Project A, but the application will force completion of X before completing A or B.
In your case, perhaps you have projects ‘Achieve profitability for vegetables’ and ‘Implement soil health techniques’ (like @TheOldDesigner says, projects work best if they represent a clear outcome). Both would contain an action ‘Learn how to interplant several crops in one bed (link)’ which points to a ‘Learn how to…’ project (containing all relevant learning resources) which is in a ‘Learning about Farming’ folder along with other learning topics.
Regarding the relationship between projects and areas of focus/responsibility, I agree that sometimes a project is conceptually part of several areas, especially if you are thorough in defining your roles and long-term goals. Consider representing these relationships in a different tool, such as a mind-mapping application or a spreadsheet. The relationships won’t need updating very often, and you can look at them when performing an OmniFocus review and deciding on what tasks to do next.
@dfay: OF of course allows to tag tasks, but tags are certainly not intended to be used to assign them to projects. I use tags for different contexts, rough scheduling, types of activities, etc.
Tags and projects are treated in completely different ways in OF and using tags to group tasks into projects would mean a lot of loss in functionality and user-friendliness. Tag lists can’t be sorted manually, they can’t be given any dates, they can’t be tagged, etc.
I’m not advocating to abandon the current structure of OmniFocus, just to make it a bit more flexible by allowing to assign a task to multiple projects (and possibly projects to multiple folders). If you don’t want that, you don’t need to use it – it would just be an option in addition to what’s already possible.
@MultiDim: Your suggestion to create the special actions that point to other actions is a workaround that I might use occasionally, but it does create quite a bit of additional steps in the workflow. (It’s basically like creating aliases for files in a folder system.) If I could just add two projects to a task when I add it to OmniFocus initially (as when I add several tags to a task), that would be a lot smoother.
I can see that this adds complexity when it comes to inheriting parent data etc., but hopefully that can be solved. When it comes to defer and due dates, the closest dates should be the ones inherited (personally, I usually don’t assign such dates to projects, just to tasks). When it comes to parallel/sequential behaviour, it would need to be possible that a task is available in one project, but not available in another. Task-based perspectives like the Forecast perspective should show a task if it is available in at least one project.
From my perspective, adding this flexibility would make the user experience much better. I’ve struggled with similar problems when it came to organising the files on my computer in folders/categories so many times and repeatedly tried to improve my folder-structure so they have minimum overlap and still seem natural, but I’ve never reached a completely satisfying state that way. At some point I then switched to a very different note-taking approach (using a Zettelkasten-app) and to putting all my resource-files in one folder and just organising them with tags in a reference manager. That works so much smoother for me and has been very liberating – I wish that problem could also be addressed in OmniFocus.
I agree with you about organising files and folders, or items in general. I am more comfortable with the freedom of putting them in several places of a hierarchy, and thinking about organisation as a multidimensional structure (hence my forum ID!). However many systems and apps keep the traditional folder metaphor of computing, probably because most people are more comfortable with the “everything in a single place” approach, and a tag system (often a very simple one) is added separately. Like you said, some note taking apps offer more flexibility and you can put files or objects in them. Google Drive allows you to put a file in multiple folders and the folder attributes (sharing) are inherited, even if this capability is almost hidden in the UI — in the early days its folders were shown as tags, but this was all probably too complex for most users and they reverted to showing a traditional folder UI.
OmniFocus provides great capabilities, compared to all other task managers, for organising and orchestrating your task sequences. So I think that the robust project and action hierarchy, with its attributes is a good thing. Even in its current state it can take some time to master. The addition of multiple tags in OF3 has been a huge improvement and I’ve found an acceptable solution for all the task workflow problems I had in OF2.
It’s fun to think about a totally flexible structure where you could perfectly model your workflow or mental representation, but it would lead to huge complexity of implementation and use, and not good for most customers. If you allowed multiple inheritance of action attributes, you’d need to decide on the right behaviour when there are conflicts, and make them clear to users in the UI. I think I could make an argument for why the behaviours should be the opposite of the ones you suggest. I’m sure there would be epic arguments on this forum about the correct choices, and loud calls for providing options to use one way or the other! :)
