Some thoughts on GTDNext next action logic

question
#1

There are several threads going on about how the logic does work and should work in GTDNext. We really appreciate all the discussion and feedback! Rather than reply to all those threads separately, I’m going to respond here with our current thinking on several different ideas that have been proposed and what our current thinking is on these topics.

In this post I will cover:

  • Defaulting actions to one at a time
  • Sequential versus Parallel Sub-Projects
  • Force Next Option

These three topics are all part of how the logic of GTDNext works, so I thought it would be good to address them all in one spot.

Defaulting Actions to One at a Time
Currently: We default actions in projects to be shown one at a time on the next action list. You finish one action and the next action in your project then displays on your next list. We have an option called “Force Next” that allows customers to add (or force) other actions in the project to be added to the next list.

Future: We plan to keep the default as it is today.

Reasoning: We believe one of the main benefits of following the GTD methodology is the use of next actions. Having hundreds of actions (many of which you can’t act on) crowd your next action list and does not hold true to the GTD methodology. At that point, users might as well use one of the hundred other list mangers on the market that doesn’t even have the next action concept.
From what we see, most users are attracted to a GTD app in part because of this feature and as such our defaults should be in alignment with the methodology.
We recognize that there are lots of exceptions to this rule and even some people who may want to use the app that are not GTD practitioners and so we will provide several different alternatives. The ability to “force next” an action will allow non-GTD practitioners and special case projects to be handled fairly easily. At the core though we believe customers usually strive to identify the next physical action they can take in any project. You can’t do two things at once.
When you have 100 to 150 projects, each with 1 to 10 actions you have way too many actions in your next action list, even with filtering. Education will be key here as not everyone get’s this concept and we will have some videos to help customers learn the concepts if they are not familiar with them today.

Sequential versus Parallel Sub-projects:
Current: Currently we default to parallel sub-projects. Meaning, if you have a sub-project in your project, the first action of that sub-project will be marked as a next action automatically, even if there are still actions remaining in the main project and they are “ahead” of the sub-project in the tree structure.

Future: We will be adding a project level control that will allow users to control if a project is handled in parallel or sequential when it is part of another project. We think most people will want parallel turned on by default so we will default to parallel with the ability to change the default in preferences.

Reasoning: While we think many people will like having parallel turned on at the sub-project level. In our testing most of the sub-projects we create it seems to make sense in the knowledge worker works and in consulting and software creation world. Typical knowledge worker sub-projects contain tasks that are not so dependent on the main project that they can’t be started in parallel with other projects. So we will have this as the default. We will eventually have a switch in preferences that allows users to control what they want as the default.

Force Next Option:
Current: Currently the option to add an action to the next list that is not currently the true next action is called “force next”.

Future: At the action level, we like this name better than the name of sequential and parallel. We think people (not on this thread) will get it better. We still don’t love the name, but we abhor long names… So until we have a better short name it will stay as force next.
For sub-projects we will use parallel / sequential - unless we find something better there as well.

Loophole in Sequential Task Progression
Beta 2 Released
Recommendation: Parallel
#2

@James

Good move to fuse these discussions into one thread. I will not repeat much here, as I have explained most of what I think would be the best solution in those other threads, so I will just refer to them indirectly, if necessary.

What I will focus on here in this post is just comment on some of the “new” aspects that you just toughed upon here, namely what is “GTD methodology” and what is not, as this is often an area of confusion.

I think it is important to know that apps such as GTDNext are already quite a bit “beyond” core GTD as described by David Allen (DA). GTD is designed for paper, and is represented most closely by apps such as Wunderlist or iOS Reminders, i.e. flat lists without any linkages between lists and without any hierarchies.

I personally like the “advanced” style of GTDNext and similar apps, which goes way beyond core GTD, but it is necessary to be aware of the fact that there is often no GTD terminology for the things we are discussing. For example, words such as parallel and sequential, sub-projects, “true” Next action, dependent actions etc are simply not in the GTD vocabulary.

So, if, apparently, we all want to go beyond core GTD and still want to stay perfectly in line with GTD, I think it is best to look at what DA really does say:

GTD only deals with actions and projects
DA says that for most people most projects tend to be small. He does mention that some projects can be very big, with multiple levels, Gantt charts etc etc., but he leaves that aside. The methodology only covers actions and projects.

GTD assumes no documented linkage between action and project
The list of projects is just that - a flat list of projects. It serves as a list (or checklist) of “reminders” (a term frequently used by DA for both actions and projects) of what projects you have to deal with. During your review you simply look at each item on the list (each project name) and quickly dream up a few actions (Next actions or others) that are now relevant to list (list on your current GTD main lists Next, Waiting etc). DA says it is not even worthwhile to write down which project a given action relates to, as this is often obvious.

GTD’s “project support” is where the future actions are kept, if you even have any
The main GTD category lists (Next, Waiting, Someday/Maybe) are lists that should be useful and meaningful to look at and consider doing something about now, anytime. If you have a project in which you have foreseen or planned some actions which are not possible to get done yet or not relevant to list yet, the place to keep these is in the GTD bucket called “project support”, the organization of which is not described, but whose contents comprises anything and everything that is not on the main lists (things like budget, brochures, project plan etc)

GTD can have any number of next actions in a project
DA says it is essential to identify every next action in every “moving part of every project”, in others words identify everything that actually can be started now, which can be at least one or more actions.

GTD requires conscious activation/deactivation of projects
In GTD you should not take on more than you can handle, and “prioritization” takes place primarily at the project level, not the task level. It is necessary to review the list of projects and decide which ones are going to be active.

Conclusion - how GTD relates to GTDNext

The whole discussion about sequential vs parallel defaults and true next actions is totally beyond GTD. In GTD, only “true” next actions are next actions. Period. Everything else is “project support”. And there are no rules for how to automate the transfer from the inactive “projects support” bucket to the "active GTD lists. A manual/mental approach is tacitly assumed.

So what we are in fact talking about here is a way of “integrating” some of the contents of “project support” into the same app that also manages our current main GTD category lists. And also to automate the transition of such “project support” action into a regular (currently active) GTD action on the main lists. There is no GTD terminology for this.

I think probably the only major principle we can carry with us from core GTD is that we must not clutter our current main GTD category lists with stuff that is not yet relevant.

GTDNext Hierarchy

You have already chosen a path with flexible-depth hierarchies. This is very nice. Even though it goes way beyond core GTD it does not in any way break it. And it opens the door for very complex planning of the future. But what it also does is it half-shuts the door for “noobs”. Obviously it is easier for a “noob” to have Actions vs Projects clearly identified with separate names and icons etc, rather than have an infinite hierarchy of little square “nodes” which can represent virtually anything. But there are sufficiently many apps out there already for “noobs”, so I think you made the right choice, There are plenty of people who want to go beyond core GTD.

I think it seems unwise, though, both from an engineering point of view and from a user simplicity point of view, to have different defaults and adjustment mechanisms depending on what level of the hierarchy we are at. It is difficult enough as it is. It is easier to have one principle that applies generally to “a node with child nodes”, whatever that node and its children represent. Also, if you start to build in assumptions about what all the levels are going to be used for in real life (e.g. assume that level 2 from the bottom is necessarily a “sub-project for knowledge workers”), then I think you are creating many more problems than you are solving. (If you are going to have different rules for different levels, then you’d probably be wise to consider having different names and icons for them, too, to make it easier for people to understand each level’s unique set of features.)

GTDNext Automation

Automation is obviously more valuable at lower levels, with a higher “churn”. It is not necessary to have it automatic, of course, but it is certainly neat and convenient, if implemented appropriately. Automation can also be of value at the next level up, e.g. if that level is a small sub-project with tiny tasks, and the 3rd level (above that) overall moves much more rapidly forward that you care to review it. But generally speaking, automation has lower and lower value the higher up you go, so if there are engineering reasons for limiting it to just one (or two or three) levels, then I do not think this will be a dealbreaker for anyone. There will be some difficulty for new users to “learn” that automation stops working above a certain level, but if that’s the only difference between levels, then I think you should be fine.

GTDNext on/off switching for "nodes"

The crucial thing - simply a must at all levels - is to able to individually switch selected nodes on or off (activate/deactivate projects etc). This is even part of core GTD. Currently it is not so. All items are “on” and there is no way to switch them “off”. http://forum.gtdnext.com/t/loophole-in-sequential-task-progression

It sounds now as if you are thinking about introducing the rigid one-or-all option from the 2nd level and up, and this I’d say is definitely a no-go. It adds no value, solves nothing, and if anything just makes it more confusing (to have a separate principle). There must be an individual switch for each item. Simple. And there is no way around that, whatever defaults you apply.

GTDNext defaults

As I have said before, it matters little from a pure GTD point of view what defaults you have as long as the default decisions can be changed on an individual basis for each item. That is the key point. As I have said before I think there is strong case generally speaking for applying parallel (could be called Normal) as the general default. http://forum.gtdnext.com/t/recommendation-parallel

Regardless of what the general default is, I consider it essential from a safety point of view that items that are not entered carefully using the Workflowy mode but are instead “tossed” into a project (node) using menus or dropdown lists etc without being deliberately placed are set to be “on” by default (active, parallel, whatever you care to call them.) Having such items set to “off” (sequential) by default would necessitate many unnecessary visits to the project just to correct this, and will inevitably lead to important actions being overlooked whenever the user forgets to correct the default setting.

Color coding for Active, Waiting, Scheduled, Someday
#3

I think I initially disagreed with this, but working on the site in practice (and given your logic) it makes sense. It’s not that hard to go in and “force next” for those things that you might want to see at once. But yeah, it is a bit hard to do two things at once. :wink:

The idea of having a next list that’s entirely too long an unmanageable is a very good point. I fell into that trap recently and ended up just feeling overwhelmed. So I think that’s a good check on things.

#4

Don’t forget that when you enter tasks in Workflowy mode it would be handy if the default setting for the new task were to mimic the preceding task. This ensures that when you enter tasks in the sequential (later) part of a project they would default to sequential (“off”), whereas if you enter a task among the few top ones that you have already marked green, the new task would also be green (“on”).

Color coding for Active, Waiting, Scheduled, Someday
#5

Oh, and also don’t forget that what were are saying here applies not only to intended Next actions, but to intended Waiting and Maybe (Someday) actions as well. You need green switches for all of them. None of these should be allowed to “pollute” the current lists unless we want them to; if placed sequentially before other actions they should block all of these in the same way, and vice versa. And I’d say that goes for Scheduled, too, even though scheduled (called Tickler file in GTD) is not one of the three main GTD categories. If a scheduled action, placed sequentially, is still gray, then it should not show up on the Scheduled list, and it should block anything gray that follows.

#6

This should be happening now for “info” mode in the 1.3.8 build that came out today. Thanks for pointing that out.

The new Force Next at Project Level feature in 1.3.7 should solve this problem. When we get to building out settings area we will also look at turning this on by default. [quote=“Folke, post:2, topic:65”]
So, if, apparently, we all want to go beyond core GTD and still want to stay perfectly in line with GTD, I think it is best to look at what DA really does say:
[/quote]
Excellent run down here of DA’s comments. We certainly have gone beyond what his books say. As much as possible we will use the principles as our guide for this product, but I agree that the principles don’t always inform very well or dictate what should happen in the more advanced areas we are trying to create with GTDNext.

#7

I just thought I would show you in a single picture what I am spending tons of words on :wink:

The way I see it, green would men “on” (“active”, “enabled”, “engaged” or whatever you would like to call it).

As you can see in the example below, the main Project is “on”, as are Subprojects 1 and 2, whereas Subproject 3 is “off” (gray).

When the Subproject is “on” its contents can also be “on” according to the setting of each individual item within. In the example below, only four actions are “on” (visible on an “active list”, e.g. Next, Waiting). These four actions are A1-1, A1-2, A1-3, A2-1.

Subproject 3 is “off”, indicated by its gray color. Nothing in this subproject will be visible on any “active lists” as long as the subproject itself is gray. And therefore nothing can be green inside. But you can still see in advance in the outline view, and prearrange, which ones are going to be green initially when the subproject (parent) is eventually turned on, using the same icon switch as always. The only difference is that these “green flagged” tasks are shown in another color until that happens to clarify that these tasks are not “on” just yet - not visible on the “active lists” yet - but all set to go as soon as their parent is turned “on”. This will be essential for preplanning.

GreenSwitch.jpg960×720 33.4 KB

1 Like
#8

Hi Folke, thanks for all the ideas you have for the project!

First of all, to understand each other better I’d suggest to use the terminology we currently have for the project. That will save a lot of time for all the participants of the forum, will let us understand your ideas easier and you won’t need to repeat them many times.

About the above example. It seems that Subproject 3 is of type Someday or Waiting (no other way to turn the Next button off in the current state of the project).
You’ve already mentioned earlier you wanted to have an indication of the Next (Force Next) actions for not currently Active projects.

We found the idea useful and are planning to implement it in the future (for now we have a really tough development schedule but maybe we’ll manage to cram it in one of the following releases).

#9

Hi Sergio. Thanks for the feedback.

I thought a picture would be good for everyone, even for myself. Fewer words.

First of all let me assure you that I believe GTDNext may well turn out to be a good, perhaps even the best, app in the market despite all these discussions. :slight_smile: It is still too early to say. There are many factors that will weigh in. Most apps do not have much at all in terms of “logic” for their projects, and I believe we are all accustomed to using workarounds of all kinds, using whatever mechanisms are available in the app we are using at the moment. Project logic may not even be the most important feature overall. But you seem to have gone a long way already to try to beat most of the others in terms of levels and “parasequential” behavior, so what I am trying to accomplish here is make it possible for you to avoid some of the pitfalls other developers have fallen into, and come up with something very simple and - perfect.

I currently use Doit, which has four fixed levels (Goal-Project-Task-Subtask), no automation at all at any level, and no built-in way to put sequential actions on hold, but it does have a built-in way to put projects on hold. So for managing projects where some actions are not “parallel” (current now) I need to use a workaround to put them on hold. (I use a combination of Someday + No Priority, which makes these easy to either find or to ignore on the Someday list. Doit has a very clear priority indicator in four levels and I need only three of these, so the white No Priority is available.)

Before Doit I used Nirvana, which had 2½ levels (Project, Action and Subtasks as checkable comments.) It has strict sequential automation, which I never used, since I almost never have strictly one-at-a-time sequential projects. It also had the “normal” full parallel, which is what I therefore used consistently (in conjunction with a special “list” they had called Later, where I placed the on-hold tasks.)

MyLifeOrganized has infinite levels, and the option at each level to treat its immediate children as either parallel or sequential. In other words, MLO is not as flexible as the mixed “parasequential” approach you have chosen for the action level, but on the other hand it is consistently done at all levels, and thereby very simple to understand. (MLO has certain problems in many other areas, though, including a too-slow mechanism to set priorities, so I decided not to use it.) Since MLO has unlimited hierarchical levels and the two extremes fully parallel or strictly sequential at all levels, you can build any kind of parallel/sequential structure you like by increasing the depth of the hierarchy. But personally I am not too keen to use this approach. It gets messy to introduce additional levels that have no “meaning” other than to accommodate some special parallel/sequential structure. I favor an easy or even “sloppy” way of working, and think it is simply perfect to have the option to mix some parallel items to go first and have the rest on auto-sequential hold, just like you have done it already at the action level.

I am trying, but I am not sure I can. Some of the stuff I am talking about is a “generalized” version of what you currently have. For example, your “green/gray switch” currently only applies to actions in the GTD Next category (not Waiting etc), and it only really applies at the action level (not projects etc). So I am not sure what to call “my” version of this switch. In my opinion, it should apply to all GTD categories (Next, Waiting etc) and at all levels - in exactly the same way at all levels for consistency and simplicity.

While it may well be true that there is currently no other way in GTDNext to generally block all actions from showing up on the next list than declaring the whole project as something other than “next”, this is not really good enough. Even Doit and Nirvana can do better. (They both have an “inactive” setting for projects).

Putting such “sequentially dependent / on-hold” projects in Waiting is entirely out of the question even as a workaround as far as I am concerned - a real Waiting item is somebody else’s current Next action (or active project), and might be completed or “arrive” any second, hour or day now; e.g. people who “owe” me a report, a quotation, some money, a call etc; I need to review my Waiting items quickly every day, and I cannot afford to have any clutter there (e.g. in the form of items that are on hold and therefore cannot possibly happen now.)

Someday is better workaround. Strictly speaking, the things that are on hold are not Someday/Maybe - a true Someday/Maybe item is something I hesitate whether I even need to do; but there is no hesitation in this case; nothing I need to decide or even consider; so I would not want to confuse them with each other. But if I can somehow visually separate the true Maybes from the “sequentially on-holds” it can be an OK workaround to use Someday, because I do not look at it every day, so clutter and/or inconsistency is not equally disturbing (as long as it is not a total mess). But a “proper” solution would be better. (You probably cannot imagine how much flak Doit are taking on their forum for wrongly “forcing” people to use Someday. Fortunately, I have a spare priority to use for these so I can at least see them clearly, and also get them auto-sorted to the bottom, but others must have a real hell.).

A final word: I know you are very busy, and that some features are probably more important and urgent than project logic. So please do not get me wrong here. I am just trying to fill in the missing “little” piece that would turn this into something much more simple and more powerful than it is. You already have the infinite levels and the “parasequential” logic (at the action level). All that seems to be missing is a little bit of “consistency” (uniformity) between levels (and between GTD categories).

Cheers :slight_smile:

#10

Thanks for such an extended response. We really appreciate the time and effort you put into helping us making the project better.

Though, the response is so huge and touches so many topics that I don’t know from what to start :smile:
I’d actually prefer to discuss each problem user may face using our app in a separate thread to separate the problems and have it discussed more detailed without mess from the cross-topics. But still I’ll try to response to the main points here.

First about the terminology. When you say about “generalized” version I guess you mean your vision or a mental model of how the perfect (in your understanding) application should work. But we just can’t follow all the user’s mental models. Even though you are not the average user of the forum of course :wink: it is still sometimes very hard to follow your ideas. I just can’t get without reading it twice or more what you are talking about when you say “green/gray switch” or GTDNext category.

The category term is misleading here. We just call it (Inbox, Active, Waiting, Someday) - a List Type or simply a Type of the project/action.

The “green/gray switch”. We actually don’t have it.
The Action may be in two states: Regular and Next Action. There is an algorithm (let’s not discuss it here :slight_smile: ) that assigns the Next state to the action.
There is also a Force Next switch. All it does is allows user to assign the Next status to Action manually.
So, the action may become Next in two cases: automatically and manually assigned.
The behavior of the Next Action is simple: If the action is Next it appears on the next list.

About the Force Next option on projects. Some time ago you’ve shared a concern about missing an Action created or dropped on the project, because it not gets the Next status automatically. With the Force Next ON on the project any new Action you create becomes active automatically. We also plan to introduce the option in the user settings called Auto Force Next. When On it’ll allow to create top level projects with Force Next on automatically. That feature should fully cover the issue with missing the new items.

About not having the Next and Force Next button on the Waiting and Someday types - it’s just what I’ve said about in previous post: we are planning to implement it.

About the Sequential projects (with only one Next Action automatically assigned) - we are also planning to implement it. Using Waiting or Someday to suppress the currently assigned Next status of actions is a temporary measure/workaround until we implement the sequential projects.

#11

And thank you, too, Sergio, for engaging with me on this topic. I actually understand more now about your future plans, and feel much more comfortable. I also want to apologize for confusing you with my non-GTDNext terminology.

Let me just show you how much of what you said that I totally agree with:

I agree that you do not have a green/gray switch with the functionality I envisioned, but you do have a green/gray icon, and this icon can be toggled, with different effect depending on what kind of node it belongs to.

I am perfectly fine with Type (I think DA calls it category, and that’s the reason I used it, but I agree it is a misleading word, as are so many other of DA’s choices of words).

Terminology problem: I think the Type currently called Active ought to be renamed to Next. This makes it easier to know which of the main Type lists the item is on or will be on. (The term Active is misleading, since it can be construed by newbies and others as “not on hold” etc, i.e. fully visible on the main Type lists etc, i.e. confused with “Force Next”.)

Great! I did not realize it was planned. So no need to pester you about that anymore :slight_smile:
(It is such a nuisance to have these show up right from the start when they are not relevant yet)

Terminology problem: At that stage the term “Force Next” will be confusing, as it can then apply to an action of any Type, such as Waiting. I suggest you instead consider terms such as “Normal” or “First” or “Initial”, or just “Force” (or even “parallel”, but that is too technical for many users).

Great!
(In fact I think this could be the system default for “tossed” tasks - it matches the “landing on top” default. I am not sure anyone would want it any other way, but an option never hurts …)

UI problem (potentially major, but avoidable): If you continue to use the current (new) ability to use the “Force” toggle to control this default for new tasks within the specific project, it will not be possible to also use the same toggle to control whether the project as a whole is on hold or not. So you would need a whole new icon/toggle to inactivate a whole project. It is already confusing that the green/gray toggle has a different meaning for projects and actions, and to have to throw in yet another toggle just to be able to inactivate a project would clutter the UI.

The solution is simple:

  • Take away the “new” Force feature for projects and rely entirely on the planned general default feature (that you mentioned) for these “tossed” tasks (i.e. those that were not placed into a particular position).
  • For tasks entered in a precise position in the outline/workflowy mode you had better not look at any of these general default settings, anyway, but instead default to mimicking the Force setting of the neighboring task in the list (analogously to how you mimic the indent setting). This will make it extremely easy to enter a dozen sequential tasks e.g. at the end without having to set each one to gray, or add a few additional “green” tasks among the top bunch.
  • Consider making use of the Force toggle for projects in a way that is similar to how this toggle works for actions, i.e. let it control the visibility on the current Type lists (gray meaning hidden from those lists).
#12

It seems no matter where I go, there is a group of people who make GTD complex and others who keep it simple. I think these two groups will always be around and there is not much that can be done about it.

The truth is, GTD is actually very simple. DA does not dive any deeper because it’s simply not needed to make it work. GTD is not designed for paper, but the book was written at a time when paper was widely used by many. DA is currently working with a company to create an official GTD app.

Not an attack on your comment @Folke. You know you are my bud. lol

My initial thoughts about GTDNext is confusion. I know it’s in beta but I put simplicity and ease of use ahead of just about anything else when it comes to an app that should help me be productive. The less time I spent inside of it, the more time I spend doing.

I was confused about my next actions showing up under the project list. I could not figure out how to create a project until I accidentally hit tab and then I could not figure out how to undo it because what I indented was actually a different Next Action. Once I realized you can indent task, I think I figured out projects, but I can’t simply create a project and add actionable items to it. It seems I must create new actionable task under the task I consider the project title and indent them in. Then I realized that what I though was a project was not listed as a project in the project list or maybe it is but my Next Actions are there as well. This is why I think it’s confusing.

I could not figure out how to create a checklist until I realized it’s the same process of a project but I must change the “Mode” somehow to make it work. I don’t know what the modes means and info. makes no sense to me at all. Where does my list live? I don’t have a checklists section or is it considered a next action as well?

So basically, I am still confused but maybe that’s because I am a moron.

If I need a project, I want to click “Create Project”. I then want to simply add actionable task to it by hitting Add or simply just typing in an entry area under the project itself.

If I need a checklist, I want to click “Create Checklist” and then simply add bullet items quickly under it and be done with it.

If I want to create a single actionable item (Next Action), I simply want to create the task in my Next list and not have it show up in any other list.

If I need to “quick add” something. I don’t just want it to go into inbox, but the option to create it in the current list I am in which leads me to another question, how do you create a new next action? I can’t seem to create one unless I create it as an inbox item first. Maybe I am missing something.

I now understand the concept of “Force Next” but anything that needs to be explained to someone is just confusing. It’s not a matter of “noob” or “expert”, but usability. How about “Make Actionable”.

Mode: Honestly. I don’t know what it’s for and how it works. I just know that If I leave it in Auto, things seem to work. Not sure what Info. is for

As more people give feedback, you will have many decisions to make, but the most important to me is usability and simplicity. If you create something that is too complex with more bells and whistles needed to achieve productivity, I think you will loose a crowd that understands the simplicity of GTD.

If the goal is to create a GTD app, it should be simple and easy to use just like GTD itself. If your goal is to go beyond GTD and provide other concepts that are more advanced for those who are looking for these features, that is fine as well.

Just remember that the people who love simplicity won’t be found in the forums very often. I may be the exception. The people who love the simplicity of GTD and the app of their choice are usually spending their time getting things done and not talking about how to get things done. :smile:

I will continue to play with GTDNext and see what direction it takes. In the end you can create something that one of the two groups will like. It’s also possible to achieve a balance between GTD simplicity and additional advanced options. It’s just a fine line that is hard to walk.

The only advice I can give is to create what your heart desires and don’t be influenced to change your original goal. Listening to feedback is crucial to success but it can also steer you in the wrong direction. This is true for my advice as well. So if I say stay simple but your goal is to have more complexity, then don’t listen to me and create what you intended to create.

I applaud anyone who is passionate enough to create their own app.

I know I am constantly thinking about it myself. lol

Keep up the good work and enjoy the journey.

#13

You value simplicity, but like ZenOverdone? :stuck_out_tongue_winking_eye:

Seriously, though, my understanding is that the actions-lumped-with-projects thing is a temporary thing related to the early beta build.

Regarding creation of projects, I remember asking James about that, and his reply was that it can’t be a project until it has an action embedded in it, because a single action != project. I agree with you that you should be able to set something up as a project, then add actions, but once you know that, it’s not hard to do. Make the project title, hit enter, enter first action, and you get a project.

It’s funny, because I just got done telling James via private e-mail today that I thought the simplicity of design on GTDNext was one of its selling points. I eventually grew tired of DoIt’s inflexibility, I hated Nirvanna made me waste screen space with fiddly “energy” and “time” options that merely took up my time clicking on, and Zendone’s interface still gives me nightmares.

You’re definitely right that it’s a “to each their own” thing. This one might just not do what you want it to do. :frowning:

#14

I too agree that I think GTDNext is simple yet providing some needed automation that is needed. I think that the BETA will get better and it will ultimately be a very good and simple product.

#15

@Proximo

Good to see you again here. I saw you make some minor remarks a few weeks ago, and then seemed to leave. I honestly did not think you would come back. I did not think this would be your cup of tea.

I agree with @hntopper and @trebro (aka you.know-who?) that GTDNext is quite simple and clean, and it is an early beta with lots of needed polish remaining, but moving ahead quite fast, so I am not worried. But I still think you have some very good points:

  • when looking at a given main list (Next, Waiting etc., or even a project selected from the left menu) I think it would be good if as a default the new task landed on that same list that you are looking at. This makes it easy for newcomers to start using the app on a small scale, and see what is happening, without even having to go into the All Projects section at all (and see how it is really organized).
  • although I personally have no problem understanding how to create a project or a checklist I agree that some people might, and that it might therefore be worthwhile to consider a few “packaged commands” (button etc) for these. One example could be “create project” which (in today’s terminology, Sergio) would do the following three things in one go 1) create a task (2) mark this as Mode/Project, which will make it visible in the left menu, 3) select this project as if it had been clicked. This means you would be looking at an empty project ready to accept new tasks

What I do not entirely agree with is the comment that the flexible hierarchy is a bad thing. I am OK with the four fixed levels I have in Doit, but unlimited gives me even more possiblities. People quite often ask for subprojects and subsubprojects etc (and I sometimes would like this, too), and people also often ask for higher horizons (I have found that I can easily use a plain hierarchy up to the 30 k horizon with no problem at all, perhaps 40 k with some lateral use of tags). All of this you can do if you have more levels, so theer is some tremendous power in this. But it also has the downside that it gets unnecessarily abstract for the average user. All is just “nodes” that can represent anything. I think maybe with the direct buttons mentioned above the app can be made more easy to use by more people, and maybe the term Project can be used generally for all nodes except the lowest level (called Action), but I think it is essential to realize that this is already a niche product. Of course the majority don’t need infinite levels! The majority don’t even need two levels! iOS Reminders and Google tasks etc cover what the majority needs!

In the sense of unlimited hierarchies GTDNext competes with Todoist and MyLifeOrganized, who have both had this from the very outset. Todoist have managed to make their hierarchies quite “sexy” (styling options, font size, colors etc etc) whereas MLO have tried this too, but not managed to make it equally appealing.

What GTDNext also has done, is it has taken its first beta step in the direction of parallel/sequential projects, and already at this stage its flexibillity (“combo” capabilities) rival those of Zendone, whereas both Nirvana and MLO have only the rigid one-or-all-approach. But MLO is still ahead in the sense that you can set any level to parallel/sequential, which means you need not worry how you organize your projects or goals or whatever - you have this feature available at all levels wherever you might need it.

#16

Hmm? Not sure what that was in reference to. Did I do something crazy I’m unaware of?

#17

Not at all. Nothing crazy that I am aware of either.
But you do use a lot of different nicks, don’t you? I wasn’t sure if Proximo recognized you, that’s all. Or maybe I have “over-recognized” you (mixed you up with a few other people)?

#18

I am sure that playing with GTDNext enough, I will find things easier to understand. What we need to remember is that if you need to explain something that should not require explanation, there is an issue there.

I consider myself a geek and have tried hundreds (at least it seems like hundreds) of GTD apps. If I can’t make head or tails to what is going on and what I am doing after 15 minutes of use. I think there is an issue.

Even at early beta, I worry that there are not enough UI elements to make things clear for a first time user. But again, this is beta and that is what we are here for. I am sure things will only get better moving forward and there is a healthy group of GTDers on here to keep things interesting. lol

As for Zendone. Yes, the UI is not great, but it’s getting a complete revamp as mentioned on their blog. But let’s not waste time talking about other apps here. Let’s focus on GTDNext and what it can become.

I do admit that after several days, I still find myself confused and not sure how to make it work and I would imagine I am not the only one that would feel this way. Some of this confusion could be elements that will change completely as the beta makes progress, so I am not going to worry too much about it. I do mention it because that is my job as a beta tester.

Good to see some familiar names around here. It’s been a long time since I jumped into forum discussion and this is mainly due to how busy my life is and my focus on getting things done. :smile:

I am only in here because I really like the passion the GTDNext guys bring to the table and if I can assist in any way, I will be glad to do so.

Sometimes @Folke and I can be a blessing or a curse. Depends on the day. ROFL I do know we are both very open to discussions about GTD and we are willing to learn and change along the way. This is true for many of you on this forum although I can’t recognize you if your name changed. This makes me wonder about you @trebro. Do I know you as a different name from one of the other forums? hmmmmm.

I initially jumped on here and then got really busy which is why I did not make any new post. Now that @Folke is here, I may just let him do all the writing. We both agree on 90% of things but the interesting conversations take place with the other 10%.

Now here is a confession I need to make. The more I use GTD the more flexible and open minded I become. After using it for so many years in a successful way, I have learned that my success is based on adapting and changing along the way. I don’t use GTD the way I did at the beginning or even last year. It’s something I constantly evaluate with the goal to make my life easier. Because of this, I have learned to let some things go.

I don’t use context like DA teaches.
I don’t NEED time and energy like I though I did in the past.

With this in mind, if GTDNext has a twist on a concept or a new idea that would work well for me, I am open to change.

#19

OK @Proximo, let me try this on you - in part it is an explanation of how the beta actually works now (despite its sometimes confusing terminology), and in part it is an explanation of something I find very detrimental and confusing concerning the hierarchies and parallel/sequential behavior. I am not at all sure that you will agree with me - you’ll probably say “Who needs more than just projects and actions, anyway” :slight_smile: But here we go.

Here is how it works now:

If you have managed to set up a project with some actions in it you will notice that there is a green or gray icon on the right. You may also have noticed a checkbox in the edit pane called Force Next. This checkbox and the icon are almost the same thing. They are directly connected. In the Nirvana or Zendone forums the green actions would usually be referred to as parallel and the gray ones sequential. GTDNext allows you to toggle the icon (or the checkbox) to change this status. Only the parallel ones will show on the Next list. You can toggle as much as you want, for any of the actions, except the first one will always be green. In other words we have the perfect parasequential (“combo”) project here, with some parallel, some sequential, in any mix, already implemented in the beta. So far so good. Very impressive. The terminology might benefit from an overhaul, and some of the defaults could be modified a bit, but I won’t get into that here. Basically it is fine; only polish remaining.

Now, suppose you take all those actions, some parallel (can be started now, in any order), some sequential (can only be started after the parallel ones are done), and start to break them down into finer steps (subtasks) (for whatever reason; this is just an example; maybe to see better what doing looks like), then this whole excellent parasequential setup vanishes into thin air and goes totally berserk. All of a sudden subtasks from all those former actions (now probably called subprojects) will start showing up on the next list -  even from the “sequential” ones that cannot be started yet. A totally different behavior. As if they became parallel just because I broke them down into smaller steps. Extremely confusing. And there is no way to turn these former sequential entities off, not even manually, to stop their subtasks from appearing immediately.

I have suggested that the existing parasequential approach should be implemented generally at all hierarchical levels for maximum uniformity and simplicity (they are all just “nodes” anyway; can represent anything) - or at least allow all such “nodes” to be manually inactivated/activated at all levels).

This is one of the main issues discussed in this and some other related threads.

#20

@Folke I can see the issue here. I think I understand the suggestion you are making which will allow you to simply toggle the option regardless of the sub-level it’s in. Maybe I am wrong here, but this would allow sub-projects to also be sequential, parallel, or a combination of the two while ignoring the options for other tasks/sub-tasks in the project itself. I think I just got a headache, and I am not sure I even understood the suggestion you are making to correct the issue.

Personally, I won’t use sub-projects very often if at all. That’s because I choose to keep my workflow simple and I am still able to clearly define what doing looks like. This may not be true for everyone which is why I always supported the idea of sub-projects. Making this all work with the flexibility of sequential and parallel options can be a challenge.