This has been mentioned before in a question thread, but I thought I had better flag it properly as a bug/problem. It is hardly an intentional feature, and it does sabotage the concept:
There is currently a big loophole which breaks the sequential flow of tasks in projects. Example:
Say we a have a plain regular project with ten tasks. Only the first one has the green icon, and the tasks are intended to be done one at a time. For example, the 8th task cannot be started until the 7th has been completed. Etc.
Now, if for some reason we decide to break down, say, the 8th task into steps (subtasks), look what happens: All of a sudden the first subtask under task 8 appears on the Next list instantly, although task 8 cannot be started until after task 7 is completed. In reality, creating subtasks under a task renders it parallel to task 1. That’s the loophole.
Solution outline:
no children can be fully green (visible on any of the “current” lists, Next or Waiting) if the parent is not fully green
the “force” toggle and “green” mechanism must apply at all levels, regardless of whether a node has children
better have two different green shades for the icon, the clearest one indicating that the task is now current and visible on the “current” lists (Next or Waiting), the paler shade indicating that it has been preselected for becoming visible once its parent reaches the fully green state
better change the icon letter from N to C (as in Concurrent, or sometimes Current; can also apply to a W/F action)
This will be an interesting discussion, as I’m not sure I totally agree with your comment that it is “hardly an intentional feature”.
I actually thought long and hard on this topic, as I’ve never seen a to-do app that auto promotes next actions for large outlines of actions/projects and sub-projects. So we are kind of in new territory here.
When I thought about this problem, I knew there would normally be two use cases (plus some edge cases).
Case 1: Parallel Sub-projects The main project has one or more sub-projects. Those sub-projects all have actions that need to be worked on, but they don’t need to be done in sequence. They are all on seperate sub-projects but they all need to be done to complete the main project. It’s really as if the projects were not sub-projects at all, they just act like any other project.
** For example** - Think about building a house, there are tons of different sub-projects that you need to do to get the process going. However, if you did every single item in each sub-project in order, you would never get the house built. You would get very far in one sub-project, but be way behind in the others. (See picture).
Case 2: Sequential Sub-Projects Projects that require sub-projects to be done sequentially. Personally, I think this is the minority of projects. But you tell me. Give me some examples of how you would use this. Also, would the Someday feature work for you? For example, see the picture below. All sub-projects are marked as “someday”, which automatically marks all tasks as “someday” and prevents them from having a next action.
I also discovered this issue and I realised that your case 1 example would work with the application’s implementation of next actions. However, I believed case 2 would be the more common use. The bigger projects like the one you used as an example would not be everyday projects for knowledge workers; in fact, the larger and more complex the project, the more likely that there would be a bona fide project manager with dedicated project management software (think of OmniPlan vs OmniFocus).
An everyday example I would use would be;
Project: Research feasibility of implementing new software package
Brainstorm requirements
Investigate options
Invite suppliers to demo software
Waiting for demonstrations to be completed
Waiting for further information (parallel)
Waiting for quote from supplier 1
Waiting for quote from supplier 2
Waiting for quote from supplier 3
Draft report for internal consultation
Waiting for comments from consultation
The sub-projects are not really projects per se, just a group of actions that can be done in parallel.
Yes, I see what you are saying about knowledge workers’ projects possibly being different. However, I’m left wondering if the built in features for “waiting” or “someday” would be sufficient to cover these cases. That way, you still get the benefit of next action automation. In cases where it doesn’t make sense to auto promote the next action, then you need figure out why. Are you “waiting” on something, or is it something you are going to do “someday”? In your example, I think the “waiting” state would make sense. (See picture below).
Does that make sense? Or am I just picking on your example while this solution wouldn’t work for other cases?
I think the whole issue can be easily resolved even without mentioning any particular example. It is very simple:
GTDNext already has - and this is good - the capability to have “nodes” with a number of “children”, and by default these children will be executed one at a time. The first child under the node is marked green by default and will be the child executed first. Other children under that node can be marked green manually, and this will make them parallel to all the other green children under that node. Children can have further children etc etc more or less in infinity.
Basically this is all fine. Except that the app must use the same “green flagging” approach consistently, regardless of whether the children have their own children or not. The current flaw is that the app completely hides the “green flag” mechanism (the “force next” feature) for nodes that have children. Instead these are somehow assumed to be “tacitly green” (unchangeably parallel) the moment they get their own children. You need to make that “green flag” fully available for all nodes in a consistent fashion.
Exactly. And my answer is simple: Just mark those subprojects green as appropriate - just as you would have done if they were tasks. The green marker is what should make it parallel, i.e. make the the green subproject as such “jump the queue”. In your building contract example you’d mark all three subprojects green. And then within each subproject you can mark the individual tasks green or not, just as you have done. In other projects you might have a mix of green and non-green subprojects, as you see fit. To continue with your building example, if you were to add a subproject for “Paint the interior” you probably would not want to make that subproject green just yet, even if it had subtasks in it.
If the subproject as such is not green, then the green markers of its children should have no effect. This is my basic message. This is also why I suggested earlier that you could have a paler version of the green icon to visualize parallel items within not-yet-active parent nodes, just to make it all easier to see in the All Projects view.
I agree that pure sequential subprojects are rare, but nevertheless this is the fundamental mechanism you have chosen for GTDNext, and I think it is actually very good, because in conjunction you also have the “green flag” to select additional parallel items. This means you have all the necessary means to mix sequential and parallel items in a project in a way that is appropriate for each project. In effect you thereby create the very useful differentiation within each node between “first of all, in parallel” (green) and “thereafter, sequentially in the order listed” (not green yet).
What I would like, though, is the default mechanism that if I just “toss” something onto a node (analogous to the “latest on top” discussion), I would like the tossed item to be marked green by default. I can always un-green these items later when I review/edit that project if I don’t want them to be parallel to the first task. It is much safer that way! I would not want to inadvertently “forget” items that I just toss into a project. And it will be very convenient overall, too, because, as you point out, parallel items are very common, in some projects even predominating.
Conclusion: It will all work perfectly, for all of the use cases mentioned and any others as well, if only you just make the green flag available for all nodes, and interpret it (and visualize it) consistently.
No, Someday is not really an option for a powerful and “almost there” app like GTDNext. That’s the kind of workaround I use with Doit; and fully manually, to boot. No, no, no - just fix that “green flag bug” and open a bottle of champagne!
Well, I know you were joking, but it’s not really a bug. The feature is working as designed, it’s just that you aren’t so found of the design
I’d like to hear from some other people as well. So far I see two opinions for handling projects sequential @Folke and @Stephen but I also have two for parallel @James and @sergio
Maybe I would understand the problem better if people could provide me some example projects where our current parallel implementation would break a sequential project. I’m using the product right now quite a bit and so far the current implementation works really well for me. Show me why it doesn’t for you…
Let me know how it’s not working so that we can design something better. The people who want parallel surely don’t want to always have to click “force next” to move their project along, and the sequential people don’t want to have to prevent automated next actions by setting the project to “someday” or “waiting”.
Tell me more about this idea. How would you use this?
Maybe I can explain it better another day. Hopefully someone else can explain it better than I can, before that. I am really sorry, but I have tried to explain it maybe three times, and I cannot fathom what it is that makes this so difficult for me to get across.
For example, why do you see this as a choice between sequential and parallel? It isn’t, and it should not be. It should be neutral, adaptable to the individual project. Some projects can be all parallel, some can be all sequential, and many projects are something in between. The app should be able to handle that, and it almost does.
The way it is done now is almost fully functional:
you have a solid mechanism for making items sequential. The line position itself conveys that; items further down are “disabled” by default
you have a mechanism for “enabling” items in parallel, i.e. for “jumping the queue”. The green flag does that. For items without children you can set this flag to green, or switch it off. This is totally flexible and good.
and here is the inconsistency: for items that have children the green flag is always “on” but it is invisible and you cannot switch it off.
Are you with me so far? Can you see why this could be seen by some as a “notable difference” (or inconsistency) that the green flag is fully available for some nodes but not for others?
Let me try to explain by asking a few questions (maybe I have missed some of the other features):
how do I completely “switch off” an entire project or subproject etc (i.e. a complete tree or subtree, from any level downwards). The use case for this is the usual one; I cannot or will not start it yet, and consequently cannot start with any of its children or further descendants either. Is there some other “off” switch (other than the invisible green switch)?
why is it apparently so repulsive to you to simply show the green flag for all nodes of all kinds at all levels and simply let the user say which things can be started in parallel and which things must wait until after - in a super-simple and consistent fashion, exactly the same at all levels as for simple tasks within a simple project?
why, if a certain task has been set to be sequentially done only after some of its siblings have been completed, why would that same task all of a sudden be allowed to jump start automatically just because I have broken it down into smaller steps?
Silly simple example project: Send a letter:
Item 1 Write the letter (green item by default)
Item 2 Get envelope (green item by choice; can be done in any order)
Item 3 Put letter inside and seal it etc (gray; I need both the letter and the envelope)
Item 4 Send it off (gray)
If I now add subtasks to task 4 (Send it off), such as “put on shoes and go out”, “walk to mailbox” etc these will appear on the Next list immediately. Why has “sending it off” (item 4) all of a sudden become possible to do in parallel to “writing it” (item 1)?
Another example: Your construction example, Say you enter another few subprojects - paint the interior, plant the garden etc. You probably just write them down for planning purposes now; you may not really aim to start doing them yet for a while. How do you stop any of their tasks or subtasks (e.g. buy crocus seeds, fling grass seeds etc) from appearing on the Next list already at this early stage before you have even bought the house?
Hi Folke - I’m very sorry this discussion is frustrating you, that wasn’t my intent at all. I think you have actually gotten your points across very well. That isn’t the issue. I think it’s possible that I’m not jumping on the bandwagon as easily as you thought I should, so that’s dragging this out . However, since this a very core piece of logic, I want to make sure we get it right. You seem to feel it’s an error in logic, while I think it’s simply a choice we made to help make people more productive. Thank you for being so willing to engage on this!
I think I saw this as a choice between the two methods because we were trying to lean towards a solution that would most often work for users in an automated way. Something they wouldn’t have to remember to go do to make it work. Keeping it neutral means everyone has to do “something” to make it work. We wanted to keep it simple, so we were leaning towards the solution we thought would most often be used. I still think the solution might be the most often used. So far, only couple of people have said they don’t like this method. I’d like to hear and see examples of real world projects to see if I’m right or wrong. In my usage of the app so far, it’s been the right choice for all of my projects.
Now, here is where I think we were a bit short sighted. We didn’t fully think through the best way to do sequential sub-projects. We default to parallel, but we don’t give users a satisfactory way to do sequential. Yes, setting a project to “someday” or “waiting” will work. But I think we can do better, and we will.
To Sum up my position: In real life, actions in sub-projects can be done in parallel, sequentially, or a mixture of both ways as part of an overall project. We thought most people would enjoy the automation of auto-promoting actions to “next actions” that comes by defaulting sub-project actions to a parallel methodology.
There are two problems with this thinking:
Not everyone agrees that the way we default is the best way.
While we have a workaround for sequential sub-projects we don’t have a excellent way of handling it.
What we will do:
We are thinking about ways to handle these two problems and come back with a solution. We have some other work ahead of this, but we will come back to this logic soon.
Thanks again for all your input. It’s truly valued.
I’ll repeat my request for everyone - please add some real world project examples so we can see which logic would work best as default or perhaps determine that no default is indeed the best solution.
You have done a great job so far, and I am sure you will continue in the same spirit.
Just to make one thing clear, that I did not mention before: I would have absolutely no problem at all with parallel being the default. On the contrary, that’s probably how I would have designed it myself. Both ways are perfectly fine:
parallel default with the ability to disable and sequentialize those items that should only be started after the first ones have been completed
sequential default with the ability to enable those items that can be started simultaneously as a first batch
The reason I have been arguing from the latter of these two perspectives is the fact that your app seems to have been designed primarily around that - only the first task is green by default, and the rest can be turned on manually. And that is perfectly OK by me. But if you would prefer, a parallel default is equally OK by me, even better. It has the advantage that no special solution is required for “tossed” items. But I am fine with both.
The main thing is it must be possible to adjust the outcome of the default mechanism - be able to turn individual items “On” (parallel) or “Off” (sequential), because whatever the default is (parallel or sequential) it will not always be right for each item under a given parent. Right now that adjustability is not at hand except at the lowest level, and that leads to serious limitations to how the hierarchical capabilities can be at all used. A manual on/off switch (the green flag or its equivalent) really must be present for all nodes at all levels regardless of which default principle you use. Or this whole flexible unlimited-level node tree thingy will have been built almost for nothing.
Another aspect that I believe is quite important, more so for you and new users than for me, is that you use the exact same default and adjustment mechanism at all levels. Whether the default is parallel or sequential, it is best to have it all totally consistent. Otherwise people will have much greater difficulties to learn. If you are worried about real use case statistics, I would advise you to base your choice on what is best for regular size tasks in regular GTD projects. People create many more regular tasks than anything else. Whichever of the two mechanisms you think is most suitable for regular tasks directly under a regular project will be perfectly usable for any other kind of sibling nodes under a parent node, regardless of what level these are on in the tree structure, or what the user actually uses them for. Simple consistency will make the app easier to learn, I believe.
One simple thing you could do, if you do not like my more general solutions described elsewhere, is to at least plug up the loophole by providing an “off switch” for every item (at least for projects).
This switch would simply turn the whole item and all of its descendants completely “off” - until the user turns the item back on manually by flicking this switch back on. In other words, nothing at all in this whole subtree would ever turn up under any conditions whatsoever on any of the “current” action lists, i.e. Next, Waiting, Someday, Scheduled or Inbox. It would override all green/gray/Force settings etc. Off means off. Completely off.
A possible and very appropriate visual indicator would be to let the green/gray toggle turn red when this switch is set to “off”. This would show the user that this thing must be observed and managed manually. For example, all your inactivated projects would then have this red icon (at the project level where the switch has been activated). Please remember that inactivating projects is a core concept in GTD.
And it would be neat and cool and easier to read the list if you would indicate any thereby incapacitated green descendants by changing their color to yellow. This would not be necessary initially if it means a lot of difficult work - the most important thing is to plug up the loophole as such. But in the future it might prove desirable to be able to filter the outline view by “currently visible on the main lists” etc. Then this distinction would be critical - only the true greens will be visible there, not the yellows. And in any event, it will look cool and be easier to read.
In the future, if you ever decide to implement something like the more general solution I have described in many threads, this “off” position can be very well integrated with my suggested green/gray (parallel/sequential) switch such that you have these three positions 1) Normal (parallel), 2) Sequential (auto) and 3) Inactive (manual). (I think I have already mentioned this in one of the threads).
I’ll have to play more with the new option later to see how it works. One initial question, though: Why do you still need Force Next, if “non-Sequential” really would mean the same thing? Or does Sequential here mean “manually managed”?
But don’t worry. I’ll find out when I play more with it, and get back to you with more relevant comments
In the Parallel (the default) mode every first Action in every Subproject is the Next action (appears in the Next list).
In the Sequential mode only one, the very first action for the whole tree may be the Next action.
You may apply the sequential mode to the whole Project, a Subproject or even a single Action.
Force Next is just allows you you make an arbitrary action to be the Next regardless of the Parallel/Sequential mode selected.
parallel is always a safer default than sequential (no risk of hiding things inadvertently)
you can now “hide” a subproject from the next list by marking it as sequential. This will turn off the auto-green action.
What I also find and like less:
you cannot pre-mark (plan in advance) which actions will be parallel in the sequential subproject (and subsubprojects). As soon as you hit the green icon (force next checkbox) they get hot-wired straight to the next list even though the whole parent has been marked sequential.
the sequential option seems to affect both the marked node’s relationship to its siblings (at the same level) AND the relationship between its children. This makes it all much harder to understand than necessary
no visual color marker for whether the subproject itself is “on” (parallel) or “off” (sequential)
old, but still valid remark: At the project-action level, I think the Force Next setting for projects, which causes all new actions to be parallel by default is unnecessary and confusing. It is much better to let the default for outline mode edits and moves be dictated by where the action is created/moved, and for “dropped” actions to be consistently parallel.
I think the solution is quite simple:
let the sequential switch affect the project node - it and and its whole subtree - as an entity, but do not let it affect the internal relationship between its children. This change will make it very clear and easy to see what has been controlled from where.
for additional clarity: indicate with the color icon which subprojects are “on” and which ones are “off” (on sequential hold)
in the sequential project, still show the intended “green” tasks in the outline view, but say in yellow or pale green, to indicate that they are not yet visible on any of the “current” lists. In other words, “kill” the Force Next’s “hotwire”, but keep its ability to mark things as parallel. This will allow for pre-planning.
it would be very nice to also have the third option to switch a whole node (and its descendants) entirely off (never visible even when first in line) ) and thereby have it marked red. This will be a very clear and simple way to reliably and indefinitely inactivate an entire project or subproject, and put its reactivation entirely under manual control.
Actually, I think you still need only two edit pane checkboxes for all of the above, same at all levels for total consistency: an “Inactive” checkbox and a “Sequential” checkbox (ignored when Inactive). When neither is checked the items will be parallel to their parallel siblings (and will be done before any gray siblings). Simple. And the main defaults are controlled by where you create/move the item when in outline mode, else parallel (no checkmarks when just “tossed” via a menu etc).
Great suggestions and thoughts @Folke. We do plan to add some sort of indicator in the near future to make it more clear what kind of project it is.
We’ve spent a lot of time on this feature. It’s been worth it as I believe we have come a long way in making GTDNext one of the most flexible GTD apps on the market. Thank you for your insights and help!
Next, we will let the feature “rest” for a bit, while we focus on the rest of our backlog. After we get some more users and see what kind of feedback we get from people as they start to use these features we will identify any problems and make more updates and enhancements as needed.
. However, since this a very core piece of logic, I want to make sure we get it right. You seem to feel it’s an error in logic, while I think it’s simply a choice we made to help make people more productive. Thank you for being so willing to engage on this!