I bought a Subaru recently. There's a spiffy site for Subaru owners, but just try getting in with a browser you might have in your car.
My.Subaru.com wants JavaScript, even though I can see no rationale for it. The site serves three major purposes: vehicle maintenance tips and scheduling, recall notices, and general information about owning the car.
Several of these should be accessable on any web client, especially wireless ones. If you put your odometer readings into the site, it will more accurately know when to send an email reminding you of upcoming maintenance tasks like oil changes. The site's browser requirements are so stiff that no wireless client could ever hope to live up. I am best positioned to read my odometer when sitting in my car, but there's no way to update the web site from there! And of course, the time I am most in need of the roadside assistance phone number is not when I'm near my desktop computer.
Curiously, the designers chose to represent the odometer as graphics. This is a bad decision from the start, for all the usual reasons I hate to see graphics where text would suffice. More troubling, though, is their choice of graphics. The odometer on the web site is of the classic, wheeled variety. The odometer in my car is a backlit LCD. The excess stylizing of the site makes it more alienating than comforting!
Far, far more annoying, though, is the Flash demo. I hate Flash and I hate almost everything I've ever seen done in Flash. This time was no exception, and the demo crashed my browser. An earlier draft of this very article was also lost in the browser crash. The site tour took about a minute to load, was completely non-interactive, and had far too many transition effects and sounds for my humble 1996 Pentium. Crash!
There are a few spots where opportunities to use server-side technology for a better user experience are completely missed. There is a pull-down menu for estimated annual mileage. The settings are very far apart. Wouldn't it make sense for the server to calculate a reasonable approximation of my estimated annual mileage based on the actual data points I'm painstakingly entering? Maybe a graph of miles-per-day over the life of the car would be interesting. Even just a table of all of the times I've recorded the mileage would be an improvement. I get the feeling they only take my last entry and time as an intercept and plot the slope based on an extremely inaccurate estimated annual mileage from a pull-down menu. Stupid!
Another missed opportunity for server-side goodness is the maintenance schedule. In the printed manual for the car, there is a table of recommended service mileages that goes up to 120,000 miles. I like the idea of a car that lasts me 120,000 miles. I am given another reason for optimism: if I need service recomendations beyond 120,000, just add 120,000 to each mile marker on the table. The same table appears on the web site. Would you believe that the web site version also stops at 120,000 and advises adding 120,000 beyond that? Couldn't the server just start adding new entries according to that rule once my odometer, either estimated or actual, hit that number? Since computers are so good at simple things like copying a table but adding a constant to one column, this kind of boneheaded implementation is truly baffling.
Posted by ventura at March 28, 2002 04:34 AM