H.264 Red Herrings

DF, regarding hardware acceleration for Flash video:

clearly, [Adobe and Apple are] working together to make Flash perform better on Mac OS X.

True, perhaps, for some values of “working” and “better”.

Adobe’s attempt to excuse themselves for poor Flash performance on the Mac by arguing that Apple didn’t provide necessary hardware acceleration APIs was always a red herring. As noted by the Flash engineer in the linked article, hardware acceleration for H.264 video is only available on a subset of the Mac installed base:

  • MacBooks shipped after January 21st, 2009
  • Mac Minis shipped after March 3rd, 2009
  • MacBook Pros shipped after October 14th, 2008
  • iMacs which shipped after the first quarter of 2009

Don’t get me wrong; hardware acceleration for video is where the future is, and it’s great to see Apple and Adobe making nice and making improvements in this area. But there are still a lot of pre-2009 Macs in the field, on which Flash video performance continues to lag far behind both QuickTime’s performance on the same video stream and Flash-for-Windows performance on the same CPU — they’re all being done in software. It’s cases like these which betray Adobe’s lack of concern for a quality user experience.

Post-PC Multitasking

From Neven Mrgan (via Gruber):

Trying to “clean out” your tray is not a habit you want to get into. It’s pointless, and besides, you can never win – as soon as you run another app, in the tray it’ll go. It’s like the world’s worst game of Whac-A-Mole. Instead, learn to see the tray as a “recent apps” area. If you’re in the middle of one task – say, writing an email – and you need to switch to something for a second — say, looking up a spelling — then the tray is your friend. But once you’re done with that, you’re done.

I’d take this a little bit further: if you’re trying to “clean out” the tray, you’re thinking too much like you’re on a desktop OS. And if you’re thinking like you’re on a desktop OS, you just might be outside the target audience.

Remember two weeks ago — before the iPhone OS 4 reveal — when everybody was talking up how great the iPad was for not multitasking? The argument we kept hearing then was that managing a bunch of concurrent application isn’t something a lot of users want to do. Actually, it’s something an awful lot of users don’t want to do — how many times have you heard about the guy who doesn’t know why his computer is so slow when he has no idea how many apps he’s running?

I’m betting a large (perhaps overwhelmingly so) number of iPhone OS 4 users will never care about quitting background recent applications, just as they don’t care about quitting applications on desktop operating systems. But they won’t suffer for this ignorance the way they do on desktop operating systems, and as a result they’ll have more time for the stuff they do care about.

I’m just here to say one thing: when Scott Forstall answered the question of “how do you quit apps” with “you don’t”, he wasn’t just being terse; he was looking out for your sanity.

To put it another way: he’s reminding you this isn’t the PC anymore.

Safari 4: “Delicious”?

Heh. “Perhaps I’ll get back into the swing of things soon,” I said in the last post… two and a half years ago. I guess I’ve just been reluctant to publicly talk the talk about UE issues when I haven’t been publicly walking the walk lately. (Yes, I need to stop tinkering and start releasing, but hobbies and their side projects a good at distracting me, as is buying a fixer-upper house.)

But this Safari 4 beta fiasco is too juicy to pass up. Go read John Gruber’s excellent summary of the situation if you haven’t already.

The sense of déjà vu here keeps grabbing me. Is this a fruit of Mike Matas moving to Apple a few years ago? It’s so much like the later parts of my time at Omni: artist-designer takes the beginnings of a good idea and pours all his time into iterating on its presentation… until it impresses all the engineers and managers with how slick and cool it looks that nobody pays attention to the interaction-designer in the corner wailing, “but it breaks every fundamental rule of the Mac UI!”

Yes, the Delicious Generation may take its name from Delicious Library being one of the first high-profile products of that nature to ship. But it was born earlier: in fanboy gushing over UI reskinnings on the MacNN forums in the early years of OS X, in that and similar communities’ enthusiasm for Apple’s own design style divergences of the day — like QuickTime Player, iTunes, and the 10.2 Address Book — and at a little office in Seattle that looks like a house. 

It’s all the same: controls that are nonstandard for novel (if debatable) reasons, overdesigned to look cool but break consistency of look and feel; standard controls repurposed for completely nonstandard uses; oddball new controls that fit nothing other than the artist’s whim (and are redesigned again a few weeks later, once the engineers are busy implementing the earlier design). Just like when, after taking home top design honors two years in a row, those at Omni most responsible for UI design stopped working together and started exclusively (but for the protests of some) following the plans of a high-school intern who spent all his time making (and embellishing, and advocating, and embellishing some more) spiffy UI mockups. 

Moving browser tabs above the other browser chrome and integrating them more with window chrome is an idea with merit: as Lukas Mathis notes, it fixes an odd conceptual hierarchy issue that’s been around since browsers first started going tabbed several years ago; and as Manton Reece notes, it’s a good prologue to moving tab-style window-collection management out of the realm of inconsistent third-party variations and into the realm of OS-provided standards. (Personally, I hope adopting Google Chrome’s UI hierarchy is also prelude to adopting its underlying multi-process model.)

But as all the discussion of this issue has shown, it’s an idea that — in order for it to be implemented well — requires careful consideration of many usability issues that don’t readily come up in Photoshop mockups. Hopefully Apple considers Safari 4 a beta of not just the rendering engine but the UI as well… Sean Sperte’s idea is a good start, but really this is an issue that needs a lot more debate and iteration before it’s ready for prime time. (Me, I’m still waiting for OS-level window-group management that brings together the best of browser-tabs and Exposé.)

Other Safari 4 thoughts

Combining UI elements to save space is a worthy goal — when handled well, at least. So why are we still stuck with a strip of web browser chrome at the bottom of the window?

Okay, Safari’s status bar isn’t shown by default, but savvy users are quick to turn it on: without it, there’s no way to determine the nature of the link you’re about to click. Is it to related content on the same site, or some completely different site that I’d rather spawn off another window or tab for and come back to later? Is it a site I really want to go to, or does the URL look phishy? Is it going to stay in this window or is the HTML hardcoded to make it open another regardless of what I might prefer? Okay, I clicked it but it didn’t do anything — is it broken, or does it run a script that’s likely failing due to my Block Pop-Up Windows preference?

Back in the early days of Mac OS X, I loved how the borderless Aqua windows combined with OmniWeb 4’s unorthodox design (only showing a status bar while loading, and showing link targets on mouseover in place of the current-page URL) freed web pages from the heavy web browser chrome prevalent at the time. You could have just the page, with a tiny strip of titlebar/toolbar at the top and your desktop background behind it, and nothing else to distract from the content.

I’d love to see a browser that gets rid of the status bar chrome without undermining its purpose. In non-browser WebViews — like in Mail — hovering over a link shows a tooltip with its URL. Safari, like most other browsers, shows a tooltip with the link’s TITLE attribute (and/or ALT attribute if it’s a linked image). Why not, if the status bar isn’t showing, a tooltip that shows both? And the link’s expected behavior (open in new window, run script, etc), too?

The Good, the Bad, and the Tog: Efficiency Isn’t Everything.

I’m not sure if I’ve mentioned this here (or in any of the other public forums for my thoughts on UE) before, but I have this general skepticism towards many of the so-called luminaries in my field. There’s the academic HCI experts whose research is of little use outside of their ivory towers, the web journalists who know exactly what they want in an interface and assume it’s the best thing for everybody… and then there’s the folks who did good work twenty years ago but have apparently lost their way since.

One of these made waves in the Mac community this past week… revered HI commentator Bruce “Tog” Tognazzini (founder of Apple’s Human Interface Group) wrote up a review of Mac OS X 10.3 and its interface, after being largely silent on OS X for the past few years. Despite his credentials , Tog’s column reads little differently from the many rants we’ve seen in various online forums and blogs — the ones from longtime Mac “power users” who see any and every change from the OS 9 environment as a crippling blow to everyone’s productivity. He’s got a few good points, but it’s looking like he’s lost his edge and feels the need to resort to sensationalism. There’s an awful lot to criticize about this article — indeed, folks are already ripping it to shreds in some forums — but I’d like to focus on one issue that’s been largely overlooked.

If Tog’s still an expert on anything, it’s the subfield of human interface study that relates to user efficiency; that is, how to optimize a software design so that the user can accomplish the most tasks with the fewest actions in the shortest amount of time. He recognizes that Exposé is a great step forward in this area, and notes the minor time-wasters associated with it (if you use “hot corners”, you have to be careful not to accidentally hit a corner; a problem which could be solved with a tiny delay), and points out several issues of low information density and user slowdowns in the Finder and Dock.

The problem with this argument is that efficiency alone doesn’t make for a good user experience. After all, seasoned Unix command-line jockeys are well known for their ability to accomplish with a few arcane gestures over the keyboard what point-and-click laymen can take a whole day to work though. The whole point of graphical user interfaces is that they balance efficiency with intuitiveness. An intuitive interface may make some tasks take longer to complete than they could in an interface designed for maximum efficiency, but you can learn it on the spot instead of having to take time digging through documentation.

Yes, the Dock takes up more screen space than the OS 9 Apple Menu and Application Menu did. But what we lose in efficiency we make up for in usability: no longer are new users confounded by applications which remain running with no windows open, for example. In fact, the usability advantages of the Dock are making many users more efficient and productive than they were on OS 9 — making favorite applications easily accessible no longer requires an understanding of aliases and a complicated procedure for setting up an hierarchic Apple menu or set of tabbed Finder windows full of them. Also, since the Dock merges these two OS 9 interface elements, users need not concern themselves as much with whether an application is running when they go to activate it.

The best interface designs strive to find a balance between being efficient and being intuitive. Sometimes the one has to be sacrificed for the other, but often, with a lot of work, some inspiration, and maybe a little luck, it’s possible to arrive at a solution that maximizes both.