The Omni Group Forums

The Omni Group Forums (http://forums.omnigroup.com/index.php)
-   OmniFocus 1 for Mac (http://forums.omnigroup.com/forumdisplay.php?f=38)
-   -   Two requests (http://forums.omnigroup.com/showthread.php?t=19631)

gshenaut 2011-01-07 09:16 AM

Two requests
 
These are a couple of related things I wouldn't mind being able to use in OmniFocus.

(1) Being able to mark an object with an explicit, invariant “Due Soon” and “Overdue” without entering an absolute date. Sometimes, I really don't have an actual deadline, but certain work is inherently due soon or even overdue. This status would not change, that is, the invariant “Due Soon” mark would never change to “Overdue”, it would just stay “Due Soon” until I changed it manually to something else. An excellent way to implement this would be in terms of invariant relative dates (dates that stay relative): invariant “Due Soon” would actually an invariant “due in 2 days”. Allowing invariant Overdues that are invariant “due yesterday” versus invariant “due last week” would be a nice touch.

(2) Being able to mark explicit sequential dependencies between objects such that Object B is blocked until Object A is completed (or deleted), at which point it would automatically become active. If Object B was marked with a relative (but not invariantly relative) date(s), then its date(s) would become absolute. However, invariant “Due in 2 days” would stay as it is, but would start showing up as (e.g.) “Due Soon”. This would allow something to be “Due two weeks after Object A is completed”, and chains of these would really cool for planning. A graphical view of dependencies like Omniplan's Gantt Chart view would make this extremely useful.

In summary, there would be three types of date:
(1) absolute dates
(2) invariant relative dates
(3) blocked relative dates (convert to absolute when unblocked)

Greg Shenaut

P.S. Note that the two kinds of relative dates could be combined, if the “invariant relative dates” were simply “relative dates” blocked with something that will never happen, perhaps a built-in, system-defined “Never” event.

RobTrew 2011-01-07 10:29 AM

Your 1) seems formally similar to flagging an item.

Your 2) looks like the tasks in a sequential project, in which each is treated as 'unavailable' (in the language of the filter system) until its predecessor is marked as completed.

gshenaut 2011-01-07 04:24 PM

(1) Not if implemented as an invariant time offset. Also, there is only one mark: how could there be a mark for invariant Overdue and for invariant Due Soon? And, the idea is for the invariant versions of those states to be treated just like the normal versions (that is, displayed with other Due Soon or Overdue objects); the mark doesn't do that. In other words, on Monday, an invariant relative time of two days in the future would be treated just like an ordinary time of Wednesday; the difference is that if nothing changed, on Tuesday, the same invariant relative time would now be treated the same as an ordinary time of Thursday.

(2) No, the difference is that tasks and projects could be linked to other tasks and other projects. Currently, only tasks within a single project can be linked in this way, as I understand it. As an example: if I were working on an application and realized that I can do a better job on them if I developed a tool, I could put them on hold in their current state until I finished the tool. When I finished the tool, all of the projects would become active again, with their schedules updated to the present. If, while building the tool, the same thing happened again--an additional tool was needed, and one or more of the tools applied to more than one current project--then you'd see the kind of cross-project dependencies that could be represented.

curt.clifton 2011-01-08 09:06 AM

[QUOTE=gshenaut;91378]
(2) No, the difference is that tasks and projects could be linked to other tasks and other projects. Currently, only tasks within a single project can be linked in this way, as I understand it. As an example: if I were working on an application and realized that I can do a better job on them if I developed a tool, I could put them on hold in their current state until I finished the tool. When I finished the tool, all of the projects would become active again, with their schedules updated to the present. If, while building the tool, the same thing happened again--an additional tool was needed, and one or more of the tools applied to more than one current project--then you'd see the kind of cross-project dependencies that could be represented.[/QUOTE]

Interesting ideas. One way I handle this using the current features of OF is to add a task to the dependent project like "In time, finish the helper tool." with a context of Awaiting. Later, when I review that project, if the helper tool is done, I'll just check off the item. Alternatively, I might put the dependent project on hold and add a final task "Activate dependent project" to the helper tool project.

Neither of these is automated, of course; but both are possible today and are in the spirit of GTD: a simple system, regularly reviewed.


All times are GMT -8. The time now is 07:09 AM.

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