In response to a popular recent item — “We posted weekly.pdf to the website. Isn’t that good enough?” — Sarah Allen echoes my favorite Sergey Brin quote. Sergey said: “I’d rather make progress by having computers understand what humans write, than by forcing humans to write in ways computers can understand.”
Sarah, citing weblog software as an example of software that enables people to write naturally, goes on to say:
Likewise, it is natural to record calendar information overlaid on a timeline with day, week, and month views that mimic traditional paper visualizations of time. This enables the software to generate structured data without people needing to think about it.
I mostly agree with her about blog software. And I would have been inclined to agree with her about calendar software too, until I started looking seriously into how people do — and often don’t — use calendar software.
Let’s look at a fragment of a softball schedule which, significantly, has been written as an Excel file:
| Fri. Apr. 25 | 6:15 | Whitney Brothers | Greenwald Realty |
| 7:45 | Servpro | Athen’s Pizza | |
| Sat. Apr. 26 | 9:00 | WR Painting | Peerless Insurance |
Notice what’s missing? There’s no AM/PM, because everybody is expected to know that 6:15AM would be too early for a Friday game while 9:00PM would be too late for a Saturday game.
Yes, it’s natural to view calendar information in ways that mimic traditional presentations. But it’s unnatural to write it using calendar software that constantly nags you to specify nitpicky details like AM and PM. People understand what’s a reasonable time for a Friday or Saturday game. Why can’t software figure that out?
I guess that’s why another recent item on parsing human-written date and time information struck a chord with readers. Until we create (and widely deploy) naturalistic interfaces, people are going to avoid the Procrustean bed that is conventional calendar data entry.
As a sometimes date-manipulation geek, I like this topic for all of the considerations that it illustrates.
My concern is that the requirements for context are pretty intense and the software designer is going to bolt certain guesses about that into the software in ways that can never always be right.
One that gets me has to do with understanding time changes. When I calendar something, what if it is something that is happening in a different time zone than I am in at the time? (Outlook makes me crazy about this). How about start times and end times in different time zones (or different daylight-time adjustments), as when recording departure and arrival for an international, or cross-country flight.
I have no idea how we can get that “right” and I suspect that it will involve my being able to somehow specify the exceptional cases easily while there are reasonable defaults for the usual cases.
If I did calendaring like that, as a power user I might want an easy way to introduce some custom templates for events or time situations that I could easily assert for a calendar item.
But the parsing bit is not the hard part. Actually, it is fun to do. Knowing the context and tacit conditions (such as baseball game times) is the hard part and maybe the problem is to get the computer out of the way in a helpful manner rather than putting it more in the way.
Something to think about. A great illustrative case. Thanks.
> Knowing the context and tacit conditions
> (such as baseball game times) is the hard
> part
Exactly.
And getting it right doesn’t necessarily mean nailing everything. In this case it’d be great if the data entry software could assimilate some contextual clues, make some assumptions, show you what it assumed, and then enable you to easily confirm or correct.
It’s interesting to think about how to help the software acquire those contextual cues. I’ve never thought about this until just now, but suppose that you told it where you intended to publish the information. The situation of that XLS file — its neighboring pages and their connected sites — provide all sorts of clues about the softball league schema, in the Roger Schank sense of the word schema.
We receive meeting notices from the school with the
time & date but NOT the day of the week! It just
drives me crazy!
Software can’t figure it out because software doesn’t play baseball :)
Okay, but it’s not just a bad example. It’s demonstrative of the problems of context in social situations. It’s not simply that software’s too stupid.
I do agree in general, though. It would be a better world if everything worked without me having to communicate what I want.
> Software can’t figure it out because
> software doesn’t play baseball
In general I think that’s a correct statement about AI. Not having a body, and not living in society, software can’t experience life and and learn from it.
OTOH, software can detect patterns. One of those patterns is that softball games in the spring and summer in New England occur at certain times but not others on weekdays vs weekends. Lots of examples of this pattern are discoverable on the Internet.
Wouldn’t it just be easier if 24:00 format was the standard. No worries about am/pm…
@Sine Nomine: if the notices were sent in a standardized calendar data container (iCalendar, XML) then what you use to receive it could easily provide day-of-week from the date, as the algorithms are pretty well known.
@Robin Capper: carry it a step further, abolish time zones, and do everything in UTC.
Time zones (at least in the US) were invented to solve a problem (railroad schedules), now they’ve become a problem in some ways – although most software can deal with them
@all: It’d be sufficient for software to make reasonable guesses, as long as you have the opportunity to make corrections to its guesses.
@Robin Capper: carry it a step further, abolish time zones, and do everything in UTC.
Time zones (at least in the US) were invented to solve a problem (railroad schedules), now they’ve become a problem in some ways – although most software can deal with them
That’s what Phil Windley thinks too:
http://www.windley.com/archives/2008/12/a_member_of_eastern_standard_tribe.shtml