Tivo Owners: Relax Please
Nov 20, 2004 in Usability/HCI
So TiVo recently announced that they're going to run banner ads when you fast forward through ads. The blogosphere went wild, not least becase of the LA Times' inflammatory headline, "TiVo Will No Longer Skip Past Advertisers". TiVo is all about the next generation of TV watching, so it's natural that, during the product's evolution, there will be changes, and these changes will make some people uncomfortable. But this seems like an authencally good idea, with little downside for either viewers or advertisers. All PVRs (or DVRs), including TiVo, make advertisers scared, for two reasons: PVRs let users fast-forward through ads, thereby ignoring marketing prodtimeucts that cost millions of dollars to produce and place PVrs let users watch TV shows at unexpected times ("-shifting"), which can mess with demographic predictions Viewers love PVRs, because: PVRs let viewers fast-forward through ads PVRs let viewers watch shows when they want to watch shows Clearly, we have two stakeholders whose interests are in complete opposition, right? Maybe not, if we think about what these stakeholders actually want, when it comes to ads. Advertisers want viewers to attend to, and retain, their ads Viewers want their desired content to be interrupted as little as possible while they watch TV That second one is very important. It's not about ads, per se, for viewers; it's simply that viewers, quite naturally, want to see their show uninterrupted. Who actually likes interruptions? Users don't fast-forward because they hate ads, users fast-forward because they hate being taken away from their desired content. Most of these fast-forwarding users happily watched 30-minute ads for products like GI Joe, The Transformers, He-Man, Captain Power, and other products like that; in those cases, the ads were the content, and nobody complained or tried to skip them simply because they were being sold to. The fast-forward banner ad does a good job of fulfilling both advertisers' and viewers' needs. Viewers get minimal interruption. Advertisers get an ad that will be closely-attended as the user focuses on fast-forwarding only through the ads and not through the show. This is a great solution for a new way of advertising.... Read on...
The Santa Monica Farmer's Market Accident: Did The Car Cause It?
Jul 20, 2003 in Usability/HCI
There was this awful accident in Santa Monica last week -- an elderly driver got in a minor fender-bender, got confused and drove into the street Farmer's Market, which was packed with pedestrians and farmers peddling their goods. He killed more than ten people, including a two-year-old girl and an elderly survivor of Stalin's oppression. There are a great many issues that have been found already to have contributed to the accident, from the initial fender-bender to the fact that Santa Monica only used wooden sawhorses, not concrete Jersey barriers or metal posts, to stop traffic from entering the Farmer's Market, which was on Second Street itself. One factor that hasn't been discussed much is the proximal cause of the accident, admitted by the driver -- he confused the brakes and the gas and floored it while he meant to brake. According to the LA Times, this is a common error and has happened more than 10,000 times in the past 20 years. Apparently, it's particularly common among older drivers. But it's not that odd of an accident, when you think about it. A driver doesn't normally look at the pedals at all, and on some cars they're basically impossible to see when you're driving. We don't expect people to carry out any other tasks in which they can't see what they're doing -- sure, people touch-type, but many more hunt-and-peck. It's only in driving that virtually every single person is expected to be able to carry out major tasks -- operating the pedals -- while they attend to another, substantially different task, working the wheel. The nature of this task seems to increase the chance of errors just like the tragic one that took place in Santa Monica, in which the operator makes a serious mistake in the secondary, non-viewable task. The software project manager in me wants to fix the interface to reduce the chance of this error. For instance, we might move the throttle control and brakes to the wheel column, a configuration already used by the disabled. Or we might put switches on the wheel itself, near where drivers' hands should be. Usually, fixing a broken interface involves just this kind of an approach -- thinking outside of the box to place controls and options in more useful, reasonable places. But driving is a special case -- dozens of millions are already trained in using the existing system. And learning a new system always results in an increased rate of errors, errors we can't afford in a new throttle control system (after all, the goal is to reduce the rate of injuries). So, we need to work from the existing approach and expand or adjust it prudently to limit the kind of errors that are our targets. I can think of two reasonable modifications: Display a light on the dashboard to indicate acceleration. This light should be hooked to the pedal itself -- perhaps pressing the pedal could close a circuit. A company could probably fairly easily produce a kit that garages could install on existing cars. This light would inform people when they're accelerating by command (as opposed to by accident), so, if they're expecting to stop, there will be visual evidence that they're using the gas pedal. The LA Times article states that elderly... Read on...