[macula]

Originally Posted by Toadling

Many people weren't using the parents' default context field, though, so now many parents are showing up in the "No Context" bin in context mode.

Toadling,

For the sake of completeness in your good overview of the issue, may I add that the problem is deeper and wider than the "migration" of existing data to the new system.

1. Users are not accustomed to using the "default context" field, so they are prone to neglecting to set it, thus accidentally adding many future parents in the "no context" bin.

2. Some users don't even like to set a "default context" for parents. They just can't be bothered. Capricious or not, this needs to be taken into account.

3. (Some) users consider it conceptually absurd to assign a single context to a parent whose children carry a multitude of contexts.

4. The new system makes "default context" quite literally a misnomer, since it now also stands for "parent's context."

5. The new system equates the "default context" (i.e. normally the context used by the highest number of children) with the parent's own context. Even if we temporarily assume that "parent's context" makes sense (though it really doesn't), we must realize that it is not necessarily determined by frequency. For example, a project titled "Write article" may consist of 5 children in the "errands" context…

a. Make photocopies of research notes
b. Clean up desk
c. Call publisher to request copy of guidelines for authors
d. Enter new book acquisitions in bibliographic database
e. Get "XYZ" book from library

… and only 2 children in the "scholarship" context...

f. Write outline of article
g. Write article

While 5 > 2, and therefore the default context for this project would most likely be "errands," one would be hard-pressed to claim that the project "Write article" is itself an errand! Indeed, "Write article" itself belongs in no context. It seems more of a work of scholarship although, really, it is just what it is—a project.

So, clearly, the "double entendre" of the "default context" field is convenient for Omni (developers), but not convenient for us (users). This is perfectly acceptable (necessary, even) as long as this is a pre-release version. But, as I said in an earlier post, it doesn't seem to me viable as a permanent solution presentable to a wider public accustomed to Omni Group's exacting standards.

[Toadling]

Thanks for the elaboration, macula. You bring in some important points to the overview. Perhaps my coverage was a bit too simple; my goal was to suggest that the real complexities of the 1.8 changes were in the parents' context issue rather than in their blocking nature.

Originally Posted by macula

While 5 > 2, and therefore the default context for this project would most likely be "errands," one would be hard-pressed to claim that the project "Write article" is itself an errand! Indeed, "Write article" itself belongs in no context. It is what it is—a project.

I understand your thinking on this matter and wholeheartedly encourage supporters of this position to send their feedback to the Omni Group.

In the case of your example project, however, I would simply assign the context I need to be in to determine if the project can be closed or needs further actions to meet its goal.

Once you've checked off your 5 actions, what resources, location, or state do you need to be in to make your final decision to mark the project complete? Maybe it's in your office, or the MacBook on which you do your writing, or your "scholarship" hat, or maybe it's something you'd do while just sitting in front of OmniFocus.

Maybe this line of thinking is too loose for GTD-purist, but it seems to make sense for me. Having said that, I don't see how adding the proposed "Parents" bin would negatively impact my workflow, so I'll support it if Omni can be convinced to play along.

-Dennis

[ksrhee]

I have to say this is amusing to say the least. The default context option has been available going back as far as I remember. So, 1.8 did not introduce this concept!

What 1.8 did was to having projects/groups show up in the context view so that folks can have the option to have it appear when there are no action items associate with it - thus you can take action on the empty project/group. Now granted that the implementation could have been smoother or more elegant, but hey it's the first try. So, let's give OG some slack.

Now this new feature does alter the workflow somewhat, but hey, that's the way change works. When something changes, you try to adapt. It seems like some people are not even willing to give a new system a try.

So, my suggestion to KC and OG is to make this a global option for those who don't like it so that they can turn this feature off. Some of us have used other system that has this feature find this new feature useful, and for us, we would simply turn the option on.

As far as changing other parts of the interface, my intuition tells me OG doesn't have the time and resources right now to do this, given all the other projects they are working on, and perhaps this is something left for version 2. This way OG doesn't rush to react to the "reactions" of some folks in this forum and could potentially make things "worse." I think this type of interface change requires more careful thinking and an incubation period.

YMMV on this issue.

Ken

[mloiterman]

Originally Posted by Toadling

By "OF", I suspect you mean "the Omni Group". OmniFocus is a wonderful piece of software, but I don't think it put much thought into developing itself. :-)

As for "rethink[ing] this feature", that's exactly what's happening in the sneaky peek process right now! Neither the feature nor the 1.8 release have shipped. Be glad that you get to have an active role in shaping the outcome by trying out the sneaky peek builds with an open mind and a willingness to provide constructive feedback. There aren't many development shops that give the consumers this much input into the process!



Actually, it's not really confusing at all. It's just a slight change in behavior.

**For this discussion, projects and action groups behave the same way, so let's collectively refer to them as "parents".

You probably wouldn't consider a parent complete until all of its actions are completed, right? So OmniFocus treats parents as blocked if they have any incomplete actions (and parents are styled accordingly).

If you set your Availability Filter in context mode to "Available", parents will be hidden from view because they are blocked, unless all their actions are completed, in which case the parent is no longer blocked.

Pretty logical and straightforward, I think. It should have worked this way all along in my view. :-)

Where the confusion comes in is how should OmniFocus sort parents in context view, which is designed to display items by context? Traditionally, parents don't have contexts, only actions do.

Parents do have a "default context" field (and have had it for quite some time now), so the simple solution was to categorize parents by the value of this already existing field.

Many people weren't using the parents' default context field, though, so now many parents are showing up in the "No Context" bin in context mode.

One proposed solution has been to simply assign some kind of "review" context to your parents to keep them out of the "No Context" bin. Another is for the Omni Group to add some kind of "Parents" bin to the context mode sidebar (actions without contexts go in the "No Context" bin, parents without contexts go in the "Parents" bin).

Whether any of these are acceptable solutions and how they might be improved is still being debated.

-Dennis

Yes, by OF, I meant OG.

In terms of the blocking behavior, what you're saying makes sense. I see now how it's supposed to work. Nevertheless, the way it's implemented is confusing. Especially if you're used to the previous behavior.

For the Parents bin idea, I guess it makes sense, but it seems like a "dirty" way of getting around a larger conceptual problem of some people wanting / needing to assign contexts to Projects and Actions and others not wanting / needing this behavior.

I guess the easiest way to deal with all this, if I understand everything, is a checkbox somewhere that asks if you want Projects and Action Groups to be actionable. And, maybe an additional checkbox that asks if you want to be able to assign Contexts to Projects and Action Groups. Or maybe a better way to say it, since this capability has been around for a while, is if you want the program to behave as if this is a requirement.

I'm not sure I need or want this...I just don't use the software like that because it has never worked liked that before - been using it since Kinkless and pre OF 1.0 days.

[Toadling]

This has been mentioned in other threads and earlier in this thread, but I'll point it out again. The "parents appearing in context mode" feature can be disabled using an OmniFocus setting URL.

omnifocus:///change-setting?ContextModeShowsParents=false

Replace "false" with "true" to reverse the setting.

-Dennis

[jasong]

Originally Posted by Toadling

Many people weren't using the parents' default context field, though, so now many parents are showing up in the "No Context" bin in context mode.

One proposed solution has been to simply assign some kind of "review" context to your parents to keep them out of the "No Context" bin.

The argument against this, as others have noted before me, is that a "default context" for parents imposes that context upon its children, which breaks many workflows (my own included), because (A) not everything in a project should get that default context and (2) a missing context is valuable to find incomplete loops.

Originally Posted by Toadling

Another is for the Omni Group to add some kind of "Parents" bin to the context mode sidebar (actions without contexts go in the "No Context" bin, parents without contexts go in the "Parents" bin).

This is certainly a potential solution, and I'd love to see it tested. After a little more living on 1.8, this appears the most viable alternative.

[jasong]

Originally Posted by Toadling

This has been mentioned in other threads and earlier in this thread, but I'll point it out again. The "parents appearing in context mode" feature can be disabled using an OmniFocus setting URL.

omnifocus:///change-setting?ContextModeShowsParents=false

Replace "false" with "true" to reverse the setting.

-Dennis

That hides the entries themselves, but still pollutes the No Context item with a higher-than-reality number.

[Toadling]

Originally Posted by jasong

That hides the entries themselves, but still pollutes the No Context item with a higher-than-reality number.

Good point, jasong. So maybe that setting needs to go a bit further as well.

-Dennis

[ksrhee]

Originally Posted by jasong

The argument against this, as others have noted before me, is that a "default context" for parents imposes that context upon its children, which breaks many workflows (my own included), because (A) not everything in a project should get that default context and (2) a missing context is valuable to find incomplete loops.

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.

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.

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 don't think this will impact any new users since they would not have known the previous workflow anyway.

[ksrhee]

Originally Posted by jasong

That hides the entries themselves, but still pollutes the No Context item with a higher-than-reality number.

Good point. Perhaps OG can address this point once the new option to turn on/off is installed.