This text is made up of ashes. Originally I wanted to make some very clever points about OmniFocus being at odds with GTD. But then I realized I was wrong (what a surprise) - I ended up with suggestions that seem to be implemented already. - OF rules!
There are a few issues left, though. But most of them are about the look and feel of the app - things that probably wait for later stages of the development process.
A caveat is in place: Iīm German and have read David Allenīs book in German. So, I might use wrong terminology (retranslating what I read). Furthermore, I apologize for my English.
First things first: I guess it is possible to change text color, but it just doesnīt work for me. Am I missing something? (It works for notes, but not for tasks: I select the text, push the "colors" button, select a color, but nothing happens.)
(I desperately need this, because with the default settings I canīt read most of what I put into OF.)
Second, I feel there is something peculiar about "next actions" as defined by OF, that might stem from considering all projects sequential. I donīt know if Iīm with David Allen in this respect, or if OF is. But certainly OF is much more restrictive about next actions than I am. For OF, there is just one next action per project. Therefore it matters, if I put up one project to hold twelve tasks or if I organize these same tasks in three projects with four tasks each. In the first case thereīs one next action, in the second case there are three.
I think the important thing about next actions is this: if something from your inbox turns out to be a project, you should instantly assign a (physical) action to it (unless you put it on hold deliberately). The idea being that you should be clear about doing something or doing nothing. You might put "lose weight" onto several lists, but until you decide on physical actions that support this project, you put it on hold without admitting this.
To me it seems, the idea is to assign at least one next action to active projects - and not at most one. The goal is to foster doing something - and not to concentrate on doing something specific (because it is the next of many available actions). Why should the design of larger or smaller "projects" matter? (Concentrating on a small number of available actions is handled by the context lists.)
Of course, all this only means that "available" seems to be the more relevant category than "next".
Third, I think a project really is just a "conainer" of (related) actions / tasks. So there is no need for three categories of containers: projects, buckets and folders. But this has been discussed before, and I think buckets and folders do not hurt.
Fourth, my greatest concern was about "stuff" within OF. And the greatest discovery was that "stuff" has already been implemented - "tasks" without a context are "stuff". I would only wish for a more visible distinction. To me, the distinction between physical actions (doing something) and everything else is most basic. Therefore, the ease of converting actions into projects and vice versa (something I would always want to keep) is dangerous. You need not answer the basic question: "What is this?" But declaring something an action should always be a conscious decision. Converting stuff into actions / tasks is the magic act at the center of GTD.
To be more pragmatic: I think "stuff" items should not have checkboxes. There might even be two separate areas beneath a projectīs heading: one for "stuff" and one for actions / tasks. (The notes area might seem similar to such a "stuff" area - but this area would be like an inbox for the project, where all "stuff" items would go that have been assigned to the project.)
If there is just one "area", I would really love to have an indicator in each projectīs title bar that lets me see at once if there is any available / next action assigned to this project. Because I think it is not essential to plan your project entirely, but to collect everything that is related ("stuff" - reference material and items that might become actions or subprojects when reviewing the project) and to assign at least one physical action. Therefore, a project is in good health, if within an amorphous mass of "stuff" there is one proper action, and I can wait for a thorough review of the project to sort things out. But if there is no action I need to decide on one or put the project on hold.
These are my thoughts about OF at the moment. If Iīm wrong about GTD or miss any features of OF, I will be pleased to be told so. Thanks for reading.
There are a few issues left, though. But most of them are about the look and feel of the app - things that probably wait for later stages of the development process.
A caveat is in place: Iīm German and have read David Allenīs book in German. So, I might use wrong terminology (retranslating what I read). Furthermore, I apologize for my English.
First things first: I guess it is possible to change text color, but it just doesnīt work for me. Am I missing something? (It works for notes, but not for tasks: I select the text, push the "colors" button, select a color, but nothing happens.)
(I desperately need this, because with the default settings I canīt read most of what I put into OF.)
Second, I feel there is something peculiar about "next actions" as defined by OF, that might stem from considering all projects sequential. I donīt know if Iīm with David Allen in this respect, or if OF is. But certainly OF is much more restrictive about next actions than I am. For OF, there is just one next action per project. Therefore it matters, if I put up one project to hold twelve tasks or if I organize these same tasks in three projects with four tasks each. In the first case thereīs one next action, in the second case there are three.
I think the important thing about next actions is this: if something from your inbox turns out to be a project, you should instantly assign a (physical) action to it (unless you put it on hold deliberately). The idea being that you should be clear about doing something or doing nothing. You might put "lose weight" onto several lists, but until you decide on physical actions that support this project, you put it on hold without admitting this.
To me it seems, the idea is to assign at least one next action to active projects - and not at most one. The goal is to foster doing something - and not to concentrate on doing something specific (because it is the next of many available actions). Why should the design of larger or smaller "projects" matter? (Concentrating on a small number of available actions is handled by the context lists.)
Of course, all this only means that "available" seems to be the more relevant category than "next".
Third, I think a project really is just a "conainer" of (related) actions / tasks. So there is no need for three categories of containers: projects, buckets and folders. But this has been discussed before, and I think buckets and folders do not hurt.
Fourth, my greatest concern was about "stuff" within OF. And the greatest discovery was that "stuff" has already been implemented - "tasks" without a context are "stuff". I would only wish for a more visible distinction. To me, the distinction between physical actions (doing something) and everything else is most basic. Therefore, the ease of converting actions into projects and vice versa (something I would always want to keep) is dangerous. You need not answer the basic question: "What is this?" But declaring something an action should always be a conscious decision. Converting stuff into actions / tasks is the magic act at the center of GTD.
To be more pragmatic: I think "stuff" items should not have checkboxes. There might even be two separate areas beneath a projectīs heading: one for "stuff" and one for actions / tasks. (The notes area might seem similar to such a "stuff" area - but this area would be like an inbox for the project, where all "stuff" items would go that have been assigned to the project.)
If there is just one "area", I would really love to have an indicator in each projectīs title bar that lets me see at once if there is any available / next action assigned to this project. Because I think it is not essential to plan your project entirely, but to collect everything that is related ("stuff" - reference material and items that might become actions or subprojects when reviewing the project) and to assign at least one physical action. Therefore, a project is in good health, if within an amorphous mass of "stuff" there is one proper action, and I can wait for a thorough review of the project to sort things out. But if there is no action I need to decide on one or put the project on hold.
These are my thoughts about OF at the moment. If Iīm wrong about GTD or miss any features of OF, I will be pleased to be told so. Thanks for reading.
Linear Mode
