Tim Morgan's thoughts that are too big for Twitter
Separating good design and good behavior (and additional nitpicks on the Twitter app)

As I continue to use Twitter, I find I have more to say about it.  I’ve collected some additional thoughts below.

But first, the elephant in the room is of course Gruber’s response to my original post.  In a nutshell, he says that yes, OS X is changing, and Apple is the banner-bearer for that change by themselves discarding the HIG and forging individual UIs for each of their apps.

This change is indisputable, and it is no doubt effected by (or at least affected by) the Web.  Gruber’s piece is largely agnostic regarding where he stands on this matter, as I suspect his opinion on the matter may still be nascent.  Personally, I do not deny that applications like Twitter are beautiful; the problem is they can also be inconsistent and confusing to use. (Twitter certainly is at times.)

Apple makes it very easy to make an application that behaves as you would expect; all you have to do is use the existing Cocoa UI elements as intended.  Usability comes free.  The curiosity for me is when designer/developers exert time and effort rewriting UI elements from scratch, merely to make them look differently from the Aqua UI.  Now the onus is on the developer to replicate the behavior of the UI element he is approximating — and it’s hard to get all the details right, which means few developers do.

For example, consider how the Twitter app handles the process of clicking a button, holding the mouse button down, and moving the mouse.  You will find one of four different behaviors:

  • If you do this over a sidebar or toolbar button (such as those in a user detail view), the button highlights briefly, then deactivates, allowing you to move the window.
  • If you do this over a “stoplight” button, the button does not deactivate, but remains highlighted, but moving the mouse moves the window.
  • If you do this over a button on the bottom bar (e.g., the Follow/Unfollow button in a user detail view) or in the main view, the window does not move, and the button remains active.

Worse is that the top, side and bottom bars are all draggable areas allowing you to move the window, but click-holding on buttons to drag the window works only in the top and side views.

Most, but not all buttons highlight when you click-hold on them.  The Reply buttonlets next to DMs, the delete buttons next to saved searches, and the avatars next to tweets are all buttons that give you no feedback when the mouse is clicked on them.

Most buttons, when clicked, will darken or brighten, but clicking the More Actions button on a user profile view or the clear button in the search field causes the button to lighten instead, a look I find more appropriate for the disabled state.

In my mind, the worst offender among buttons is the Follow/Unfollow button.  You may not even recognize it as a button at first: If you are viewing the detail page of someone whom you follow, a “Following” — I’m not sure what to call it, so I’ll call it a state indicator — is displayed on the left of the bottom bar.  (This state indicator is not to be confused with an activated button, which it appears deviously similar to.)

Hovering over the “Following” indicator reveals that it is in fact a button that you can use to un-follow the Twitter user.

It took me a matter of minutes to figure this one out.  I suppose I don’t see what’s wrong with doing something more like this:

It’s not like the horizontal space is being used for anything else.

I mentioned the pitfalls of the “stacking” UI concept in my previous post, and upon further use I discovered that some views slide in from the left (toolbar buttons), whereas others slide in from the right (search results).  This isn’t such a huge deal until you consider that the “close” button for the latter views (which, in Web tradition, is actually a “go back” breadcrumb) is an arrow pointing to the left:

Left arrow causes right-sliding animation

If you click the left-facing arrow, the view unexpectedly slides out to the right.  The root of the problem is that the “stacking” UI concept doesn’t jive with the “tree” navigation that you’re actually performing.

Twitter could also be more consistent in how it portrays drop-downs.  As a Mac user I am conditioned to expect a drop-down when I see a down-facing arrow, as used in the “more actions“ button at the bottom-right of the main window:

However, the “more actions” button in the user detail page looks, for all intents and purposes, like a normal click-to-action button.  It is, however, a drop-down:

The purpose of laying out these nitpicks is two-fold: First, if Loren Brichter happens to read this, maybe he’ll agree with me on some points and implement fixes.  Second, the purpose is to show that good design and good UI are two separate things.  The classical way of thinking is that good design and good UI coincide: Design to the HIG and it will both look good and feel right.  With the push for individuality (as Gruber puts it), the way we design applications for the Mac falls apart.  Developers are forced to rewrite UI functionality which causes gaps and inconsistencies in behavior.

The way I see it, there are two solutions to this problem: You can give up your individualized UI in exchange for the comfort of the tried-and-true Aqua interface (unacceptable to the “new generation” of Mac developers), or we can change the way user interfaces are developed on the Mac.  Perhaps it’s time that Cocoa got a solid, full-featured skinning layer on top of the UI toolkit, so that appearance and behavior are finally separated in the Application Toolkit APIs?