The Data of Dates
I’ve blogged before about how I think calendars are to dates what pie charts are to numbers, but recently I’ve been thinking a bit more about this issue.
The background to this was a discussion I had several months ago around the pros and cons of using calendars for date range selection, for example in booking a hotel. As with many design issues, this is one heavily encrusted with tradition and gripped by the dead hand of the “design pattern.” In an attempt to think about it more effectively, I cast the calendar (in the context of date range selection) as an anti-pattern: wasting space; requiring you to interact in more than one dimension; an inappropriate emphasis on days of the week, and other problems. In response, I came up with the idea of a time line instead. That too had flaws (not least because my initial approach attempted to build in too much into a single UI), but I think it had legs.
The calendar anti-pattern subsequently got me thinking about the presentation of dates in general, and in particular for the purpose of deciding which dates to pick for an event. For example, I am often contacted by beer-swilling loons to accompany them on trips to the pub, to see films or endure dinner and light conversation a their place of residence. These are all usually evening events of indeterminate duration. In a different context, I am expected to keep track of meetings I must attend, events I must speak at, and flights I must catch. These are all usually events of exact duration, often under the control of other people: they can be cancelled, moved or otherwise manipulated without my prior consent.
At work I am forced to use Microsoft Outlook for email (a UI so bad as to allow somebody at Google to design a vastly superior interface almost without trying) and calendaring. To be fair, I currently using Evolution at home, which isn’t actually much better, but that’s a different matter.
The very use of the word “calendaring” when referring to managing a diary shows how entrenched the notion of a calendar is to our idea of how to manage time graphically. The traditional calendar layout places an emphasis on discovering the relationship between a date and a day of the week (eg is the 12th a Friday?), and to a lesser extent on showing that some months have more days than others. Pressing this interface into the service of managing a hectic diary seems a classic case of using the wrong tool for the job.
For example, if I have a choice of attending an event at the start or the end of a week, the first issue is to understand whether I can fit any such attendance around my existing commitments. But the raw number of commitments per day isn’t the whole story. Some commitments are optional, some I know will probably be cancelled at the last minute, and others open-ended or otherwise flexible. An interface that allows me to make a good decision about where to place a new commitment in my diary is called for. When considering all this, it’s highly unlikely that I will give a damn about whether the 12th is a Friday, or if an event falls in one month or the next. What I want to know is will it be possible to attend without pushing out other stuff or killing myself trying to get there on time.
One design direction we could take would be to combine a time line with a zooming interface, and introduce some symbolic representations of the types of commitment involved. This is not a trivial task though, and needs a good deal of experimentation.
This post is therefore a run-up to some experimentation along these lines. Meanwhile, if anyone has any thoughts to offer on the subject, let me know.