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.

Book A Month Challenge for March: Craft

Morris, William. 1894. The Wood Beyond the World. A facsimile of the Kelmscott Press ed. New York: Dover, 1972.

Although Morris was a late-Victorian contemporary of Conan Doyle and Kipling, he affected a 17th Century style of English in this romantic fantasy about a young man driven to a quest by misfortune at home and by visions of a beautiful Lady and her two mismatched servants.

Golden Walter, our Hero, is an honourable and handsome, but common, young man. Cursed at home by an unfaithful wife, he leaves on a trading ship to avoid causing a feud between his father's family and that of his estranged wife. While trading in far lands, he sees visions of the Lady, her beautiful maidservant, and an ugly dwarf, but resists the natural urge to hunt for the source of these visions out of his sense of duty to his father's ship. In the farthest reaches of the empire, he receives word that his attempts to avoid a feud have failed, and that his father has died, so he sets out to return home. Unfortunately, the elements conspire against his honour and drive him into strange heathen lands and the country ruled by the Lady of his visions and the maidservant with whom he falls in love. The novel has a strong episodic structure, with Walter moving (or being moved) from encounter to encounter, meeting all of the usual fairy tale tropes until the typical "happily ever after" ending.

A note on the edition: While many libraries have The Wood Beyond the World, my copy is a photo-facsimile of the Morris's original Kelmscott Press edition, which takes some time to get used to reading for the modern reader, but is very pleasing to the eye.

Social Aggregators

With Google's OpenSocial API, we're starting to see hints of the social networking interoperability I talked about a while ago, but the idea of "social aggregation" seems to accomplish some of the same goals. Feed aggregators, which gathering together information about updates to websites and present them all together for the reader's convenience have been around for a while, but these new social aggregation sites provide a simple way to gather together information about social network participation and online identity into one place.

There are two basic models of social aggregation services:

• I aggregate my identities into a portal, which might be a public site I can share with friends as a "portal to all things David", or a private starting point for tracking and accessing my online activities;
• I aggregate all my friends' identities into a portal, so I only have to go to one place to go to see what they're all up to, taking stalking to a whole new level.

(I came up with the name "social aggregators" independently, but it's pretty obvious terminology.)

Aggregating oneself seems to be a fairly basic way of handling online identity management, especially if one has a broad portfolio of online content and a common name (not a problem for me). The simplest example of this kind of aggregator is the site ClaimID, which doesn't provide information about updates to sites, but just gathers together all of your information into something like an online CV.

Aggregating all your friends is the more useful service: I don't have to go to every social network that my friends are on to find out what's going on with them. The service that provides the creepiest example of this is Spokeo. Once you create an account, you can either upload your address book, or, more simply but much less secure, give it your hotmail/yahoo/gmail userid and password and allow it to harvest your address book directly. Once it knows who's in your address book, Spokeo will go out and harvest all the social networks it knows about and reports to you what your contacts are doing on those networks. Spokeo goes to great lengths to explain that it is only accessing information that is publicly available on the net for anybody to see, and thus isn't an invasion of your privacy. But having Spokeo trawling the net for everything about oneself just feels qualitatively different from connecting with friends as one becomes aware of their activities in the various venues.

Between services like Spokeo and google alerts, the possibilities for Total Information Awareness aren't limited to just the government. Maybe privacy really is dead.

On Keeping a Reading Journal

I'm usually not very good at keeping a journal or diary (see, for example, the regularity with which I write in this particular venue). I've tried several times over the years, because I think that I should, and I never last for very long. At the beginning of the year when so many blogger were posting various stats about their reading habits last year, I decided to keep a log of what I read. "Nothing could be simpler," I thought, "it's just data gathering!"

And so it is. I've got a spreadsheet on google docs. Whenever I start reading a book, I fill in the author and title, whether it's fiction or nonfiction, and the date I started reading. When I finish, I fill in the end date. And I get to do some simple spreadsheet programming to keep various statistics, which is always fun (no, that's not sarcastic, although some people may think it ironic).

There are some operational problems. Whenever I start reading a book, I have to remember to record it, at least within a day or so, so I get the start date right. For some reason, recording the end of a book is easier for me to remember. And, of course, I need to be near a computer; I foresee this causing problems during my summer reading binge, when there's not a computer in sight on the upper reaches of the Ottawa River.

More interesting than these mechanical issues, which are fairly obvious, I've already started to notice some effects on my reading behaviour. I normally read quickly: for my vacation I usually plan to read one book a day (if nothing else, that means I won't run out of books), but so far this year, it's taken an average of six days to finish a book (of those I've completed). The book I just finished yesterday took seventeen days to complete, but that has nothing to do with the difficulty of the book or my lack of interest in it, and everything to do with the fact that I've started a big project, and don't have as much spare time to devote to reading.

Which leads to the biggest effect of keeping a reading journal on my reading habits: I am loathe to start a new book until I know that I'll have time to devote to it. It seems that the incomplete books on my list (two right now, one dating from Christmas), impart a certain weight, and that, for me at least, recording data has moved me from "always have a book on the go" to "promptly finish the books I start." I suspect that I'll read the same number of books regardless, it's just that I won't start them until I have some spare time, so I'll have short reads with large "illiterate" gaps, rather than continuous slow reading.

Of course, if I really wanted to rack up the numbers, I'd just stop reading The Economist every week (but then, I'm falling behind on that too).

BAM Challenge: Heart

Bennet, Alan. The Uncommon Reader. New York : Farrar, Straus and Giroux, 2007.


Bennet starts with a simple premise: "What would happen if the Queen suddenly developed an interested in reading for pleasure?" This short novel, a mere 120 pages, is a light exploration of that question, and shows how reading leads to neglecting one's duties and avoiding human companionship.

But it also shows how she grows through her reading. The Queen, after even just a brief exposure to fiction, seems to think more about the people around her, and show genuine concern for her staff in small ways that she never did before: reading, and exposure to the human condition, has given the Queen more of a heart, made her more compassionate.

(Sometimes it can be a stretch to fit a book into the theme, but I know I can do it!)