The Omni Group
These forums are now read-only. Please visit our new forums to participate in discussion. A new account will be required to post in the new forums. For more info on the switch, see this post. Thank you!

Go Back   The Omni Group Forums > OmniFocus > OmniFocus 1 for Mac
FAQ Members List Calendar Search Today's Posts Mark Forums Read

 
OmniFocus 1.8 sneaky peeks are now available Thread Tools Search this Thread Display Modes
Quote:
Originally Posted by macula View Post
I don't see what the problem was with the original implementation. We all review our projects regularly, so upon completing all subtasks of a group/project, and during the next review at the latest, would always find out that a "childless" parent task exists, and we would cross it out as completed.
Ah, so in a paper-based GTD system done strictly by the book you would have waited until you did a weekly review to notice that a project was done, rather than observing you had come to the end of your list of next actions?
Quote:
Quite clearly, OmniFocus is not a 100% GTD-compliant system anymore.
No offense intended, but when people start talking about things being "100% GTD-compliant" it makes it difficult to read the post due to all the eye-rolling going on, it's like trying to read on a roller-coaster :-) You can find plenty of hits in a Google search for "GTD-compliant" but none of them are on David Allen's websites. He does however have the following description:

http://www.davidco.com/what_is_gtd.php

regarding which one maker of a "GTD-compliant" app list observes:

This list is short to accommodate individual preferences, and because the David Co. official description of GTD is very broad.
Quote:
Yet those of us who adhere to GTD as a system—some of us practitioners for years—this is a step backwards.
Maybe your last sentence might start as follows:

Quote:
Yet for some of us who adhere to GTD as a system
Fair enough? I've also been a GTD practitioner for years, and I think Ken would likely consider himself one as well. For something that's apparently a step backwards, he's always seemed pretty enthusiastic about it :-)
 
Maybe an example would help me understand it. So lets say that I have a project that is day job related. I have actions in this project that use the Calls, Office, Computer, Agendas:Tom, Waiting For and Errands contexts. What context would be recommended to set for the default context of the project and why would it be a good choice?
 
I think that Ken's suggestion of putting the context as "Review" on a project (or action group) makes sense if you really don't want to look at the empty project until your next review cycle.

This is what I've done, and it works better for me now that the projects show up in the "Review" context, particularly since I do my "Daily Reviews" in context view rather than project view, so it allows me to more easily see these empty projects on a daily basis and thereby decide if they're truly "done" or if there are more actions for them. In the past, I use to actually drop a final placeholder task into such projects that said "Review Project Completion" which often required an extra step.

The only real change that I'd like to see is that projects and action groups that are set to auto-complete probably should be hidden from the context view. There's not much sense in displaying that extra project entry when it's going to disappear after the last task is completed anyway.
 
Quote:
Originally Posted by sriggs View Post
Maybe an example would help me understand it. So lets say that I have a project that is day job related. I have actions in this project that use the Calls, Office, Computer, Agendas:Tom, Waiting For and Errands contexts. What context would be recommended to set for the default context of the project and why would it be a good choice?
Personally, I use a "Review" context for projects like these so that it comes up during my next review cycle (end of day or beginning of day, as the case may be). I can then drag-and-drop it to its appropriate context, assuming I don't manually assign one when I create the task.

Realistically, I rarely do much with default contexts anyway, and the "review" context is largely a catch-all placeholder -- new items land in the inbox and in my system don't leave the inbox until they've been assigned both a project and a context. My Inbox of course gets reviewed daily.
 
Quote:
Originally Posted by jdh View Post
Personally, I use a "Review" context for projects like these so that it comes up during my next review cycle (end of day or beginning of day, as the case may be). I can then drag-and-drop it to its appropriate context, assuming I don't manually assign one when I create the task.

Realistically, I rarely do much with default contexts anyway, and the "review" context is largely a catch-all placeholder -- new items land in the inbox and in my system don't leave the inbox until they've been assigned both a project and a context. My Inbox of course gets reviewed daily.
Thanks for the reply. Have you found that your workflow has improved with this new context as opposed to using the built in review perspective?
 
Well, it's too early to tell for certain, but it seems an improvement. I only use the actual "Review" perspective for my weekly reviews. I do my daily reviews in context view with a custom perspective ("Tactical") that displays all available tasks grouped by context. I start by cleaning up anything in the Review context or "No Context" section, reassigning those tasks to proper contexts. I then drill down quickly through the remaining contexts to flag critical items for the day, reassign contexts if necessary and look for anything that's on hold or otherwise stuck.

Following my review, I work primarily from a "Today" perspective that includes due or flagged items that are available, and only switch back to my full "Tactical" view (all available items by context) on the rare occasions that I actually empty out an active context and still have time or energy to do other items in that context.
 
Quote:
Originally Posted by whpalmer4 View Post
Ah, so in a paper-based GTD system done strictly by the book you would have waited until you did a weekly review to notice that a project was done, rather than observing you had come to the end of your list of next actions?
Indeed I don't see this as a problem, so allow me to clarify and summarize my objections once again:

First, it is conceptually untidy to categorize a project or group into a single context.

Second, I have a penchant for (re)viewing my actions grouped per context and filtered by "remaining". In this scenario, the new implementation will include my project and group titles as individual tasks to be completed. This is both redundant and misleading.

Overall, the user is now forced to adapt to the idiosyncrasies of the software, rather than the other way around.

Quote:
No offense intended, but when people start talking about things being "100% GTD-compliant" it makes it difficult to read the post due to all the eye-rolling going on, it's like trying to read on a roller-coaster :-)
Every little recess in the system has a psychological impact, so "anything goes" is not a constructive mindset.

Assigning contexts to projects runs contrary to both the spirit and the letter of GTD. "You can't do a project" (p. 155). I couldn't care less about the letter, but the ramifications in this case are non-negligible.
 
Quote:
Originally Posted by macula View Post
Are you sure this is the correct path to the calendar file? On my system, the correct path is https://idisk.me.com/[my username]/Documents/OmniFocus-Reminders.ics
[please note the capitalization]
You are right. I forgot to specify the full path in my post earlier.
 
May I suggest this as a middleground solution which could put an end to this quarrel between the "ancients" (such as me) and the "moderns" (whpalmer):

In the application preferences, under "Data > Projects and action groups," allow the user to define a default context for new projects and action groups. Given this option, I would create a "project/group" context and define it as the default context for those entities. My projects and action groups would be assigned to a context automatically, sparing me the need to change my deeply ingrained habits, with the added advantage that the particular context would make sense.

Ken, are you open to this suggestion?

Last edited by macula; 2010-02-18 at 12:31 PM..
 
Quote:
Originally Posted by sriggs View Post
Maybe an example would help me understand it. So lets say that I have a project that is day job related. I have actions in this project that use the Calls, Office, Computer, Agendas:Tom, Waiting For and Errands contexts. What context would be recommended to set for the default context of the project and why would it be a good choice?
I'd take a few seconds to think about the likely tasks in the project and pick the most common context. I wouldn't spend much time on it because I rarely rely on the defaulting mechanism -- most of my manually-created actions get created via quick entry or the inbox. As a result, I had about 200 projects with no default context assigned.
 
 


Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes


Similar Threads
Thread Thread Starter Forum Replies Last Post
OmniFocus 1.7.5 sneaky peeks underway! Ken Case OmniFocus 1 for Mac 1 2009-10-21 01:34 PM
OmniFocus 1.7 sneaky peeks have begun! Ken Case OmniFocus 1 for Mac 56 2009-08-27 04:37 PM
OmniFocus v1.6 sneaky peeks! Ken Case OmniFocus 1 for Mac 32 2009-02-26 01:12 AM
Sneaky Peeks gone? Smithcraft OmniWeb General 5 2007-10-25 05:10 AM
CPU use in sneaky peeks hardcoreUFO OmniWeb Bug Reports 7 2007-08-31 02:23 PM


All times are GMT -8. The time now is 01:20 AM.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2019, vBulletin Solutions, Inc.