@vbaschen
Hi,

Q: 1. Important: In the next list show one should attend projects actions only. Standalone actions should all be available in the next list (that belong to the list).
A: Do you mean that you could not use the show one feature when you group the tasks by context?

Q: 2. "Show one" actually means Next Actions. Next Action per Project and all standalone actions. I the feature "show one" per context if I switch to sorting my actions along contexts deliver me not the needed information. I think it shoud show me the same one action per project and all standalone actions but sorted along context. Meaning there will be more than one action per context, but as many as projects next actions are available.
A: List with different group options has different order. Do you mean that you want the order will be the same no matter how you group the tasks?

Thank you for your support!

Best regards,
Doit.im Team

I think the whole idea behind "show one" unfortunately is completely wrong. It is not a matter of finding a general "number". It is a matter of being able to enter tasks into your GTD app well in advance before they become visible on the GTD lists (Next, Waiting, Someday/Maybe, Tickler, Calendar) and to be able to "hide" the ones that are not truly active yet (the ones that David Allen categorizes as project support/project plan).

For example, in one project maybe I have three active tasks (one Next task for me to do myself and two Waiting tasks for other people to do) and have another five tasks that should be hidden for now (that are neither Next nor Waiting nor Someday nor Tickler nor Calendar just yet). In another project maybe I have one active and twenty inactive. In another project I have ten active and two inactive. Etc. The inactive tasks are impossible to do anything meaningful about at this stage and are therefore irrelevant (annoying clutter) to have visible yet on the main GTD lists (Next, Waiting etc). This is true regardless of whether I keep my list grouped by deadline, project, context or whatever.

wendy, you said: "List with different group options has different order. Do you mean that you want the order will be the same no matter how you group the tasks?"
Yes, absolutely. It is best to have only one global manual order, and it would be good to have a grouping option None to be able to adjust the sorting conveniently in one single place. This single global manual order is also important from an entirely different point of view. It would enable us to have priority based default placement WITH manual adjustment - a real killer feature.

@wendy_only
Hi Wendy, thank you for quick response.

Q: 1.
A: Do you mean that you could not use the show one feature when you group the tasks by context?
Explanation: No. This question isn't about context for now (problem with contexts show one feature was described in the 2nd question). It is a general order and filter question of active AND actionable tasks that should be shown in the next list in accordance to David Allens GTD System. (See example for the booth questions below)

Q: 2.
A: List with different group options has different order. Do you mean that you want the order will be the same no matter how you group the tasks?
Explanation: Yes and no :) I mean there should be three different order functions.

a. The one should be a filter order, that should be always the same (for next list and as for context list) that is based on the (manual) order within project AND on the state of the task (today, next, waiting, someday). This filter order should be responsible for "what is next actionable action?" question. It is not really the order that the user may want to select or so.

b. At the same there is another type of order (that user should be able to switch): Sort View. This should be sorting option for already filtered list. Meaning user is able to sort next lists actions along project, context, priority, (time)*, (energy)*.

c. In the best case user should be able to filter the already filtered (actionable only) next action list at least by context and priority (theoretically also by time and energy). Meaning: If I'm ready with todays tasks, or I'm for example at home, or I'm waiting for something and have 15 minutes free time, I go to the next list and filter them
- by priority (only actionable tasks with priority 1 will be shown) or
- by context (only actionable tasks with context @phone will be shown) or
(- by time (only actionable tasks thats estimated time is until 15 minutes))* or
(- by energy (only actionable tasks that require from me low energy input to be done)*

*Belongs to David Allens GTD system, but not available in doit.im, or are implemented not really in accordance with GTD-System. (but it is another topic :))


EXAMPLE:
For example you have following tasks/projects in your doit.im system:
---
- Standalone task 1 (next, prio 3, context 1)
- Standalone task 2 (waiting, prio 2, context 1)
- Standalone task 3 (next, prio 1, context 2)

- Project 1
-- Project 1: task1 (due Today)
-- Project 1: task 2 (next, prio 2, context 2)
-- Project 1: task 3 (next, prio 3, context 1)

- Project 2
-- Project 2: task 1 (waiting, prio 1, context 1)
-- Project 2: task 2 (next, prio 2, context 2)

- Project 3
-- Project 3: task 1 (next, prio 1, context 1)
-- Project 3: task 2 (next, prio 2, context 1)

- Project 4
-- Project 4: task 1 (next, prio 3, context 2)
-- Project 4: task 2 (next, prio 3, context 1)

------------
SCENARIO A: The filtered (a) "Next" section for these action that is sorted (b) by PROJECT should look like:

- Standalone Actions:
-- Standalone task 1 (prio 3, context 1)
-- Standalone task 3 (prio 1, context 2)

- Projects Actions:
-- Project 1: task 2 (prio 2, context 2)
-- Project 3: task 1 (prio 1, context 1)
-- Project 4: task 1 (prio 3, context 2)


1. As you can see all available active standalone actions are in the list. Not just one.
2. Project 2 is not in the list because the depending 1st action is on waiting list and the 2nd is not actionable for now, until the 1st one is done.
------------

SCENARIO B: The filtered (a) "Next" section for these action that is sorted (b) by CONTEXT should look like:

- Context 1:
-- Standalone task 1 (prio 3, context 1)
-- Project 3: task 1 (prio 1, context 1)

- Context 2:
-- Standalone task 3 (prio 1, context 2)
-- Project 1: task 2 (prio 2, context 2)
-- Project 4: task 1 (prio 3, context 2)

Comment: All the same actions but sorted by context. It is not filtered by context (as it is implemented now), there are more than one action per context.
------------

SCENARIO C: The filtered (a) "Next" section for these action that is sorted (b) by PRIORITY should look like:

- Prio 1:
-- Standalone task 3 (prio 1, context 2)
-- Project 3: task 1 (prio 1, context 1)

- Prio 2:
-- Project 1: task 2 (prio 2, context 2)

- Prio 3:
-- Standalone task 1 (prio 3, context 1)
-- Project 4: task 1 (prio 3, context 2)

Comment: Again - all the same tasks just sorted by priority.

----

I hope you can understand my english (I'm not a native speaker) :) And sorry for the huge text, but I think the best way to describe the problem is to built up some scenarios.

best regards,
viktor

@wendy_only In addition:
The best case for the so called "show one" feature for next list would be actually if doit.im could also handle with different types of projects. There are two types of projects: sequential (a) and parallel (b).

a) While sequential project is active step by step. Meaning you can't start 2nd task until 1st one is unfinished. Therefore in the next list

b) Parallel project: all actions in that kind of project are actionable and all of them should (like standalone actions) always be seen in the next list (not only fist task of the project). Alternatively you could let user decide which actions parallel (could be done independently from each other). This solution is also good and probably also better than the parallel project, but I think technically it will be more difficult to implement.

With example in the post above (#3) scenario A would look like:

- Standalone Actions:
-- Standalone task 1 (prio 3, context 1)
-- Standalone task 3 (prio 1, context 2)

- Projects Actions:
-- Project 1: task 2 (prio 2, context 2)
-- Project 3: task 1 (prio 1, context 1)
-- Project 4: task 1 (prio 3, context 2)
-- Project 5: task 1 (prio 1, context 1)
-- Project 5: task 2 (prio 2, context 2)
-- Project 5: task 3 (prio 2, context 2)
-- etc.

Pros of system like I've described should be clear. You have only relevant stuff in your next list (only tasks, that are ready to be acted with), sorted (pre-defined) by project or manually by what ever is relevant for you at the moment, and last but not least: you can filter these action-ready tasks based on ressources you have at the moment (context, time, energy).

By the way, contexts lists that doit.im has now are not the same. The way, how context lists are implemented now is in my opinion completely right one. That lists should (as it is) show all actions that are marked with one specific context independently from state of the task. While filter along context in the next list, would show only actionable tasks with selected context (=dependently from state of the task).


best regards,
viktor

@vbaschen and @wendy_only

I disagree that a separation of sequential and parallel is the way to go. It confuises many users, and it has proved its shortcomings in Nirvana, MLO and other apps that have it. It is way too rigid.

It is better to bite the bullet and accept the fact that a project can have 1 or 2 or 3 or 4 or ... or any number of now active (parallel) actions, even all. Any remaining "inactive" actions can be made to automatically progress to the active state when no active actions are present anymore.

Automation is in fact popular, and the above solution allows for full automation, AND also allows users to nominate additional actions, which is essential both for GTD compliance and for sufficient realism and flexibility. And also, there is no up-front choice of "type of project" to confuse users.