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.
|
Unless I'm misunderstanding something, this solution appears to be potentially
more confusing. Very few of my projects actually only use a single context, so how would OF determine which context should be assigned in those cases?
Quote:
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.
|
That sounds even odder... Creating a context for projects and groups defeats the purpose of having a streamlined workflow, since the user has no control over where things
do appear. To create a "projects/groups" context, we might as well just switch back to planning mode.
Quote:
Originally Posted by vinyl_warrior
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.
|
The more I think about it, the more I see this aspect as the crux of the problem. If I choose not to assign a context to a project/group, perhaps OF should just ensure that this particular project or group doesn't appear in context view
at all -- not in "No Contexts" or some new placeholder context or anywhere else.
I'd also combine this with the idea that projects and groups that are set to automatically complete should not appear in the context view either -- if they're going to be automatically marked completed when all of their dependent tasks are finished, then what's the point of showing them in context view, since in that sense they really aren't "actionable" but are rather just containers.
I'd propose the following simple change in logic:
A Project or Action Group will appear in context view if and only if the following conditions are met:
1. It has been specifically assigned a context.
2. It is NOT set to be marked completed automatically.
3. It is NOT a Single Action list (this one is already there).
This way, those who don't want their projects showing up context view could simply avoid assigning them a default context. This also means that majority of users who
don't want this feature wouldn't have to change a thing, since most users don't have contexts assigned to their projects anyway.
Note that this
does leave some murkiness around the issue of Default Context, which some users may have want to use without having to assign an actual project context. IMHO Default Context and "Project Context" should be two distinct settings, but of course that would require a second context field on every project and may be going a bit beyond the scope of our current discussion.