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 whpalmer4 View Post
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...
I also rarely used the default context mechanism, but I've started to now that there's more reason to do so.

In my case, I try to assign the context I need to be in to make the decision whether to complete the project/group or to add more actions. As a catchall for when I can't think of anything else, I have an "OmniFocus" context that I use similarly to the aforementioned "Review" context.

-Dennis
 
Quote:
Originally Posted by macula View Post
Does anyone know how to make the reminders calendar visible on iCal without getting duplicate reminders on the iPhone? If I subscribe to the reminders calendar both on the iPhone and on the desktop I end up getting duplicate reminders on the phone.
Yes, iPhone OS 3.1 syncs subscribed calendars from iCal, so if you subscribe to the your OmniFocus Reminders calendar on both your iPhone and in iCal, and then sync the two devices, the calendar will show up twice on your iPhone. I wrote about this last September:

http://forums.omnigroup.com/showthread.php?t=13801

AFAIK, the only current workaround is to not subscribe to it in both iCal and the iPhone Calendar app. It's probably best to only subscribe to the OmniFocus calendar from your iPhone since the copy from an iCal sync is static and not updated in realtime -- it only gets updated when you sync with iCal.

-Dennis
 
Quote:
Originally Posted by Toadling View Post
I also rarely used the default context mechanism, but I've started to now that there's more reason to do so.

In my case, I try to assign the context I need to be in to make the decision whether to complete the project/group or to add more actions. As a catchall for when I can't think of anything else, I have an "OmniFocus" context that I use similarly to the aforementioned "Review" context.

-Dennis
Dennis' and whpalmer's suggested solutions only corroborate that the new behavior of projects and group actions in OF 1.8 forces users to use "hacks", and thus interferes with the user's thought process. I really do not want to be a nuisance by repeating ad nauseam my aversion to this revision—and indeed will spare you from further comments on this from me—but clearly, if Omni wants to ensure projects and group tasks will not "fall through the cracks," then they should come up with a genuine solution instead of forcing the user to resort to conceptual acrobatics of this sort. It should be easy for us, not for them.

Last edited by macula; 2010-02-18 at 01:18 PM..
 
Quote:
Originally Posted by Toadling View Post
AFAIK, the only current workaround is to not subscribe to it in both iCal and the iPhone Calendar app. It's probably best to only subscribe to the OmniFocus calendar from your iPhone since the copy from an iCal sync is static and not updated in realtime -- it only gets updated when you sync with iCal.

-Dennis
Thanks, Dennis, for this info.
 
Hallelujah!

As whpalmer posted in another thread, it is now possible to deactivate the display of projects and group actions in context views with the following bookmarklet:

omnifocus:///change-setting?ContextM...sParents=false

I think this answers our plea for making the new behavior optional, and everyone can be happy now.

Thank you.
 
Sorry, I am breaching my self-imposed censorship on this matter. One last point if I may:

I understand the reasoning supporting the new behavior of projects and group tasks that Omni is introducing in OF 1.8. What I do not like is the implementation: Forcing the user to enter an arbitrary context or, as an equally ugly alternative, put the project/group in the "no context" black list.

Here is a possible workaround that is conceptually elegant and user-friendly: Tweak the OF code so that all projects/groups are internally assumed to belong in all contexts that the project's/group's completed and remaining actions collectively belong in. In this scenario, upon completing all children actions the parent project/group will appear as available in all contexts of the completed children.

An alternative solution—easier in terms of engineering, it seems to me—is for Omni to automatically and non-modifiably place all projects/groups in a dedicated "context" called "Projects/Groups" or something, without requiring the user to set that context or any other context as the default for each project/group.

Last edited by macula; 2010-02-19 at 01:24 AM..
 
I'd like to throw my two cents in on the discussion about assigning contexts to projects. After upgrading to 1.8, I now have a modest 22 items with no context, which surprised me because I try to make sure that all of my tasks have contexts. The No Contexts bucket used to be a great tool for me to quickly identify any tasks that I didn't give a context to.

From my understanding, I'll now have to assign a context to all of my projects (a default context), just to have that bucket counter clear. That, however, completely ruins my use of the of the No Context bucket. I won't get to see the tasks that I missed assigning contexts to because the default context will make sure that nothing ever appears there.

That one change seems totally busted and inelegant. OF is essentially forcing me to assign a context, and if none of my contexts are appropriate, the given suggestion by Ken is to assign a completely arbitrary context to every project I create for reasons that ultimately sabotage my workflow.

[erased furious rage]

All of the other changes in 1.8 seem great, but projects without a default context showing up in the No Context bucket completely missed the mark.

Quote:
Originally Posted by macula View Post
Here is a possible workaround that is conceptually elegant and user-friendly: Tweak the OF code so that all projects/groups are internally assumed to belong in all contexts that the project's/group's completed and remaining actions collectively belong in. In this scenario, upon completing all children actions the parent project/group will appear as available in all contexts of the completed children.

An alternative solution—easier in terms of engineering, it seems to me—is for Omni to automatically and non-modifiably place all projects/groups in a dedicated "context" called "Projects/Groups" or something, without requiring the user to set that context or any other context as the default for each project/group.
The first suggest seems at first brush to be unobtrusive and useful, two qualities that the current implementation lacks. The latter seems serviceable.

Last edited by vinyl_warrior; 2010-02-19 at 01:47 PM.. Reason: frustration was too snarky
 
Quote:
Originally Posted by macula View Post
Here is a possible workaround that is conceptually elegant and user-friendly: Tweak the OF code so that all projects/groups are internally assumed to belong in all contexts that the project's/group's completed and remaining actions collectively belong in. In this scenario, upon completing all children actions the parent project/group will appear as available in all contexts of the completed children.
Unless I'm misunderstanding something, this solution appears to be potentially more confusing. Very few of my projects actually only use a single context, so how would OF determine which context should be assigned in those cases?

Quote:
An alternative solution—easier in terms of engineering, it seems to me—is for Omni to automatically and non-modifiably place all projects/groups in a dedicated "context" called "Projects/Groups" or something, without requiring the user to set that context or any other context as the default for each project/group.
That sounds even odder... Creating a context for projects and groups defeats the purpose of having a streamlined workflow, since the user has no control over where things do appear. To create a "projects/groups" context, we might as well just switch back to planning mode.

Quote:
Originally Posted by vinyl_warrior View Post
From my understanding, I'll now have to assign a context to all of my projects (a default context), just to have that bucket counter clear. That, however, completely ruins my use of the of the No Context bucket. I won't get to see the tasks that I missed assigning contexts to because the default context will make sure that nothing ever appears there.
The more I think about it, the more I see this aspect as the crux of the problem. If I choose not to assign a context to a project/group, perhaps OF should just ensure that this particular project or group doesn't appear in context view at all -- not in "No Contexts" or some new placeholder context or anywhere else.

I'd also combine this with the idea that projects and groups that are set to automatically complete should not appear in the context view either -- if they're going to be automatically marked completed when all of their dependent tasks are finished, then what's the point of showing them in context view, since in that sense they really aren't "actionable" but are rather just containers.

I'd propose the following simple change in logic:

A Project or Action Group will appear in context view if and only if the following conditions are met:

1. It has been specifically assigned a context.
2. It is NOT set to be marked completed automatically.
3. It is NOT a Single Action list (this one is already there).

This way, those who don't want their projects showing up context view could simply avoid assigning them a default context. This also means that majority of users who don't want this feature wouldn't have to change a thing, since most users don't have contexts assigned to their projects anyway.

Note that this does leave some murkiness around the issue of Default Context, which some users may have want to use without having to assign an actual project context. IMHO Default Context and "Project Context" should be two distinct settings, but of course that would require a second context field on every project and may be going a bit beyond the scope of our current discussion.
 
Quote:
Originally Posted by jdh View Post
Unless I'm misunderstanding something, this solution appears to be potentially more confusing. Very few of my projects actually only use a single context, so how would OF determine which context should be assigned in those cases?
In fact, I was suggesting that the project at hand would be displayed not under one but actually all contexts of its children. For example, if your project X includes an "errand" and a "phone call," upon completing these two actions project X would be made visible and "float" in both the "Errands" and the "Phone Calls" contexts (perhaps with a different color to indicate that this is a floating project/group rather than a genuine action in that context). I realize this requires significant modifications to the underlying logic, however.

Quote:
That sounds even odder... Creating a context for projects and groups defeats the purpose of having a streamlined workflow, since the user has no control over where things do appear. To create a "projects/groups" context, we might as well just switch back to planning mode.
Well, it doesn't defeat the purpose in the sense that projects/groups would not risk "falling through the cracks" anymore, instead appearing in context view upon having their constituent actions completed.

Quote:
If I choose not to assign a context to a project/group, perhaps OF should just ensure that this particular project or group doesn't appear in context view at all -- not in "No Contexts" or some new placeholder context or anywhere else.
That's a good suggestion, but again, it does not respond to the perceived need to prevent projects/action from "falling through the cracks," which motivated these changes in the first place.

Quote:
I'd also combine this with the idea that projects and groups that are set to automatically complete should not appear in the context view either —
Quote:
Note that this does leave some murkiness around the issue of Default Context, which some users may have want to use without having to assign an actual project context. IMHO Default Context and "Project Context" should be two distinct settings, but of course that would require a second context field on every project and may be going a bit beyond the scope of our current discussion.
I agree that two distinct settings would be better. In general, though, I strongly oppose the manual assignment of a particular context to projects and groups. As numerous users have repeatedly written in this and other threads, this is a "hack", a conceptually inconsistent workaround, for ensuring that projects and groups will not "fall through the cracks". My intention was to counterpropose two conceptually sound solutions for addressing this need.

Last edited by macula; 2010-02-19 at 06:40 PM..
 
Quote:
Originally Posted by macula View Post
My intention was to counterpropose two conceptually sound solutions for addressing this need.
Interesting ideas, but I'm not convinced they're better than the current implementation for my workflow (or even that the current behavior is a "hack").

Just wanted to point out that not everyone dislikes these 1.8 changes. I'm not even sure there's a significant number of people having a problem with it. That doesn't mean the issue still can't be addressed in some way, of course. :-)

-Dennis
 
 


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:10 PM.


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