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

 
What are the outstanding workflow issues in 1.8? Thread Tools Search this Thread Display Modes
That seems like a pretty elegant way to have it both ways, especially using perspectives to help manage that.

Will these changes affect the iPhone application? It would be nice to see the same flexibility there. (And, BTW, I *heart* perspectives on the iPhone!)
 
So 1.8 is about to go final, and the "default context" field still serves double duty as "project/group action context," as well.

This is disappointing, and I expected better of Omni than a so evidently half-baked feature.
 
Quote:
Originally Posted by macula View Post
So 1.8 is about to go final, and the "default context" field still serves double duty as "project/group action context," as well.
There isn't a "default context" field anymore, items just have contexts. If you don't want to see parents listed under their context in context mode, you can choose "Hide Parent Items in Context Mode" from the View menu.

Is there some workflow that this breaks for you?
 
Thanks for alerting me to that change—I missed a few posts on this thread. I understand that now tasks "simply" inherit the context of their parent. In that sense, the context of a group action or project behaves as a "default" context for the children. Unless I'm missing something, then, the change you are referring to is rather nominal.

I have written my objections to this new behavior above but will gladly repeat here: Conceptually speaking, (my) action groups and projects do not really belong in any "real" context because they contain children of various contexts. At the same time, leaving the "context" field of groups/projects blank would not work either, because I would not want my "no context" view to mix groups/projects with single actions that I have left without a context only inadvertently.

Therefore, the best solution I could come up with was to create a "group/action" context, which would display those types of entities together in context view.

Once this step is taken, however, all children tasks automatically inherit this "group/action" context. And quite often I forget to notice this erroneous context, with the result that single actions are mixed in context view with groups and projects. This behavior is erratic because the expected outcome of neglecting to set a task's context would be to find the task in the "no context" bin rather than the "group/project" bin. At present, however, the user needs to check for "neglected" (e.g. hastily entered) tasks at two places: The "no context" bin (for tasks entered via the Quick Add pane) and the "project/group" bin (for tasks entered in the app's main window). It's inconsistent and clumsy, and truly jars against the overall elegance of this software.
 
Go read Ken's post #60 in this thread again, as it sounds to me like it addresses your complaints. No need to assign a context to projects or action groups, and they can be hidden when trawling for contextless actions in the No Contexts bin.
 
Thanks, Bill. I see your point but the solution still seems to me like a patch up job. Let's take a sequential project as an example:

Code:
PROJECT MyProject [sequential]
     Group_Task_A [sequential or parallel (doesn't matter)]
           Task_A.1
           Task_A.2
     Task_B
Following yours and Ken's suggested setup, Group_Task_A and MyProject are assigned no context. Also following your suggestion, I have chosen to hide groups and projects from the "no context" bin.

Now, like most people, during the day I tend to use the context view alone to get things done. I only use the project view for my daily and weekly reviews. Let's assume that early in the morning I complete Task_A.1 and Task_ A.2. The next actionable step is now Task_B, which will not be released until Group_Task_A is checked off. In this setup, however, this group task will be visible only in the project view which, as I said, I never bother to (and should not have to!) review more than once during the day. As a result, I miss the opportunity to complete Task_B before my next daily review.

The only solution is to ensure that groups and projects are automatically marked as completed upon completing their children. This however has serious workflow implications (disadvantages), as we all know.

In short, using OF feels to me more "precarious" and "unpredictable" than before. There are too many parameters to take into consideration and yet, ironically, the user feels that less degrees of freedom are available in setting up and using the system, because every solution involves a compromise.

All such problems—this overall lack of transparency—would be instantly resolved if group actions and projects had separate fields for their own context and for their children's default context. Or (as has been suggested) if projects and groups were automatically placed in a hard-wired bin dedicated to these two types of entities. Despite the apparent increase of information and complexity, this solution would actually simplify things in terms of usability. I feel that the developers' understanding of "complexity vs. simplicity"—and their express intention to "simplify" this application—is misguided in this case.

Last edited by macula; 2010-05-29 at 12:51 AM..
 
Quote:
Originally Posted by macula View Post
Thanks, Bill. I see your point but the solution still seems to me like a patch up job. Let's take a sequential project as an example:

Code:
PROJECT MyProject [sequential]
     Group_Task_A [sequential or parallel (doesn't matter)]
           Task_A.1
           Task_A.2
     Task_B
Following yours and Ken's suggested setup, Group_Task_A and MyProject are assigned no context. Also following your suggestion, I have chosen to hide groups and projects from the "no context" bin.

Now, like most people, during the day I tend to use the context view alone to get things done. I only use the project view for my daily and weekly reviews. Let's assume that early in the morning I complete Task_A.1 and Task_ A.2. The next actionable step is now Task_B, which will not be released until Group_Task_A is checked off. In this setup, however, this group task will be visible only in the project view which, as I said, I never bother to (and should not have to!) review more than once during the day. As a result, I miss the opportunity to complete Task_B before my next daily review.
That is true only if you aren't including the No Contexts bin in your perspective, or have otherwise narrowed the view to exclude wherever the project would pop up once all the actions are complete. That same issue will be present with the proposal to have a separate bin for projects and groups -- if you aren't looking there, you won't see the project or group becoming available.
Quote:

The only solution is to ensure that groups and projects are automatically marked as completed upon completing their children. This however has serious workflow implications (disadvantages), as we all know.

In short, using OF feels to me more "precarious" and "unpredictable" than before. There are too many parameters to take into consideration and yet, ironically, the user feels that less degrees of freedom are available in setting up and using the system, because every solution involves a compromise.

All such problems—this overall lack of transparency—would be instantly resolved if group actions and projects had separate fields for their own context and for their children's default context. Or (as has been suggested) if projects and groups were automatically placed in a hard-wired bin dedicated to these two types of entities. Despite the apparent increase of information and complexity, this solution would actually simplify things in terms of usability. I feel that the developers' understanding of "complexity vs. simplicity"—and their express intention to "simplify" this application—is misguided in this case.
You should of course provide your feedback, as you are doing. But I think it is worth contemplating the possibility that with well over 50,000 OmniFocus customers out there, your viewpoint (or mine!) may not be representative of what Ken & Co. are hearing from the customers who are contacting Omni directly for support.

I'm not trying to sell you on this approach being the "right" one. Very little, if any, of this feature comes from suggestions i have made publically or privately, and if Ken decides this afternoon he wants to do something completely different, that would be fine with me, so long as it is an improvement. My aim with my forum posts is to help people effectively use the tools we have, because for the most part, the pace of change is slow, unless they happen to be working on the area in question at the time.
 
 


Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes


Similar Threads
Thread Thread Starter Forum Replies Last Post
Workflow shapes zoltanbarabas OmniGraffle General 3 2013-01-23 11:22 AM
Omnisync Workflow mattsbrand OmniPlan for iPad 0 2012-12-17 06:13 AM
Non-GTD workflow using OmniFocus Arrow Applying OmniFocus 4 2009-04-05 06:41 PM
OF and your workflow steve OmniFocus 1 for Mac 4 2007-09-02 03:57 AM
RC1 is outstanding! Handycam OmniWeb General 19 2006-08-31 11:49 AM


All times are GMT -8. The time now is 12:22 AM.


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