Desired Feature: Project Structure

09-21-2013, 06:56 AM

With this post I aim to reach two categories of people. One is GTD app developers, who I wish to encourage to implement the types of features described here. The other is fellow users who might be able to point me in the direction of apps that already have all this.

General Background

The periodical review of your lists is a fundamental part of GTD. One of the main purposes of these reviews is to go through and verify that you have everything that needs to be done listed, that nothing is missing, that everything is properly categorized, and that old entries are removed or modified. Another important purpose if the review is to genuinely understand and adjust, and build an intuitive feel for, what the totality is all about, what is important, and how the various parts fit in with your overall goals.

Projects are important in GTD, because even the simplest little task with more than one action step in it is called a project. And projects can also be very large and contain lots of actions. Often some tasks need to be completed before others can be started. And in real life, projects are often not entirely independent of each other, but rather a bit inter-dependent both in terms of certain actions being fundamental for multiple projects and in terms of having certain overall goals or purposes.

Some simple but significant features to the fundamental project structure offerd in most apps would be immensely useful, making reviews much simpler and accurate, and making the work in between reviews, and ongoing task selection on a daily basis, so very much simpler.

Feature: Hierarchies (subprojects)

Being able to arrange projects and tasks hierarchically brings overview. The list of projects (usually on the left) can be kept as short and overviewable as you like it. Each project, at any of its levels, can be kept as short and overviewable as you want it. You can specify your projects down to the tiniest little action without thereby creating a big daunting mess. And you can consistently filter tasks by tags (i.e. contexts, labels etc).

There is nothing novel or strange about this, nor is it complicated for the user. This is how we all normally organize stuff in Windows etc. You make your hierarchies as deep or as flat as you want them - whatever serves your purposes and your personality and the particular project best.

Feature: Multiple parents

Much of what we need to do serves more purposes than just one. If we plan to buy a good scanner, this may be part of an overall refurbishing plan for the office, but the scanner may also be needed for a particular photo/advertising project we are about to start, and for a litigation project where we need to capture in electronic format some heavy legal documents that we expect to get in the mail next week.

By being able to list "Procure scanning equipment" (which itself is a task or subproject) in all those projects for which the scanner is essential, we make our review work so much simpler and less worrisome. We need not make notes about these interrelationships. We need not feel anxious that something is overlooked. We need not switch back and forth between different projects to make sure all is covered. We can see, wherever we need to see it, that buying the scanner is necessary for the project to succeed.

The very same multi-parent capability is a powerful solution to another extremely common situation. GTD (and most other methodologies) suggest that we batch things up and do more than one thing when in a given context. Sometimes these contexts need to be deliberately planned and set up; they do not just "happen". The multi-parent capability allows us to create little "batch" (or "agenda") type projects such as "Meeting with CFO" - about all kinds of things that belong to different projects, or "Trip to outlet center X" - to buy things for many different projects. And then we can also add little "context setup" actions to that little project, such as book a van, book a conference room etc.

Feature: Semi-dependent task flow within projects

Some apps have separate project types, parallel ("shotgun") and sequential ("bead of pearls"), but it is simpler and better to have just one universal project type and make it realistic enough to serve both purposes. What we need is to see all our true Next actions on the Next list (and true Waiting actions on the Waiting list), while keeping the rest (the not-yet-relevant actions) well hidden within their project until it is their turn. And we want the automatic progression sometimes offered as a strictly sequential project type.

The solution is simple: Make the "sequential" container a built-in part of an overall "parallel" project. Let the sequential container feed tasks one by one into the parallel main container when this gets empty. All actions in the parallel container would be visible on the Next and Waiting For lists, but all actions in the sequential (subsequent) container would be hidden. Allow the user to manually move actions between the parallel and the sequential container as required. Default placement for new tasks should be the parallel (active) section (to avoid being overlooked if you forget to place it in its correct position.)

This gives us all existing capabilities of both project types, and adds the flexibility to manually adjust what tasks are currently active (in parallel; often more than just one) and which ones are subsequent and in what sequential order. It is not only more powerful, it is also easier for new users to understand (no need to select a project type).

In addition, this very simple task flow mechanism is actually all we really ever need even for more complex pre-sequencing of the task flow, because subprojects can be made use of for creating sub-suites of tasks that fit into the simple overall structure of its parent project.

Summary

All this might sound a bit abstract to some, but things are easier to see and understand in real life than it is to understand a theoretical description of them. These features typically can be implemented with virtually no impact at all on the existing UI for the novice user, but increases the app's power tremendously for those users who have reached the limit of what they can use the app for. Basically, for the UI, the subtle difference with these enhancements is that you can drag and drop (move) things a bit more freely - but that almost invisible difference makes a world of difference in power and usefulness.

Comment

I think this has been addressed by DA in his last book where he said that the while it would be nice to cross reference every task to a project, it would probably be more trouble than it was worth. You would spend more time on updating your system than necessary, although I would imagine that depends on the individual. Some people might find it more rewarding to add the extra details.

... while it would be nice to cross reference every task to a project, it would probably be more trouble than it was worth.

I think there is a misunderstanding here. All three features are simple and virtually invisible - and would not require any action at all on the part of the user except for those projects where he/she needs these features for better overview and control, or to reduce the strain on his/her memory:

Hierarchies: By all means, keep projects as flat as you want - several pages of tasks, if you like, but if on occasion you would like to group related tasks under a single line (a subproject line listed within the project) you would have the means to do so without either cluttering your main project list or losing sight of it from within the project.

Multiple parents: By all means, rely on your memory whenever you can, but if on occasion you notice a tendency to forget or overlook the fact that some steps in a project are actually vital to another project as well, then you would have the means to make sure that you do not overlook this when looking from that other project's point of view. Also, it would relieve you of being forced to make silly-rigid classification decisions such as whether a particular photo shoot is best considered as belonging to the brochure project, the web shop project or the exhibition project; instead, you have the means to see it from as many of those projects as you want - if you think it is worth the trouble (say, shift-drag the subproject over to an additional project as well). And, important, too, in my opinion, although a slightly different use case, is where you have little "batch projects" (context based projects), such as a plan to hire a van and do certain heavy errands that belong to totally different projects all at once. This is a kind of situation I encounter all the time, often with meetings, conferences etc. (Using temporary special tags etc is usually not convenient enough.)

Semi-dependent task flow: By all means, keep your tasks all active at once if you like (parallel), or have them made active one action at a time (sequential-automatic; available in some apps), but if you ever have a project where there are more than just one action perfectly relevant to see right now on your Next and Waiting For lists, but far from all actions in the project, then you will appreciate being able to handle this more realistically and still have a degree of automation that guarantees that you never see less than one action.

Comment

I agree with the other replies in this thread, but thought I should say that Omnifocus can do most of what you want. However, it's the app that launched a thousand posts. There are more reviews, set-up guides, tweaks, et cetera about Omnifocus than you can imagine, which should tell you something. It's a decent program, but it is no more essential for gtd than a rhinestone-studded day planner. Be careful what you wish for- you might get it.

I think most productivity programs, even the good ones, can become monsters if you let them.

I agree that there are lots of programs with half-baked solutions built in, which add complication and do not really solve anything. And there are also examples of brilliant solutions - things that are easy to understand and use, while perhaps having been very difficult to design. Good design takes a focused mind. And it is always more difficult for us humans to discuss creations of the mind than to experience creations that we can see and touch in real life.

Let us assume (for argument's sake) that we all find the paper clip to be a "simple" thing. Now, imagine a situation where you would want to explain, in words only, the purpose and design of the paper clip to a person who has never seen one. I'll bet you it would sound very complicated ("boat-shape", "bent threads running in parallel along the sides" etc). And it would sound even more outlandish if the other person has never contemplated the need or possibility of having a specialized solution just for making sheets of paper stick together, separate from solutions for making things in general stick together, for which you can use well-proven solutions such as glue, screws etc. ("what's so important about papers"). Conclusion: The paper clip is an overcomplicated solution to a non-existing problem

Originally posted by bcmyers2112

The problem I have with the concept of having software automatically "promote" items into next actions is that life just throws too many monkey wrenches into even the simplest of projects.

Actually, I agree that automation as such is not necessary (for me), but it is popular and handy. I currently use an app that has strict sequential promotion (one at a time) and I do not use it; I use an ugly workaround instead for keeping Next and Waiting project actions off my main lists until it is their turn. But I can vouch for the popularity of the automatic feature, and I see it requested often in forums of apps that do not have it. The reason I do not use it is because only one single action shows up on the Next list. I usually have a few more. The alternative is the "parallel" project type (usually the one and only kind in most apps) where absolutely everything gets dumped on your Next and Waiting lists. I have never seen an app that has a solid, simple, manual solution for selecting precisely those few tasks that should show up on those lists. So my idea of having a simple combined "parasequential" project, as complicated as it may perhaps sound here, seems to be something that is equally simple as the existing solutions to use as either a full parallel or as a one-by-one auto-sequential, while allowing people like me to have exactly the right actions listed in Next and Waiting without using ugly workarounds. To me, this seems like a simpler solution than any other I have either seen implemented or heard requested.

I seem to have forgotten to mention the left menu

Much of the disagreement (or misunderstanding) in this thread might have its roots in the fact that I used the word "project" in a generalized sense. I think a more correct expression would have been "the elements in the left menu". Most GTD apps have a list called "Projects" in the left menu. Some people say they have several hundred projects there. I don't. But a few hundred is not necessarily an unrealistic number if you have every GTD micro-project (multi-step action) listed there. It's just that I cannot bear having so many things on my left menu. I like to cluster them, and use "subs" (a hierarchy), in order to make the left menu meaningful. The things on my left menu ("project list") are often larger projects (still true projects, though; completable etc). I also use some "projects" as AoR folders that hold a number of GTD micro-projects that belong to a certain area ("role"). In some cases the items on my left menu are perhaps best described as goals (or even visions or a "general direction" such as "expand into Europe"), specified in terms of what actions and smaller projects that I need to do for that purpose in the foreseeable future, but perhaps with an uncertain overall outcome or finishing line.

Personally I am not overly concerned with words. I am perfectly happy for my app to call all these things "projects". I want to be able to stack them up into hierarchies, that's all. I have seen apps that have special features for areas, goals, subtasks etc, but I have usually found these implementations to be half-baked, rigid and overcomplicated, with different rules and limitations for each of these. For me, and many others, I am sure, it would be simpler and more powerful to just be able to have actions and "projects", and be allowed to arrange these "projects" hierarchically as required, regardless of what would be the correct term for what they actually represent.

Finally, back to the example with the scanner. A simple task or "GTD micro-project" such as buying a scanner is nothing I want to see on my left menu. So under which heading do I put it? Assuming I have this serious court settlement to deal with, then that would definitely be one of the main things on my left menu (and the scanner will be needed there). Also the new product launch (where the scanner will also be needed). And I would also have a heading for the current total modernization of my office (of which the scanner is a part). Those three would be among the "projects" on my left menu. The scanner is just one of a hundreds of little things. So where do I put it? To me, that's complicated. It could go anywhere, so how do I choose, and how can I ensure I won't overlook it? So why not keep it simple - let me put it under as few or as many headings as I like. That seems so much simpler than either having to remember these relationships, or having to review the whole list to temporarily grasp it all again, or having to maintain comments, or defining new tags and remembering to filter for those every so often. Again, I see this as pure simplicity that only sounds complicated when you debate it in words.

And, as I already said, but maybe you do not agree, the multiple-parent capability (say, ctrl-drag the item into yet another project) is probably the simplest and most intuitive way possible for being able to prepare in advance a number of carefully selected agenda items or related errands etc. and getting them done at the same time. Using, say, temporary tags for these handpicked items for this particular occasion is so much more complicated both to do and to see in your lists. Having a separate "project" for them is much easier, and as an extra bonus (depending on the software) you might be able to simply "star" the whole "errand project" or "meeting project" when the day comes, without having all the individual items cluttering up your "starred" (Do Now) list.

Comment

The problem I have with the concept of having software automatically "promote" items into next actions is that life just throws too many monkey wrenches into even the simplest of projects.

Depends a lot on your initial project planning and type of projects. For me I usually spend time up front defining projects very well. Once I do so it is very rare that anything will change the order or sequence of next actions. Sometimes my projects span years or decades or lifetimes and yet I can usually still work off the original project plan if I did it right the first time. The projects that do not work that way are ones i really didn't follow the natural planning model on very well.

Comment

I agree that IQTELL and many other apps are overcomplicated. I believe one reason for this is that developers tend to pack in too many partial (lame; half-baked; inadequate) features, rather than think it through thoroughly and have a rare few "elegant" (versatile; powerful) features.

Yes, I like Nirvana's simplicity, but even Nirvana has its shortcomings. Some of these are where they have made things unnecessarily overcomplicated, from my perspective, and thereby have also limited the versatility of the product.

For example, relating to this thread, they actually confuse novice users and force us to choose between making the project parallel (totally parallel) or automatic sequential (one action at a time only). Why not keep it simple; just simply projects; the project being fundamentally parallel, just as people are used to, but allowing users to drag not-yet-possible actions to the "rear" sequential section and auto-feed sequentially from there (instead of having an entirely separate project type for this). Not only would novice users be less confused, but seasoned users would also have the ability to select exactly which actions (often more than just one, but far from all) that will show up on the Next and Waiting lists.

I have never tried Omnifocus (as I do not have a Mac) but I have gotten the impression that they have the same split approach as Nirvana does. Now, where is the simplicity in that? I think it is overcomplicated even to begin with, and even more so when you consider that you then have to find your own workarounds for the very common and real case that you have some tasks, more than one, but not all, that you need to see on your Next and Waiting lists.

Another example of overcomplication is Doit. They have subtasks, tasks, projects and goals - four different "features" with different capabilities, and very difficult to combine. And still no way for even the very basic GTD need to "hide" from Next/Waiting those actions that are not yet relevant.

Comment

I have never tried Omnifocus (as I do not have a Mac) but I have gotten the impression that they have the same split approach as Nirvana does. Now, where is the simplicity in that? I think it is overcomplicated even to begin with, and even more so when you consider that you then have to find your own workarounds for the very common and real case that you have some tasks, more than one, but not all, that you need to see on your Next and Waiting lists.

Omnifocus allows complete outlining within projects. Both projects and groupings within projects can be made sequential or parallel. It's a powerful, easily misused feature, but OmniGroup does it right, IMHO.

Comment

Omnifocus allows complete outlining within projects. Both projects and groupings within projects can be made sequential or parallel. It's a powerful, easily misused feature, but OmniGroup does it right, IMHO.

Wow. Omnifocus really seems to be a well-rounded package. It is also very reasonably priced, and seems to have lots of users. To me, as an outsider, it is astonishing that they elect not to earn money from Windows users as well - that would seem to be low hanging fruit.

Originally posted by bcmyers2112

I know you said you don't like tags ...

Sorry. That is not what I meant. I love tags and wish I could use them even more (but that's a possible topic for another thread). What I meant earlier was that in the case of "context based" small projects, such as hiring a van and picking up various heavy things for various projects, simply creating a project called "Pickups with van" would be the simplest and most intuitive way for me personally as a user to deal with it. Of course I could instead create a short-lived special tag for these "van pickup" tasks, or use comments in the notes, or rely on my memory, or reexamine all errands over and over etc., but simply setting it all up as a small project, and collect suitable errands in it, would be the easiest and preferred way for me personally. But I would not want to do this if that meant I had to remove those errands from the "real"/original projects where they belong; hence my original request for multiple parents. That's what I meant, and I know we disagree, but now at least now you know what I meant.

Associated topic: Could Time Planning be to blame for poor GTD project features

I can hear you saying: "Has he gone totally mad now?" ROFL. Please bear with me.

Let us forget about dates for a moment. Let us focus purely on GTD projects. I know that we all in this thread know and agree that in a GTD project many of the actions typically are not yet relevant to show on the Next list (or on separate context Next lists, or on the Waiting list either, for that matter.) In basic GTD we choose the actions that are now relevant (possible) and simply leave the rest behind. This is very fundamental.

Now, in the probably dozens of so-called GTD apps I have taken for a test drive, not a single one has this fundamental distinction built in. Mind you, this is at the very fundamental GTD level, long before we even start dreaming of automating anything or exactly outlining the flow. Truly fundamental. In a true GTD app you would need, as a minimum, to have some simple mechanism where you select for each task whether it is "show or hide" (or active or inactive; or current or subsequent; or however people might prefer to call it). This has been 100% missed everywhere that I have looked.

Isn't that a bit strange? So fundamental GTD, and still generally totally absent in all "GTD" apps I have seen. Here is my wild guess (hypothesis; allegation):

Maybe most "GTD" app developers and most "GTD" users have not really bought into David Allen's approach, which is fundamentally date-averse and situational (dynamic); planning and preparation yes, but time planning generally no. So what they do is assume that everything of any degree of importance or urgency is scheduled in the traditional manner to some specific date or time slot. The Next list therefore becomes their "backlog" (of "spares"); everything else is already in their "schedule", possibly even mapped to a calendar. Since this backlog (their "Next" list) is now so incomplete and of such limited importance it matters little whether it shows or hides the remaining "spare" actions in the projects correctly as per GTD - as soon as they spot something there that they want to schedule, they simply schedule it.

A piece of "circumstancial evidence" to support this hypothesis is the fact that most "GTD" apps call their Tickler file "Scheduled". Sure, you could argue that the ticklers are in fact "scheduled" for being processed again, but I get the distinct feeling that many use "Scheduled" to actually schedule their tasks for being done on that day.

Any thoughts on this?

Comment

Wow. Omnifocus really seems to be a well-rounded package. It is also very reasonably priced, and seems to have lots of users. To me, as an outsider, it is astonishing that they elect not to earn money from Windows users as well - that would seem to be low hanging fruit.

It would probably be difficult to port Omnifocus to windows, because the underlying database as well as the UI leverage apple software libraries. Omnigroup's expertise is in apple stuff, and I don't see them changing any time soon. Personally, I find their behavior pretty sensible- Windows is a big bag of hurt to support.

I wouldn't call it "date-averse." DA simply asserts (rightly in my view) that something doesn't have a hard deadline unless it does, and you shouldn't clutter your calendar with things you want to do that day but don't have to do.

Well, it is maybe not the best word, but I have been "date-averse" myself since the late nineties when I moved from paper to electronic (Outlook) and initially tried to used dates as my principal planning tool. (But of course I still use dates for appointments and ticklers. And hard deadlines, if any, are among the notable characteristics of tasks, even though I do not base my planning on them.)

Now, any thoughts on my "wild" hypothesis?

I am referring to the suspicion that a mental legacy of time planning (scheduling for no "hard" reason) is perhaps quite prevalent among both developers and users of "GTD" apps, and that this might explain, indirectly, why "GTD" apps generally do not have even the most basic GTD support for distinguishing between those project tasks that are to be visible (on the Next list etc) and those tasks that are to be simply "left behind" in the project, invisible elsewhere.

Another piece of "circumstantial evidence" for this is the seemingly immense popularity of "calendar integration". Although not totally useless for anyone, not even for the most "date-averse ultra-GTD purist" (or myself), its usefulness obviously increases dramatically with the amount of "soft scheduling" that the user does. The more a person uses soft scheduling (time planning) rather than dynamic GTD criteria (context, energy etc) the more useful calendar visualization becomes.

I forgot about Zendone. They have actually implemented something that allows users to have as many Next actions as he/she wants, while hiding the rest within the project. Their implementation is perhaps a bit clunky to use, but it does come straight out-of-the-box, without any need for inventing your own workarounds for this very fundamental GTD distinction.

Comment

....In a true GTD app you would need, as a minimum, to have some simple mechanism where you select for each task whether it is "show or hide" (or active or inactive; or current or subsequent; or however people might prefer to call it). This has been 100% missed everywhere that I have looked....

I've always operated with this principle: A project task with no context is "inactive". Assigning a context IS the simple mechanism to mark it active. FWIW, I've always used @waiting as a context, since most @waiting's start life as some other context... it is a simple matter of changing the context. If a software package can't do this I look elsewhere. Which, I just realized, means I've never used software that could be called "a true GTD app". YMMV.

Comment

Interesting thought. But wouldn't that mean, or am I misunderstanding something, that you would have to "artificially" hold on with your context assignations until such time that the task is to become "active"? (It is nice to be able to offload all such facts that you may have about the task already from the outset.)

Comment

I like Nirvana's simplicity, but even Nirvana has its shortcomings. Some of these are where they have made things unnecessarily overcomplicated, from my perspective, and thereby have also limited the versatility of the product.

Hi Folke,

This was one of the reasons I never went with Nirvana after moving away from Toodledo. It was just too complicated. I appreciated that they were trying to be "pure GTD" but I just don't think that this is possible or worthwhile - it ends up shoe-horning users into a specific way of doing things.

I've found that using a relatively simple list manager works best for me. The more complexity there is, the more time I spend trying to get my data tweaked to fit the pre-defined model.

That said, you might need this kind of complexity, and from what you've described I'd suggest you check out some of the more fully-fledged project management systems in the cloud. These apps will let you define projects with a lot of granularity and linkages.