I'd like to throw my two cents in on the discussion about assigning contexts to projects. After upgrading to 1.8, I now have a modest 22 items with no context, which surprised me because I try to make sure that all of my tasks have contexts. The No Contexts bucket used to be a great tool for me to quickly identify any tasks that I didn't give a context to.
From my understanding, I'll now have to assign a context to all of my projects (a default context), just to have that bucket counter clear. That, however, completely ruins my use of the of the No Context bucket. I won't get to see the tasks that I missed assigning contexts to because the default context will make sure that nothing ever appears there.
That one change seems totally busted and inelegant. OF is essentially forcing me to assign a context, and if none of my contexts are appropriate, the given suggestion by Ken is to assign a
completely arbitrary context to every project I create for reasons that ultimately
sabotage my workflow.
[erased furious rage]
All of the other changes in 1.8 seem great, but projects without a default context showing up in the No Context bucket completely missed the mark.
Quote:
Originally Posted by macula
Here is a possible workaround that is conceptually elegant and user-friendly: Tweak the OF code so that all projects/groups are internally assumed to belong in all contexts that the project's/group's completed and remaining actions collectively belong in. In this scenario, upon completing all children actions the parent project/group will appear as available in all contexts of the completed children.
An alternative solution—easier in terms of engineering, it seems to me—is for Omni to automatically and non-modifiably place all projects/groups in a dedicated "context" called "Projects/Groups" or something, without requiring the user to set that context or any other context as the default for each project/group.
|
The first suggest seems at first brush to be unobtrusive and
useful, two qualities that the current implementation lacks. The latter seems serviceable.