Thinking About Dates on To-Do List Web Sites

The great thing about reading time management books and comparing task management websites is that it's not really procrastinating.

David Allen's book, Getting Things Done, is the current hot time management textbook (and has been for the past few years). Like many of these books, it's common sense distilled into a "system", and sold at management consulting rates, with much talk of "next actions", "workflows", "processes", and "models". But it all boils down to to-do lists and a process for reviewing them. While I wouldn't pay to attend a workshop on the method (nor would I send my staff to one), I do think that the book is definitely worth the $15 cover price and the day of time it would probably take to "implement" the system on one's own.

Because Allen is the current hot property in the time management sphere, task management web sites all claim to support the "GTD" system, and all claim that their competitors are lacking in some way, providing partial support for GTD, at best. I have a couple of pages of notes about two of the more prominent to-do list management sites (Remember the Milk and Toodledo), and will be posting my thoughts on them later.

But all this reflection on to-do management, and my experimenting with two different systems for accomplishing this fairly simple task, has got me thinking about the problem of dates. When I write out the simple sort of to-do lists that I use, I tend not to assign dates to the items on the list, for the simple fact that everything on the list needs to get done now. Of course, this can lead to things getting deferred indefinitely, since there's are no deadlines attached them. Some web systems don't display tasks on their default screen unless they're due "soon", and undated events are never due, according to those sites. So, I put dates on all my tasks on these systems. And that led to the problem: there are two ways to interpret the dates.

A Date is a Deadline. I think most of us think about dates on lists of tasks as deadlines: "My taxes are due on April 30," "I have to write a book review by the end of the month," and so on. Unfortunately, most automated task management systems that I've experimented with over the years (including Palm PDAs and various desktop calendar programs) don't work well with this model. Once you've associated a date with task, the task is tied to that date.

If a date is a deadline, then I have to be able to tell my task management system how long I think that the task will take, so that I can be reminded of the task in time to be able to finish it by the deadline (a task manager that tells me on Thursday morning that my taxes are due today is basically useless). Ideally, the system would also provide a way for me to track progress toward completion, so that tasks slide up and down the list relative to each other depending on their deadlines and how close I am to completing them, relatively speaking.

A Date is Almost an Appointment. Most of the time, the date associated with a task is a deadline, but sometimes it is the date on which we should, or must, perform the task. This is subtly different from an appointment, I think: "go to the optometrist next Wednesday" is an appointment, but "put the garbage out Tuesday evening" is a task to be done at a particular time.

While this sort of date is much less common, it is the type of date that most automated systems handle well. Online to-do management systems are, primarly, rich systems for managing the old-style "tickler" file.

Computer people like to talk a lot about the Sapir-Worf hypothesis that the language one speaks limits, or at least affects, the way that one thinks about the world. This is probably because in computer programming, that's true: if you're programming in Fortran, you won't be thinking about object-oriented control structures. It seems to me that the same thing can happen in task management. If your task manager associated dates with tasks in a very concrete, way, then those dates will stop being deadlines and become pseudo-appointments.

I recently ran across a quotation about computer usability:

Using a computer should be simpler than not using a computer.

For the kinds of things that I need to accomplish with my task management, I think that the computer's not quite ready to beat the pad of paper yet. But that won't stop me from trying to figure out how to make it work.

The Most Important Programming Language I've Learned

I've programmed in a lot of different languages: BASIC, Pascal, Cobol, Fortran, WSL, C, perl, icon, and more. I've been paid to program in C, perl, Bourne shell, and others, but it turns out that the most important language I learned was one that I picked up on my own, to play with: Scheme.

I'm just learning Javascript now, as part of the next phase of Evergreen development, and it was pretty easy. I just flipped quickly through the first part of the book to get a flavour of the syntax and learn the rules for scoping, and in about thirty minutes, I was ready to get started. The last new language that I learned was Python (which I started working in last year). It took a bit longer to get into Python, because it's a much richer language that Javascript, but it still didn't take long, and Python has become my favourite programming language.

But Scheme is the most important language I learned because so many other languages have adopted some of its core concepts. Modern Perl, Javascript, and Python books all spend a great deal of time talking about "lexical scoping" and what this means for variable access, and how one can define functions inside of functions, and what that all means, and they usually give the same tired example of writing a function that returns a function (usually a function that adds 5 to its argument).

Yeah.... Like Scheme did back in the '80s (except Scheme calls it "statically scoped"). Everybody keeps reinventing Lisp (and Scheme is just a specialized educational dialect of Lisp), but nobody's managed to do better than Lisp at so many things. The Evergreen guys are regularly doing sexy dynamic function creation stuff without even realizing that they've successfully recreated very-high-level programming methods that Guy Steele considered normal back in the early '80s.

Start by learning Common Lisp or Scheme, do some continuation-passing programming, and after that, everything new is just syntax.

Building Systems that Support Librarians

I've said in the past that one reason why the ILS vendors build the systems that they do is because their customers are librarians, not library users. Unfortunately, that doesn't explain the failure of our ILSs and other systems to support the work that we do as librarians.

Imagine this scenario: We have some money left at the end of the year, so we're looking at what we can spend it on. One option is to pay the one-time fee to purchase electronic access to journal backfiles (and yes, this is "purchase" for us; it will be loaded on the consortial server to which we will have ongoing access). Of course, in order to decide if buying the backfiles is worth what the Large Dutch Multinational (LDM) is charging, we need to figure out how much the backfiles might be used. One would think that it would be easy to use a list of ISSNs to generate data from the various sources of usage data that are available to us.

Unfortunately, that's not the case. Part of this is our own fault, for creating internal processes that are not conducive to gathering statistics as we go, and part of it is the fault of vendors who don't provide convenient access for "small bulk" access to data to which we subscribe, or just don't give us easy access to our own data. For example, given a list of one hundred ISSNs, how hard would it be for you to find out how many ILL requests were placed for each one?

As a programmer, I'm willing to accept a certain level of data format inconsistency between systems, since I can write my own tools to even out such problems, but my programming background also makes my sensitive to the data that's just not available, or demands inordinate amounts of manual (ie, typing and browser clicking) to reach it.

We must begin to take notice of how all the systems we use professionally fail to mesh, and demand that vendors make it easier for us to gather the scattered data we need for decision-making into a coherent format: a librarian's decision support system.