iBART: Actions vs. Options

The iBART iOS app is a great example of the do's and don'ts of creating the look and text copy for your actions and options.  What we have here is effectively a web form with select inputs, where the options are displayed on a second page.  "Show Trips" is effectively a button or an input of type submit.  But as you can see from figure one, that distinction is not made very clear.

Figure 1: Before:



Figure 2: After:




The screenshot in figure one doesn't quite capture the confusion, but "arriving: 8:00am" by default reads, "Departing Now", which somewhat sounds like a call-to-action similar to "Show Trips" directly below. It doesn't help that "Show Trips" is written in plural, misleadingly suggesting that it was another option instead of the button to see the final result of the singular trip you've just configured above.
The "Plan Trip" button equivalent in figure two solves that issue by first fixing the text copy, and by also providing the affordance of a clickable button with a call-to-action, in contrast to the row item that blended in as another row below "Departing Now".

But instead of learning from the solution to their mistake, they've turned the crosshair and cycle icon buttons in the first figure (which looked deceptively like icons instead of buttons), and made them even less obvious as buttons.

The arrow "location" icon and cycle "swap" icon are juxtaposed with the identically flat arrow in the row below, making them appear as icons only serving to make each row more uniquely identifiable. Users arriving to this screen for the first time would have to accidentally discover that there were options when these icons were tapped.  They share the same look as the icon-only indicators to the far left such that they provide no affordances of being buttons on the far right.

But to top it off, those empty and filled dots on the left being chosen to represent "from" and "to" is very unintuitive, as there is no association across these sets.

iBART is a great application for those using the BART system in the San Francisco Bay Area, so I hope they learn to get their most important page in their app done in a sensible way.

Tweetie vs. Twitter for Mac: A UI Oversight

A couple days ago, Twitter released the long-awaited update to Tweetie, the Twitter client for Mac OS X later acquired by Twitter.  Tweetie 2, rebranded as Twitter for Mac, fixed some outstanding issues like the inability to delete tweets or mark tweets as favorites.  But there were also numerous changes to the interface, beyond the more obvious visual differences, and this is where I started seeing the most problems.
There are some issues that carried over from the first version, such as the disabled zoom button beside the minimize and exit window buttons. There's no excuse for why that has to be disabled - a Twitter feed isn't a use case that can't be resized to fit to the content, especially in the vertical direction.


Crouching Cursor, Hidden Taskbar

Among the newly introduced issues is the reply button.  In Tweetie 1, every tweet had a permanently visible reply button on the top right. Without keyboard shortcuts, replying was just one click away.



In Twitter for Mac, the reply button has been moved to a toolbar hidden behind a hover state. In other words, the reply button is hidden for all tweets, meaning that in order to reply, you have to:

1. Hover over to the reply/favorite/retweet region to unhide it.
2. Shift your mouse cursor to readjust its position over the reply button's target area, instead of the other target areas within the hidden toolbar region.
3. And then click the reply button.

Now you might argue that this is technically the same number of steps if you target the cursor over the reply button's region every time. But don't discount the significance of the half-second time delay of pausing and shifting your cursor over some more. On top of that, the reply button is on the far left side of the hidden toolbar, meaning that its exact hidden position is actually less predictable than if it were on the far right of the toolbar. Then at least in that situation, you could throw your mouse cursor to the right and guess the hidden target area for the reply button more accurately.



Every millisecond counts, especially with a task as frequent as replying.


An Indicator Well Missed

Let's talk about the reverse situation - when someone sends a reply to you instead. In Tweetie 1, new messages were indicated with a blue circular dot by the Twitter user in the left sidebar (under the avatar in collapsed mode, or under the specific timeline/reply/message section in expanded mode).



In Twitter for Mac, this indicator has been replaced with a glossy bluish white light orb, partially tucked under the timeline to the right. It has taken on an oval shape, and while its diameter is roughly the same as the original's dot indicator, the core is actually smaller than the original, and is surrounded by a dark blue halo that is more difficult to see.

This makes the new indicator much more subtle than the original, and while I'm generally a proponent of going for subtlety, this implementation was too subtle for the purpose it serves.
If I were in charge of the visuals at the time, I would have seen the new orb indicator in the isolated sidebar and also decided it was the right mix to be noticeable enough out of the corner of the eye without being distracting in its presence.

But that's why I suspect that the designers who worked on this didn't work with this indicator in the context of the full application. Take a look at the indicators in Tweetie 1 and 2 again with the timeline and its content beside it. Stare and focus on the timeline only, as though you were reading the tweets. In your peripheral vision, the circular blue dot in Tweetie 1 remains noticeable. In Twitter for Mac, the oval orb blends in too much and become easy to miss.

In a real-world situation, it will become even easier to miss because it won't be in the front of your mind to look for it.


Bits and Pieces

There are plenty of other oversights all over the place that I won't talk about in detail here, but they include issues such as not having any indicator that something has been successfully retweeted. This is in contrast to the Twitter website, which addresses the problem the same way marking a favorite is handled - creating a dog eared page corner with the reweet or favorite icon peeking from underneath the flap.











Or perhaps you want to launch the "compose tweet" window, and you liked having a dedicated button for it in Tweetie 1. In Twitter for Mac, it's hidden under a menu at the bottom of the sidebar, making one of the most frequent tasks two clicks away instead of one. I would surmise that they did this to include a second option for "compose direct message", which lacked its own one-click button before. But given that the other tasks in this menu (go to user, mark as read, preferences) aren't high frequency tasks, it makes more sense to revert back to buttons for composing both kinds of messages.

I'll give them the benefit of the doubt that perhaps this was rushed out the door to meet the Mac App Store opening date. I just hope they've thought about any of these issues at all.

Single-Step Dialing on the iPhone OS

On the iPhone OS, contacts grouped into the "Favorites" section of the phone application can be dialed with a single touch to the listed name, but for all other contacts in the "All Contacts" section, this is a two-step process.  The first tap on the name instead opens the details page for that contact, and the desired phone number in that contact's details page must then be selected by a second tap.

Out of habit, I find that I sometimes tap a name in the two-step "All Contacts" section, and hold it to my ear immediately, only to discover that the phone isn't dialing.  (I then have to lower the phone to glance at the screen, select the phone number, and raise the phone back to my ear.)

What should happen is that if this contact has only one associated phone number, the iPhone should automatically dial that number once the phone is held to your ear, using its accelerometer and ambient sensors. That way, selecting a name and bringing the phone to your ear results in the same device reaction regardless of from which of these two sections the dial originated (again, for single-number contacts only).

Redownloading Paid Apps

In the iTunes Store, you have the ability to redownload an app you already purchased, which is useful if you've lost the backup copies on all your devices. But it's not immediately obvious to everyone, including yours truly, and people have to discover this by trial and error or by online resources.

Apple's official docs on this issue are also ambiguous though, as a user trying to download an owned app will encounter the message, "Are you sure you want to buy and download [app name]? Your account will be debited for this purchase and your application will begin to download immediately."

Only after the user clicks "Buy" does a reassuring second message appear acknowledging a prior purchase - "You have already purchased this item. To download it again for free, select OK".

This second message should have been the first and only message upon attempting the redownload. After all, the user is logged in with that account if this stage of the process is reached, so this can easily be determined.

A clearer approach would be to remove the price from the text copy of the button ($0.99 BUY) since the user will not be charged that price when clicking that button, as well as to remove the "buy" text because most people will interpret that word to mean an exchange of money unless $0.00 is explicitly written alongside it.

But writing ($0.00 BUY) is also misleading because the retail price of that item is not free.  So an improvement would be something like my proposal in figure 2 (second image above), with the text (REDOWNLOAD).  It could even be ($0.00 REDOWNLOAD) or (FREE REDOWNLOAD) to make it absolutely clear.

Tapping the buy button again in Mobile iTunes on iOS devices, on the other hand, is much clearer, as it first prompts the second of the two earlier messages.  It still suffers the issue of saying "buy" though.
The best implemented example is the "Update" button for a previously purchased app. Updates are free for owned apps, so it gets to avoid the buying concept altogether and throws the message, "This update is free because you own a previous version of this item. To get this update now, select OK".

These issues need to be fixed, and probably exist as a relic of the pre-app days of the iTunes Store, when users were not allowed to redownload music or other media.  It's your move, iTunes team.

Scoreboard Confusion

When I first saw the picks and results board for Yahoo! Sports Fantasy World Cup 2010, it took me a second to distinguish between an incorrect pick and the actual outcome between any given two countries.  There was something counterintuitive about their choice of icons and color coding for each row's status - it was using green checkmarks for wins, but gray checkmarks for selections, including incorrect ones.  And it was using red X's to mark the winner of the actual game outcome.

This meant that if you picked Italy to win against Slovakia (where Slovakia won), it would show you a gray checkmark on Italy to indicate that you picked it, which you might mistake as a winning result based on the similar green checkmark and background for actual winners.  In this case, the actual winner is marked by a red X and background, which you might mistake as an incorrect pick, rather than a correct result.  Seeing that the red X and background of the score prediction in the right columns actually do indicate an incorrect pick rather than result, this inconsistency only adds to the confusion.  (See the first screenshot.)

What I'd propose (in the second screenshot) is a modification that clearly distinguishes all actual outcomes the same way, say, with a bounding border with a soccer ball (not a trophy, as only one ultimate team gets a trophy).  The green checks and red X's would then be reserved for what people associate with them - correct or incorrect - in this case, the correctness of your pick.  After all, it doesn't make sense to call a country's actual win "incorrect", so it's best that the green/red system doesn't correspond with actual results at all.

Highly visible

This has been bugging me ever since Google rolled out its outset text input fields site-wide - the vertical alignment issue.

Someone's container and input heights aren't playing nice.

Headlight Icons on a Car Dashboard

For a company with a reputation for quality and attention to detail, it's surprising to see Honda's oversight of its headlight "on" indicators on the dashboard.  There are three modes for headlights on a Civic - off, daylight lamps on, and headlights on - each with its own distinct icon on the switch, as pictured in the photo.

However, the daylight lamp icon (pair of opposite lights) on the switch is the only one that lights up on the dash in both cases of daylight lamps being on and headlights being on.

The icon for the headlights on the switch has a matching icon on the dash, but that one only lights up when the high beams are on.

So here's the summary, from top to bottom on the switch:

• Off icon on switch: nothing lights on dash (correct).
• Daylight lamps icon on switch: daylight icon lights on dash (correct).
• Headlights on switch: daylight icon lights on dash (incorrect).
• High-beams mode, headlights on switch: daylight and headlight icons light on dash (partially correct).

What should happen is that there should be a dedicated icon for high beams, so that the headlights can reclaim its own icon on the dash.  You could make the counterargument that after the first time, the driver will get used to this behavior, and that it wouldn't be an issue at that point.  But if you can achieve excellency in the design, why not?