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.