Tennessee Department of Transportation 511

I haven't posted in over a week as I've been moving across the country from Austin, Texas to Washington, DC, and then waiting for the cable company to hook up my internet connection here. The trip itself took considerably longer than I had planned, due in no small part to my being stuck in this without moving more than a few feet for nearly four hours. I called my father to see if he could find out what was going on, and he directed me to the Tennessee Department of Transportation's 511 travel conditions service.

Speech Recognition
The service was terribly designed. First of all, it often could not recognize my speech. I would say in a clear voice, "Interstate 40 East", and it would say, "Sure, where do you want weather conditions?" Then there was no way for me to tell it it had misunderstood and I wanted to go back to traffic conditions. I had to just hang up and try again.

When I could get it to recognize the correct highway, it asked me which region of the highway I wanted conditions for: near Memphis, between Memphis and Nashville, near Nashville, or between Nashville and Knoxville. It didn't specify the boundaries between "near" and "between", and when I guessed wrong, I had to start over. You would think they could make rich use of speech recognition for such a program with such well-defined parameters: you specify a single route, or a single intersection, and it tells you any and all conditions in that area. Even something where they split the state into a series of regions and played regularly updated human-recorded voice messages for each one would have been far more useful.

Non-epochal Date Displays

The 511 line is poorly designed in general, but one particular problem is all too common in other systems. When I finally did get to a list of traffic conditions, they were listed in a format like this: "First incident [pause] reported July [pause] Seventh [pause] Two thousand nine [pause] Eight O'clock P.M. [pause] I-40, all lanes closed in both directions, at [pause] Exit 132 [pause] will clear at [pause] July [pause] Seventh [pause] Two thousand nine [pause] Eleven O'Clock P.M."

This system uses the ridiculous default assumption that the information you're listening to might be from some arbitrary time in which not only the month and date but the year are relevant. This assumption ought to be questioned in any new system today, but particularly for a system whose entire purpose is to provide up-to-the-minute information, it is absurd. There is no reason for this system to report any more information than the times at which the incident was reported and is expected to be cleared.

This is one of the areas where Facebook and Gmail are really ahead of the game. They avoid the problem of too much information by displaying dates in a current-time-aware mode. Dates from today display as "xx minutes ago" and after a while as "xx:xx PM". Dates from a few days ago display the month and day but not the time. Only when more than a year has passed is the year displayed. Date formats that assume they are not being rendered at some arbitrary time are incredibly easy to program, and should be a basic principle for UIs meant to display any sort of regularly updated information.