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

What are the outstanding workflow issues in 1.8? Thread Tools Search this Thread Display Modes
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.

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"
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.
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.
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.

Last edited by palmer108; 2010-05-20 at 12:22 PM..
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:

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.
Originally Posted by whpalmer4 View Post
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.
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.

It doesn't make sense

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.

It's confusing to the point of uselessness

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!

It crosses work modes

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.

It clutters Contexts and makes them far less useful

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.

I end up spending more time shuffling papers

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.

It breaks GTD

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."

The cure is far worse than the disease

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.

Last edited by iNik; 2010-05-26 at 03:36 PM..

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Similar Threads
Thread Thread Starter Forum Replies Last Post
Workflow shapes zoltanbarabas OmniGraffle General 3 2013-01-23 11:22 AM
Omnisync Workflow mattsbrand OmniPlan for iPad 0 2012-12-17 06:13 AM
Non-GTD workflow using OmniFocus Arrow Applying OmniFocus 4 2009-04-05 06:41 PM
OF and your workflow steve OmniFocus 1 for Mac 4 2007-09-02 03:57 AM
RC1 is outstanding! Handycam OmniWeb General 19 2006-08-31 11:49 AM

All times are GMT -8. The time now is 05:43 AM.

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