Confessions of a User Experience Junkie

Watts Martin posts a great review of the current state of Mac text editors. It’s framed thusly:

As I’ve mentioned here before, I’ve been a TextMate user for the last few years, albeit increasingly reluctantly… A lot of old TM users have been looking for the Editor That Will Be TextMate 2.0 By Default.

But you really ought to read the whole post if you’re into this sort of thing.

Martin brings up a few halfway-decent alternatives, and commenters bring up a few more possibilities, but the consensus opinion seems to be that the Holy Grail of programmers’ text editors for Mac remains elusive.¹ Things are a little better if you’re doing web development within the confines of what Coda and Espresso do well — but some of us want an editor that’s good for more than just web development.

TextMate was never the Holy Grail anyway, but it brought enough to the table that it might have had a good motto in “it sucks less”.² Oddball double-click-drag selection and character-by-character undo, among other things, remain thorns in its side.

When I’m doing Mac/iOS development, I spend a lot of time in Xcode — which, for Cocoa and C work, at least, has a pretty nice editor. When I want to do web or other work, I have to totally switch gears to deal with another editor.

So here’s my idea of a dream editor: a more extensible Xcode, or a separate editor app built on Xcode’s editor. Oh, and with a few TM-like niceties (like multi-line typing in rectangular selections) added, of course.

The first alternative would require Apple to open up some hooks in Xcode’s infrastructure, so third parties could add support for syntax coloring, features like command-click jump-to-definition and option-click for documentation, etc. We’d also need the community to make better use of what extensibility Xcode already has — creating and sharing project templates that use shell script built phases to, say, create PDFs from LaTeX source, or convert Markdown to HTML and post it to a website, or other stuff we’d be doing with scripting or bundles in other editors.

The second option might be a bit easier on Apple’s part: just put some of Xcode’s editors into a framework third parties could use, and let someone else build an app with support for editing more languages and doing more stuff around it. They’ve already done this internally with Dashcode, anyway…

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.

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.

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?