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 ksrhee View Post
Hopefully, you can enlightened me on this. How is (A) different from what we have today (1.75)? Even in the current version, if you assign a default context, you would be presented with the situation you say you don't want.
The difference is that in 1.8, my No Context list is polluted unnecessarily if I don't assign a default context, or all my items get a default context that may not match reality and lead to open loops.

Quote:
Originally Posted by ksrhee View Post
For (2), yes, you would not find this is the missing context, but if you assign a context such as "review" to the project or groups, then you would find the "missing" contexts items in the Review context because you didn't reassign context to the items when you created them. You would just have to find it at a different place.
And if I did want to use an *actual* default context for some reason? Then I have to track down the item with the "wrong" default context, which should have a different default context, leading to the "loss" of items by placing them in the wrong context.

Quote:
Originally Posted by ksrhee View Post
I believe if people get used to the new work flow, I don't think it would matter to them that much, but YMMV.
I think it depends on how you use OF, Contexts, Projects and so on. For some, this is clearly a welcome change, because they previously had to deal with lost actions, open loops or ugly workarounds.

For others, this is a terrible change, because it has the potential for losing actions, creating open loops or implementing ugly workarounds.

Can't win for losing.

I don't tend to use default contexts, because I want to chance to review my items with no context and ensure they're properly categorized. It destroys my workflow to put everything into a default "Review" (or whatever) context, because that means items without a context no longer show up on "No Context", they show up in "Review", and I have to look at possibly dozens of projects and actions, mixed together, only some of which are actually actionable.

Hiding the projects, and using Available instead of Remaining may be a workaround. The inaccurate number of items in a context remains an issue, and disturbs my attempts at "mind like water".
 
Is anyone else experiencing Action group styling issues? I tried to set it to green so i could visually discern the action grouped tasks, but they don't change color.
 
Quote:
Originally Posted by MutantSquid View Post
Is anyone else experiencing Action group styling issues? I tried to set it to green so i could visually discern the action grouped tasks, but they don't change color.
I can confirm that action groups set to be styled a different color are so styled in 1.7.5 but not in the latest 1.8 sneaky peek. Just to clarify, however, only the action group header is styled, not the actions contained in it.

Hmm, I see the project itself is being styled differently as well, wonder why that is...
Attached Thumbnails
Click image for larger version

Name:	Action group example in 1.7.5.png
Views:	685
Size:	10.9 KB
ID:	1278   Click image for larger version

Name:	Action group example in 1.8.png
Views:	654
Size:	11.4 KB
ID:	1279  
 
Quote:
Originally Posted by jasong View Post
The difference is that in 1.8, my No Context list is polluted unnecessarily if I don't assign a default context, or all my items get a default context that may not match reality and lead to open loops.

And if I did want to use an *actual* default context for some reason? Then I have to track down the item with the "wrong" default context, which should have a different default context, leading to the "loss" of items by placing them in the wrong context.

I don't tend to use default contexts, because I want to chance to review my items with no context and ensure they're properly categorized. It destroys my workflow to put everything into a default "Review" (or whatever) context, because that means items without a context no longer show up on "No Context", they show up in "Review", and I have to look at possibly dozens of projects and actions, mixed together, only some of which are actually actionable.

Hiding the projects, and using Available instead of Remaining may be a workaround. The inaccurate number of items in a context remains an issue, and disturbs my attempts at "mind like water".
I can see how you find this not helpful since you do have to change the workflow.

This is something I used to do when I used LifeBalance, and now I can implement this in OF.

Every project gets the default context that matches most of actions in the project - this way I don't have to enter the context again.

I put filter to things that are available in the context area so that I can only see things I can work on. Even Next action filter should block projects.

The only time projects will show is when it's empty. If a project shows up, I decide to act on the project itself: add more action items; put project on hold and assign a new context (such as Review), mark the project complete, or drop it.

If I add more action items, the project will no longer show in the context view; so, the problem solved.

If I drop the project or complete it, it's done.

Now with the project on hold and with a new context, I can set up the perspective to track these pretty easily.

Let's say I decide to reactivate the project (take it out of hold) and add a new item, but I forgot to change the default context (i.e., it remains as Review). Then the new action items in the project will inherits "Review" as the context, and that's not what I want. However, if I look at what's under Review, I should be able to find the new action item pretty easily. [Right now I believe there is a bug in the context view under remaining that complicates the matter.] Then I can change these items' context easily.

Yes, this does require you to change your workflow, and some people may not like it, and thus, the option to disable this completely (& fixing the bug on counters of course).

However, as some of us have said, I find this feature extremely helpful when using another program (nothing falls through the cracks and I get stuff done earlier than my periodic review would allow); so, I welcome the change in OF.

Now one new feature that might solve your issue might be to have the ability to assign a different contexts to projects/groups themselves that are different than default context (e.g., projects or action groups), that way, we can track these easily in the context view if they show up.

Again, YMMV.

Last edited by ksrhee; 2010-02-22 at 01:01 AM..
 
Quote:
Originally Posted by whpalmer4 View Post
I can confirm that action groups set to be styled a different color are so styled in 1.7.5 but not in the latest 1.8 sneaky peek. Just to clarify, however, only the action group header is styled, not the actions contained in it.

Hmm, I see the project itself is being styled differently as well, wonder why that is...
I ran into this too. It's because the action group is marked as "blocked" until all the actions within the group are completed.

This gets to the heart of why this is so confusing.

The one thing I'm still seeing, that I believe is a bug, is the same behavior with projects. Projects are still styled as blocked, even if everything within the project is complete. Bug or user error, I'm not sure, but it appears to be a bug.
 
One additional reason why the new behavior is, in my view, problematic. You look at your actions in planning mode, and see at least one available action within an unavailable group. How inconsistent and disconcerting! Available actions under unavailable headings… That's a lot of mental turbulence.

Last edited by macula; 2010-02-22 at 10:09 AM..
 
I don't know if this has been brought up already in this thread—if so, please disregard and accept my apologies.

It seems to me that the source of all evil is the ability bestowed upon the user to keep a parent "pending" (i.e. not ticked off) while all its children are completed—I'm referring to that insidious option at the very bottom of Preferences>Data. That's how the dilemma that the Omni developers faced emerges: Shall the action following the parent be released anyway (whereby the parent risks "falling through the cracks") or kept unavailable until the parent is ticked off (whereby your project risks stalling with the user possibly in oblivion or confusion)?

It is reasonable and laudable that Omni tries to address this problem. However, the solution they are suggesting in 1.8a is, as many of us in this thread believe, at least as confusing and introduces lots of conceptual and usability problems.

So much confusion, and so much debate pitting two imperfect approaches against each other, just in the name of "flexibility": Allowing the user to keep a parent open even if all its children are completed. In my view, this is too high a price to pay for a damn check box in the preferences!

Here is my somewhat radical suggestion then: Remove the check box altogether and hardcode this behavior whereby a parent will be automatically marked as completed when its children are completed. Then also remove all this "1.8 baggage", most of all the assignment of contexts to parents, which has sparked so much lively debate among both devoted and new users.

The cost will be minimal: If you want to add a further action to a completed parent, just make a perspective to display completed parents and do your thing.

The benefit is maximal: Nothing falls through the cracks, and everything is kept simple, clear and tidy. No conceptual acrobatics. No mental turbulence.

As an added benefit, this suggestion only requires pruning of the existing code, rather than augmentation.

Last edited by macula; 2010-02-22 at 11:01 AM..
 
I'm not really a fan of the idea of having projects automatically complete without my intervention, simply because they will fall through the cracks. A perspective to view completed projects doesn't help this, as I could have dozens of completed projects, and going through all of the ones that are actually closed and done to find the one or two that may need to be re-opened is going to be cumbersome at best.

For what it's worth, I think there are two critical issues here that may be quite easy for the Omni folks to solve: The appearance of unassigned parent items in the "No Context" section (or in context view at all), and the new double-meaning for the "Default Context" field. I propose the following:
  • Projects and action groups get two fields: Default Context and Parent Context.
  • The Default Context behaves exactly as it did pre-1.8 and has no effect on the appearance of projects or action groups in context view.
  • The Parent Context field handles the new functionality introduced in v1.8.
  • Projects and Action Groups without a "Parent Context" assigned simply do not appear in action lists at all. No Context continues to be used only for actions and not projects or action groups.
  • Projects and Action Groups with a "Parent Context" behave in the same way they do right now in 1.8 with the Default Context.
The above would allow users who don't like the new functionality at all to completely ignore it by simply not assigning "Parent Contexts" to any of their projects or action groups (which would also be the default state). Those users who know what they're doing and want to take advantage of projects and action groups as actionable items can assign "Parent Context" entries as necessary. Unlike a global option, this also has the very useful advantage of allowing a mixed-mode scenario. For example, I would very much like to see some of my Action Groups be actionable items in context view, but I don't really like the idea of seeing my actual projects appear there.

Although we're talking about adding an extra field, this solution actually strikes me as elegantly simple since it leaves the new functionality "off" by default -- the "Parent Context" field is blank on all existing projects and action groups until the user explicitly specifies one, and only those users who want to use the new feature are going to be bothered doing so.

Last edited by jdh; 2010-02-22 at 10:38 AM..
 
Quote:
Originally Posted by macula View Post
Here is my somewhat radical suggestion then: Remove the check box altogether and hardcode this behavior whereby a parent will be automatically marked as completed when its children are completed.
Uh, no thanks! That would require complete planning of all actions in a project before starting, or additional time hunting down completed action groups and projects to see if something more should be added. The former definitely isn't something that would be put forward as a GTD precept, and the latter is a big waste of time.
 
jdh,

I'll have to think about it some more, but your suggestion sounds good to me at first hearing. I like the ability to use the functionality only some of the time (which is how I use the auto-complete feature), too. I think "parent context" might be a confusing name for some, however, especially when dealing with action groups.
 
 


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 02:19 PM.


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