Helping Apple Mail’s Data Detectors

I like using Apple Mail’s Data Detectors to create iCal events, and have written about how I use them a couple of times. Today I learned something new about formatting email to get more out of the Data Detectors and save more time; and I want to write it up before I forget.

Last night I got my younger son’s baseball schedule. On paper. So I opened my laptop, typed up the schedule, and emailed it to myself so I could use Data Detectors to create iCal events. If you’re wondering why I didn’t just open iCal and enter the events directly, I suspect you’ve never tried to enter a batch of events in iCal—it’s very painful. Every entry requires several steps and lots of context-shifting. It’s much easier to just type in a bunch of lines of text—especially if your text editor allows you to add entire columns of text at once.

So the body of the email I sent to myself looked like this:

4/25/09    10:00 AM     Winding Creek North
4/29/09     6:00 PM     Knoch 7
5/02/09    12:00 PM     Winding Creek North
5/06/09     6:00 PM     Knoch 7
5/09/09    12:00 PM     Winding Creek North
5/14/09     6:00 PM     Knoch 7
5/16/09    10:00 AM     Winding Creek North
5/21/09     6:00 PM     Knoch 7
5/23/09     2:00 PM     Knoch 7
5/27/09     6:00 PM     Winding Creek North
5/30/09    12:00 PM     Winding Creek North
6/03/09     6:00 PM     Knoch 7
6/06/09     2:00 PM     Knoch 7
6/09/09     6:00 PM     Knoch 7
6/13/09    12:00 PM     Winding Creek North
6/17/09     6:00 PM     Winding Creek North
6/20/09    12:00 PM     Knoch 7
6/25/09     6:00 PM     Knoch 7

I fired it off and went to bed. When I got to work this morning, the email was waiting for me and I started adding events to iCal. The first one went fine. Because I’d set the Subject field to “Baseball,” that’s what the Data Detector put in the summary of the event. The date and start time were taken from the line I clicked on. Even the Location was correctly inferred from the text at the end of the line.

The second event had a problem. The summary, date, and start time were all correct, but the location was taken from the line above, not from the line I clicked on.

The location should be “Knoch 7,” but it’s “Winding Creek North.” A quick bit of experimenting showed that for every subsequent event the location was taken from the line above, not from the line with the date and time. This is pretty stupid behavior, and Apple should fix it; but unless and until it does, it’s the behavior I’m stuck with. I began testing other arrangements of the data to see what format would get the location detected correctly every time.

It took 4-5 tries, but here’s what worked:

Winding Creek North
4/25/09    10:00 AM

Knoch 7
4/29/09     6:00 PM

Winding Creek North
5/02/09    12:00 PM

Knoch 7
5/06/09     6:00 PM

Winding Creek North
5/09/09    12:00 PM

[etc.]

Separate paragraphs for each event, the event’s location on the first line of the paragraph, and the date and time on the second line.

You may think that spending the time to learn this quirk of Data Detectors is never going to pay off, but you’d be wrong. My sons are 12 and 9, and have years of multiple-sport seasons ahead of them. Now that I know how to format a schedule—whether by typing it myself or by editing what someone else sends to me—the 20 minutes I spent figuring it out will be repaid in just two or three seasons.

By the way, iCal’s default 1-hour duration isn’t right for these games, but I don’t worry about that because I already have a script for making batch changes in event duration.

Update (5/13/09)
I’ve learned that if the first event is at the very beginning of the email, the Data Detector may take the location info from the second event. To avoid that, add an introductory paragraph or a few blank lines to the top of the email.

Tags:


One Response to “Helping Apple Mail’s Data Detectors”

  1. Rob says:

    I have a hunch that the data detector isn’t parsing data based on the lines the information is on, but rather recognizing address-like words and context in which the data is presented. “Knoch 7” doesn’t look like a place. It could be a name. It could be anything really. If instead it was something like “Knoch Building 7, 37 Baker Street”, it might use that in the original format. I use the data detector a lot and I know it also uses context, like an address following the word “at”. I hope that it gets better, because it would make event coordinators’ lives easier.

    Rob