Your Blog Post on Parallel/Sequential

problem Resolved
#1

I am disappointed:

  • you wrongly claim that in GTD there can only be one next action in each project. I know this is a common myth among those who learned GTD by hearsay, but the fact that it is common is no excuse for a serious GTD developer to use it as a methodological foundation. Please read the first book again (ch 3 / next actions / the basics), and amend your analysis accordingly.
  • you persist in using totally different approaches for actions and subprojects when it comes to parallel/sequential. This is inconsistent for no good reason and gives rise to major confusion and an ugly interface with too many difficult terms and checkboxes
  • you persist in using the word “forced” for the most “natural” thing that all normal app users take for granted. When normal non-scientists enter a task on a list I can tell you they expect it to stay visible there, not disappear. But you want them to explicitly “force” it to stay visible. Really twisted.
  • to make it even worse you represent this “forced” condition visually in totally different ways for different types of actions (sometimes green, sometimes a red smudge), and you even give it a totally different meaning for projects than for actions. And the icon for it even looks like a Next action icon! A real mess.
  • you have no way of pre-marking actions as parallel in still-sequential subprojects (because the “Forced Next” checkbox hardwires them straight to its currently active lists, even if the subproject they sit in is sequentially on hold)

You can solve all this is a gazillion different ways, of course, and it is your app, not mine. So go right ahead with whatever you want.You can even keep it like this if you like it so much. (But I’ll bet you this will come back and bite you sooner than you think.)

The simplest solution I have for you is this:

  • get rid of the Forced Next checkbox completely
  • use the Sequential checkbox consistently at all levels (actions, too)
  • introduce a consistent graphical representation for an item’s sequential/parallel status.

But maybe you do not want it neat and clean and simple and powerful, not when you can make it look like the morning after a nuclear rocket science fest ;-)?

#2

Hi Folke,
Thank you for the time you’ve spent analyzing thoroughly my post. I knew you’ll like it :slight_smile:
I’ll work on myself to make less stupid and lame decisions in future, I promise :slight_smile:

Sorry, I won’t comment all the stuff you’ve written here. I’ll just answer the first one, about the single next action.

I agree I have spoken not correctly or maybe not clearly enough that the project may have only one next action. Of course it may have many and this is exactly how it is implemented in GTDNext.

But lets look closer at the Chapter 3 of the book, the basics section. What it says is there may be a Next action in each Moving Part of the project.

What is the interpretation of the Moving part and how one can implement that in GTDNext?
For me the most logical way is through the sub-projects. And this is exactly how sub-projects work in GTDNext - each one has its own Next Action.

But of course, the real project’s logic may go beyond that limit of one Next action per project/sub-project, and that is why we have the Force Next option. It allows to mark any number of actions as Next. (I agree, and I guess I’ve told already about it, it sounds not well. But so far it is the most descriptive name we’ve came up with.)

And we are planning to move even further. (Planned to talk about it in the next post, but will describe it here in short)

Working with my real projects on GTDNext I noticed I often group some actions/projects into a single Project.

Sometimes it is not the project, actually, but just a container for separate Actions.
Sometimes it’s a huge project, like “GTDNext project” in my outline. And it is not the Project in the GTD sense, as it is virtually infinite and can not be assigned any measurable goals.

What it is - is a container for real Projects and Actions. And we do not have a way to treat these containers in current version of GTDNext.
That is why we are planning to add another node type, named Container (or you may suggest a better name).

The items in the container will behave the same way as if the were in the top of the Projects/Actions hierarchy (all actions are the Next actions, cheers!).

Of course the system evolves with time, and maybe someday we will rearrange the way the Next actions work, but so far it seems fine for us and many of our users, providing a good balance between convenience and flexibility.

Btw, If you or anyone have a concrete example of a project or workflow you can’t handle with the current GTDNext functionality, please provide it to us, so we can find the way to resolve it.

Good Luck,
Sergio

#3

Hi @sergio

Thanks for the hard and ingenuous effort you are putting into GTDNext. And in my previous post I forgot to reiterate how fundamentally important and correct your decision is to relate the parallel/sequential settings to the siblings, not the children. This is the whole key to your great potential! But as we have seen we also have some minor differences.

I use such containers all the time. I use them as AoR single action containers. Other people use them for “books to read”, “gardening projects” or “fun stuff”, whatever. You do not need a special container type for these!. All you need to do is make sure that the app does not hide the things people put in them unless people really decide to.

To explain why no separate container type is necessary, please bear with me and let me begin by first explaining how David Allen sees the typical project for a normal person. A normal DA project goes like this: You create a project name, say “Build a garden”, and then you must also write at least one action that you will actually do to keep the project moving, say “Read gardening magazine”. That’s the minimum - to always have at least one action listed per project, and you should also write down any other actions that are also possible now, but no more. And people do not think even a second further than that!. A typical GTD project is “played by ear”, a few actions at a time, with a minimum of planning. You create new actions as you go. There is no “project plan”, but there is a project.

This means, using our terminology, in a normal DA project you have just a rare few actions defined, all implicitly “parallel” (can be done in any order), and no further actions exist in writing anywhere.

Similarly, in your general “container” that you mentioned that you might want to implement, I assume you would have mainly parallel items, too?

In addition, there is no doubt that you also need sequential capabilities, particularly for people (like us) who sometimes like to do some serious long-term planning of large projects. We then need the ability to “draw the line” - i.e. under each parent to split the items into two different categories:

  • will go first, all at once “in parallel”
  • will go afterwards, sequentially, one at a time

The question is why you would need separate types of containers for any of this, when you can have one single container type that can handle it all?

The solution is simple. Let items be assumed to be “normal” (parallel) unless deliberately defined as sequential. That’s safe. But in the outline mode have a default that makes new actions sequential if they are created (with Enter) from a sequential item, and another default that makes dragged items sequential if they are placed after a sequential item. One single, simple solution that works super efficiently for all use cases, and will never cause anything to disappear.

I have a suspicion that you are afraid that people will not notice your powerful capabilities unless you physically force their actions to be sequential (hidden) by default. But please don’t be afraid of people not noticing. People will have heard from the buzz, and from your own marketing, how versatile and powerful your app is in this regard, and those who want the sequential functionality will find out easily enough how to actually do it - just set the first desired sequential action in the project to sequential, and the rest will follow automatically. So simple. It is more important that you make the solution smooth for both power users and novices, with no nasty surprises such as tasks that disappear if you drag them onto a project etc - no one will put up with that. (And having different container types also turns people off; Nirvana has that).

#4

I’m not sure this is the best example. I certainly don’t want 10 or 20 books all marked as next actions to clutter up my next action list. Personally I view that more of a reference list, best placed in one of our info nodes.

However I think your point is that there are times and cases where projects should support having all actions available for the next action list. Our view (which may or may not coincide with DA or with yours) is that you really only can physically do one item at a time. So that is how we are setup by default. In projects where it doesn’t matter which item you choose to pick first, we do have a mechanism to allow other actions to be selected. And another to make that the default for all new items added. This in our mind is better than what other apps can do. I understand you don’t agree with this approach.

I’m not sure I agree with this statement. I’m not sure why they would all be “implicitly parallel” Based on what I see and experience myself most people either plan things out in detail from the start. Or if they don’t and just add actions here and there the ones they add are rarely parallel in nature. When they add items it’s usually just one or two items and I personally think they are usually sequential. Of course if they are not we have ways to handle this case.

I’ll never rule anything out, but right now I don’t see a reason to make this change.

Can anyone out there show me a project that can’t currently be planned in GTDNext? Right now, with our available features, I think we have covered the bases pretty well. I totally understand that Folke would like the default to be the reverse of what we currently have and has issues with our terminology.

For those of you following the thread, but have not so far contributed.

Please let us know where you stand on this. Is there something you can’t do today with the current feature set? Is the terminology confusing? So much so that it needs to be changed?

@Folke As always, thanks so much for your input and for the most part :slight_smile: keeping things positive and agreeing while without being disagreeable. We all want this to be a positive place to exchange ideas.

Thanks!
James

#5

You do not need to have two types of containers (as @sergio announced - one type for predominantly “sequential” projects and one for predominantly “parallel” projects). One type is enough. Wouldn’t you at least agree that one is a smaller number and simpler at least in that sense?

Will only one type do well enough for both purposes? Yes, because it will never really actually matter what type it is (sequential or parallel) PROVIDED there are a few really simple and realistic defaults:

  • Whenever (in the outline view) a task is created or dragged deliberately to a specific position within a project its sequential/parallel setting should simply mimic that of the action immediately before it. (This is in some ways similar to the automatic adaptation to the indent levels).
  • When items are “tossed” onto a project name (e.g. a project name chosen in a menu, without the action being deliberately placed in a specific position within the project) it should be set to “parallel” and be placed first in the project.

Why are these defaults good?

The first default is good because people usually tend to keep their project actions in a roughly chronological order, if possible. In a real proejct, one that has a few actions that can be done first of all, people usually keep these few at the top, and the rest following as a long sequential tail. If someone creates (or drags) an action in among the first lot it is almost certain that they intend it to be parallel, too. Similarly, if they create/drag an action in among the tail of sequential actions they normally intend it to be sequential.

If the “project” is just a “task collection” (not actually a completable project) then presumably all the actions are parallel, and the default will still work perfectly.

The second default (tossed actions to be parallel) is necessary to reduce mistakes and confusion. Example: Otherwise, if someone is looking at the Next Actions list and sees an action that really should belong in one of the projects, and therefore declares the action as belonging there (“tosses” the action there without placing it, e.g. using the left menu), it would suddenly and totally DISAPPEAR from the Next Actions list. What a terrible shock for a newcomer to GTDNext! And what a terrible annoyance for an experienced GTDNext user.

(Besides, if you “toss” a task and it lands at the end of the invisible sequence, this placement will almost never be exactly right and will require some adjustment, wheres chances are quite high that the action was something you had forgotten and want to add last minutes to the top, so if it lands there all visible there is nothing you need to correct.)

So that’s that. One “type” of project handle all use cases and all users (new and experienced).

EDIT. I might add that I know that the term “parallel” is not the best of terms for what we are discussing. I think the term is mainly used by Nirvana and Omnifocus, but not by MyLifeOrganized and others. In my opinion it is a misleading term, probably borrowed from project management. Only seldom in a personal situation (GTD) are “parallel” tasks intended to be literally executed simultaneously (in parallel). No way; why make things difficult. Usually they are to be done one a time but they can be done in any order (random sequence) - in other words, there is no sequential dependency between them that makes it necessary to do one before the other. I am fine with calling the “parallel” tasks just “normal” tasks (tasks without dependencies).

#6

@James, right now i can do everything i would like to do with GTDNext.

The checkboxes for Sequential and Force Next are not intuitive though. For example Sequential only works on projects/subprojects, why is the checkbox even rendered for actions if it is irrelevant there?

Personaly i like the sequential/parallel defaults as they are now, as they fit to my way of thinking.
But it takes a little getting used to, and i can see that there might be use cases that consistently work against these defaults.

Perhaps the ability to configure this default as a user would be a way to go?

#7

Many situations can now be handled, but not all:

  • complete: We have always been able to mix any number of normal (“parallel/any-order”) and sequentially dependent (“sequential”) next actions in an active project using the Forced Next toggle. Works :slight_smile:
    (Opinion: The term Forced sounds very artificial for something that is perfectly normal. Opinion 2: The sequential default is dangerous. Opinion 3: the term Active for Next action sounds strange.)
  • complete: Recently you have added the capability to “sequentialize” not only next actions but also other actions, e.g. other people’s next actions that we are waiting for, and scheduled actions and someday actions. Works :slight_smile:
    (Opinion: the term forced Next sounds even more inappropriate when it refers to Waiting, Someday and other non-Next actions)
  • complete: You have also added the capability to sequentialize subprojects. This is done using a separate checkbox called Sequential. Works :slight_smile:
    (Opinion: You have chosen an excellent term for this, namely Sequential. Opinion 2: But why have two checkboxes with two different names for something that is essentially the same kind of thing? Opinion 3: We need a visual indication for those subprojects that have been marked Sequential.)
    (There is a possible bug with how the Sequential setting affects different projects differently, or is it intentional? http://forum.gtdnext.com/t/another-project-inconsistency)
  • not complete: in a sequentially dependent subproject (marked Sequential) there is currently no way to mark the actions that will go active at the same time “in parallel” and which ones will be sequentially dependent upon those initial actions. This limits the ability to plan projects for automated task progression (which is one of the main attractions for many people). This limitation is due to the fact that the Forced Next toggle hardwires the actions straight to the active list even though the whole subproject is inactive (sequentially dependent).
    (Opinion: This probably would not happen if the Sequential switch could be used for actions in the same way as for subprojects. Opinion 2. Actually you could get rid of Forced Next and just use the Sequential/Normal checkbox. Opinion 3: You need a third visual indication level, e.g. gray-YELLOW-green, to show those tasks or subprojects that are non-sequential within a sequentially inactivated subproject (for pre-planning purposes).

So, apart from opinions and preferences and psychology and convenience etc, the only thing that is objectively missing now is the pre-planning (pre-marking) capability (and the inherent automation capability that comes with it), which I would have assumed to be principal purpose of even starting to deploy the kind of advanced hierarchical and sequentialization features we are talking about here.
(Opinion: You could definitely streamline the whole related UI and make it much more accessible to many more people.)

Some Outstanding Questions
#8

Let me take you all to Proximo World. In Proximo world, a GTD app uses the core fundamentals and is so simple in it’s implementation, that no training or explanations are needed. GTD is a straight forward and simple methodology that continues to have apps created around the concept, but in their own interpretations of what GTD is.

I keep reading the threads and I even keep playing with the app to see how things are going. I simply don’t have that much time to spend on deep analysis for something that should not require it.

It is possible to create a straight forward GTD app that covers the methodology and requires no training or explanation on how to use it. As @Folke mentioned, the idea that a project can only have one next action is wrong. Some apps don’t recognize the importance and simplicity of sub-task and why they are so helpful when structuring your projects. Some apps must be explained that sequential and parallel task should co-exist in a project, although the logic is so simple.

Keep up the good work, but In my opinion, if you are having lots of discussion on how to use a GTD app, it’s probably too complex and not clearly designed from a user perspective.

I admire anyone who is willing to build something and I know it’s impossible to please everyone in the process. I have a vision of creating a GTD app not based on how Proximo likes to do things, but on the GTD methodology at it’s core. This can produce various flavors of apps, but none of them should be difficult to use or require explanation. At this point, you are simply catering to different style preferences and not interpreting how GTD works. Do you prefer context based list, or core lists with context filters? Things like this can produce different flavors of a GTD app, but they should all be super easy to use and understand.

Keep it up, Just because I don’t post much anymore does not mean I am not interested on the progress. I am simply very busy with my professional career at the moment and don’t have a lot of “Free” time to spend outside the office. Playing Little Big Planet 2 with my daughter takes a higher priority for me than work during the weekends. :smile:

I keep looking for the simplicity a GTD app deserves, which is why I am usually disappointed.

1 Like
#9

@Proximo, i really love your vision of a GTD app that is both simple and intuitive.
But i am really not sure of this statement:

It is possible to create a straight forward GTD app that covers the methodology and requires no training or explanation on how to use it.

If that really is the case, one of the gazillion GTD implementations out there should have nailed it by now.
Personally i got a hunch, that implementing GTD is not as straight forward as it seems to be.

#10

@Camelorn

You forgot the first step of reading my post. You need to enter Proximo World. LOL

You are correct. In the real world, this would never happen because everyone interprets things differently and this is were the challenge sets in. I do believe most people over complicate GTD and productivity in general.

So…

In Proximo World, If someone already understands GTD, the app would require no training or explanation on how to use it. This could be partially true in the real world, except that many understand GTD differently, which brings us back to the real world. :frowning:

1 Like
#11

@Proximo
Understood, i really forgot about that premise when quoting your sentence.
Just shows that quotes without propper context can foster misunderstanding.
Luckily our misunderstanding here has been a rather mild one.

#12

For some odd reason @Proximo this reminds me of a favorite quote from the movie Gladiator when Lucilla says, “This is a pleasant fiction, is it not?” :smile:

Since you mention you don’t use the app all that often, I thought I’d mention here that we do allow users to specify more than one next action per project. The discussions have been more around should we change the default to make all actions show up as next actions. We prefer to have only one action show by default. Everyone seems to easily get how to add another one. No training issue here.

That’s an interesting perspective. I suppose it could be true sometimes, but in my experience working with developers on a lot of apps over the years I haven’t found this to be true. Creating great software, easy to use software doesn’t just happen. It takes time and a lot of discussion to make it “seem” simple.

It often doesn’t get designed that way from the beginning. In some ways we let you all in on that development process, because some users find it interesting and they want to be a part of the process. We find it helpful as well to hear from “real” users but by doing so, users sometimes get a glimpse “behind the curtain” and it takes a little of the magic away.

As it should be Proximo! Thanks for stopping by!

1 Like
#13

I agree with @Proximo’s sentiment about simplicity. Even if total perfection perhaps can never be attained it is always worth striving for - striving hard for, and perhaps reaching or touching. Even Apple seem to agree. Before the launch of iOS 7, they wrote:

Simplicity is actually quite complicated

Simplicity is often equated with minimalism. Yet true simplicity is so much more than just the absence of clutter or the removal of decoration. It’s about offering up the right things, in the right place, right when you need them. It’s about bringing order to complexity. And it’s about making something that always seems to “just work.” When you pick something up for the first time and already know how to do the things you want to do, that’s simplicity.

1 Like
#14

Simplicity is a difficult thing to pull of while at the same time making something useful. ROFL.

I admire those who go out to build something (app) of their own.

2 Likes
#15

That is very true. The key point for me building an application is not the simplicity but the balance between simplicity and the flexibility. And that’s what we are trying to achieve building GTDNext.

1 Like
#16

Let me revert to the topic of the original post.

Are the differences then intended to provide some kind of flexibility?

For example, the fact that there is no way of seeing in the outline view which projects are marked sequential, whereas you can see more easily which actions are marked sequential (non-forced)? The fact that there are different checkboxes to use? The fact that the default settings are different? Etc. Will these differences provide some flexibility for future versions or different kinds of users? How? Or is it just that they are still in the backlog to get fixed?

Love your efforts. Hope you don’t mind some candid feedback.

#17

Hi @Folke,

About the difference between default parallel Projects and sequential Actions, I don’t see any inconsistency in that. The reason the Projects are parallel by default and Actions are not is in their own nature. Please, re-read the James’s post above for some argumentation.
Besides that, parallel actions by default will quickly lead users to be overwhelmed by the number of the Next actions flooding the Next Action List.

So, No, we are not going to make actions parallel by default.

However, as I’ve said already, there may be some situations, where you need the actions to be parallel in some kind of projects. We are still exploring the options for implementing that, and one of the options is the new node type - Container (or Collection).
But that’s up to user to decide whether to enable this option and on what project.

That is the decision we’ve made and it is not going to be changed.

We love any feedback! The only appeal I have to you is to take into an account already discussed items, not to get back over and over again. Thank you!

1 Like
#18

@sergio

I certainly do not want to reiterate old discussions if it can be avoided. But sometimes some of the old things are part of something bigger that has not been answered.

Yes, I know that you like the sequential default for actions but parallel for subprojects. And I respect that even if I disagree with it. Whether you call this a difference or an inconsistency is a matter of taste, I guess. And it is perfectly possible to solve the ensuing problems whichever way you do it (and you can even avoid the problem completely, as I have also outlined to you). But, at the end of the day, if you allow people the option to set the default to parallel, as you seem to have planned, then that should do for most of us - as long as you can set selected things to sequential within those parallel containers.

But there’s more. Defaults are not all.

Why do you not indicate visually in the outline which projects have been set to sequential? This is an inconsistency (aka difference) that I cannot recall having ever being answered satisfactorily. Why? It is critical to our ability to review our projects that we can see which subprojects will start in what order. So why is this “sequential/parallel status” only visible for actions, but not for subprojects?

And why on earth are there two different checkboxes with two totally different names? That is another “thing” that has never been properly answered. Why should a sequential subproject be called sequential but a sequential action be called “non-forced-next”? (And why non-forced-Next if it is in fact a non-forced-Waiting and so on?). I think inconsistency is a correct word for all this.

I could understand and respect it if you said that all these things are in the backlog, but it seems that you guys are trying to pretend that the product is somehow finished and that fundamental issues such as these are beyond questioning. This is something I find hard to understand.

#19

About the sequential indicator.
I can always see if the project sequential, by looking at it’s actions’ Next indicators.
But I agree we need a special indication for that in the outline view and we planned one.

About the action’s “inconsistencies”. It is very simple.
Action may be in one of two states: Next or non-Next.
The action’s Next state is clearly visible through it’s indicator (N).
The Next state may be set to the Action automatically (according to the app logic and settings) and manually (Forced).
That’s it.

Of course one can draw the “non-forced-next”, “non-forced-Waiting”, “apple-egged” or whatever terms here but that has nothing to do with the consistency of the project or it’s logic.

#20

Great, @sergio :slight_smile:

I hope you decide to have the same visual indicator for this as for the actions :wink:

After all, it will indicate the same thing - that this item is either to be done

  • “first, together” or
  • “afterwards, one at a time”

I would like to caution you that I think you may perhaps be mixing up two different things:

One is the fact that some actions are “listed”, others are not. The “listed” items need not necessarily be listed on the Next list. They can also be on the Waiting For list, the Someday list or on the Calendar or incubating in the Tickler file (aka Scheduled). You are right that it is already possible to see which actions are “listed” and which ones are not.

For some reason the indication looks different, though. For “listed” Next actions the icon is green. For “listed” actions of other types the icon is gray with a red “decor” in the top left corner. (And the icon is still shaped like a Next action even though it is not a Next action).

Perhaps it has nothing to do with the logic. But it would be easier to see the clear and simple logic if all sequential items were consistently called sequential and had the same checkbox and the same visual indicator.