My experience switching to plain text

[cfoley]

Being the computer geek that I am, the temptation to tweak my GTD system is often irresistible. Over the past several months, I have been evangelising plain text files for a number of purposes, including at least once on this forum. I decided that I should eat my own dog food and at least try using plain text files for my GTD setup. It's an ongoing process but I wanted to share it with you because I believe something simple and beautiful has emerged.

The philosophy behind text files is that they are readable on any computer with a text editor (i.e. all of them) and I can write scripts to automate anything I want. This can be simple stuff like searches right up to complicated stuff like web servers and graphical interfaces. In short, I'm not constrained by someone else's ideas of a list manager. It can be as simple or as complicated as I need with exactly the features I want (no more and no less).

Getting Started

My old system was on Toodledo. They offer a CSV download so I grabbed that and had one large flat file with everything in: Actions, projects, ticklers, somedays. I wanted each line to make sense out of context so I reformatted the file to look a bit like this:

@Work Water desk #plant (Started 2015-02-23) (Due 2015-03-02) (Repeat weekly)

The fields like "Started" and "Due" were all optional. I didn't like this format but it was just a quick way of getting started that was readable for me and parsable for scripts. Hashtags have no special meaning other than to help me with text searches and the list name (@Work) could be anywhere in the line, not just the start.

Everything was in one big text file. I put it on Dropbox et voila: a fully functional text file GTD setup I could access from anywhere.

Optimising Workflow with Scripts

Working off one big file was a bit unwieldy, especially since actions, projects, ticklers, etc were all together. I started writing some scripts to:

* Tabulate all list names with their number of items.
* create a temp file for a list for editing.
* merge the edited temp file back in.
* filter out actions that had not started yet.
* sort items
* truncate output to fit the screen.

This was working really well. I could tap a few keys and jump straight to a context list. The hashtags were really useful. I could use the same mechanism to pull out all the entries for a particular hashtag (which were usually the same project)

Ditching the Scripts

I was really pleased with my scripts and excited about the direction of this project. However, In one weekly review, I realised most of the scripts I was planning to add only existed to get around the problems associated with using one big file. I decided to separate things into four files: someday.txt, ticklers.txt, projects.txt and actions.txt

When I did this, it became apparent that "Start date" and "Repeat" were only useful for ticklers, and that actions that had them were serving a dual purpose. I copied these actions to the tickler file and removed these fields from elsewhere in my system.

I now see the conceptual difference between ticklers and actions. They are "reminders of stuff" and "the very next thing to do" respectively. The "Water plant tickler" may spawn a similarly-named action each week but I want to get into the good habit of treating these concepts differently (at least for the time being).

Another thing emerged: all the scripts I had written were now obsolete. I was a bit sad at this but deleted them anyway.

I had originally planned to split my action list further, into a file for each context. The current arrangement was just supposed to be a point along the way. However, my action file only had about 150 lines and it was easy to scroll up and down to see different contexts, perhaps easier than opening a different file.

Simple and Beautiful

My software setup is Dropbox and Sublime Text. But it could be any cloud service and any text editor. There are no scripts or automations. The action file is sorted by context (i.e. alphabetically with the context as the first word.)

Using my system is this simple:

To add an action, I type it in.
When a task is done, I delete it.
To change an action's context, I edit the first word and press F9 to resort.
To see the actions for a context, I scroll up or down the file.

There are some features that I used to like that I don't have any more: item counts for each of my lists; linking between projects and actions; notes field in my actions; start dates everywhere; The star field for temporarily highlighting; saved searches; a checkbox for done.

I don't miss any of them, and I say that knowing that within an hour I could implement each in any way I could imagine.

I thought I was clever when I used all the bells and whistles I had before. However, by giving myself permission to program my own system, I have settled on something that is very similar to the recommendations David Allen set out in his original book. I find this embarrassing and reassuring in equal measure.

Looking to the Future

Nothing is ever perfect. It's not easy for me to see my lists on my (android) phone, despite Dropbox syncing the file. It looks like there are apps that can display text files as widgets. I hope one works well enough with my layout. If not, I can always fall back on my original philosophy and write an app myself.

Universal capture is a separate issue but I would like to use my phone as a capture tool to write straight into a text file. I haven't begun to look for solutions yet.

My project support material needs some attention. I have been toying with the idea of linking folder names via hashtags. I could do it with a simple script but I'm worried I might be reintroducing unnecessary complexity.

If you got this far then thanks for reading. I feel the path I took was quite enlightening for me and I hope you enjoyed reading about it.

 

[Folke]

Wonderful story. And I totally agree it does not really take a lot of complexity to keep things in good order. The super-simple system DA describes (that even works on paper) is often good enough. I used something like his system and yours (using paper) for 2 or 3 decades until I started using a computer in the late 90s.

I makes me think of another thing, though. I find it hard to understand the aversion we sometimes hear expressed to some of the "unnecessary niceties" a computer can offer. Just like some of us may prefer to use a gold plated pen instead of a plastic pen or a handsharpened pencil, or en expensive Moleskine instead of loose sheets, why would it be wrong to prefer an app that can link actions to projects and can let you choose whether right now you want to look at what you have in a particular context or look at what you have in a particular project or area? Even if it is not "necessary", it is nice ;-). That is a good enough reason for me to use a "gold" app rather than a plain "list" app. But I do feel that most of these apps contain probably ten times more bloat, that I will never use, than the few real niceties that I actually appreciate and made me choose that app in the first place.

 

[cfoley]

Thanks for reading.

The process was enlightening for me from two perspectives. The GTD one is obvious in this forum. The other is from a software development perspective. None of the features were difficult to write code for but most of them were only necessary because of defects in the design. That's something for me to look out for in any software I write.

Maybe you were talking more generally but I certainly don't have an aversion to linking projects to actions. I only observed that I didn't miss the feature when I took it away.

The way I see it, there is at least some benefit in linking actions to projects. It follows that it's worth at least some overhead in setting them up. Maybe explicitly linking each one is too much so maybe there is a clever algorithm.

I've given this some thought and here are some suggestions:
Links could be defined through hashtags and a little discipline.
Machine learning (maybe naive bayesian) could have a shot at linking them for us, although the user would need to provide feedback.
Support files and natural planning output could be used to help guide machine learning.
Part of a weekly review script could help unite empty projects with orphan actions, maybe usin some of the suggestions above.

Maybe one day I'll try out the above.

 

[Folke]

I could be wrong, but I think that when using a "flat" approach like yours (or paper) it is probably not worth the effort to link projects and actions. The reason it is so easy, virtually zero-effort, to create and maintain this kind of linkage in a "gold" app is that it is built for it in the first place. Usually, in those apps, when you review a project (or simply look into it. click into it, for whatever reason) then that is where you "are" right now and that is where any new task will be placed if you hit "create task" or some such button. You do not have to make the link as such. It just "happens".

And also, these apps typically have a left menu which contains the whole list of projects, so you can quickly drag a task from anywhere in the main pane onto a project name in that list on the left. Very convenient if you make a mistake or just change your mind about where it belongs. And nothing forces you to drag/place everything into projects, if you do not want to. I often skip that "formality" for "quick stuff" that I expect to do later the same day - I just create it straight on my Focus list (shortlist; "white index card") and save myself the small drag to a project ;-).

I really agree with your conclusion of your own experiences. For example, you said that difficulties mostly arose due to defects in the design (or underlying analysis, perhaps). This is so true, and it applies not only to software development but to virtually anything - contracts, business plans, presentations or home renovations. If you have not managed to put your finger on what it is all about, then it is hard to find a simple and effective way to address it.

 

[cfoley]

If you have not managed to put your finger on what it is all about, then it is hard to find a simple and effective way to address it.

Oh, that's the essence of it! Thanks!

I see what you're saying about the "gold app". If you're working from a project view then it's easy to add to a project. The worst part I have found is adding an action when processing the inbox. Often I wanted to link new actions to existing projects. Locating the correct one from a list could take a few seconds. In Toodledo it was a little harder again. My attitude with linking has always been all or nothing. A partial list of actions for a project is something I cannot trust to be correct and complete.

It could just be that I've been using bronze apps and the gold ones are so much better than I can imagine.

 

[PeterW]

Universal capture is a separate issue but I would like to use my phone as a capture tool to write straight into a text file. I haven't begun to look for solutions yet.

I know you mentioned that you have an Android phone, but there is an iOS app named 'Drafts' that would be perfect for your system.

I use this app all the time. It has the ability to write (append) to text files in Dropbox. When the app opens, it presents you with a blank page ready to type. You simply type what you want (and there is an extended keyboard that makes inserting special characters easy) and then tap on a button to bring up the Action menu. Actions are customisable and enable you to do what you want with your text note, e.g. writing to a text file or csv file on Dropbox, email it, and lots of others.

Maybe there is something similar out their for Android. Take a look at the features of Drafts (http://agiletortoise.com/drafts/) and then search to see if something similar exists for Android.

I use Drafts as part of my GTD solution to get tasks into Omnifocus.

 

[cfoley]

Thanks for the suggestion. It looks like there is an android app called "Draft" (without the S) that overlaps a lot of the features in Drafts. If the Dropbox sync is two-way then it might be exactly what I need for capture and also for viewing my lists. I'll need to look around the play store a bit more but this looks promising.

 

[Folke]

I see what you're saying about the "gold app". If you're working from a project view then it's easy to add to a project. The worst part I have found is adding an action when processing the inbox. Often I wanted to link new actions to existing projects. Locating the correct one from a list could take a few seconds. In Toodledo it was a little harder again. My attitude with linking has always been all or nothing. A partial list of actions for a project is something I cannot trust to be correct and complete.

It could just be that I've been using bronze apps and the gold ones are so much better than I can imagine.

I think you are completely right. No matter how "golden" your app is there will always be places (e.g. Inbox) where you need to somehow choose the project either from a list or by some form of key entry (more or less "intelligent" key entry) or a combination of those methods. Apps differ in the finer details for how this is done, and the overall convenience of it can vary quite a bit due to these small differences, but there is always something little that you need to do. You are right.

Overall it does not disturb me, though. Having the flexibility to alter between viewing actions either by context etc (primarily for selection) or by project/area etc (primarily for review) is something I value a lot. This is also the main reason I moved from paper to computer in the first place. I would not want to be without it. But yes, there is a price to pay for it.

Anyway, I think I may have drifted off the topic a little bit. Sorry if that is the case. Your original post also inspired some thoughts about tickler/start dates and Next/Waiting/Someday vs contexts, but I'll have to think whether those comments belong here. Maybe in a separate post later.

 

[cfoley]

No matter how "golden" your app is there will always be places (e.g. Inbox) where you need to somehow choose the project

This kind of thing is the reason behind a plain text + scripts approach. With someone else's application, you're stuck with inefficiencies in the user interface. With a command line, inefficiencies can be automated.

It's interesting to note that you use the context view for selection and the project view for review. For me, selection is a more common activity than reviewing. Time might reveal that I really do miss the project view. However, right now I have 69 projects and 147 next actions. Most projects will have only one next action so maybe the project view wouldn't reveal much for most of them.

I would be very interested to hear the thoughts you mentioned in your third paragraph, either in this thread or another.

 

[Folke]

With a command line, inefficiencies can be automated.

I do not know the first thing about scripting, but still I cannot help but wonder how you could possibly automate the attribution of an action to a particular project (unless, for example, you key in some other keywords etc). Could you please explain?

For me, selection is a more common activity than reviewing.

For me too. But both happen frequently enough to require full convenience and clarity.

However, right now I have 69 projects and 147 next actions. Most projects will have only one next action so maybe the project view wouldn't reveal much for most of them.

Perfectly understood. I know many people do it that way, i.e. the "core/paper" GTD way, and this has been a frequent topic on this forum. It appears that preferences vary widely.

For some of us, we tend to include in our main GTD app all those future actions that are not possible until other actions have first been completed. These dependent actions are classified by the GTD book as belonging with the "project support" material, outside of the main "lists", but nothing says the "lists" and the "project support" material cannot "live" within the same app (as long as the dependent actions do not pollute the next actions lists etc). This means we have the entire "project plan" straight in our app rather than in some external Word document or Evernote etc. This increases the task count considerably, and also makes the app's project view very useful for most of our review needs. We also typically have Waiting and Tickler and even the odd Someday/Maybe (plan B type) tasks in our projects.

I suppose the project view is mainly of value for those of us who deal with it in this "all-inclusive" way, and less so for those who keep the "project support" tasks outside their main app.

I would be very interested to hear the thoughts you mentioned in your third paragraph, either in this thread or another.

I'll be happy to. Let me get back to you about that in a separate post.

 

[devon.marie]

I did sort of the same thing - I went back to paper. I found that using apps like Omnifocus, Todoist, etc. required so much upkeep to keep my lists formatted in the way I wanted them that I was spending more time pruning vs. doing. I also listened to David Allen's talk on Lynda.com and it really inspired me to wipe it all and start fresh. I'm no longer on paper, just because it was an incredible amount of work to keep writing things, crossing stuff out, etc. but have since simplified my GTD setup immensely, using one board on Trello for each AoR and containing every todo and project in there. I love that I can see my Next Actions list (single tasks not tied to projects) next to my Project lists, and I use the colored labels to mark Next Actions, Waiting, Errand, Agenda, etc. I used to have a rigged-up complex system in Todoist that involved using all 4 priorities to mark Priority, Scheduled, and Next Action, complex searches for my different contexts, etc. and it was just a complete PAIN to keep up. My setup in Trello has saved me immensely.

Have you tried using plain text-ish list apps like Workflowy or Moo.do? I'm curious what your take on them would be.

 

[bcmyers2112]

There are some features that I used to like that I don't have any more: item counts for each of my lists; linking between projects and actions; notes field in my actions; start dates everywhere; The star field for temporarily highlighting; saved searches; a checkbox for done.

I don't miss any of them, and I say that knowing that within an hour I could implement each in any way I could imagine.

I am not a programmer and wouldn't be able to write code to save my life, but a couple of years ago I too simplified my GTD setup and found I didn't miss the tools and features I once thought I could never live without.

 

[bcmyers2112]

I find it hard to understand the aversion we sometimes hear expressed to some of the "unnecessary niceties" a computer can offer.

You may be surprised to learn that I don't necessarily think these "niceties" are inherently bad (although I no longer have any desire for them). But some people let them get in the way, spending copious amounts of time fiddling with GTD software and lamenting that they can't get work done because the perfect app doesn't exist. My point is not that you have to practice GTD without these tools but merely that you can. That's why I advise those who are getting wrapped around the axle with software tools to try something much simpler like paper or flat digital lists.

If your GTD system works for you, Folke, I wouldn't presume to tell you to abandon it. But when I read of someone who is spending vast amounts of time worrying about list apps rather than achieving worthwhile things (and I was once one of those people), my advice to those people is to try a back-to-basics approach which I know from experience can work.

 

[Folke]

But when I read of someone who is spending vast amounts of time worrying about list apps rather than achieving worthwhile things (and I was once one of those people), my advice to those people is to try a back-to-basics approach which I know from experience can work.

I think your advice is sound.

 

[JohnV474]

You may be interested to watching Carsten Dominik's video on Org-Mode. Org-Mode is a major mode for the Emacs text editor.

By using plain text files and then having a set of scripts (Org-Mode) that will format the text, written in a type of markup, some very handy tools become available.

For example, by starting a line with *, a heading is created and everything until the next line started with * can be folded away, as a hierarchical tree outliner. Starting a line with ** creates the second level of the outline.

Scripts exist for due dates, reminders, hyperlinks within the file or to other files or even websites, a TODO/DONE status, summary reports, even calculations. There are no limits, as the scripts are cross-platform and open-source. Unfortunately, Android only offers a few apps able to interpret the plain text files, so no elegant mobile solution is available. Of course, they are still editable with any text editor.

The solutions they have figured out work best from a computer, but they still may serve to offer ideas for future automating. I would expect few people to be willing to learn Emacs simply for Org-Mode, but those who do will always have a plain text system available that is, in a sense, simple.

-JV474

 

[Folke]

cfoley,

I mentioned before that your original post made me recall a few other general observations and distinctions that I personally have found clarifying, even though I understand that they may seem totally academic and of little consequence - unless you really want to put your finger on the essence of everything and make sure you tweak your approach to reflect your own truth.

Waiting, Someday ...

One of these philosophical questions concerns Waiting For and Someday/Maybe and what they really are. If you use paper (or a plain list app) maybe this question would never even cross your mind. You simply put your Waiting Fors on a separate sheet of paper, and you have lots of other lists, too, each on it own separate sheet of paper. Whether or not there is any fundamental difference (beyond the obvious) between the Waiting For list and, say, a Context list is not anything you need to worry about. But when you start using featured GTD apps you will notice that different developers have needed to choose one of two very different approaches to the fundamental difference that actually exists there. One approach is to have a new separate action characteristic (called "action type" or "state" or "focus" etc) which can take on values such as Next, Waiting, Someday ... . The other approach is to have no such "extra" feature for making this particular distinction, but to have the user create a regular "contexts" for @Waiting and @Someday.

I have tried both approaches in practice. They both have their pros and cons, to some extent depending what other features the app has to complement it. I will not get into that here. But overall I prefer the approach where a separate "action type" (Next, Waiting etc) is used. It has proved to be more practical for me, and I also find it more clear-cut from a philosophical point of view. The way I see it, Waiting For simply is not a contextual requirement (place, tool, person etc) that I need to have available in order to be able to do the task.

The distinction is rather related to who will do it (or even if):

Next: me
Waiting: someone else
Someday/Maybe: maybe nobody, not decided if at all (not "approved by me" yet)

I get the impression that you have take the opposite view, treating Waiting and Someday as contexts rather than as "action types". That's fine, too. I just wanted to comment.

Ticklers, Start dates

Another philosophical question that probably would never enter anyone's mind as long as they use paper relates to Ticklers. When the day comes you simply take them out, place them on your desk and process them. They are neither Next actions nor Waiting For actions nor Trash nor Reference nor anything until you have made them so. And until then they are just Ticklers (or Inbox items) - pending processing.

But in any featured GTD app you will notice that developers have usually made a decision about what they are and what they will be. I have only seen one app (getitdoneapp) that actually places them in the app's Inbox for processing when the day arrives. Most apps place them among the next actions, which saves time as this is the most common case statistically (and when this is occasionally wrong you just move those few to Waiting or Trash or whatever is appropriate).

The fact is that the eventual "action type" is very often known in advance, and most of the processing was probably done when you initially filed it. For example, a tickler reminding you to clean the kitchen fan ever four weeks will clearly become a Next action. A tickler to expect a report from Dave early every month will clearly become a Waiting for. Etc. So the question arises whether Ticklers are really best regarded as a separate "action type" (as they are in most apps, and in GTD) or as just "regular items" that have a future "earliest start" date associated with them, usually one of these:
- a Next action with a future start date (e.g. a report that you must write every month)
- a Waiting For action with a future start date (e.g. a report that you can expect to receive every month
- an Inbox item with a future processing date (if you are not sure what you will want to do with it).

I like the Start date approach for its greater flexibility, and for an entirely different reason, too. I like to make a note of when each action became possible to do. It can sometimes help me determine whether I should do something about it. For example, "since when have I been waiting for John to write that proposal". Or "since when have I not managed get my butt in gear with this". To some extent, the "since date" will to some extent influence my opinion about whether I should do something about that action now.

A single start date (past or future) can serve both as a since date (past) and a tickler date (future). It would never be relevant to have both at the same time (because if it is tickled for a future date, that date will become the since date when that day comes). All actions therefore can have a perfectly meaningful (and useful) Start date. In Toodledo (not specifically designed for GTD) you can use the Start date in this way. Very simple and good. I have never seen anything like it in a GTD app.

Hashtags

I got a bit confused about your hashtags. I am not sure whether you use them as contexts or projects or areas or what.

 

[cfoley]

I do not know the first thing about scripting, but still I cannot help but wonder how you could possibly automate the attribution of an action to a particular project (unless, for example, you key in some other keywords etc). Could you please explain?

It's possible that it can't be done. However, the overhead can certainly be reduced.

* Most obvious is things like looking for common (but not too frequent) words to help suggest links.
* This would never link the action "Call Bob" to the project "Fix dripping tap". However, using data mining, Bob might be clustered with other previously used tradesmen and "Fix dripping tap" might be clustered with other home maintenence projects. You could reasonably expect an algorithm that used this info to link this action and project.
* Text is using links that are already there. If a project is linked to the output from going through the natural planning model (esp the brainstorming part) this could be a powerful input to the above two algorithms.
* Next is using navigation links within the program: If you enter "Buy washers" just after you check off "Call Bob", the computer could reasonably infer they are from the same project. If the program tracks all navigation then it might be able to use the patterns to help drive suggestions. What's important here is not that it can associate these two actions at the time but that the navigation from one to the other is preserved for future use.

Techniques like these will assign probabilities to links between actions and projects. At the end of the day, the user would still have to say which link is correct but choosing the project from a list of the top three suggestions is better than choosing from a list that might not even fit on the screen.

Similarly, when you select the project view, you could see completed actions, next actions, future actions, notes and a shortlist of likely actions for the project. The user could confirm or deny these links (or not, if it's not important at the time.)

Have you tried using plain text-ish list apps like Workflowy or Moo.do? I'm curious what your take on them would be.

I have not, but I will look into them. I've played with Ginko which I thought was really cool but didn't have a use for at the time. It would probably be difficult to write scripts to interface with these, which would make them less attractive than plain text.

I am not a programmer and wouldn't be able to write code to save my life, but a couple of years ago I too simplified my GTD setup and found I didn't miss the tools and features I once thought I could never live without.

I think I have seen you post about this before. I wonder if you had always used a simple system, would you be jealous of those features. Maybe you had to go through the process to appreciate that you didn't need them.

You may be interested to watching Carsten Dominik's video on Org-Mode. Org-Mode is a major mode for the Emacs text editor.

I keep threatening myself with learning Emacs, but I already have a text edotor that I can write scripts for (which seems to be Emacs' main selling point). I've never really looked into org mode. I'll do that. Thanks for the suggestion.

 

[Folke]

It's possible that it can't be done. However, the overhead can certainly be reduced.

* Most obvious is things like looking for common (but not too frequent) words to help suggest links.
* This would never link the action "Call Bob" to the project "Fix dripping tap". However, using data mining, Bob might be clustered with other previously used tradesmen and "Fix dripping tap" might be clustered with other home maintenence projects. You could reasonably expect an algorithm that used this info to link this action and project.
* Text is using links that are already there. If a project is linked to the output from going through the natural planning model (esp the brainstorming part) this could be a powerful input to the above two algorithms.
* Next is using navigation links within the program: If you enter "Buy washers" just after you check off "Call Bob", the computer could reasonably infer they are from the same project. If the program tracks all navigation then it might be able to use the patterns to help drive suggestions. What's important here is not that it can associate these two actions at the time but that the navigation from one to the other is preserved for future use.

Techniques like these will assign probabilities to links between actions and projects. At the end of the day, the user would still have to say which link is correct but choosing the project from a list of the top three suggestions is better than choosing from a list that might not even fit on the screen.

Similarly, when you select the project view, you could see completed actions, next actions, future actions, notes and a shortlist of likely actions for the project. The user could confirm or deny these links (or not, if it's not important at the time.)

Yes, I am sure it must be possible in principle to automatically generate semi-intelligent guesses about which project an action belongs to, and that this could reduce the length of the list of projects to choose from, and/or cause the list to be reordered such that the most likely alternatives come first. But obviously this would require software that has not yet been developed. And most of us probably would not need it:

• Some of us do not even want to link actions to projects. This is probably the case for most of those who prefer to keep their dependent projects actions in an external "project support" file rather than keep them within their main app/list, and who therefore only have the rare few "currently active" actions in the project listed in their app/list at any one time.
• Some of those of us who do link our actions to projects have no problem using the common methods (dragging, key entry with intelligent choices coming up as you type, automatic linking when looking at a particular project etc). This is probably particularly true for those of use who create most of our new actions during our projects reviews and/or who for some reason do not have a massive influx into the app's mail inbox.

I personally belong to the latter type. I enter possible future actions into each project as soon as something occurs to me. This usually happens during my reviews. Only to a more limited extent do I have entirely new thoughts or emails etc coming in during the day that give rise to entirely new actions. Most such input during the day only results in existing actions being amended. Those that do require a new action being written I have no big problem at all selecting a project for along with all the rest I need to enter for a new action - project, due date (if any; quite seldom), review priority, context tags etc. And as I said in an earlier post, I totally skip this "complete entry" step for quick actions that I expect to do later today and therefore just leave on my focus list for a few hours. Only if I decide to keep the task for longer do I do the "complete entry". I even have a "saved search" (aka Perspective aka Advanced filter aka Smart list etc) to find these incomplete tasks (just in case I had un-flagged them from my focus list by mistake)

I realize we are not all like that. I have heard many people on various forums whose lives are totally dictated by email, and who usually have a one-to-one relationship between task and email - every task emanates from some particular email (inbox item). And probably for these people it might even make sense to add to your tentative algorithm the fact that different sender addresses probably correlate to different projects, no?

Hashtags

I got a bit confused about your hashtags. I am not sure whether you use them as contexts or projects or areas or what.

Is it perhaps the case that the hashtags are intended for the type of algorithm you described?

 

[Folke]

cfoley,

I was just curious whether you had any thoughts about my comments in post #16 above (http://gettingthingsdone.com/forum/...e-switching-to-plain-text?p=171901#post171901) about Someday/Waiting and Ticklers/Start dates.

 

[cfoley]

Sorry for not responding sooner. I think I was typing my previous answer while you were posting that, and I forgot to go back and respond.

Waiting, Someday ...

This is something I have thought about a lot. Here is my classification, and only one of the three is expressed in terms of actions.

Next An action for me.
Waiting A deliverable from outside me in which I have a vested interest.
Someday An aspiration for the future.

However, the implementation can be independent of the conceptualisation. When I used Toodledo, I used their context field to name all my lists. GTD context lists started with the @ character. Project lists started with |. Someday lists started with ~. Inbox started with - to place it at the top. Therefore, everything I stored in Toodledo was just items and the semantics were revealed only by convention.

I think this is probably where you get the impression of how I treat Waiting and Someday. In a sense I do (because that's how they are stored) but I don't think of them like that.

My new plain text system evolved from a download of my Toodledo data. WaitingFor is still lumped in with the actions. I've considered making them their own file. Conceptually it would make sense but I don't know if it would improve my workflow.

I also designed (but didn't build) a GTD app centred around a database. I spent a long time refining the database schema and settled on this:

Like my Toodledo everything was just items. Items were assigned exactly one item type from the list [stuff action project tickler waiting-for someday-maybe note]. Stuff was the default and it marked it as an inbox item.

Items could also have zero or more tags. Examples of tags could represent contexts, locations, people, areas of focus, priorities, stars and even more. In fact tags and tag types could be defined by things outside the database. This means that the user could define his or her own. It also meant that the software could add its own too. If it wants to store red, yellow and green stars in the database, it just creates tag type [STAR] and tags #red, #yellow and #green.

One driving force for this was using other software that did not let me classify things in the way I wanted. Contexts, locations and people usually align very well, but not always. And you rarely want to assign all these categories for all items.

A case in point is my girlfriend. She had an agenda list. There were errands I could only run if she was with me. There was admin work we had to sort out together. In all, there were maybe four contexts where I could partition the actions between "just me" and "with girlfriend".

Nothing I had seen before would let me track this separately. Closest was using tags for all my classifications, and that had always got messy fast. Tagging with embedded semantics, and realising that I could never imagine all the useful tag types while developing, would (I think) solve that.

Ticklers, Start Dates

In the past, I have conflated actions and ticklers. In Toodledo, it was a case of changing the "context" from ~Tickler to @Work. I also used start dates to control when they appeared. The problem here is sometimes I would change the start date but forget to move an item to the tickler. The biggest problem here was repeating actions.

You mentioned it too: Ticklers are more similar to inbox items than they are to anything else. The difference being that all of them have been through the inbox before and have been processed at least once.

The example I always consider when thinking about ticklers is a paper flyer. With a physical folder implementation it's so easy, you throw it into whatever folder you want and forget until you process the folder. This example is always awkward for computer implementations. Do you copy or scan the information or do you make a note of where you filed the original flyer?

I think the temptation is to partially process it into an action and schedule it for the future in the guise of calling it a tickler. Instead of tickling the flyer, what I have sometimes done is add "Call the people on the flyer" to my tickler file. Then when the day arrives what I have looks less like "stuff" and more like an action so I just move it to @Calls.

Then when I've got my phone out I realise that I'm still not ready to make that call yet. It doesn't take too many misplaced actions like this to undermine confidence in my lists.

I have found value in defining the edge between a tickler and an action. The overhead of retyping something is small. Today I had no ticklers. Tomorrow I will have five. The average for me is about three. It's not a lot of typing and the hard edge is more valuable.

In separating ticklers and actions, I have found start date to be important for ticklers but not actions. I thought it would be useful to look up how long actions have been in my system. It turns out that's just a distraction and waste of screen space, at least for me.

I also find that "Call people on the flyer" is a poor tickler. They are better phrased as suggestions: "Am I ready to start ?" That prompts me to do some processing rather to automatically shuffle data around a system. I haven't updated this universally yet. "Take out bins" is still on my tickler file. I could rephrase it as "The bins are collected tomorrow" but in this instance it probably doesn't matter.

I have also decided that neither actions nor ticklers repeat. I should really create 52 ticklers to take the bins out each week, and an extra one to remind me to to set up another batch at the start of next year. I'm never going to do this because a reminder to retickle works well enough, and is more easily adapted if the council changes the collection day or I move house.

That's quite a bit longer than I intended. Thanks for your thought provoking post and sorry for not responding sooner.