Peachtree Ultra Quickie

I totally thought this meant "1 out." (Even though I knew Mike Hampton was pitching? Zing!)

Even after seeing the little balls above the word "out" light up as people got out, I paid attention to something else for a minute, looked back at the game in the 2nd inning, and thought it was 2 out...

Concert Banner Usability

So, I went to the Wicker Park Fest both days this weekend, and while it was a really fun time (pretty unbeatable for $5, and Daedelus killed it on Saturday afternoon), it also spawned a debate about how they designed their stage banners.

Each stage had two tall banners, one on each side, with the names of each act and the times they'd be going on throughout the day. The interesting choice, though, was that they violated normal reading convention by placing the final act at the top of the banner and the earliest act at the bottom. A few people I talked to agreed that this was really disconcerting, but then one of my friends made the point that as the crowd gets bigger (later in the day), it's easier to see the tops of the banners.

Although I'm not sure which concern wins out from a usability perspective, I think this is an interesting example about looking at things in context. Since I'm a user experience person, I noticed the inconsistency, but since I'm a 6'1" user experience person, I missed the potential upside of that design choice.

Gameday: One More Thing

I noticed today on mlb.com's Gameday that the center batter view is totally movable. This is really cool, but I keep messing up because the click-drag interface is a little awkward for me.

The problem (and I don't know if this is generalizable to people other than me) is that the drag is moving the camera, not the batter. I suspect that modern operating systems have conditioned me to drag the object that I click, so when I use Gameday I expect to move the batter rather than the camera -- and since these two directions are at total odds, I'm having serious trouble.

What I'm finding interesting is that when I just float the mouse (drag with no click), the camera behavior seems normal to me. This really leads me to believe that the click is setting expectations for me on how the system should work, which are then violated by the implementation model. Moving the camera is the predominant mode in 3d programming (I think), so this probably seemed completely reasonable to whoever created the application. However, most people are not 3d programmers!

Anyway, this is a kind of neat cognitive dissonance thing; even though I know what's happening I still keep messing up. I encourage you to fire up a Gameday page for yourself and see if you encounter the same issue.

[Edit: So far, 3 other people agree that it doesn't feel intuitive. Maybe I'm not crazy after all!]

[Second Edit: To get to an actual Gameday broadcast, you have to click one of the tiny baseball diamonds in the left-hand scoreboard panel on the mlb website. Sorry I didn't make that clear earlier!]

Yes, Yes Indeed

Iron Chef America: Supreme Cuisine: The Video Game.

1. This is going to be totally awesome.

2. The gesture-based control scheme for Wii games has spawned some really neat metaphors so far. But I think this game could be the Joël Robuchon of gestural input (much like that analogy was the Masaharu Morimoto of analogies).

In Which the Author Fails at the ATM

Yesterday I was using a Bank of America ATM for the first time, and it has a card-swiping thing where the user is supposed to put the card in and then pull it back out. Now, I didn't realize this, so I just put my card in and then got confused when the system wouldn't start.

Here's the rub: the ATM had two cues on how to swipe the card. One was a tiny, bi-directional arrow on the mouth of the card slot, which I actually saw and didn't correctly interpret (I thought it was just an arrow indicating where to put my card). The other was the ATM splash screen, which had a photo of a smiling woman taking up 3/4ths of the screen and then the sentence "Insert and remove your card to begin" taking up the lower part.

The designers probably thought that sentence would be sufficient to explain to the users how to swipe. But the problem here is that my focus wasn't on the screen at first, because I'm used to ignoring the splash screen and starting the process by swiping my card. My visual attention was completely on the card slot, and I didn't even see the helpful instruction.

When I talk to non-designers about various interaction problems, a suggestion that I often hear is that "it should be labeled better." But I think this is a good example of how labeling is often not enough to correctly guide the user.

There Has to Be a Way to Work Sushi Into This Blog Somehow

And there is! I'm headed out to Kamehachi with some friends later this week, and when I was checking out their menu online I was struck by how well-designed it was. Even though this isn't "traditional" (read: computery) interaction design, I wanted to highlight some of my favorite parts of this menu.


First: informative headers! It's not so long since I was a total sushi amateur, and would have loved an explanation of the difference between nigiri and maki (I've seen several people have trouble with this distinction). Also, it tells you how many pieces you'll get by default, which is something else I've seen cause sushi buying confusion (usually in the context of "is that the price for just one roll?").


The menu correctly does not assume the customer knows cuisine-specific jargon. Each item is explained, with a clean visual presentation that makes it easy to scan and process the text.

Maybe I'm reading too much into it, but I like this line. It creates plausible deniability for that one guy who wants his carrot garnish cut into the shape of a cylon, while at the same time saying, "Hey. If you have a special request, shoot. We're accommodating, friendly types." Also, I think phrasing it like this makes the customer more comfortable making a special request, because check it out, so many other people make special requests they had to add a thing about it on the menu!

This is just a straight up brilliant idea. Kamehachi has identified a massive pain point ("I don't think I want to try raw fish...") in beginner sushi adoption and has created a menu item specifically to address it. Someone give these guys an honorary user experience designer certificate, please.

Other restaurants, take notice! Kamehachi enthusiastically wins my sushi budget for the near future, and if the food is as good as the menu this place could make it into heavy rotation.

Ballgame, Part 2

Two posts ago I talked about the interaction design of ESPN's GameCast, so today I want to get back to that topic and look at MLB.com's Gameday.

To me, Gameday seems like a more data-intensive take on the internet baseball experience, primarily because of its inclusion of Pitch F/X data to record the speed and flightpath of each pitch. Here's what the most important center column of the Gameday window looks like during play:

























While GameCast's interface focused on balls in play, you can see that Gameday's focuses on the batter vs. pitcher matchup. My experience has been that GameCast is a more engaging experience by itself, but that Gameday is more informative and even provides great value when run side-by-side with a video feed of the game.

My favorite part about this interface is the selectable granularity of the game description, with a great default: it gives pitch-by-pitch data for the current at-bat but collapses previous at-bats into single results.

Another thing I like is the 3D representation of the batter's box. This makes it way easier to visualize the strike zone and hitter's handedness than the GameCast "here's a square grid" method. One slight complaint I have here is that the batter avatar isn't related to the physical dimensions of the player (Albert is a liiiiiiittle bit bigger than that guy in the image), but even with the generic player cutouts I think this visualization is better than more abstract strike zone views.

Finally, in the top right of the image, where "3 out" is colored red, you can also see how Gameday uses animation to make changing elements of the interface more salient.

I think an optimum solution for watching baseball on the internet would involve a combination of Gameday's animated strike zone and GameCast's animated field view, with some user-customizable statistic displays to top everything off. If Bud Selig's reading this (and I know he is), how bout makin' a few calls, huh?

It's the Little Things

So I just typed in "netflix..com" accidentally and hit enter. And then, of course, it sent me to an error page.

But if this were a well-designed system, it should be smart enough to try "netflix.com" when "netflix..com" didn't work. That's not some kind of science fiction technology that's impossible to program. It's hugely possible to implement that. So why don't software designers accommodate accidental inputs like this? Because of the perception that "errors" are the user's fault.

Typing an extra period is just one example of many mistakes that absolutely anyone can make, from grade school to MIT. Don't let lazy design make you feel guilty for being human!

Take Me Out to the Ballgame

As an expatriate St. Louisan living in Chicago, I usually have to get my Cards games through methods other than television. I am an mlb.tv subscriber, but sometimes it's not feasible for me to watch a video stream of the game, so I turn to one of the surprisingly detailed web game-casting applications. Seeing the play-by-play and stats updated live is great for my baseball side, but my interaction designer side is fascinated by how these applications create an engaging user experience. Let's talk about ESPN's GameCast first (MLB.com's Gameday to follow in a later post).

Right off the bat (pun intended), these applications have one huge obstacle to overcome -- there's a lot of downtime in a baseball game, and watching what is basically a real-time summary of results can get boring fast. GameCast tries to address this in a few ways, including what is one of my favorite design touches in recent history: whenever a ball is hit in play, the "field" graphic displays an animation of the ball flying to its landing point before announcing the result of the play. This helps create some tension similar to watching a real game, because the outcome of the play is unknown at first... if the play-by-play window just popped up "A Pujols doubled to left," that wouldn't be as fun!

Another way GameCast helps fill the pauses is by presenting a lot of contextual statistics. This interests me as a sabermetrically-inclined fan because even when a game's on TV, I'd love to see more information about the players than just average and home runs (OPS+, please!). In the web context, not only do these stats enrich my baseball experience, but they provide something to look at between pitches.

The stats-rich environment can be a bit busy, though, so the system uses animation to make changes to important areas of the screen more salient. Play-by-play results, player changes, and score changes are all accompanied by smooth sliding transitions and fade-ins, which help the user track what is happening on screen.

One area where I think GameCast falls a bit short, though, is in its strikezone display. It shows a grid for the strike zone and plots incoming pitches in different colors for strikes, balls, fouls, or "in play," but there isn't any information about the type of pitch that was thrown. To me, not knowing if a player swung through a 98-mph laser or a 70-mph hook takes away an important element of the battle between hitter and pitcher. Also, a quarrel I have with the simple square grid is that it's hard for me to visualize the handedness of the hitter. Even though a little label is shown in the left hand or right hand corner, I still have to think about it a lot, since it's not clear whether the user is looking from the pitcher's viewpoint or the catcher's.

Overall, I'm impressed with how engaging it can be to follow a game on GameCast. If you're a baseball fan that hasn't tried this (or Gameday) out yet, I'd definitely recommend it, especially if you're stuck in a computer lab, classroom, library, or any other place where watching a live video stream (and screaming "Cubs suck!") might get you disciplined.

Take It Down a Notch

There's this guy at the CVS I frequent who is amazingly efficient at checking out customers. So efficient, in fact, that it's actually somewhat jarring. The moment I start to put my stuff on the counter he immediately asks for my CVS card, but I don't even have my wallet out yet! The actual scanning happens at light-speed, and as soon as that receipt touches flesh it's time to move, because he's already starting the process with the next hapless patron.

As far as time per checkout, this guy could probably win a contest. However, this doesn't lend itself to a very pleasant user experience. I get performance anxiety whenever he checks me out -- what if I can't fish my card out fast enough? can't situate my 12-pack in time? or type in the wrong pin? -- and even when there's a line, I'd rather he just slow down a bit.

Could this ever be the case in interaction design, where efficiency is often preached as a key metric of overall usability? I'm not arguing for designers to intentionally create inefficient experiences, but I do think that sometimes incorporating a brief pause can help the user understand what's happening. Especially in computer applications, where some actions can be processed instantaneously, it can be hard for a user to follow rapid changes on different parts of the screen. This, in turn, can make it tougher to understand causality and create a valid mental model of the system.

Inserting a brief pause gives the designer just enough time to make a changing item blink once, to scroll a list instead of jumping to the end, or to have an item animate into a shopping cart instead of magically teleporting there. These visual effects are one of my favorite applications of web 2.0 technology because they allow designers to change traditional hypertext (a series of instantaneous pages) into a richer, animated experience with vastly more behavioral cues.

Now, if only I could get a "CVS guy 2.0" that would just settle down a bit at the counter...