I just wanted to put in my .02, even though it is probably worth less than that. I have read David Allen’s book and I try to follow the general concepts of it. I remember reading somewhere that while it is an awesome system, sometimes we need to tweak it a bit to fit our own individual needs; i.e., no one system is likely to fit everyone perfectly. Much in the same way that it is going to be impossible to make one software program that meets everyone’s needs.
I love simplicity and ease of use. In order to use a program, I really need to understand it. In general, I am quite computer savvy, and catch on quickly. Other systems I have used, even ones designed specifically for GTD, offer a beginners video explaining how everything works, including a brief introduction of how that applies to GTD.
My problem with GTDNext is in my job I have recurring tasks that need to be done weekly, monthly, quarterly, etc. If I have a recurring task, and I don’t complete it, I don’t want it to disappear, I need it to show out there as past due. I also have a lot of deadlines. I know I am supposed to put items with specific hard due dates on my calendar, technically, however, to have to go to more than one program to see what tasks and projects I have scheduled is something I consider cumbersome. My calendar is for appointments and meetings. My “to do” app is for managing projects and tasks. Perhaps I am just not clear on how GTDNext handles this (hence the idiots guide/video to GTDNext would be helpful). I would like to be able to pull up “Scheduled” and see exactly what I have due and when. On next actions, I would prefer if items have due dates, they show up in date order at the top, instead of all over the place. I don’t understand why, when I have a recurring task, it gets turned into a project. A project is something with more than two steps. Many of my recurring tasks are one step items, they don’t need to be a project.
Again, this may just be me not understanding how GTDNext is setup to work. But, if I don’t understand it, how many other people out there also don’t understand the basics of your software? How many other potential eventual paying customers are you losing?
From your post I see there is only one thing you don’t understand: why recurring tasks are shown inside the project.
Other things look more like wishes/expectations of the App’s behavior.
The first one I see is the need of having Due Dates in the Recurring actions.
It’s the feature I also expect a lot and it is scheduled for us with one of the highest priorities.
The second one is the presentation of scheduled items.
We are also planning a number of features for it, like filtering the outline for items with the due dates only.
The ordering in the Next list is a special case and will be resolved when the manual sort of Next List actions is implemented.
About the presentation of recurrent items in a Project.
As you’ve noticed the recurring actions are created inside the Scheduled Action.
When it happens the scheduled Action is automatically changed to a Project.
That may seem confusing at first, but you may just consider it not as a project, but as a container for all the generated recurring actions.
This approach has a number of advantages and disadvantages.
Among the former are:
the Scheduled item (Project) serves as the setup-holder of the settings for generated recurring Actions,
while the actions itself behave like the regular Actions
the generated actions are stored inside a container, thus do not mess with the other actions of the owning project
(may be useful when you have a number of incomplete generated recurring actions)
the behavior of recurring actions within a Scheduled item can be controlled by the settings of that scheduled item
(like, focusing the scheduled project makes the generated recurring actions get focus automatically)
Among the disadvantages I’d mention the option #2 from the advantages list.
It is sometimes desirable to have the action appear right inside the real project it belongs to.
The learning curve for the users not used to such approach also can be considered as disadvantage.
I hope with this post I have cleared things out a little.
Please, feel free to ask here or contact personally in case of any unclear things about the App or features to be implemented.
Sorry, Folke, Sometimes I feel like you are talking about a different application with me
I don’t know what you mean by “listed” here. In GTDNext everything is much simpler.
If the action’s N icon is green - the action is the Next action and is showing in the Next list.
If the action’s N icon is not green - the action is the non-Next action and is not showing in the Next list.
It the action has the red F mark on it’s N icon - means the Force Next is ON for the action.
It the action does not have the red F mark on it’s N icon - means the Force Next is OFF.
In combination with a couple of another basic rules (like, Waiting or Someday action can not be Next in any circumstances), these options make decent balance between simplicity and flexibility of the App.
Btw, talking to you I’ve got another idea to resolve the Parallel actions issue (as an alternative to the Container node type). I’ll post about it in the next blog post shortly, I guess.
I thought I did explain that, but anyway: By “listed” I meant visible (listed) on one of the “main” GTD lists, or, to be specific, the next actions list, the waiting for list, the calendar/tickler list (called scheduled in GTDNext) or the someday/maybe list (or the inbox, for that matter).
So, what I was saying was that there is no simple and consistent visual indication of whether a given action is visible on the main lists or not. In other words, of whether this action “on” or “off” (parallel now or sequential later)? As you just described, and I did earlier, too, the visual indication varies from green or gray base color with or without a red decor.
Haha, It is OK. I feel exactly the same when you guys try to explain stuff
Sounds great
And please remember that you can make much of the issue go away by simply implementing some defaults in the outline mode - make created tasks (Enter key) or dragged tasks mimic the parallel/sequential status of the action above it. Most people keep their actions in chronological order, so this default is bound to have a very high “accuracy”. This will reduce the “parallel/sequential problem” to pertain to only those actions that are “tossed” (without exact placement) onto a project name in a menu etc. If you want to provide user defined settings for that, then fine, but parallel will be both safer for novices and smoother for experienced users.
I don’t like this either. Not only does it look weird, but the worst thing is that it cannot have subtasks (a checklist). That is a very serious drawback and it is not consistent with how non-repeating actions behave.
