What are the outstanding workflow issues in 1.8?
 

In OmniFocus 1.8 (currently available as [URL="http://www.omnigroup.com/products/omnifocus/download/sneakypeek/"]sneaky peek previews[/URL]), projects and groups can show up in context mode lists, such as Context lists, Due lists, and Flagged lists. This change solves some a number of workflow issues (e.g. due inbox items and projects falling through the cracks), but it sounds like it has introduced new workflow issues as well.

I'd like to identify new workflow issues introduced by this change and figure out potential workarounds and solutions.

Here's an example issue:
[INDENT]With most of my projects listed under "No Context" (since they don't need one), it's hard to review the list to find individual actions which are missing a context.

Current workaround: Since projects are not considered available until all their children are complete, you can hide most projects from that list by only showing Available actions.

Disadvantages: This doesn't help you find unavailable actions which are missing a context. And projects without actions will still be in the list.

Possible solution: Add a view option which hides and shows projects and can be saved as part of the perspective.[/INDENT]
Can you help me identify other workflow issues caused by 1.8's changes? I'd appreciate your help!

[QUOTE=Ken Case;76277]
With most of my projects listed under "No Context" (since they don't need one), it's hard to review the list to find individual actions which are missing a context.

Current workaround: Since projects are not considered available until all their children are complete, you can hide most projects from that list by only showing Available actions.

Disadvantages: This doesn't help you find unavailable actions which are missing a context. And projects without actions will still be in the list.

Possible solution: Add a view option which hides and shows projects and can be saved as part of the perspective.[/QUOTE]

Since you made projects/groups visually distinct in context view, I have no problems with them showing in "No Context".
I think the user should decide this through the choice made in the Inspector "Mark complete when completing the last item". If that box is ticked, group/project header is not actionable anyway and should not appear in context view at all. There shouldn't be any need for extra view options.
You might simply add a little text snippet under the "Mark complete (...)", both in Preferences and Inspector: "If you tick this box, your group and project header(s) will not appear in context view

Ken,

I tend to use context mode mostly for 'doing', so I'm only viewing available actions anyway. Besides that, I never have the No Context bin selected: I don't want to see the inbox items, since I haven't committed to them; and tasks don't escape my inbox without a context.

This gets at why the current implementation doesn't actually do what I hoped it would for my workflow. I expected that having parents show up in context mode would let me retire my [URL="http://www.rose-hulman.edu/~clifton/software.html"]Verify Next Actions Exist[/URL] script. However, in day-to-day use I don't see any parents popping up in context mode, because I'm not viewing the No Context bin and none of my parents have a default context. (I don't use default contexts, because then tasks might automatically and accidentally get the wrong context.)

So, projects and groups still stall until my evening review when I run the script. If the script identifies a parent without an incomplete child, then I [I]am[/I] using the No Context bin to navigate to the item.

I still like a couple of the proposals in [URL="http://forums.omnigroup.com/showthread.php?t=15345"]this thread[/URL]. [URL="http://forums.omnigroup.com/showpost.php?p=73703&postcount=71"]My proposal[/URL] would probably be simpler to implement, but [URL="http://forums.omnigroup.com/showpost.php?p=73832&postcount=108"]jdh's[/URL] is more flexible (assuming a default parent context preference). Either of the proposals would let me have context mode perspectives that showed stalled parents without showing the No Context items in my inbox.

In sum, I'm not personally getting much benefit from the new behavior. It's close but not quite discriminating enough to show the information I want. Based just on my own experience, I wonder whether the change in workflow required of users—and the attendant support costs of helping users through the transition—are worth the benefits. They might be, but implementing something that would allow viewing the parents while omitting the inbox items would make the difference for me.

(Third time's the charm, I hope) I've written a detailed response and lost it because of login issues. In a nutshell: I add Contexts to everything now, even if artificial, and the flow works fine.

[QUOTE=curt.clifton;76388]Ken,

I tend to use context mode mostly for 'doing', so I'm only viewing available actions anyway. Besides that, I never have the No Context bin selected: I don't want to see the inbox items, since I haven't committed to them; and tasks don't escape my inbox without a context.

[/QUOTE]

What if you could just have the current parents display in context mode without the presence of Inbox items in the No Context bin? You could then add the No Context bin to your context mode selections to pick up the group and project parents in real time without otherwise cluttering your view, right?

[QUOTE=whpalmer4;76427]What if you could just have the current parents display in context mode without the presence of Inbox items in the No Context bin? You could then add the No Context bin to your context mode selections to pick up the group and project parents in real time without otherwise cluttering your view, right?[/QUOTE]

That would work for me, Bill. But my understanding was that having inbox items appear in context mode was an important feature for many people. (Witness the many forum posts from people confused about why their actions weren't showing up.)

Right, I was thinking that it would be an easy option to add, most likely, and perhaps one that could linger in the obscurity of a CLI setting...

CLI or otherwise, this would be a highly unsatisfactory solution: From the perspective of usability, it would feel like a hack. It also would not meet the needs of those of us who want their inbox items to appear in the 'No context' bin, [U]and[/U] have an automatic mechanism for placing groups/projects in their own separate bin, [U]and[/U] ensure that this mechanism does not implicate the 'default context' field (and therefore does not interfere with the creation of new children).

I would find it unfortunate if we—the users—started negotiating between ourselves in an apparent effort to minimize the developers' effort. Our role should rather be to request optimal solutions. I truly do believe—as I have repeated elsewhere—that it should all be easy for us [users], not for the developers.

The solutions suggested by jdh and Curt (see links above) are, in my view, the only satisfactory ones proposed so far.

Thanks.

separate default context from project/AG context
 

I found it confusing that to choose a context for a project/action group, one had to use the "default" context. I kept looking for a way to pick a context similar to how an action context is selected.

I also agree with Curt that the context I choose for a project isn't necessarily the default context I want for all my actions. I am planning on using project contexts as a way to reconcile my goals and objectives list (that my supervisor needs) to my actual day-to-day projects/actions list I keep in OF. In other words, the "context" for Project A might be "Goal 1: Manage Lab" although most of the tasks under this goal are in the context "work" or "desk" or "computer".

I would suggest separating the default context from the context one selects for projects/action groups which would solve many of the problems brought up on this thread so far.

Eric

Exactly!

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

[QUOTE=curt.clifton;76388]I tend to use context mode mostly for 'doing', so I'm only viewing available actions anyway. Besides that, I never have the No Context bin selected: I don't want to see the inbox items, since I haven't committed to them; and tasks don't escape my inbox without a context.[/QUOTE]

Would it help if you could put your Inbox on hold (like you can do with projects)? It sounds like this would let you retire your "Verify Next Actions Exist" script.

[QUOTE=Ken Case;76506]Would it help if you could put your Inbox on hold (like you can do with projects)? It sounds like this would let you retire your "Verify Next Actions Exist" script.[/QUOTE]

P.S. — You can put your Inbox "on hold" now by using this [URL="http://people.omnigroup.com/kc/DebugOmniFocus/DeactivateInbox.html"]Deactivate Inbox[/URL] page. This should work in the OmniFocus 1.8 sneaky peeks as well as the iPhone app—though I should note that it's not yet supported and doesn't have a lot of testing.

[QUOTE=Toadling;76498]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[/QUOTE]

I noticed it too, and don't see any way to fix it.

Solving group-/project header issues in context view
 

If I understand it right, most people seem to support the concept of [URL="http://forums.omnigroup.com/showpost.php?p=73832&postcount=108"]an additional parent context for group/project headers.[/URL]. So do I.

But in addition, I think there is an unsolved issue for those who don't want to see headers in context view. Personally, I want to alternate, given the very different nature of my headers...
As I suggested myself in [URL="http://forums.omnigroup.com/showpost.php?p=76364&postcount=2"]this post[/URL], the logic implied using the tick box "Mark complete when completing last item" has been ignored so far in 1.8.x. When this is ticked, it is very counter-intuitive to me that my header is still considered an actionable item. Anybody else agreeing, or am I overlooking something?
I would really like to see the value set in that check box deciding if headers appear in context view or not. Such a feature should not interfere with the above mentioned concept of a parent context, which I would love to have for my actionable headers.

Any thoughts on this?

missing disclosure triangles on projects and action groups
 

[QUOTE=Toadling;76498]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[/QUOTE]

I haven't had the triangles visible on either projects or action groups except on mouse-over for ages. And I swear years ago (or what feels like years ago!) that they would remain visible as a visual cue. This was particularly helpful for action groups. This mouse-over-only behavior is happening on 1.8, but also it happened on 1.7 and I think 1.6 for me.

So they should remain visible? Has anyone figure out how to make them visible again? It would be quite helpful!

Thanks,
Eric

Unless I am misunderstanding the problem description, I am not able to reproduce the issue: Said triangles are always visible on OF 1.8 v77.48 r131389.

[QUOTE=macula;76533]Unless I am misunderstanding the problem description, I am not able to reproduce the issue: Said triangles are always visible on OF 1.8 v77.48 r131389.[/QUOTE]
I misunderstood the problem description also!

The disclosure triangles in question are the ones to the left of the project title, not those for the contents of the project. I'm still seeing the bug with r131392, now that I know where to look :-)

[QUOTE=whpalmer4;76534]I misunderstood the problem description also![/QUOTE]

Sorry about that. I suppose I could have been more descriptive or provided a screenshot.

Anyway, thanks for the confirmation, everybody. I'll send a bug report to the ninjas.

-Dennis

[QUOTE=Ken Case;76506]Would it help if you could put your Inbox on hold (like you can do with projects)? It sounds like this would let you retire your "Verify Next Actions Exist" script.[/QUOTE]

I'll try the Deactivate link and see how it works.

Product: OmniFocus-1.x
Tag:
Date: 2010-04-28 13:11:22 -0700
Builder: omnibuild
Host: tb106i.private.omnigroup.com
Revision: 131410

Selecting a context to delete and then clicking on the minus button at the bottom of the Context Sidebar causes the sidebar to expand to the right, click 2-3x more it continues to expand, until it disappears.

[QUOTE=Ken Case;76509]P.S. — You can put your Inbox "on hold" now by using this [URL="http://people.omnigroup.com/kc/DebugOmniFocus/DeactivateInbox.html"]Deactivate Inbox[/URL] page. This should work in the OmniFocus 1.8 sneaky peeks as well as the iPhone app—though I should note that it's not yet supported and doesn't have a lot of testing.[/QUOTE]

After a couple of days of use, this is working well for me. Thanks, Ken!

I still think a more general solution might be helpful to avoid confounding the context of a parent with the default context for children. I don't use the default context field, so this doesn't affect my personal workflow. As such, I'll let others make the argument for that.

Being able to add a child in the context list.

When I find an action that ends up spawning child smaller actions, I flip back over to projects and add children, then back to the context.

[QUOTE=curt.clifton;76388]Ken,

I tend to use context mode mostly for 'doing', so I'm only viewing available actions anyway. Besides that, I never have the No Context bin selected: I don't want to see the inbox items, since I haven't committed to them; and tasks don't escape my inbox without a context.

This gets at why the current implementation doesn't actually do what I hoped it would for my workflow. I expected that having parents show up in context mode would let me retire my [URL="http://www.rose-hulman.edu/~clifton/software.html"]Verify Next Actions Exist[/URL] script. However, in day-to-day use I don't see any parents popping up in context mode, because I'm not viewing the No Context bin and none of my parents have a default context. (I don't use default contexts, because then tasks might automatically and accidentally get the wrong context.)

So, projects and groups still stall until my evening review when I run the script. If the script identifies a parent without an incomplete child, then I [I]am[/I] using the No Context bin to navigate to the item.
[/QUOTE]

Same for me.

[QUOTE=curt.clifton;76615]I don't use the default context field, so this doesn't affect my personal workflow. As such, I'll let others make the argument for that.[/QUOTE]

It appears that I am one of those who need to make this argument, then! :-)

Setting the Inbox "on hold" feels very awkward in my hands. It still gives the impression of a "hack" and does not give me the peace of mind that one expects of a GTD solution.

I fathom that adding a genuine "context" field for projects/groups in addition to the existing "default context" field involves quite a bit of work on the part of the terrific OF developers. But you guys have spoiled us [users] and I think that a very respectable number of us expects nothing less of you than a real, intuitive, "healthy" solution: Please add that extra field. Or, at least, add an option "hard wiring" the placement of projects/groups in a dedicated bin.

A comment from the developers on this suggestion (which has been voiced by a great number of users here) would be very much appreciated.

I like the idea of a project having a default context of it's actions. Maybe even it's last completed action... unless a project has a default context assigned.

This would mean, whenever completing the last action of a project or action group, the project would be in the same context that the action is in.

A person can either complete the project / action group, or add children to it.


Another thought is to move the project / action group into the stalled project filter once the project / action group doesn't have any children.

Either one of these would free me from curt's next action script.

Big changes today. I'm now seeing both Projects (with no tasks, in bold) as well as future tasks (in gray) in my Next Actions list. I saw this in the release notes "Since projects are now actionable, they're now eligible to become their own next actions" but was surprised to see future actions are now appearing along with Next Actions.

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.

But why future actions? They are neither actionable nor requiring attention so why are they now appearing?

Problem with Next Actions Perspective in Omnifocus build v77.48 r131891
 

In build v77.48 r131891, I have a perspective to view only next actions; However, I am seeing actions that shouldn't be shown. For example, I am seeing actions that are not supposed to start until later in the future even though they are the next action(s) for their respective projects. The perspective settings I have are
context filter: active
grouping: context
sorting: due
availability filter: next action
status filter: any status
estimated time filter: any duration
I don't remember seeing this problem in the previous alpha builds

The behavior appears to start with r131859...

[QUOTE=pjb;76852]I'm now seeing both Projects (with no tasks, in bold) as well as future tasks (in gray) in my Next Actions list.

…

But why future actions? They are neither actionable nor requiring attention so why are they now appearing?[/QUOTE]

Woops, sorry, that was a bug—thanks for reporting it!

It's been fixed for the next sneaky peek.

[QUOTE=pjb;76852]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.[/QUOTE]

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.

[QUOTE=whpalmer4;76865]The behavior appears to start with r131859...[/QUOTE]

and was called a regression and fixed in r 131939

[QUOTE=Toadling;76498]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[/QUOTE]

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

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.

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!

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

1.8 and Group Context
 

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?

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 [U]remove[/U] the conceptual complexity imposed by ambiguity and a constricted workflow.

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:

[B] First, [/B]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.

[B]Second[/B], 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).

[B]Finally[/B], 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.

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. [U]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![/U]

[U]CONCLUSION[/U]: 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.

Going forward, rows simply have a context.

New rows inherit the context of their parent by default, but can be moved to another context as desired.

Thanks, Brian. You are describing the behavior of rows with regard to their context. Your description is accurate, but I was trying to make a point about usability here. The problem is that once simple rows become parent rows, their context ceases to be visible on screen, and therefore such rows run the risk of not being assigned to the "projects/groups" context that I expect them to have.

Brian,

Could you explain how these group contexts should filter down to the iPhone? I unfortunately see a disconnect. While they appear in context view on the desktop (Group row with Default context defined), the do not show up under contexts under the iPhone. I could be wrong, but the wording of the last iPhone update reads that this should be supported.

Quoting from the iTunes "What's new for 1.6.3"
Workflow
• Groups and projects can now appear in Context mode perspectives.

Sorry for the delayed response, Kunicki - I meant to post here yesterday but got caught up in other tasks.

The release note is referring to context-mode perspectives, but doesn't affect the top-level Contexts list. We want to get this behavior out on the Mac before we modify the way the latter behaves.

Project context : no in-line field
 

[QUOTE]With most of my projects listed under "No Context" (since they don't need one), it's hard to review the list to find individual actions which are missing a context.

Current workaround: Since projects are not considered available until all their children are complete, you can hide most projects from that list by only showing Available actions.

Disadvantages: This doesn't help you find unavailable actions which are missing a context. And projects without actions will still be in the list.

Possible solution: Add a view option which hides and shows projects and can be saved as part of the perspective.[/QUOTE]

1. The No Context inbox is now a mess. I don't need contexts for projects and groups. But if others do require them, yes please create a view option to hide projects and groups in context mode.

2. If projects and groups must have contexts, there should be an in-line field just as there is in actions. It is not practical to have to switch to context mode or go to the inspector to give the project or group a context.

This may need a new thread, but for now... can someone explain again the benefits of having projects show up in my No Context bucket?

(Latest 1.8 sneekypeek, 132800)

This is a legit question, not a snarky one. I'm trying to understand this so I can decide if it's something I should be incorporating into my workflow.

I'm asking now because there are about half-a-dozen items in my No Context box (Availability Filter: Next Action or Available), all projects with no actions. I want to take some actions on them, but doing so means switching to Planning mode.

That means I can "fix" one project, but then I need to switch back to Context mode, select the next No Context item, before switching back to Planning mode again.

In some cases, the "fix" is putting an item On Hold (which is done easily enough from the Inspector), but other times it's adding an action, which can't be done except in Planning mode.

Curiously, these items don't show up in my Stalled Project Filter (even though they should by definition be "Stalled": active/no next action/no future start date), while "not stalled" items do.

This means I have no good way of finding these wayward Projects with no actions that I need to review to ensure they're being moved forward.

And, what does the No Context count actually mean? Right now it says "2", but there are as I mentioned at the top, six items in Next Action/Available, or 36 items in Remaining. What does the "2" represent?

OmniFocus is starting to become very confusing (and I say that as a user from some of the earliest betas two-plus years ago!).

If you double-click the row handle for one of these, you get a new window focussed on that project. Add the desired actions, click the close button on the window, and you are back where you were with minimal fuss.

See Brian's post for the rationale on why the semantics of the stalled filter have changed: [url]http://forums.omnigroup.com/showpost.php?p=77604&postcount[/url]

I'm still up in the air on whether or not this makes life easier or not. To clarify, I'm speaking only of the stalled filter change, not the whole projects showing in contexts change.

[QUOTE=whpalmer4;77635]If you double-click the row handle for one of these, you get a new window focussed on that project. Add the desired actions, click the close button on the window, and you are back where you were with minimal fuss.[/QUOTE]

Yeah, that's a handy short cut I should have tried. Thanks!

With all due respect for the hard work you all put into these things, I think this change is a total disaster, and undermines the many benefits of having the clean divide between planning and acting.

[b]It doesn't make sense[/b]

Projects contain actions that often (almost always, for me) have different contexts. So assigning a single context to a project is nonsensical. Plus you end up with truly bizarre results like projects grouped with themselves in a given context.

[IMG]http://dl.getdropbox.com/u/172082/screenshot-100526172001.png[/IMG]

[b]It's confusing to the point of uselessness[/b]

Okay, the next action is the thing I have to do to make progress on a project. But when I see a project in the context view, how can I know what the next action IS?

Or, wait, what if there isn't a next action? Do I need to assign one? Is it in this context? Is this a one-off project and can just be checked off, or are there additional next-actions I'm just not remembering?

The fact is, I can't SEE any of this, and these are not questions I should have to research when I'm just trying to buy groceries!

[B]It crosses work modes [/B]

Projects and Contexts are two different organizational axes for my to-do lists. Each is used for different work modes; Projects for planning, Contexts for working. Essentially, each one represents a "context" of sorts -- with the Project meta-context being appropriate for my weekly review, and the Context meta-context being the one for the work day. Mixing these up causes me to break out of the flow of acting in context, and forces to to, instead, go back to planning mode.

[B]It clutters Contexts and makes them far less useful[/B]

Under this new layout, I end up with a completely useless "No Context" view -- since it's overwhelmed by every project I have, and is no longer useful to triage actions without contexts. I'm confident that if I added more contexts to projects, it would do the same thing for other contexts.

[B]I end up spending more time shuffling papers[/B]

Now, just to keep my program looking nice, I'm having to assign contexts (often arbitrary ones) to my projects, just to get them out of the useless No Context view. I want to spend LESS time categorizing things, not more. The whole point of contexts in projects was to set a default, not to categorize the project itself.

[B]It breaks GTD[/B]

This is the weakest reason, because there's no reason to be married to canonical GTD, but it stands. Per The David, there is a difference between a project and a next action. A project is something that requires more than one action to complete. An action is an atomic task, that can be accomplished in a given context. Projects do not have contexts.

It blurs the distinction between contexts, projects, and actions. Per "canonical" GTD, contexts and projects are individual lists. They're organizational axes. The point of the two views is to give two different perspectives on the same task: A Planning and a Doing view. These represent not just different views of my action lists, but different modes of work. My review/plan action is in the project view "context," and my work day is spent in the context "context."

[b]The cure is far worse than the disease[/b]

Honestly, I don't see what this is fixing. Yes, it provides a means to make those one-off actions peers to projects, but I'm not clear that's necessary. OF already supports bucket-projects, and they work great. Actions show up accordingly, and you can prioritize those buckets according to your own priorities or available time. Easy peasy.

If you're worried about things falling through the cracks, the stalled projects perspective and other custom perspectives give great visibility to these things. Then "No Context" can also be used to find actions that need to be triaged (Although not with 1.8's changes -- then "No Context" becomes a trash heap of contextless projects)

And the downsides to this are immense, as I've enumerated. It's contrary in so many ways to the basic workflow that OF supports.

If there is a need to categorize projects by context, why not just have a Context group in the project view that provides this? Then you have projects-by-context, and it's not conflated with actions-by-context, which are often contrary to the parent project's context, anyhow.

[quote]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.[/quote]

ONLY if all the child actions are in the same context. Otherwise they're divided from the project and not displayed.

If you want to work a project through to completion, just click the "switch" button to go to the Project mode and check off your actions for that project. Isn't the project mode where you SEE actions-by-project, after all?

Alternately, if you want to see all the contextually-available actions for a given project, group by project and change the filter to show remaining actions, rather than available/next actions. Then you've got what you need.

This is the thing, all of these circumstances are well covered and done so in a way that is consistent with the design of the app. If I wanted to conflate projects and actions, I would be much better served with a free tagging system, rather than an app with two clearly defined views.

[QUOTE=iNik;77684]
Ken says: "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."

ONLY if all the child actions are in the same context. Otherwise they're divided from the project and not displayed.
[/quote]
I think you are misreading Ken's statement here. If you have a sequential project with actions A, B, C, if you view that project in context mode, only showing Next Actions, you will initially only see action A in whatever context it occupies. Tick it off, and B pops up. Again, tick it off and C pops up. Tick that off, and the project itself pops up, allowing you to either mark it complete or add more actions. He is not saying that the actions will be necessarily shown grouped together in context mode (though they might be, if you grouped by project). Of course, if you have your projects and action groups fully populated at all times, and the bit set that tells OF to auto-complete them, this isn't much of a feature!

IMO, this is not intended for use as you suggest, working on one project to the exclusion of all else, but rather to make it more quickly apparent that a project (or action group) has had all of its predetermined actions completed so that it can be immediately marked complete, if appropriate, or fleshed out further, without having to wait for a review to catch the now-empty project or action group.

[QUOTE=whpalmer4;77689]IMO, this is not intended for use as you suggest, working on one project to the exclusion of all else, but rather to make it more quickly apparent that a project (or action group) has had all of its predetermined actions completed so that it can be immediately marked complete, if appropriate, or fleshed out further, without having to wait for a review to catch the now-empty project or action group.[/QUOTE]

That makes more sense. However, that's not what I'm seeing, unless I have a VERY specific set of filters set up in Context view. Otherwise, I get projects lumped in with everything else, with no information to tell me whether the project is completed or not.

And, truly, what context should the "Wanna check off the project for good?" action/project/item exist in? Per my earlier post, projects don't really belong to any given context -- the assignment is fairly arbitrary -- so there's no guarantee that the project will "pop up" per your example. It is just as likely to pop up in another context entirely, again, leaving me without the information I need to know whether the project's still open and has actions, whether it's stalled, etc...

A more useful approach would be to add a "Yay! You're done!" next action to the end of every project, reminding you that it's time to close the project.

And I have to ask: What's the harm in having an empty project that's actually been completed? Until you're in Project/Planning mode, it won't get in your way at all. And once you are in that mode, well, then you have all the information you need to appropriately check off or add actions and extend open projects.

And, to be sure, checking off a project is NOT an action in and of itself. It's just a record keeping activity to clear off your list of "open loops." So, again, it doesn't belong in "Action Mode."

Workflow-wise, it would make more sense to have a special view for projects which have no more available actions. Something like... I dunno... "Stalled Projects." ;)

[QUOTE=Ken Case;76277]Possible solution: Add a view option which hides and shows projects and can be saved as part of the perspective.[/QUOTE]

Enabling the Project view to group by context would handle this pretty well. Show stalled projects, group by context, you're done.

[QUOTE=iNik;77694]That makes more sense. However, that's not what I'm seeing, unless I have a VERY specific set of filters set up in Context view. Otherwise, I get projects lumped in with everything else, with no information to tell me whether the project is completed or not.
[/quote]
The project shouldn't be styled as available until the contained actions are done...
[quote]
And, truly, what context should the "Wanna check off the project for good?" action/project/item exist in? Per my earlier post, projects don't really belong to any given context -- the assignment is fairly arbitrary -- so there's no guarantee that the project will "pop up" per your example. It is just as likely to pop up in another context entirely, again, leaving me without the information I need to know whether the project's still open and has actions, whether it's stalled, etc...
[/quote]
I agree that in a restricted view, the project might not appear, but that is no worse than the previous state of affairs.
[quote]
A more useful approach would be to add a "Yay! You're done!" next action to the end of every project, reminding you that it's time to close the project.
[/quote]
And in which context does that appear?
[quote]

And I have to ask: What's the harm in having an empty project that's actually been completed? Until you're in Project/Planning mode, it won't get in your way at all. And once you are in that mode, well, then you have all the information you need to appropriately check off or add actions and extend open projects.
[/quote]
It is a major issue for repeating projects with a short repeat interval, because the next instance isn't created until the prior one is marked complete.
[quote]
And, to be sure, checking off a project is NOT an action in and of itself. It's just a record keeping activity to clear off your list of "open loops." So, again, it doesn't belong in "Action Mode."
[/quote]
That same logic applies to checking off actions, does it not?

[quote]Workflow-wise, it would make more sense to have a special view for projects which have no more available actions. Something like... I dunno... "Stalled Projects." ;)[/QUOTE]
I do like the ability to see such projects easily in project mode, which the old version of the stalled filter provided.

Maybe my memory is playing tricks on me, but I'm pretty sure I remember there being an option to turn off the display of parents.

I posted a link that will change the option in this thread: [url]http://forums.omnigroup.com/showthread.php?t=15363[/url]

[QUOTE=whpalmer4;77700]It is a major issue for repeating projects with a short repeat interval, because the next instance isn't created until the prior one is marked complete.[/quote]

That's where the "Mark complete when completing last item" checkbox comes in handy. I have that for every quick-repeating project.

[quote]That same logic applies to checking off actions, does it not?[/quote]

Nope, it doesn't. On a paper list system, it's organizational (and possibly a nice memory jogger -- "Did I do that yet, I can't remember...?"), but in OF, it performs the task of "releasing" the next action on the project's list.

[quote]I do like the ability to see such projects easily in project mode, which the old version of the stalled filter provided.[/quote]

Agreed. The new stalled filter also needs some work.

[QUOTE=iNik;77682]Honestly, I don't see what this is fixing.[/QUOTE]

There are a lot of folks out there who don't understand why some things show up in context view and other things don't. One goal of this change is to make the behavior of the app less confusing to those people...

Brian, can you give an example of something that might cause that confusion?

[QUOTE=jasong;77741]Brian, can you give an example of something that might cause that confusion?[/QUOTE]

"Context mode" isn't just used for viewing things by context: it's used to view items which are coming due, flagged, or completed; to view schedules of start dates, and items with recent changes. Most people expect to see projects show up in all of those other (non-context-based) lists—and would be mystified (and justifiably upset) when projects with due dates failed to show up in their Due perspective at the appropriate time.

For the most part, this change doesn't affect the GTD workflow: the Contexts perspective doesn't show the contents of the "No Contexts" group, and that's where projects would generally show up in that view (since most GTDers won't assign contexts to their projects). Also, Context mode is most useful when you filter it to only show Available actions, and projects won't become Available until all the actions within them are complete.

However, I do understand that many people are finding that those projects are cluttering up that "No Context" list, making it harder to find actions that are missing a context and thus slipping through the cracks of their system. That's why we've now added an easy toggle to the View menu which can hide parent items from showing up in Context mode. Ideally, though, that "hide parent items" toggle should be a view state which can be saved as part of a perspective, since otherwise you might forget to turn it back on and end up missing a project which is coming due. As soon as we make that change (and then document everything and translate it to all our supported languages), I'm hopeful that 1.8 will be ready to ship.

That seems like a pretty elegant way to have it both ways, especially using perspectives to help manage that.

Will these changes affect the iPhone application? It would be nice to see the same flexibility there. (And, BTW, I *heart* perspectives on the iPhone!)

So 1.8 is about to go final, and the "default context" field still serves double duty as "project/group action context," as well.

This is disappointing, and I expected better of Omni than a so evidently half-baked feature.

[QUOTE=macula;77782]So 1.8 is about to go final, and the "default context" field still serves double duty as "project/group action context," as well.[/QUOTE]

There isn't a "default context" field anymore, items just have contexts. If you don't want to see parents listed under their context in context mode, you can choose "Hide Parent Items in Context Mode" from the View menu.

Is there some workflow that this breaks for you?

Thanks for alerting me to that change—I missed a few posts on this thread. I understand that now tasks "simply" inherit the context of their parent. In that sense, the context of a group action or project behaves as a "default" context for the children. Unless I'm missing something, then, the change you are referring to is rather nominal.

I have written my objections to this new behavior above but will gladly repeat here: Conceptually speaking, (my) action groups and projects do not really belong in any "real" context because they contain children of various contexts. At the same time, leaving the "context" field of groups/projects blank would not work either, because I would not want my "no context" view to mix groups/projects with single actions that I have left without a context only inadvertently.

Therefore, the best solution I could come up with was to create a "group/action" context, which would display those types of entities together in context view.

Once this step is taken, however, all children tasks automatically inherit this "group/action" context. And quite often I forget to notice this erroneous context, with the result that single actions are mixed in context view with groups and projects. This behavior is erratic because the expected outcome of neglecting to set a task's context would be to find the task in the "no context" bin rather than the "group/project" bin. At present, however, the user needs to check for "neglected" (e.g. hastily entered) tasks at two places: The "no context" bin (for tasks entered via the Quick Add pane) and the "project/group" bin (for tasks entered in the app's main window). It's inconsistent and clumsy, and truly jars against the overall elegance of this software.

Go read Ken's post #60 in this thread again, as it sounds to me like it addresses your complaints. No need to assign a context to projects or action groups, and they can be hidden when trawling for contextless actions in the No Contexts bin.

Thanks, Bill. I see your point but the solution still seems to me like a patch up job. Let's take a sequential project as an example:

[CODE]PROJECT MyProject [sequential]
Group_Task_A [sequential or parallel (doesn't matter)]
Task_A.1
Task_A.2
Task_B
[/CODE]

Following yours and Ken's suggested setup, Group_Task_A and MyProject are assigned no context. Also following your suggestion, I have chosen to hide groups and projects from the "no context" bin.

Now, like most people, during the day I tend to use the context view alone to get things done. I only use the project view for my daily and weekly reviews. Let's assume that early in the morning I complete Task_A.1 and Task_ A.2. The next actionable step is now Task_B, which will not be released until Group_Task_A is checked off. In this setup, however, this group task will be visible only in the project view which, as I said, I never bother to (and should not have to!) review more than once during the day. As a result, I miss the opportunity to complete Task_B before my next daily review.

The only solution is to ensure that groups and projects are automatically marked as completed upon completing their children. This however has serious workflow implications (disadvantages), as we all know.

In short, using OF feels to me more "precarious" and "unpredictable" than before. There are too many parameters to take into consideration and yet, ironically, the user feels that less degrees of freedom are available in setting up and using the system, because every solution involves a compromise.

All such problems—this overall lack of transparency—would be instantly resolved if group actions and projects had separate fields for their own context and for their children's default context. Or (as has been suggested) if projects and groups were automatically placed in a hard-wired bin dedicated to these two types of entities. Despite the apparent increase of information and complexity, this solution would actually simplify things in terms of usability. I feel that the developers' understanding of "complexity vs. simplicity"—and their express intention to "simplify" this application—is misguided in this case.

[QUOTE=macula;77792]Thanks, Bill. I see your point but the solution still seems to me like a patch up job. Let's take a sequential project as an example:

[CODE]PROJECT MyProject [sequential]
Group_Task_A [sequential or parallel (doesn't matter)]
Task_A.1
Task_A.2
Task_B
[/CODE]

Following yours and Ken's suggested setup, Group_Task_A and MyProject are assigned no context. Also following your suggestion, I have chosen to hide groups and projects from the "no context" bin.

Now, like most people, during the day I tend to use the context view alone to get things done. I only use the project view for my daily and weekly reviews. Let's assume that early in the morning I complete Task_A.1 and Task_ A.2. The next actionable step is now Task_B, which will not be released until Group_Task_A is checked off. In this setup, however, this group task will be visible only in the project view which, as I said, I never bother to (and should not have to!) review more than once during the day. As a result, I miss the opportunity to complete Task_B before my next daily review.
[/quote]
That is true only if you aren't including the No Contexts bin in your perspective, or have otherwise narrowed the view to exclude wherever the project would pop up once all the actions are complete. That same issue will be present with the proposal to have a separate bin for projects and groups -- if you aren't looking there, you won't see the project or group becoming available.
[quote]

The only solution is to ensure that groups and projects are automatically marked as completed upon completing their children. This however has serious workflow implications (disadvantages), as we all know.

In short, using OF feels to me more "precarious" and "unpredictable" than before. There are too many parameters to take into consideration and yet, ironically, the user feels that less degrees of freedom are available in setting up and using the system, because every solution involves a compromise.

All such problems—this overall lack of transparency—would be instantly resolved if group actions and projects had separate fields for their own context and for their children's default context. Or (as has been suggested) if projects and groups were automatically placed in a hard-wired bin dedicated to these two types of entities. Despite the apparent increase of information and complexity, this solution would actually simplify things in terms of usability. I feel that the developers' understanding of "complexity vs. simplicity"—and their express intention to "simplify" this application—is misguided in this case.[/QUOTE]

You should of course provide your feedback, as you are doing. But I think it is worth contemplating the possibility that with well over 50,000 OmniFocus customers out there, your viewpoint (or mine!) may not be representative of what Ken & Co. are hearing from the customers who are contacting Omni directly for support.

I'm not trying to sell you on this approach being the "right" one. Very little, if any, of this feature comes from suggestions i have made publically or privately, and if Ken decides this afternoon he wants to do something completely different, that would be fine with me, so long as it is an improvement. My aim with my forum posts is to help people effectively use the tools we have, because for the most part, the pace of change is slow, unless they happen to be working on the area in question at the time.