[iNik]

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.

[Brian]

Originally Posted by iNik

Honestly, I don't see what this is fixing.

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

[jasong]

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

[Ken Case]

Originally Posted by jasong

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

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

[iNik]

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!)