[Ken Case]

Originally Posted by pjb

I'm not too happy with all my taskless Projects suddenly becoming Next Actions but you all think about this more than I do so I'll probably figure out how this is supposed to work (be sure all of my Projects have some actions and auto-complete, or are on hold) and it will be for the best.

Here are some of the benefits of projects being potential next actions:

You should now be able to work a project all the way through to completion simply by checking off its Next Actions one at a time in context mode.

Projects without child actions can now be considered single-action projects, where the project is itself the action. This eliminates the need for special single-action lists for each folder (e.g. "Home:Miscellaneous" and "Work:Miscellaneous") since you can simply drag an action directly onto a folder to turn it into its own single-action project.

[pjb]

Originally Posted by whpalmer4

The behavior appears to start with r131859...

and was called a regression and fixed in r 131939

[Greg Jones]

Originally Posted by Toadling

OmniFocus 1.8 sneaky peek (77.48.0.131330)

I just noticed that the disclosure triangles on projects in planning mode only appear on mouse-over. Anyone else seeing this behavior, or have I mucked up my styles somehow?

-Dennis

The r132044 release notes indicate that this has been fixed, yet I still do not see the triangles. Is this working for anyone else?

[curt.clifton]

Greg, are you using custom styles?

I'm seeing the triangles, but I'm running with essentially the default styles. (I'm using a smaller font size in the sidebar, but otherwise stock styles everywhere.) There's been a long standing bug where the disclosure triangles would sometimes disappear for action groups when using custom styles. I was planning to switch to custom styles today or tomorrow to see if that bug was fixed.

[Greg Jones]

Yes, I am using custom styles. I read your note and loaded the default styles and the triangles were visible. When I switched back to my saved theme, the triangles disappeared again. Personally, I didn't miss that they were gone until it was first mentioned in this thread!

[pjb]

I get it. It's helped me clean up a few loose ends.

[kunicki]

I just downloaded the latest build (as of today) because I really needed the ability to assign a group to a context. I am curious about how this works?

So far I have found that if I assign the "Default Context" to a context at the parent item for the group, example


+ Parent Item
-- Sub Action 1
-- Sub Action 2

That the Parent Item shows up under the appropriate context. COOL!

However, I find the idea of "Default context" to be a bit odd. Because now when I add action items to the group, of course by default they are assigned the "default context", which is not what I want. To me there needs to be two fields: Context and Default Context.

Am I missing something here?

[macula]

You are not missing anything, in my view. Actually, I think your reaction (confusion) is perfectly normal to my mind, as the current 1.8 builds sorely need a dedicated "context" field for action groups and projects. This has been discussed very extensively (and passionately) in two threads: First in the thread that announced the 1.8 sneaky peeks, and then in another thread on "1.8 workflow issues".

Take a look and see what you make of it. I find it surprising that the Omni guys have not yet commented on the possibility of adding an extra field. The solutions they have been suggesting to date (in the above threads) feel to me (and several others) like "hacks" and do not do justice to a phenomenal product.

I just hope that the developers are not reluctant to add such an extra field on grounds of simplicity. I read a post by Ken Case (Omni) in which he rejected some other requested feature, advocating that the product needs to be simplified. In this case, however, I would argue that the added field would actually remove the conceptual complexity imposed by ambiguity and a constricted workflow.

[kunicki]

Thanks for your note. I did search earlier for something on this, but did not find anything. I have to say though, there is truth to keeping OF simple on the surface, especially for use in the beginning. However, I hope under the hood they will continue to add depth. Similar to a program like pages. Very simple in the beginning. But as you need advanced functionality over time, it is there, just buried deeper.

Too add to this question further:

First, I tried syncing with my iPhone. Even though the website mentions support in 1.6.3 for group contexts, they don't show up on my iphone. They are working in the current build of 1.8 (as described in my first post), but when I pull up a context, the group item that I put into that context is not visible.

Second, When I pull up a group in OF, I see no way to edit the details of the group (in other words, to assign it to a context).

Finally, in OF on the desktop, when I see my group and its sub-actions, there is no way to visible see the context, even though the context field is enabled for the view and visible in the sub-actions.

I am sure this is all just part of the beta process, I just want to make sure I am not missing something.

[macula]

The "default context" attribute of projects and group actions still serves a double role in 1.8 beta builds, being both a default context for children and a "context' for the project/group action itself. Here is an additional reason why this is a flawed approach:

Let me begin by clarifying that I use a "Group/Project" context for projects and action groups. This provides the benefit of presenting all such entities under the same category in context view as soon as they become available.

Now, let's assume that I have single Task A, and that right below that task I create a Task B. I also assign Context A to Task A and Context B to Task B.

Two days later, I review my task list and choose to make Task A a parent task for Task B.

Upon doing this, the context field of (Group) Task A is no longer visible on the screen, and the only way to access it is via the Inspector, which may well be closed at the time. As a result, (Group) Task A "silently" remains associated with Context A and will no longer appear under the "Groups/Projects" context—where I expect it to appear—when it becomes available!

CONCLUSION: Once again, I strongly believe that a separate context field for projects and group actions (user-adjustable or hard-wired) should be added. Having actionable projects and group actions in 1.8 is great, but the current implementation is half-baked, adding conceptual complexity and confusion.