[Toadling]

Originally Posted by macula

I very much hope the Omni crew will listen to our plea, which after all seems to enjoy consensus more or less.

Whoa, wait a minute. Consensus? Let's not jump to conclusions. I count no more than a handful of commenters in this thread, and they're not even in complete agreement. There are potentially hundreds, if not thousands, of others who have not voiced opinions here. Maybe those users would agree, maybe not. But we can hardly claim a consensus! Only Omni has a true sense of the kind of feedback coming in.

Before this feature was implemented, there was an equally vocal group of users asking for the current behavior. The consensus seemed clear and Omni responded. Now that the change is up for preview, the first group is likely happily working away while the "second shift" steps in asking for the old behavior. I guess you really can't make all the people happy all the time. :-)

Originally Posted by macula

Really, all we are asking for is a hard-wired bin for projects and action groups. Omni produces very elegant software, and pretty much everything is well thought-out; I am sure they realize that the present situation is not tenable in the long term.

You seem to be projecting your firmly held belief on everyone. I'm not saying this proposal is necessarily bad, but I still remain unconvinced that it's the best solution. Perhaps others feel the same way and simply don't have the time or energy to debate it here.

Personally, I like the new blocking nature of action groups -- that seems perfectly natural and intuitive to me. I also like empty parents (i.e. projects/groups without next actions) to "bubble up" in context mode. That feels perfectly natural and intuitive to me too. I've felt it should work that way for years, although I never made a fuss about it.

The only uncertainty in my mind is the issue of what context the parent should appear in. The current sneaky peak implementation seems like a simple solution that makes use of existing functionality (i.e. the default context field), so it was an obvious first choice for getting this feature out for alpha testing. That's what the sneaky peaks are all about.

My concern with Curt's propsal of a dedicated "Parents" bin is: would I still be able to see my parents intermingled with my actions or would I only be able to see them in a separate view? I want to be able to check off actions in a group and eventually see the action group itself appear in the same view (with my filter set to available). I *do not* want to have to click on a Parents bin to find the related parent, nor do I want to Command or Shift-click on both my Contexts bin and Parents bin and end up seeing seperate sections for parents and actions. Now that seems clumsy and inelegant to me.

-Dennis

[ksrhee]

I for one likes this new feature. Initially I was against it until KC indicated in the forum that you can hide projects/groups by selecting available filter under the context view unless they are empty. This is a behavior I precisely want the program to remind me of (which mimics what happens in LifeBalance). Since I can only work tasks that are available, this doesn't bother me at all, and I want the program to tell me I need to do something on that project. Now I do a weekly review, and this is how I used to catch empty projects or groupings, but the new way makes me catch empty projects much quicker and act on it rather than wait till the weekly review.

Right now, I see the projects/groups if I select the remaining filter the availability filter bar, but I can turn this off via off/on command temporarily or sort the items such a way they appear at the bottom of each grouping rather than mixed in with others.

It seems like it's easy for OG to implement the global preference; so, I would say that would be a good compromise for now. Given what KC said in this forum and elsewhere, I don't think they will have time to revamp the whole interface in the next few months anyway.

Just my 2 cents.

[vinyl_warrior]

There are too many disparate discussions going on here for us to reach any kind of a consensus.

I, for one, don't mind groups and projects showing up in context lists when they're the next available "action". I think that will improve my workflow -- in certain custom perspectives (eg. where I view tasks grouped by project).

What I am wholeheartedly opposed to is being forced to manually assign contexts to every project so that they don't appear in the No Contexts bucket.

Give me a Projects bucket (probably similar to the proposed Parents bin) in the context sidebar and populate that with projects that don't have contexts. Then, ideally give me a way to turn it off ;) Don't mix projects with tasks.

If OG absolutely needs to mix projects and tasks into one bucket, at least give me an option to automatically assign new projects to a certain context (the proposed "Review" context). I understand that this will mean that nothing will ever show up in No Context bucket, but mixing projects and tasks together already broke my workflow -- this would just allow my OCD to rest easy because there won't anything unassigned to a context.

I can't believe that I actually woke up this morning mad over this whole stupid kerfuffle.

[curt.clifton]

Originally Posted by Toadling

My concern with Curt's propsal of a dedicated "Parents" bin is: would I still be able to see my parents intermingled with my actions or would I only be able to see them in a separate view? I want to be able to check off actions in a group and eventually see the action group itself appear in the same view (with my filter set to available). I *do not* want to have to click on a Parents bin to find the related parent, nor do I want to Command or Shift-click on both my Contexts bin and Parents bin and end up seeing seperate sections for parents and actions. Now that seems clumsy and inelegant to me.

Of course you would. You see your No Context items without clicking on No Context now, don't you?

By putting the Parents in a separate bin, a sibling to No Context and Contexts, you have complete control.

• Want to see all the actions and parents (subject to view bar filters). Then don't select anything in the sidebar, just like in the current 1.8 sneaky peeks (r126204 for posterity).
• Want to see actions that lack contexts? Then click No Context in side bar?
• Want to see just actions and no parents? Then click No Context and command-click Contexts.
• Want to see just actions that have contexts? Then click Contexts in the sidebar.
• Want to see actions with contexts, plus all parents? Then click Parents and command-click Contexts.
• Want to see just the action groups that are blocking your progress? Then set the view bar to show available actions and click the Parents bin in the sidebar. There's your list.

And all these combinations can be saved as perspectives. Greater power with simpler rules!

As far as I can tell, everything you want is there, Dennis. Please set me straight if I'm wrong.

I think there are only two problems not addressed by the Parents bin idea.

First, the Parents bin doesn't give us a way to view all action groups and projects that lack a default context. We didn't have that before the 1.8 sneaky peeks either, so I think it's a wash.

The tougher problem is for folks who don't like the new blocking behavior. That problem can't be addressed by tweaking the context view. It's a fundamental change in the definition of "Available". The auto-complete option makes the change less onerous, but it's still a different way of dealing with task dependencies. I personally think the new definition of Available is the right one, but the change will cause some pain for some folks. I hope that pain isn't too disruptive.

[ksrhee]

Here is my current workflow. Some of you might find it helpful.

My "working" perspectives always have "available" filter; so, the only time a project/group pops up is when there is no action attached to it (empty project). When it pops up, I have several choices:

1. Add an action item or items (I could really use a shortcut to add a subtask in the current version). If I do, then the project will disappear once again.

2. Mark complete if the project is complete.

3. Put on hold and assign the context that I created to put in all the hold project (e.g., Dormant Projects). This context is on hold; so, it doesn't show up in my working perspectives.

During my weekly review, I review all my dormant projects and then take action on those (e.g., assign more action items & take it out of dormant context or leave it as dormant).

On other perspectives (remaining filter), the projects/groups do show up, but they don't really bother me since I don't use context-based perspectives to plan or take action.

[malisa]

Originally Posted by curt.clifton

After all, action groups and projects don't have a "context". They have a "default context".

I haven't played with the new features enough to have an opinion one way or the other yet, but I think this is an important distinction. I think that if there's no other major change, it would seem like at least there should be one default context for the actions which will be generated (as there is now) and a separate one that is consciously assigned to the action group or project itself (knowing what that means with the new behavior.)

[Toadling]

Originally Posted by curt.clifton

Of course you would. You see your No Context items without clicking on No Context now, don't you?

I guess you're right, Curt, now that you mention it. My OCD rarely allows me to proceed without immediately assigning a context to everything that passes before my eyes. So I don't have much experience with that No Contexts bin. :-)

Originally Posted by curt.clifton

As far as I can tell, everything you want is there, Dennis. Please set me straight if I'm wrong.

I must admit you're winning me over to your proposal, especially if Omni can do it with a minimum of work and it makes my fellow OmniFocus users happy.

-Dennis

[jasong]

Finally having a chance to "live" with 1.8, and I'm in the camp of those who don't like the change to have projects and subprojects show up in Contexts.

Here are the deal-breakers I'm hitting:

* I suddenly have 48 items in my "No Contexts" list. None of those items are actually actionable items without contexts; they're al projects or subprojects. For example, my "Repair hole in ceiling" shows up there, even though it has an action assigned to it.

* Even hiding the *list* of projects isn't enough because I still see the No Contexts list with "48" next to it, making me feel I should be doing something there.

* Assigning a "default context" makes no sense to me because I don't want my actions to get that default context if I forget to assign on; I want *those* items to show up in No Contexts so I can act on them properly by assigning a context.

* Sub-groups (action groups) show up in No Contexts, but it's not because they don't have a "proper context": I can't even *assign them a context* in Planning mode. I can only assign a "default context" via the inspector, for actions within that action group. See above about default contexts.

By way of example, I have a project to "Move to HDTV". It looks something like this:

* Move to HDTV (parallel)
** Make a list of all the stuff I need to buy to do high-dev TV (parallel)
*** HDTV
*** Blu-Ray Player
*** HD Receiver
*** etc.

Each item may be in different contexts, or may have additional sub-groups

In Context mode I see

No Context:
* Make a list of all the stuff I need to buy to do high-dev TV (parallel)
* Move to HDTV

Research
* HD Receiver

Amazon
* HD Receiver

Errands > Costco
* Blu-Ray Player

I don't understand why those two items are in my No Context list. I can't do anything with them and they're effectively blocked until I deal with the other items.

Switching to "Available" solves the "display" issue, but still has my "No Context" count higher than it should be, since they aren't items that *have* a context!

OF, please comment on this thread. It's very important!

[mloiterman]

So far, I don't like having to assign a context to a project or action group. But I MAY like it or grow to like it. I don't know yet, because I think the way it works and is presented is pretty confusing. I think OF needs to rethink this feature.

The blocking feature is also confusing. For example, none of my projects or action groups are adopting the style I have set for Projects or Action groups. Rather, they've all adopted the style for Blocked. I don't understand why or how to unblock them. Maybe I'm missing something, but it doesn't seem like any of my projects or action groups CAN be unblocked.

Pretty confusing.

[Toadling]

Originally Posted by mloiterman

I think OF needs to rethink this feature.

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!

Originally Posted by mloiterman

The blocking feature is also confusing. For example, none of my projects or action groups are adopting the style I have set for Projects or Action groups. Rather, they've all adopted the style for Blocked. I don't understand why or how to unblock them.

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