Confusing Terminology

[Folke]

I have some serious objections to some of the terms used in the app. To some extent my objections are related to my views on the underlying functionality as such, but I’d say the objections hold under any circumstances (but I’ll comment below, where necessary).

The things I want to bring up here are:

• the term Active as in Inbox, Active, Waiting, Scheduled, Someday

• the term Next as in Force Next

• the term Force as in Force Next

Next

The term “Next” as in Force Next is too narrow, because it will apply to all “types” (Waiting etc, too, not just Next), to control whether or not the tasks will be visible simultaneously on the “current” lists.

Active

The term “Active” as a “type” name for Next actions is highly confusing for several reasons.
1) It does not match the name of the corresponding main/current list (which is called Next actions).
2) It is inconsistent to have two names for just next actions but not for the others (and I certainly would not recommend you to have dual names for all, e.g. to have an “Expecting” type showing up on the Waiting list, and a “Timed” type showing up on Scheduled etc ). Better to have just one name for each.
3) It has a high risk of being misunderstood as the opposite of Inactive, which is the common term for projects etc that are “turned off” (disabled). “Active” sounds as if has something to do with inactivation and/or sequential logic, whereas, compared with Waiting, it is only a matter of whether its is I or someone else who will do the task a.s.a.p., i.e. whether it is intended to be a Next action or a Waiting For action.
4) It indirectly raises anxious questions about the other types (“What? Are my Someday and Waiting turned off somehow? Inactive?”)

Force

The term “Force” in “Force Next” is highly dubious - misleading and causing anxious questions - as a descriptor of its main functionality. Its main function is to simply make tasks visible simultaneously on the “current” lists, i.e. make them parallel, if they weren’t already, and to lay this behavior down in advance for larger projects. This is nothing that needs to be “forced”. It is the “natural” way that people expect. Tasks should be visible on whichever “current” list they were entered for, unless the user decides to “hide” them, and there should be defaults in place to ensure that this works safely. Regardless of how this is done exactly, parallel is something very natural indeed - the most natural, actually - and does not deserve a strong word such as Force, which implies some kind of exception. In fact, it does not even need a name or checkbox at all, since its main function is fully implicit in the task not being marked as Sequential (the “Sequential” checkbox simply not checked. If it is not sequential, then it is parallel; no word or checkbox needed).

However, the term “Force” might be appropriate in an advanced different scenario, almost like an alternative Focus shortcut (a “Prefocus” shortcut ;-)), hotwiring absolutely anything at all even from the deepest and remotest corners of the future outline and onto the “current” lists, regardless of all sequential and similar settings in the outline that may block it. This might perhaps be useful in some cases, who knows? The funny thing is that this advanced function already exists. This is how the Force Next function actually works today - an unfortunate side effect of how it works; unfortunate because it sabotages its main function in sequential subprojects, precluding these from being planned in advance for intended parallel actions. But this nevertheless could be a feature, too - an entirely separate feature - a Forced Prefocus hotwire (could also be called “Forced Visibility” or “Forced Current” etc). In this case the term forced would be OK, because it is an extreme override of the natural/planned flow, quite similar to the Focus override. This extreme feature really has no significant bearing on the regular planned parallel/sequential functionality in general and should not be visualized or managed or named using the green/gray icons or similar terminology. Maybe it could have a pink Focus icon? Maybe two separate checkboxes for Focus and Prefocus (rename Forced Next to Prefocus)? This is not a feature that I request. In fact, I see very limited use for it, and the whole Force Next checkbox could be removed, but if it is kept in some form it should be made totally separate from the sequential/parallel functionality, and named in such a way that no confusion can arise.

[Folke]

It dawned on me that the “Forced” feature (perhaps with a pink Focus marker or other appropriate icon) would actually be very useful - for “just around the corner” tasks. It is something that I actually have today in Doit “thanks” to all the weird workarounds I have to use to make that app work for me at all, and which has provided me with this as a useful spin-off.

Imagine you have a project with a tiny next action (showing on the next actions list), followed sequentially by a really massive intended next action which will drown you in work for hours on end (but which is not showing yet on the next actions list because it is not possible to start until the tiny one is first done). And now you want to look at your next actions list and see what you have “on your plate”. You won’t even see the massive task looming just around the corner.

By using “Forced Preview” for selected tasks (with an appropriate icon to show that this task is not really “ripe” yet) it would be possible for the user on a manual basis to include particularly demanding (or otherwise interesting) tasks ahead of time for early viewing on their intended “type” list (typically the next actions list). As soon as they get “truly” listed on their own regular parallel/sequential merits, the “Forced” icon could be removed automatically.

I can admit that this feature is something of a “luxury”, and certainly quite unique/unusual, but it is a way to make some good use of the existing hotwire feature, and it does have a distinct value. For example, people could use this to identify any additional main/heavy/interesting actions that are likely to come up during the whole week ahead (before the next weekly review), and still be able to see clearly on the main “type” lists which ones are “truly possible right now” and which ones are just “on preview” (“beware!”). There could even be a filter toggle on the main “type” lists to include/exclude the “preview” items.

Just a thought. But quite an interesting one.

[Folke]

Here is another, more subtle, instance of terminology that can cause considerable confusion, especially to new users who are not familiar with GTD:

Scheduled

To most of us who are already familiar with GTD it does not matter much what you call it. We tend to use it for what David Allen calls Ticklers. David’s choice of term can seem a bit questionable, at least these days when the term tickler is often used for daily email digests and the like, so I can perfectly understand why no developer wants to call it Tickler.

What makes the term Scheduled a particularly bad alternative (even though it is quite common) is the fact that this term suggests the very practice that David Allen so strongly and fundamentally opposes - the non-objective scheduling of tasks that is so common among all those people who have been influenced by the “time management” philosophies that started to grow strong in the '80s. (“if you want to be sure to get something done, put a date on it” etc). This is the total opposite of GTD.

David’s Tickler file represents things that in themselves are objectively impossible (“premature”) until a certain date, e.g. “Buy theater tickets”, if these will go on sale only on August 1. This is a “hard landscape” date, nothing to do with how busy you are or what you plan or intend or aim for or anything of that nature. The Tickler date is the first possible date that you can do something about this thing, objectively speaking. GTD is all about the objective “hard landscape” and leaving the rest up to situational decision making (context, time, energy, priority). There is no “time management” scheduling in GTD.

I think the most accurate alternative term for Tickler file (Scheduled) would in fact be “Premature”. This says exactly what it really is, exactly what David intended. There are also other terms that are not too bad, like Pending etc.

As for dates, David also recognizes actions that need to be actually done on a certain day (and often a certain time), e.g. appointments. He calls these calendar actions, because we typically keep these on our calendars, not on our lists, but regardless of where we keep them, and in what graphical format, they are a different kind of animal. Calendar actions MUST be done on that exact day, not before, not after, whereas a tickler item can be done anytime on or after the specified date (unless it also has a deadline date). It is essential to maintain a clear distinction between these two because a calendar action is sure to impact your availability and flexibility for doing other things on the “scheduled” date (“start date”), whereas a tickler action often has no such impact at all - it will be just another action on your Next or Waiting list, typically requiring some initial re-assessment (processing), but that’s all; if you decide to actually do something about it on that day is an entirely separate decision.

There are many ways to solve this, of course. One way would be to have two lists and call them, say, Calendar and Tickler. Another way would be to keep the term Scheduled, but make it a very clear option in the edit pane, and clearly visible on the lists, whether the action is “scheduled” as a calendar action (“exact date”) or as a tickler (“premature before date, but possible anytime thereafter”). Yet another way is to make the tickler functionality available to all “types” of actions by allowing them all to have a future “start date” and only keep the Calendar type as a “type” and let all the others show up in their respective colors on the Calendar/“Scheduled” list. The latter would be my preferred solution, as it also gives us the possibility to “tickle” Waiting for actions (e.g. monthly reports we expect to receive) or Inbox actions (for complete re-processing/reconsideration; this is the core GTD way).

Whichever way you decide to go, I think it would be wise to be vary careful about using term Scheduled, as this leads people to misunderstand the very fundamentals of GTD - its dynamic, “non-scheduling” nature ;-).

Being unclear about this also will lead to many “unwanted” feature requests - such as for daily emails listing all the actions you have “scheduled” for today, single-button postponement of tasks (reschedule for tomorrow), statistics of how many of the “scheduled” tasks you actually completed etc etc. Doit are totally bogged down in such non-GTD requests (and ambitions). I hope you can mange to stay clear of such unnecessary complications.