AirPause?: Nobody’s Perfect, not Even Apple

Below, a shot of AirPlay in action. (Pardon the hairy arm, but timing and metering this shot while pressing play was no easy task and didn’t seem worth repeating.)

Paused or playing? (Click to view larger image.)

On the TV screen, the play button appears while the video is playing, while in iTunes, the pause button does so.

This difference, while it may seem inconsistent for a moment, makes sense: The play icon on the TV indicates a status, while the pause button in iTunes indicates that the action to pause the video is available—and just implies as a consequence that the video must be playing. (This fact is not always obvious, since the present state of Internet service and the inconsistencies thereof can disrupt playback.)

In showing a pause button during playback—that is, in the case where an action may be taken by clicking the button—AirPlay works like YouTube, not surprisingly:

YouTube’s pause button appears during video playback.

Still, there’s something unsatisfying about the UX decision in the AirPlay case, since the TV screen’s play icon looks, well, more like a button and less like a (“mere”) status indicator. In part, the familiar positioning of the play/pause area at or very near the left-hand side of the scrub bar, again, as per conventions established for haptically actionable video controls. (I say “haptically” because the on-TV video chrome is actionable in a way; you just have to use the remote or iTunes instead of touching the TV itself.)

It’s also just a question of styling, though. The gradient and shape of the play button look a lot like the “lozenge” button Apple used for many years (and still provides in at least one arcane corner of their developer library):

The lozenge ought to look familiar.

Elsewhere in their UX universe, Apple tackles the styling with a bit more purposiveness, if a bit less panache. In DVD Player, the on-screen play icon is styled more in line with its purpose, while the pause button on the software “remote” (positioned for your viewing convenience over the redacted video image) looks like a button:

Yes, Power Yoga. Don’t you judge me.

This, it seems to me, is way, way better. The icon is translucent, which makes a big difference, and lacks the gradient and outline that make buttons look, you know, buttony.

The morals here are probably two:

  1. No matter how much thought you’ve given to a UX issue—and Apple has clearly put some effort in here—there’s always room for improvement.
  2. Sometimes, prettier design means worse UX.

The second in particular is a battle I find myself fighting on nearly every project I tackle at a large agency. I don’t think it’s the case that I should win every time; in this case, for example, I’d probably have conceded the point, had I worked on the AirPlay project. I do wish, though, that the team outside UX would more often recognize the importance of these little choices to the user’s ultimate satisfaction with a product.

(See also my curmudgeonly tirade about Apple’s recent treatment of scroll and scrub bars.)

Classic #fux: The New Netflix App for XBox

On the happy occasion of a bug fix by way of which my list of recently watched titles reappeared in the new Netflix app for XBox, I unleashed a tirade on Twitter against the rest of what’s wrong with the app, namely, a handful of new features. I’ve adapted my rant for the blog, added a useful photo, and corrected one error I note below.

So, for starters, the new Netflix for XBox autoplays the next episode of a TV show, for example, instead of just showing you the list or the title’s info screen and letting you pick what (and when) to play. It’s possible I’ll get used to this, but I don’t feel at that stage like I’ve asked the system to play anything, so it’s annoying and obtrusive and hides what I really want, which is a list of episodes. Also, it’s wrong about my current episode and cue point more than half the time, where the previous app did land me on the appropriate episode almost 100% of the time. So get that sorted and maybe we can talk.

The inability to see an info screen without the app autoplaying means that to get more info about a title, you have to select it in the browse view and then just sit and wait for more info to scroll up, on the timeline Netflix determined was most useful for us all. This is a classic example of what I’ve called #fux (“F___ You” + “user experience”): The app punishes your simple desire to learn more about a title by making you sit and wait or making you start watching. I wonder if Netflix gets payed for every second of video you play.

Notice how much more difficult it is to see the category titles than in the old version (linked to in the paragraph at left). And look how far the still can be from my only reminder of the title it’s from.

As for the new Netflix App’s browse view itself:  The new “Let’s show a million movies so you all get a sense of our awesome selection” layout (see the conclusion of this post for more on that rationale), pictured at right, means that you can only see the titles of three browsing categories at a time. The old layout allowed you to see five, but more importantly, the categories seemed easier to navigate because they were immediately adjacent to one another, not separated by rows of images. In fact, in the new Netflix app, the category titles are superimposed on those images (or, in the uppermost category’s case, well washed out into the strong red background—as pictured at right). Their scannability in the old version made them much easier to use.

(In a Tweet, I had incorrectly suggested that you could see “eight or ten” categories at a time. I take this factual inaccuracy as a faithful reflection of my subjective experience of the difference between the two apps in terms of ease-of-use.)

Finally, it’s a minor gripe, but when I’ve landed on a certain title in the browse view, after about three seconds, the image of the cover is replaced by a seemingly random still from the title (as pictured above, like that will somehow help me make my decision about whether to watch. Instead, it just makes it harder to to get a reminder of which title I’m looking at, because of the spatial separation between the still and the name of the title (if you’ll pardon an awkward phrase). The stills are also sort of aggressively less engaging than the covers—which have been designed and tested, it’s worth saying, to get your attention and get the right people watching the right content. It’s a useless, counterproductive “feature”—and a spoiler risk—that I can’t believe somebody at Netflix green-lit.

And I guess that’s my point. I know I’m outside the target audience for autoplay (though I wonder if there really is one in this case), but this new layout—who does it serve? In his announcement of the new app on the Netflix Blog, Director of Product Innovation Chris Jaffe writes, “You really get a sense [from the new layout] of the depth of movies and TV shows available with a simple and elegant interface optimized for TV.” That rationale is so clearly driven not by user-experience but, defensively, by the critique that Netflix’s Watch Instantly library is mediocre. Stuffing a bunch of extra images down users’ throats is really a self-defeating measure, if the idea is to portray Netflix’s online streaming as a higher-quality service than current perceptions would have it.

Isolating Facebook for Privacy

Based on lots of chatter about this on Facebook and on the sudden zombie-like reemergence of passive sharing in my Feed, I thought I’d share some basic steps to isolate Facebook completely from the rest of your browsing experience. There are other ways (using incognito / private browsing mode, e.g.), but this strikes me as easiest.

Why might you want to do this?

  • to avoid passive sharing
  • to make absolutely sure Facebook apps don’t have access to your everyday browser usage
  • to stick it to the Dark Arts people at Facebook by rendering their tracking cookie useless
  • for other reasons of both sensible and tinfoil-hat varieties

Disadvantages? Sure. Forget using the super-convenient “Log in with Facebook” functionality that many sites are offering these days. Also, a bit of user-interface overhead in having to switch back and forth between two different programs to look at links people post on Facebook, for example.

Nevertheless:

  1. Download and launch a program for creating site-specific browsers (SSBs).
    • On the Mac, your choices are pretty much Fluid or Prism, as far as I know. If you use Safari as your Mac’s main browser, then either use Prism or shell out $5 for the premium version of Fluid. (Maybe some savvy PC user can chime in about Windows options.)
  2. Follow the prompts to create a new SSB for facebook.com.
  3. Launch the new SSB and configure it to redirect all URLs outside *.facebook.com back to your main browser.
  4. In your main browser, clear all cookies that say “facebook” or “fb.”
  5. Never log in to Facebook from your main browser again.

Note to smartphone users: If you log in to Facebook on your phone’s browser, you undermine the total isolation of this approach.

Any questions, please leave ’em in the comments below so other folks can benefit from them. I’ll do my best to respond quickly.

Leave My Scrollbars—and Scrub Bars—Alone

I’ve been complaining to anyone who would listen about Lion’s iOS-like disappearing scrollbars since the day they were announced. I need now to take a moment to gloat. In his incredible-as-always review of the new version of the Mac OS, ArsTechnica’s John Siracusa takes my side, explaining why it’s jarring and terrible—my words—to have disappearing scrollbars on the Mac (even as it makes perfect sense on the iPhone, e.g.). (The whole 19-page review is worth reading, but if you don’t think so, then at least give the section on scrollbars a go.) Siracusa notes:

Scroll bars do more than just let us scroll. First, their state tells us whether there’s anything more to see. A window with “inactive” (usually shown as dimmed) scroll bars indicates that there is no content beyond what is currently visible in the window. Second, when a document has more content than can fit in a window, the scroll bars tell us our current position within that document. Finally, the size of the scroll thumb itself—or the amount of room the scroll thumb has to move within the scroll bar, if you want to look at it that way—gives some hint about the total size of the content.

Thankfully, as Siracusa points out, non-hiding scrollbar behavior can be restored in System Preferences. The issue persists elsewhere in the OS, however, and in fact, has been around since years before Lion’s release today. In particular, in watching video using either of Apple’s applications for doing so (QuickTime and DVD Player), you have to deal with the same kind of pretty-but-less-informative chrome-hiding that I’ve been griping about. Let’s take a moment to review the most influential video player in computing probably ever, YouTube:

YouTube’s standard player.

Nice. I get lots of good information out of YouTube’s standard, non-full-screen player, including:

  • how far along I am in the video (indicated both visually and with temporal data and useful when my patience is being tried by the content, as pictured here)
  • the video’s length (useful in deciding whether to watch now or later)
  • how much of the video has loaded (useful in knowing whether I should walk away for a bit to “manually” increase my buffer)
  • whether I am on play or pause (occasionally useful in troubleshooting)

If all’s going well and I know I’m going to settle in and watch the rest of this video, I may not care about that information anymore. It’s not in the way in the standard player, but it would be in full-screen mode. So YouTube smartly hides it there:

YouTube’s full-screen player. (On cursor activity over the video, the controls come back.)

Great. Well done, YouTube: I see what I want when I want it, and not when I don’t.

Let’s compare this approach to QuickTime’s (both Player and plug-in) and DVD Player’s behaviors. The full-screen versions behave much like YouTube’s, but, frustratingly, so do the standard players, hiding information:

QuickTime Player.
QuickTime Browser Plugin. (Thanks, pyroinnovations.com!)
DVD Player.

Yes, I get that everything’s a little bit prettier this way. But I desperately miss the information more often than I would’ve expected before these changes came about—and I resent the growing influence of this aesthetic in places where I’d rather it not be. (As one otherwise smart and talented designer friend said in designing a video player, “If it’s good enough for Apple…”. It’s not good enough for Apple, I wanted to retort.) After living with these video players, of course, it seemed a no-brainer that disappearing scrollbars in Lion would be maddening. I just don’t get why Apple’s pushing so hard to make the Mac OS more like iOS. As Siracusa notes, the devices these OSes run on present users with totally different models of interaction. Why try to combine them when they serve such different purposes?

Google+ & Content Ownership: A Non-Issue?

My Stream is filled with articles on whether Google+ takes a weird kind of ownership of your content—especially your photographs. I’m no intellectual property lawyer, but I’ve done some amateur sleuthing and think everything’s going to be OK. Here’s why.

First, the offending Term of Service. Mostly, the articles take issue with the following sentence from the main Google TOS:

11.1 You retain copyright and any other rights you already hold in Content which you submit, post or display on or through, the Services. By submitting, posting or displaying the content you give Google a perpetual, irrevocable, worldwide, royalty-free, and non-exclusive license to reproduce, adapt, modify, translate, publish, publicly perform, publicly display and distribute any Content which you submit, post or display on or through, the Services.

That does seem pretty rough, but it’s not the whole story. None of the articles I’ve seen mention the second and final sentence of the dreaded Paragraph 11.1, which reads:

This license is for the sole purpose of enabling Google to display, distribute and promote the Services and may be revoked for certain Services as defined in the Additional Terms of those Services.

So, individual services can override the clause giving Google the right to do whatever with your content.

Two other documents seem to take advantage of that override capability by giving rights back to the user. First, all photos are uploaded to Google+ via Picasa. The following, quoted in its entirety, appears in the Picasa Terms of Service:

Your Intellectual Property Rights: Google does not claim any ownership in any of the content, including any text, data, information, images, photographs, music, sound, video, or other material, that you upload, transmit or store in your Picasa account. We will not use any of your content for any purpose except to provide you with the Service.

That’s pretty good: Seems like all pictures in the Picasa account are totally yours.

But what about content besides photographs? Google’s thought of that, too. (Of course.) The Google+ section of Google’s awesome Privacy Center (which I hadn’t known about) lays out how they use your content in great detail. It’s too long to reproduce here, but it’s very encouraging in that the only uses of your content they mention are basically the minimal stuff that they’d need to do to create and run a service like Google+: e.g., sharing your public profile information publicly. Real no-brainer stuff.

That document does refer to the main Google Privacy Policy as extending Google’s usage rights. The good news: That policy, in turn, has an “Information Sharing” section that sets pretty strict limits on when they share your personal information: (1) when you give consent, (2) when—under terms of confidentiality—they turn to third parties to process their data, and (3) when they’re required to by law.

Again: I’m no expert, but this stuff all seems pretty well locked-down in favor of the user to me.