-
Notifications
You must be signed in to change notification settings - Fork 71
Blueprint improve GTD support
Resource on proper GTD work flow:
Conclusion:
- Need support for multiple task lists
- Need support to assign tasks to projects
- Need support for "tickler" file
Current have one big list, allow to make subsets by text filter, tags & the "non-actionable" toggle. Downside is that the view is still crowded, and you have to remember what selection to look at.
Instead propose to have multiple lists and a way to assign a task to one or more of these lists.
Most flexible solution would be to allow the customer to configure lists by a search query. Interface could be to have multiple tabs in the tasklist dialog and a fixed selection for tasks per tab.
E.g. a list for active tasks versus a list with non-actionable tags. Remove special status for the "non actionable" tags, just configure a list for tags matching "not @wait" and a list for "@wait". Result is two tabs that allow easy switching. (Display number of list items on the tab.) Any further tag selection or query should result in both tabs showing a subset for that selection.
More complicated workflow could be to separate planned tasks from the inbox. This can be done be configuring a tab that shows all tasks for "namespace: Projects" and a tab for "namespace: Journal". Now you can enter incoming stuff in the journal page for today and have it show up in the inbox tab, and then move it to a project page once you decided what to do about it.
Conclusion: multi-tab interface and better query interface allow flexible configuration of work flow
GTD describes "projects" as multi-step tasks. In a way this is supported already in zim by nested tasks. However this is support is weak because you need to have all tasks in a single list to be able to nest them.
Would be more interesting to be able to have a designated project page and automatically assign all tasks on that page and in sub-pages to that project.
The project itself is not actionable, so it should not show up as a task in the list.
Idea:
- Allow pages to define a project, assign all tasks below that page to that project
- Project should have a status open / closed / on hold
- Have a view that shows the tree of projects and tasks below them (have a top level "No Project" bin for any loose tasks) versus a flat list that shows all tasks without the nesting
How? We could define a keyword like "Project: ..." and parse that if it appears on a page. Or wait for inline objects and have a simple project form with title, status etc.
For interface it may fit in a tabbed interface design for the tasklist to have a projects tab. Or allow to configure per tab whether it should be a treeview or a listview. Or allow toggle per tab. Try out what works best.
In addition tasks may have sub tasks that live on a separate (sub)page. E.g. highlevel tasks are listed on the project page, then detailed out in sub-pages.
In this case it would be nice to link to the sub-page. So new feature to make all tasks in sub-page sub-tasks of referring line item in the parent page.
Also this would be a good intermediate step before full project support.
Current way to have a tickler file could be to use e.g. the journal page as your tickler file for the day / week / month. Write stuff on future pages to set a reminder for when you get there.
Nice way to support this in the tasklist would be to have a start date for tasks and make them popup in your action list or inbox list when that date is reached.
Explicit: extend the "[d: dd/mm]" syntax to "[d: dd/mm dd/mm]" for task with start and due, or "[d: dd/mm ..]" for just start date but no due date.
Implicit: configure tasklist to assume journal page implies a start date
Works well in combination with the tabbed interface when you configure the journal namespace as your inbox. Stuff written down by today goes in the inbox immediately, stuff written down by next week pops up next week :)