Poojan (Wagh) Blog

This last week, I took a GTD training seminar (led by Chris McIntyre). I thoroughly enjoyed it and decided to get back on the wagon. I’ve come up with a system that works for me (so far), but I decided I should post a review of some things that didn’t work.

I started picking up GTD in October of 2006. I decided I wanted work to just be easier. I had recently moved from Freescale to Motorola, which made my commute and therefore my work day much simpler. I wanted more of the same big gains and isolated GTD as a way of making my work-life easier.

I used a Windows Weekly coupon (from twit.tv) to get an audible free download and downloaded the audiobook. I tried to jump in it, surveying as much software as possible. I later bought the book.

I eventually gave up around November of 2009, when I moved from Motorola to Infinium.

Here are a list of approaches I tried:

1. Thinking Rock
2. Chandler
3. TiddlyWiki (MonkeyGTD and d-cubed)
4. Rainlendar
5. 2-subject notebook
6. 3×5-card based system

Thinking Rock

I picked up thinking rock because it was described as closely following the GTD methodology. The program itself includes the GTD processing diagram.

The problem was that it was slow—both in terms of the actual application performance, but more importantly, I found that there were just so many fields to populate and task/project entry was therefore difficult.

Chandler

I got on the Chandler bandwagon pretty early. It’s main attractive feature was the ability to sync between a server (Chandler hub), WebDAV, and email. I liked its ability to “tag” rather than categorize (Chandler collections are essentially tags). However, I often found myself without a computer (especially at home) and therefore without

MonkeyGTD

Out of the computer-based approaches, I probably liked MonkeyGTD the best (tied with Rainlendar). This was an earlier version of MonkeyGTD. Entry was easy. I even created an AutoHotkey script that would add items to the MonkeyGTD file. I was also able to embed my Google calendar right in MonkeyGTD. The print facility (and ability to customize it using CSS) was also very nice.

I eventually stopped using MonkeyGTD when I was put on an important deadline. I decided I needed something that handled both tasks and calendaring in one application.

Rainlendar

I then went to Rainlendar. Rainlendar is essentially a calendaring application, but it has some unique and powerful features. Most notably, it allows URL links in tasks and events. (More on this later) It handles tasks very well. It doesn’t natively include GTD identifiers such as project, context, etc. However, they translate very easily to Rainlendar (or any iCal-based application) as category and location. It’s highly customizable in its presentation. In addition, it has a fairly good print facility.

I ended up writing a small Python program to parse the iCal file used by Rainlendar and spit out a task list, by context (location). This allowed me to take things on the go.

I was using Rainlendar with WikidPad. Rainlendar would handle all my GTD stuff and WikidPad would hold reference information and logs. (I did try WikidPad for GTD, but I found it clunky at the time—and it didn’t include a true calendar.)

One of the things I liked the best about Rainlendar was the fact that one could enter locations (“contexts”) on the fly. In most other systems, you have to set up a fixed number of contexts (@Home, @Office, @Errand, @Call). The thing I learned from adopting this system was that contexts should be able to change on the fly. If I want to create a context for drinks with my friends, I should be able to type in @Beer at any time. (Okay, I’d be more likely to put @Cider).

2-Subject Notebook

I finally decided that all the time I spent tweaking computer-based GTD applications and researching others wasn’t worth it. I found that a computer-based GTD system was more distractive: every time I sat down at the computer to review my list, I would end up doing something else on the computer.

So, I decided I needed to go back to basics and implement the GTD system in a paper-based form. I’ll confessed: I actually used 2 sections of a 3-subject notebook. The first section would handle “projects” (a GTD term I still don’t like). The second section would handle “next actions” (another GTD term that I like). The second section is divided up into “contexts” (a GTD term that I’m fine with) with a context per page.

I numbered each item in each section. So, each project gets a number and each task gets a number. The numbering format is <pagenumber>.<projectnumber>. So, for example, on page 1 of the “project” section, I might have:

1.1 Personal Blog => 1.1
1.2 Front Lawn => 2.1

Page 1 of the “context” section might have:

@Online

1.1 Compare blogging providers for personal blog (1.1)

Page 2 of the “context” section might have:

@Errand

2.1 Buy grass seed and starter fertilizer (1.2)

So, by placing numbers next to each project, I keep track of the next action for each project. Similarly, next to each task, there’s a reference back to the project.

My weekly review involved going through the project list and seeing if the task was done. If it was, I needed to come up with a new task (or cross out the project itself). I decided that even single-action open-loops would get a project. (I tended to flip-flop on whether this was a good thing or not—and still don’t know.)

The main problem with this system was that weekly reviews were tough. I’d constantly be flipping between the two sections of the notebook. It got very tedious.

3×5-card based system

I next decided that carrying the 2-subject notebook around was too difficult. I decided that I should use 3×5 cards to hold project and task information. (I was using a hipster PDA for capture for a while.)

I formatted the cards as follows:

• Each project would get a card. The project name would be written at the top.
• Each task would get a line on the card.
• I bought a set of plastic 3×5 folders from Levenger, and assigned a context to each folder.

So, for example, my “Front Lawn” project would have its own 3×5 card with the task “Buy grass seed and starter fertilizer”. I’d therefore put it in the @Errands folder. (In truth, I don’t write the “@” on my folders; that’s just for your benefit, since everyone else that does GTD seems to have it.) As soon as I had the grass seed, (possibly at my next weekly review) I’d cross out that task (or check it off) and then write the next action: “mow front lawn”. The whole 3×5 card would then go into the @Home (or @Yard) folder.

I really don’t know why this system didn’t work. It was likely just the effort I put into it. I got lazy. Its main deficiency was that I had to have the right folders at the right time. I would then have to amass all the folders for a weekly review. That’s not hard to do. In truth, I just got lazy.

PostScript

I recently attended a GTD seminar. I now have more zeal for adopting it. In the next instalment (or maybe the one after), I’ll post what’s I’m trying next: a text-file GTD system.

I’m personally using Git to version-control my WikidPad files. However, Mercurial (and especially TortoiseHg) is equally well suited for this function. In many respects, Mercurial is simpler to use than Git. The only shortcoming I had with Mercurial is that there’s no managed branches; to branch, you create an independent copy of the whole repository (clone it).

Nonetheless, for most people, Mercurial will not only suffice but give quicker rewards than Git.

I don’t use Subversion for this purpose, because subversion has a centralized approach which requires a repository, separate from a working copy. Importing, merging, branching, etc., with subversion is a bit of a hassle. This “hassle”, of course, is purely personal taste; others will (strongly) disagree. In fact, for many other purposes, I strongly prefer Subversion to Mercurial/Git/etc.

Goal

By the time you’re done with the following steps, you should be able to:

1. Place a WikidPad Wiki under version control
2. Commit changes as files change
3. Revert to prior versions Read the rest of this entry »

There was  apost over at wikidpad-devel | Google Groups, where someone talked about using Drop Box to sync WikidPad databases. The person used the original_sqlite database format of WikidPad.

I personally like the “Original SQLite” format for storage. This internal database has the following properties:

The data for your wiki is stored in plain text under the data
directory of the directory your Wiki config is stored in. There is one
file per wiki word. The database to index the wiki is stored in the
file “wikiovw.sli”.

Which is great, because I get all the features of SQLite search/indexing, but all my pages are in a text format.

The great thing about this setup is that I can use version-control to keep them in sync. I originally thought about using SubVersion. However, I decided to go with a distributed version control system instead. I took a hard look at both Mercurial and Git. I decided on Git since it does implicit renames rather than explicit renames. This means that I don’t have to write any hooks in WikidPad for when there is a rename/copy of a page. Of course, I could do without this feature in Mercurial, and it would still work. It’s just nice that Git does provide the benefit of diff-based storage without the need for explicit copies/renames/moves.

So, I keep two WikidPad notebooks going: a Work one, and a Personal one. The Personal one is on all the computers at home (Windows Laptop, Windows Desktop, FreeBSD server). It is also on a USB thumb drive. One of the features of git is that the entire repository comes along with a working copy. Let’s say I’m editing a WikidPad page at home that I already edited on another computer. I don’t have to worry about syncing. I can check in both changesets and merge later. This is a feature that Mercurial also has.

That’s the great thing about text files: they work very well with version-control systems.

I also use the ScrapBook extension from Firefox to archive/annotate pages from the web. The extension saves an index of the pages in RDF format. RDF is a form of XML, which was touted as a better way to save data because it is text-based. Curiously, XML doesn’t work well with any merge tool I’ve come across. I’ll post about my descent down this rat-hole (and how I got around it) later.

I use WikidPad at work (and at home) to keep logs/notes on tasks that I’m doing (or want to do). One nice feature of WikidPad is that it has an “always on top” setting which keeps the WikidPad window on top while another window (behind it) is active.

I use this feature with my VNC session (most of my work is on Linux) so that I can copy/paste results and snippets. Unfortunately, a lot of time the result itself (due to its placement within the VNC session) is right behind the WikidPad window. It would be nice to have WikidPad be transparent.

Turns out, AutoHotkey already has this feature. The following script does the trick:

    #T::
    DetectHiddenWindows, on
    WinGet, curtrans, Transparent, A
    if ! curtrans
        curtrans = 255
    newtrans := curtrans - 64
    if newtrans > 0
    {
        WinSet, Transparent, %newtrans%, A

    }
    else
    {
        WinSet, Transparent, 255, A
        WinSet, Transparent, OFF, A
    }
    return

    #w::
    DetectHiddenWindows, on
    WinSet, TransColor, Black 128, A
    return

    #o::
    WinSet, Transparent, 255, A
    WinSet, Transparent, OFF, A
    return

    #g::  ; Press Win+G to show the current settings of the window under the mouse.
    MouseGetPos,,, MouseWin
    WinGet, Transparent, Transparent, ahk_id %MouseWin%
    WinGet, TransColor, TransColor, ahk_id %MouseWin%
    ToolTip Translucency:`t%Transparent%`nTransColor:`t%TransColor%
    return

Key codes:

<Win>+T: Increments transparency by 25% (with wrap-around)
<Win>+W: Set black color to be 50% transparent (also does click-through)
<Win>+O: Reset transparency settings

Here’s a screenshot of a partially transparent WikidPad hovering over a full-screen VNC session; Ion3 is my window manager: