Distinguish between "workview" filtering and "actionable" tasks

[nekohayo]

Initially filed at https://bugs.launchpad.net/gtg/+bug/1305354

I've been loving GTG for my GTD needs since 2009 or so, but with the blurry distinction between my daily life and my work life, I think I've finally figured out what I'm missing: the "Workview" mode is nice, but it needs something else to complement it.

Currently, workview filters out all the tasks that are deferred into the future or all the tasks for which a tag is marked as "not to be shown in work view".

This leads to the problem where I have either too much (300) or too few (50) tasks depending on if I turned on workview.

I would like:

• An "Actionable tasks only" filter to filter out all the tasks whose startdate is in the future
• "Workview" to ignore the startdate and only concentrate on "filter out the tasks that have a tag that is not set to be shown in workview mode"

Both can be used in conjunction (actually, turning on "Workview" could even automatically activate the "Actionable tasks only" button) when I'm in a professional work setting, but when I'm at home I could turn off workview and be able to see "all the tasks that are actionable but not necessarily related to work".

This is not something I can distinguish just by using one @work tag: the problem is that I have tasks that are "R&D" or "experiments" in my life that are more like "side projects", and currently the problem is that I'm "always" in the workview because the non-workview is a complete mess with way too many tasks (half of which are in the future, and thus non-actionable).

Thanks!

[nekohayo]

Another potential approach to this would be for workview and actionable to be two independent view "filters" that the user can toggle in the UI on the fly, instead of view "modes". But one has to be careful not to bury the reachability of those toggles too far, nor to clutter the UI, so it might be a tricky thing to achieve.

[nekohayo]

...and it should probably be revisited once we have solved the performance problems after a switch to lxml and such, because if switching between view modes is much faster in 0.5 than in 0.3.x, then this might make the "in-between all-tasks and workview" state less important to have.

[diegogangl]

Two things bother me about the actionable tab:

1. It shows all tasks that aren't due in the future. Since I do daily/weekly planning, that means 99% of my tasks in open will also be in actionable unless I set them all to "someday"
2. You are forced to set some due date to get tasks to show at the top. Otherwise they are lost in the sea of tasks, since you can't sort by start date.

It feels like it should act as "focus" filter so you only see what you are set to do next, but it ends up being a mess because the algo has so many conditions that you never know when/if a task will show up there.

Once the core rewrite is done we could move the tabs to the sidebar and open the possibility for plugins to create their own views too.

[digitalethics]

@diegogangl See also #429

[nekohayo]

Possibly the "Actionable" view (or "Workview" as it was previously called) tab approach is a mistake of oversimplification, and we should instead offer a filtering bar with independent toggles the user could use. So you'd only have the distinction between Open/Closed, and then, in some sub-toolbar somewhere (maybe toggleable with a "Filters" button in the headerbar?), have GtkSwitch widgets (?) controlling these:

• "Next Actions" only (this would toggle between the hierarchical vs flat view of only-the-last-children)
• Deferred tasks (this would show/hide any tasks—and their children—whose start dates are in the future)
• "Someday" tasks
• Non-workview tags' tasks

This might significantly complicate the UI visually. I wonder if this would be considered plugin material at that point...

[nekohayo]

Or, perhaps it's really just a matter of having one or two more global view modes, so in total, we could have:

Label	Tooltip	Shows parent tasks? (hierarchy)	Shows deferred (future startdate)?	Shows "someday" tasks?	Shows tasks tagged with a "hide from workview" tag?
Open	All open tasks	✅	✅	✅	✅
Review*	"10,000 ft" view	✅	❌	✅	✅
Projects	"Current projects" workview	✅	❌ (or only those starting within 7 days?)	❌	❌
Next actions	Actionable tasks only	❌	❌	❌	❌
Closed	All completed or dismissed tasks	✅	✅	✅	✅

The tricky thing is that in theory, one might consider that "actionable" and "workview" really are independent, not-mutually-exclusive things, that my table above doesn't truly allow, still. So here's another crazy idea: what if workview was really something purely about tags, and was controlled from the tags sidebar, so that in the sidebar you'd have a set of switcher buttons between "All tags" and "Workview", which would independently affect which tags get shown (and thus which tasks get shown, too) in conjunction with the global view modes which would become:

Label	Tooltip	Shows parent tasks? (hierarchy)	Shows deferred (future startdate)?	Shows "someday" tasks?
Open	All open tasks	✅	✅	✅
Review*	"10,000 ft" view	✅	❌	✅
Projects	Current projects	✅	❌ (or only those starting within 7 days?)	❌
Next actions	Actionable tasks only	❌	❌	❌
Closed	All completed or dismissed tasks	✅	✅	✅

*: in both cases, the trickiest view mode to define—if it's pertinent to have it at all—is the "Review" mode... because possibly everyone has a different definition of what they would like to review. However:

• Maybe the review mode could be the "cheat mode", i.e. it's like the "Open" mode BUT it toggles open the custom filtering bar with all the GtkSwitch togglebuttons that the user can independently flip on/off. So in a way, you'd still have a default UI that offers the simplicity of the actions-vs-projects view modes, AND a fully customizeable review mode for those who seek to drill down with full flexibility.
• Maybe the "Review" view mode could be shipped as a plugin to reduce potential UI confusion for users who are getting started.