[Betsy]

Perhaps Omni needs to change their OmniFocus page:

OmniFocus is a personal task management system, designed to quickly capture your thoughts and allow you to store, manage, and process them into actionable to-do items. Tasks can be assigned to projects and stored within contexts (for example: "Home", "Work", or "Garden"), with built-in visual cues to highlight the next action you need to take care of. With OmniFocus, you can narrow your field of concentration to only those areas—tasks, contexts, projects—you wish to view, which helps you stay on track and organized.

OmniFocus can be used to implement the "Getting Things Done®" work-life management method developed by David Allen, but it's designed to be flexible enough to accommodate different styles of personal organization.

Bolding is mine.

It appears to me that the app is intended to be used by people who may not use GTD at all, let alone strictly in accordance with the book. Or it could be used by David Allen. :)

If OF supplies us with all of these easy ways out, shortcuts and quick fixes that ultimately undermine the larger goal of GTD ...

etc.


Most impressive to learn how much grave theology is at stake.

I had imagined that the point was simply to get things done :-)

[al_f]

OF is at heart a GTD app: Omni have said several times that they want to stick as closely to canonical GTD as possible, at least for the first version of OF. Of couse that doesn't mean non-GTDers can't use it, but it's ultimately designed to support a GTD workflow.

[Ken Case]

We plan to add an "Unassigned" context, but we'll make it inactive so it doesn't clutter the active context list.

[MEP]

I don't want a task management app. I want a productivity app.

OF could just manage your lists and push your tasks around (like a million other applications already do, but with different buttons and widgets). Or it could be a true productivity app, that actually helps you focus on doing rather than planning or procrastinating.

I want to "simply get things done". What do you really want? It sounds like you want to whatever you're already doing, but with a different interface. That's such a low goal for Omni to shoot for.

I don't think that you need to worry too much. The distinction between planning and doing is abolutely central to GTD methodology.

Remember that we are sharing just 2 views between 5 GTD stages, so a lucid conception of what those 2 views really are needs a move to a higher level of David Allan's scheme of abstractions. His more general "Planning vs. Doing" is a little closer to where they fit it in than the narrower "Projects vs. Contexts". The latter misses some things out, and is inherited more from the structure (and limits) of Ethan Schoonover's kGTD applescripts than from the GTD workflow itself.

As for the list of actions with contexts not yet assigned, it is invaluable to the review stage to have such a list generated automatically - it plugs a real leak, which people using GTD methods have already experienced and reported. David Allen would certainly make use of it himself, if only he would switch to OS X :-)

Omni are creating an excellent electronic framework for a GTD workflow, and it is bound to have a slightly richer structure than Ethan's kGTD, which was limited not by purity of vision, but by technical constraint.

[al_f]

Originally Posted by Ken Case

We plan to add an "Unassigned" context, but we'll make it inactive so it doesn't clutter the active context list.

Sounds good: should suit everyone (hopefully). Another holy war nipped in the bud. :)

Originally Posted by Ken Case

We plan to add an "Unassigned" context, but we'll make it inactive so it doesn't clutter the active context list.

Making it inactive is a good idea. I would adjust my interim applescript to make the "-UNASSIGNED" context inactive by default, but it looks as if this property of a context is not currently exposed in the applescript model.

(In fact, inactive contexts appear not to be accessible at all through applescript at the moment - they don't show up in the Contexts list of a Document ...)

[MEP]

Originally Posted by RobTrew

I don't think that you need to worry too much. The distinction between planning and doing is abolutely central to GTD methodology.

Remember that we are sharing just 2 views between 5 GTD stages, so a lucid conception of what those 2 views really are needs a move to a higher level of David Allan's scheme of abstractions. His more general "Planning vs. Doing" is a little closer to where they fit it in than the narrower "Projects vs. Contexts". The latter misses some things out, and is inherited more from the structure (and limits) of Ethan Schoonover's kGTD applescripts than from the GTD workflow itself.

As for the list of actions with contexts not yet assigned, it is invaluable to the review stage to have such a list generated automatically - it plugs a real leak, which people using GTD methods have already experienced and reported. David Allen would certainly make use of it himself, if only he would switch to OS X :-)

Omni are creating an excellent electronic framework for a GTD workflow, and it is bound to have a slightly richer structure than Ethan's kGTD, which was limited not by purity of vision, but by technical constraint.

I don't want to beat the same drum here, but I just have to say one thing about this. It seems like we're answering the wrong question here. Yes, there is a leak. Yes, OF should try to find a way to help us plug that leak. I just don't think this is the best way of doing it.

If you have a lot of actions (or even one) action that has been processed from your inbox but still doesn't have a context assigned to it, you have to ask yourself, "Why?".

We probably all know the five steps already, but I'm going to list them to clarify my point:

1. Collect
2. Process
3. Organize
4. Review
5. Do

If something is in my inbox, I have collected it, but I have yet to process it. One of the cardinal rules of GTD (and just good practice in general) is once you take something out of your inbox, don't put it back. If I have a list of actions that I've assigned projects to but haven't assigned a context to, I'm going to have to process that list, the whole list, every single time I look at it. How is that any different from putting something back in my inbox?

Why are contextless actions taken out of the inbox in the first place? What is the reason for this particular design decision, and how did this choice lead to the problem we have now where it's easy to lose track of those actions for which we haven't yet assigned a context? The decision to move contextless actions from the inbox must have been made for a reason, but in light of this other problem, were those reasons justifiable? Should these actions still be in "In"?

Having and "unnassigned" context in the context view does not plug the leak. It just collects the water. You might as well rename the "unassigned" context to "procrastination".

The leak is happening in step 2, Process. But we're trying to plug it in steps 3-5. I think the shortcoming of OF in this case (and I don't mean that in a harsh way, I think OF is a great app so far, and I've already switched to using it full time) is not in the context view, but is in the Project/Inbox view. The solution in my opinion is not to alter the context view, but to separate the inbox from the projects and make the inbox itself more robust.

Well, perhaps the inbox could remain in the same view as projects so that the view could still be ostensibly for planning and review with less tab switching, but I still think the leak here exists in the inbox and should be plugged in the inbox. Maybe creating a separate section of the inbox for partially-processed actions would work. Those actions which have projects assigned could still appear in those projects, but also appear in a sub-section of the inbox set aside specifically for things that are kind of processed but not really fully processed.

That's still not an ideal situation. Ideally, this situation shouldn't occur in the first place. I think what David Allen would really do here is not use the "unassigned" context. I think he would redefine his actions. Instead of having a project with several actions for which he can't decide what the context is, he would have a new action at the very beginning of the project called, "Sit down and define what this project really is so I can plan it out properly." If you can't always do the ideal GTD thing (and I know we can't always do that), we can at the very least have OF give us gentle reminders about what we're really doing so that we don't kid ourselves about where our leaks really are and then fall into bad habits.

I don't want OF telling me that contextless actions are processed when, deep down inside, I know that's not true. Give me a tool to procrastinate, and I'll use it to it's fullest extent. But if you give me a tool to be productive -- a tool that guides me toward those better habits even while it lets me slide once in a while -- I'll get a lot more done.

I begin to suspect that we could all get more done by posting less on these pages :-)

(Procrastination takes many forms - often impeccably worthy)

Time for me to sign off, I'm afraid. September approaches ...