Contributed by Matt Curtin
Greetings from New York. On my own Web site, I have previously railed against
stupid user interfaces.
Amazingly, my most recent rant failed to bring about a swift conclusion to all of the stupidity in the industry. Lately I have had a few more experiences with local providers that falls into the same category of absurdity: useful information being made completely useless by ridiculous design decisions.
My first example is from eight weeks ago. Riding the bus home on Thursday, June 12, I noticed that Main Street through Bexley was dark. That all retailers there would voluntarily turn off all of their lights during early evening business hours seemed somewhat improbable; that such an extraordinary event would coincide with the street lights being left off seemed less likely still. I thought that perhaps I would not be jumping to too hasty a conclusion to imagine that AEP was confronting some obstacle or other in the provision of its service. The question of whether I might have power at home was more than idle curiosity: an outage at home could well affect my ability to prepare for my last appointment for the day.
Thinking that AEP was the sort of forward-thinking company that might be inclined to make good use of the technology, I directed my BlackBerry's Web browser to AEP's Web site, in search of information on known power outages. The site wasn't particularly easy to navigate on my phone's browser but it appeared to be workable. I took one of the first options available in an attempt to get outage information: I entered my ZIP code into a box and hit the submit button, only to discover that the form would not submit because it required JavaScript. Give me a break. So I went into the browser settings to enable JavaScript and submitted the form. The form, apparently, is used to determine which of the AEP sites is best to navigate and I was consequently directed from
aep.com to
aepohio.com. Sheesh. All of that fooling around with browser configuration just so that I could be sent to a different Web site. There's no real excuse for a form failing to work because JavaScript isn't enabled on the client.
After some more navigation, I found that
outage information is, in fact, posted online. Sadly, that didn't mean a successful conclusion of my quest to find what I wanted. In order to see whether the outage in my particular neighborhood was known and what was known about it, my phone's browser was presented with still more client-heavy content. Flash. So then I would need to navigate a map of the state so that I could mouse-over a highlighted area so that it would tell me about that particular outage and the number of people affected. This is not helpful to me at all. I already told the site my location (my ZIP code, remember?) but now it's telling me that I need to have Flash player installed on my telephone to find out if they know about the outage in my neighborhood.
So, let's get this straight. There's a power outage. My telephone, powered by batteries, can't have the information because it doesn't have a desktop application like Flash installed on it. And even if it did, the content would be useless because of the screen size. So in order to get the web site to tell me about the outage presently affecting me, I need to use my computer and broadband Internet connection. How, pray tell, am I meant to do that when the power is out?
I wasted ten minutes of my life to be put into this position. Instead of pretending to give me useful information, why wouldn't AEP just tell me to go away? What am I going to do, switch power companies? Like I will get a different power grid or something, and someone else will present more useful information about what's happening out there. I'm skeptical.
What should have happened is something like this: a client submits data to the form and if it's JavaScript capable, it runs the JavaScript. If it's not JavaScript capable, it submits the data anyway and lets the server work out whatever data validation is being done on the client side. Then, of course, once a relevant results page is being displayed, there would already have been interaction with the client in that session, and it would know by then if the client were capable of displaying Flash content. The real question is why Flash content is required at all. This is a simple job. If you know the ZIP code, you know if there's a problem in the ZIP code, and you can display the information easily enough. An enumerated list would do the job, in HTML. "But it's not pretty!" complains the designer. A pretty application that won't work is of zero value; pretty is relevant only when all other things are equal. What's more: there is such an HTML box on the outages page, but only reports “major” outages. I don't care about major outages, I don't care how many of them there are, I don't care what else is going on around the state. I want to know about my outage! If you give me that, then feel free to ask if I want to know more. The whole system looks to me like it's designed not for people affected by outages but for news organizations collecting information to put on the 5:30 broadcast because the
eight stories about the weather wouldn't be complete without some impressive tally on the number of number of people who can't watch their televisions for lack of power.
So much for AEP's brilliant use of technology to get information to people who need it.
My next example brings me back to
COTA. On Tuesday of this week, I got to my bus stop at 5:50
A.M., about five minutes ahead of the scheduled arrival of my bus. At 6:12, I began to get annoyed. A minute before, the bus after the one I wanted should have rolled by, but did not. These sorts of things happen mostly when it rains, of course. “I know,” thought I. “I'll use my BlackBerry™ to get useful information from COTA's helpful web site!” So I'm an optimist.
I've complained about COTA's web site enough over the past six years or so, which makes me feel compelled to acknowledge that they've come a long way since that dreadful site that as far as I could tell never really worked for any purpose but to let you download PDFs of the route schedules. Now such things as system maps are available—so you can figure out which route schedule to download. Then there's this newfangled planner thing from Google that gives options to get around on the bus, which is tremendously helpful since COTA's trip planner is, uh, imperfect. And finally, the
coup de grâce, COTA's Real Time Bus Finder. Select the route you want, and you find little dots all over the map showing you all of the buses on that route. Click on them and you'll find out which specific bus it is, how it is doing relative to its schedule, and other such goodies.Naturally, this doesn't work on my mobile device. I can't use it when I'm at the bus stop. When I'm at the bus stop, I also don't care about all of the buses in the system. All I want to know is when the next bus will come. The data are available—the bus finder is cool, feeding telemetry data up to the system as it rolls down the street—but the problem is in presentation. I don't know whose perspective this is meant to take, but the simple fact is that this tremendously client-heavy presentation not only overwhelms me with information that I don't care about but makes it impossible for me to get the information that I want.So here's an idea. How about if I could choose a bus stop. Maybe if not every stop in the system would be made available, at least I'd get a few of those familiar “timing points” that are used on the printed schedules. Then I could with my mobile device, get information about the next few buses coming to that stop (or timing point), along with which specific version of the route each is (generally speaking, how far that particular bus goes). Then I could select one from that list and see whether it's on-time, behind schedule, or (annoyingly) ahead of schedule. This would be useful, making it unlikely that I'll see it anytime soon.
An important lesson exists in all of this for us.
When we're dealing with technology development, we really need to think about how these things are going to be used in the field. It's not a question of how much information you can pack into the screen. It's not a question of how pretty you can make it look. It's a totally different question: when would someone want to know what we have available to present, and what specifically would that person want to know? Then we'd be able to understand things like why it makes no sense whatsoever to create some application that won't work on devices with small screens and relatively little memory and processing power. If we fail to put ourselves into the context of our customers—it's high time we recognized them as such and quit calling them by the same term used to refer to the consumers of street pharmaceuticals—then no matter how smart we think we are, or how cool our application seems to be, we're wasting their time. And we'll have no room to complain when people ignore what we say and do.
Labels: technology
