Confessions of a User Experience Junkie

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.

Apple changed the big banner image on their home page last week… when you look at it on an iPad, it might make you think of this:

Somebody recently asked me what’s going on with the recent conflict between Apple and Adobe. Is Flash really that bad?

In short, yes. But that’s probably not a useful answer to anybody. (Neither is “In long, yyyyeeeeeessssssssssssssssssss”.) So where does someone just now discovering the issue turn? John Gruber’s written a ton of very insightful material on the topic, but it’s hard to keep up if you haven’t been following the issue since the beginning. I recommend reading through his archives, regardless, but for those with a bit less time on their hands, here’s my attempt at an executive summary:

Your Business, My Business

Adobe is a company whose revenue comes from selling tools to content creators. Content creators want tools they can use to reach a wide audience. So when it comes to Flash, it’s in Adobe’s interest to:

• make sure Flash Player exists everywhere, so lots of people can see Flash content.
• make sure Adobe’s tools are the only way to create Flash content.

Apple is a company whose revenue comes from selling devices to people who want a quality user experience. Apple has a very strict definition of what constitutes quality — too strict, some might say, but it’s working out well enough for their financials — so it’s in Apple’s interest to control the user experience.

All Adobe needs for its strategy to succeed is for there to be some way for Flash content creators to target every major platform where interactive media might be used. They don’t need to care how well Flash works on any given platform, or how that might affect users’ opinions of that platform, they just need Flash Player (or similar) to exist on that platform.

For Apple’s strategy to succeed, they have to make sure there’s no aspect of using a product that reflects poorly on that product. The only way they can really make that happen is to control every aspect of the product. Apple controls all the hardware and all the software on its iPhone OS products — they may not “own” every line of code (e.g. the open source parts of OS X), but they have the ability to tweak any part of the system to meet their performance / user experience goals.

Apple’s strategy also depends on being able to innovate or react quickly: if your revenue depends on having the coolest toy on the block, you need to keep up with whatever’s “cool” this year (or define it). More on this in a bit.

3, 2, 1… Fight!

Back to the dispute over Flash — this started out as a dispute over one aspect of the technology, and now it’s two:

• Since the original iPhone shipped, there’s been the question of whether some variant of the Flash Player browser plugin is included with MobileSafari, so that existing types of web-based Flash content can exist on iPhone OS devices.
• More recently, Adobe realized Apple wasn’t changing its stance on the first issue and looked for another way to enable Flash content creators to target iPhone OS devices: they made a tool which lets one build content using Flash, then have it automatically translated into a native iPhone app one can sell on the App Store. However, Apple changed the legal Terms of Use so that developers aren’t allowed to use such tools.

As for the first — putting web-based Flash content on the iPhone — it’s not too hard to see how the business cases I laid out above make this a win for Adobe and a screw for Apple.

All Adobe would need to do for their business strategy to succeed in this case is whatever minimal engineering effort is needed to make existing web-Flash content run on the iPhone. They don’t have to care about whether it runs slow (because smartphone CPUs are much less powerful than desktop CPUs), drains battery life (because all that CPU usage requires power), and isn’t quite usable (because lots of web-Flash content assumes you have a keyboard, multiple mouse buttons, and the ability to hover the pointer over something without clicking it — all stuff you don’t get on a touchscreen-only platform). All they need is to be able to sell content creators on having millions more devices on which their content (theoretically) works.

On the other hand, for Apple this proposition sucks. If web browsing becomes slow (because every other page is eating up the CPU with Flash-based banner ads), battery life becomes poor (for the same reason), and you can try to play all those Flash-based web games only to have them fail at random times for random reasons, it makes a crappy user experience for the device as a whole. And since Flash is Adobe’s software, Apple wouldn’t be able to do much about the problem.

You might think the answer is for Apple and Adobe to make nice, and cooperate on making Flash on iPhone not just work, but work really awesomely well. But this still goes counter to the business strategy. Adobe doesn’t stand to gain from such an endeavor — they sell just as many Flash Creative suite licenses either way. And while Apple could spend a bunch of money sending its top iPhone engineers to help Adobe with Flash, that doesn’t help Apple’s bottom line much — millions of people are happily buying iPhone OS products already, and it’s doubtful that number would change much with Flash on iPhone. (Not to mention that Apple stands to gain more from having its top iPhone engineers working on the next iPhone.)

Round 2: Gatekeepers Always Win

Okay, so what about the latest turn in this fiasco? Isn’t it a win-win for everybody if Adobe’s Flash tools can be used to create native iPhone apps? Not really — it’s a short-term success for Adobe and a long-term risk for Apple.

How so? Well, the benefits to Adobe from such a move should be obvious: more ways for Flash content creators to put their work in front of people means more sales of Flash content-creation tools. The problem for Apple has to do with the second aspect of their strategy that I outlined earlier: since their revenue depends on having the coolest new devices, they have to keep on top of what’s “cool” as times change — either coming up with the next cool thing themselves, or being able to react quickly to new trends originating elsewhere. If a third-party toolkit for Apple’s platform becomes too popular, Apple becomes dependent on the third party.

To get an idea of what this means, imagine Adobe’s Flash-to-iPhone technology became available a year ago — April 2009 — and shortly thereafter, more than half the developers on the App Store migrated to it, including most games. (It’s so great to be able to develop the same app once and release it for both web and iPhone!) What would the past year have looked like?

• Apple unveils iPhone OS 3.0 in mid-March. Adobe couldn’t delay their big Flash tools release for it, so the Flash-to-iPhone tech ships in April, still targeting iPhone OS 2.x.
• iPhone OS 3.0 ships in June, with great features like cut/copy/paste, landscape-orientation keyboard, push notifications, and tools that make it easy for game developers to add both local and internet-based multiplayer.
• Very few App Store products take advantage of the iPhone OS 3.0 features — there’s no support for them in Adobe’s Flash-to-iPhone tool, and the new version of that isn’t due out for several months at least.
• Adobe ships a new Flash-to-iPhone tool in January 2010, with support for all the new features in iPhone OS 3.0.
• Apple unveils iPad in January 2010, and gives developers the iPhone OS 3.2 tools needed to build bigger better apps for it.
• It takes a little while for developers to make use of the new features from the latest version of Adobe’s Flash-to-iPhone tool, but stuff using the new iPhone OS 3.0 features starts to show up on the App Store in February-March. Not much of it, though, because most of those features are irrelevant to web-Flash users.
• iPad ships in April 2010, but there’s not much third-party software for it, because everybody’s building stuff in Flash, and the next version of Flash-to-iPhone/iPad won’t be ready till October…

Get the picture? (Considering that Adobe tends to produce big new releases of its authoring tools only once every couple of years, the hypothetical timeline above might be overly optimistic.)

Regardless of what you might think about Apple having established themselves as gatekeeper to the iPhone OS platform, it’s clearly in Apple’s best interest not to let Adobe or anyone else take over that role.

Is it good for the platform and its users for Apple to be acting as gatekeeper at all? Could Apple achieve its anti-Flash goals through less heavy-handed means? What about the whole HTML5 angle? There are many more questions to be answered here, but this is an executive summary: plenty more is available elsewhere.

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?