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.

Shorter EFF: buying stolen merchandise is fine as long as you write a story about it.

The EFF does lots of great work, but this seems a bit much. If felony theft is justifiable when it’s part of a journalistic endeavor, what other crimes are okay if you’re a journalist?

There’s a more interesting legal question in all this, though (or maybe not… I’m no lawyer). “Information from sources” is an abstract notion covered by the likes of patent, copyright, and trade-secret law. Physical goods, on the other hand, live in concrete reality — where they’re either in their rightful owner’s hands or not. Where does one draw the line between the two?

In other words, what if Nick Denton had paid $5000 to a sticky-fingered bar-crawler for photos and descriptions of the stolen phone instead of the item itself? What if a thief employed a thumb drive and a quick hand to copy design schematics from a careless engineer’s laptop, and then sold his find? What if information was leaked via stolen media (whether a digital storage device or good old-fashioned printed material)? There seems to be a gradient between “information” and “property” these days.

(If you haven’t been following the iPhone heist story, digging back from above links should catch you up. Also, Here’s a nice backgrounder if you don’t recognize this post’s title.)

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.

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.

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?

For now, I’ve migrated the old blog content onto a new Wordpress 2.0 install, which of course comes with a change of theme. (Which may change some more as I tinker with it… but for now I’ve got other things that need to get ported to the new server.) Comments and pingbacks are now supported, too. Enjoy!

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.

In other news… I got a new cellphone last month, and a new PowerBook a couple weeks ago. Bluetooth is officially the Coolest Geek Toy Ever, especially when Salling Clicker is involved. Thus far, there’s been a lot of noise in the academic HCI community over “attentive user interfaces” but not a lot of good real-world implementations; but now, I’ve quickly made the transition to living with a computer that (thanks to a wireless connection to the phone in my pocket) knows when I’m present and can react accordingly. In fact, I’m sometimes rather annoyed when other parts of my computing experience can’t be usefully presence-aware. (More on that another time.)

Anywho, today I threw together a Clicker script for iPhoto 4… going through hundreds of kitten photos to mark the cutest ones and delete the blurry ones is so much more comfortable when we can do it while relaxing on the couch instead of leaning over the keyboard. It’s a keypad script designed for the Sony Ericsson T608/T610/T616, but it should be easy to translate to other devices as well. Here it is in case you might find it useful.

A lot of little usability bits have been lost in the transition to and evolution of Mac OS X (though not as many as some people think, and more than some other people think); some are difficult to find or to judge, but one that’s quite apparent is the drag-and-drop process. Just implementing drag-and-drop isn’t enough to fully conform to principles of direct manipulation and perceived stability: in order to make the interface truly transparent, what’s going on should be explicitly clear throughout the entire drag operation.

But a number of apps introduce unnecessary abstractions when they generate dragging images (the graphic, often a translucent image or outline, that follows your cursor around as you drag). For example, can you tell which message I’m dragging in this screenshot?

No, it’s not the one about “wonderful russian brides” — you can drag any message, not just the one(s) selected. Mail’s drag image is generic: it doesn’t say anything what you’re dragging, or even how many items you’re dragging.

Consider also these examples from Safari:

If you drag one bookmark, you get a drag image which clearly shows exactly what you’re dragging; but if you drag multiple bookmarks you get an image completely unlike the first, telling you nothing more than “you’re dragging N bookmarks”. (Several other applications work similarly, including iPhoto and Address Book.)

By contrast, the Finder (and numerous other applications) show you exactly what you’re dragging by having the drag image be nearly identical to the static representation(s) of the object(s) being dragged:

You can tell exactly what’s going on in the above screenshots; no matter what happens during the drag operation, the dragging image clearly shows the objects being dragged. This helps to reinforce the notion that the onscreen environment behaves according to principles similar to those which govern the real world: When you pick up an object, you see it being picked up. This aspect of existence is so consistent that we can take it for granted; when objects on the computer screen work the same way, we can apply the same assumptions to them without even thinking about it.

Lame excuses

It could be argued that behavior such as Safari’s is acceptable because in order to drag multiple items you must select multiple items, and this selection is likely to remain visible throughout the drag operation. But that’s not a safe assumption to make in all cases: window ordering can change during a drag, and various types of “spring-loaded” drop targeting may cause the source of a drag to become obscured or hidden by the time you’re finally ready to drop. It could also be argued that dragging is typically a transient state, and thus the user isn’t likely to forget what they’re dragging. But that’s not always the case either: users of trackpads and various other input devices don’t have to keep a button held down in order to maintain a drag, so there’s nothing saying they can’t get up and answer the phone (or whatever) in the middle of a drag.

But even if you brush off the above as edge cases, is there appreciable value to adding further abstraction to your interface? Abstractions of abstractions and metaphors within metaphors can get hard to keep track of. Imagine a library where you’re free to browse the stacks, but when you pull a book from the shelf it’s magically transformed into a card which says, “You’re holding one book”… until you set it down on a desk or the checkout counter, at which point it magically changes back into the book. The real world doesn’t work like that — neither should the computer.

(Don’t read this as a general endorsement of the “everything should look and act just like real-world objects” school of thought — we’ve all seen how spectacularly Microsoft Bob and its ilk have failed. Rather, the idea is that it’s best to keep the number of abstractions in an interface small: “this represents this” is okay, but “this is a placeholder for this which represents this which is a shorthand for this” is to be avoided.)

Developer Considerations

Sometimes bad human interface decisions are made for the sake of ease of implementation. Here’s some pointers to help you stay on the right track when writing your own drag-and-drop code:

• Design your drawing code so you can turn parts on and off and run through it multiple times. In a normal situation you can draw your background, selection highlight, supplemental text, etc. Then when you need to draw into a drag image, set a flag and run through the draw function/method again so it draws only the relevant parts of the items being dragged (e.g. in something like a Finder list view, you want to draw just the icons and titles, not the date modified, size, etc.)
• Cocoa developers using the OmniAppKit framework will find additional methods for drag image control in table and outline views.

[ Edit 8/31/2006: Moving to WordPress nuked the old stylesheets, so I've removed the links from this post. Maybe I'll port them someday... ]

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Some of these make pretty obvious sense (CNET, E! Online), some are tangential connections (the Susan G. Komen Breast Cancer Foundation, the FSF) and some are just… odd (X for Netscape.com?). Either way, it’s an interesting snapshot of the ‘Net and some amusing weekend fun.

In your typical OS 9 applications folder, double-clickable executables were scattered among many folders at various depths of the file system. Sometimes apps were packaged in their own folders even when they didn’t have a bunch of support files going with them — all you’d find in an app’s folder is the stuff it was distributed with (readme’s, release notes, an URL-file or two) which you probably looked at once when you downloaded the app and will never touch again.

Because of this mess of folders, we couldn’t easily use the Finder as a quick-and-easy application launcher the way it was intended, so we created all kinds of tools to fill that role by becoming intermediaries between the user and the file system: folders or popup folders or an Apple menu full of aliases, launchers, task bars, et cetera. Because of issues such as version numbers in folder names, upgrading applications usually required rebuilding whatever aliases or links these launchers used. All this setup and maintenance was difficult for inexperienced users and an annoying waste of time for advanced users.

Thanks to “bundled” applications on OS X, we get a marked improvement on an out-of-the-box system. Before, your average “Mom & Pop” or university computer-lab user only knew how to launch apps that the local computer expert had given them easy access to (and required assistance in digging for anything else). Now an Applications folder full of double-clickable app icons is quickly and easily accessible without needing expert setup — and the Dock provides an option for even-quicker access that even a novice can learn how to customize for themselves.

Of course, this nice organization is just the initial state; the tricky part is maintaining it as new software is added. If we followed the OS 9 pattern but for the addition of bundled apps, new software would come as (after automatic processing) a folder on the desktop, containing not just the app but also a readme and some URLs and other junk you’re probably only ever going to look at once. Instinctively, most users would drag that whole folder to their Applications folder. (Except for the truly novice users who leave the whole mess, plus the .sit and .bin files it came from on their desktops forever.) And after a few iterations of this process we’d end up with file system as disorganized as OS 9’s.

This is where disk images play an ingeniously subtle role. The root directory of your typical disk-image software distribution contains the same stuff yesterday’s folder did (readme’s you’re apt to ignore after reading once and whatnot). But the first point of interaction is the user looking at what’s inside the container, not the user looking at the outside of container — so they’re more likely to, of their own volition, pick and pull our the stuff they want to keep instead of dumping the whole thing on their hard drive and needing to clean it up later. (And thanks to custom window backgrounds, we can provide a prompt so the truly novice users know there’s more to do before the software is fully “installed”.)

So why the long rant about this — after all, OS 9 is dead and gone, and thanks to these changes, the world of OS X is a better place, right? Not quite. For one thing, here’s still a number of products out there using old-style distribution methods… hopefully their developers will notice the trend towards simpler distribution/installations schemes and follow along, but they could probably use some encouragement. For another, even the disk image scheme in its current design isn’t perfect — Apple doesn’t make it all that easy for developers to put together well-built installation images (auto-open, license agreement, etc). And the “disk image file” concept is still difficult for the novice user to wrap their head around (an issue complicated by the fact that so many disk images are distributed as .dmg.sit, .dmg.bin, or even .dmg.tar.gz archives because developers haven’t figured out how to set up their web servers to transmit the proper MIME type for disk image files). There are signs of improvement on the horizon, though (image mounting via HTTP looks like a good step towards working around the concept problem). But we’ve got a way to go…

Speaking of which, my title uniqueness search turned up somebody else’s comments on Apple’s Find File functionality — its author pines for the BeOS search interface of old, where search result windows were exactly like folder windows and could be saved as folder-like desktop icons. Actually, Apple was doing exactly that well before the BeBox hit the streets… it was just part of the Copland project that never saw the light of day (and unfortunately, one of the few Copland innovations that hasn’t surfaced elsewhere at Apple since that project was killed).

Anyhow, I’m still open to title suggestions.

Unfortunately, there are some major topic areas yet to be covered by the new book. And go figure, the missing parts include the advice many of today’s developers most desperately need to hear. Here’s a sample from the “Human Interface Design and the Development Process” chapter:

During the design process, you may discover problems with your product design. You can use the 80 percent solution to help determine how to solve those problems. The 80 percent solution means that you design meets the needs of at least 80 percent of your users. If you try to design for the 20 percent of your audience who are power users, your design will not be usable by the majority of your users.

Developers are often forced to decide between two approaches to any given HI issue: On the one hand, there’s the design that is easy to work out and implement and whose result is a user experience is close to simple enough that it doesn’t get in the way of a user as experienced as the developer. On the other, there’s the design that may be hard to implement and even harder to plan, but whose result is a user experience smooth enough for Grandma to handle without help. All too often, we choose the former, with excuses the likes of, “That’s not at all difficult once you learn it.” But that’s not good enough for the Mac — the Holy Grail of HI design is the interface so intuitive you don’t have to make any conscious effort to learn it.

In today’s world of Internet-enabled instant feedback and worldwide user communities, this old HIG recommendation has an interesting corollary: Don’t just follow user feedback blindly. See, the users who are active in the Greater Internet Mac Community — the ones who grab the latest stuff on MacUpdate, who run OmniWeb sneakypeeks or Mozilla nightlies, who participate in all sorts of discussion boards to debate which release is “snappier”, who send copious amounts of feedback ranging from “it’d be so cool if it could wax my floors too” to “I can’t stand that it isn’t also a dessert topping” — they’re the ones you hear the most of. But those kinds of users are the experienced ones, and what they want out of your software isn’t always what’s best for everybody.

Okay, this has gotten long, though it’s sort of just the tip of the iceberg. More on this general topic in future updates, I guess.

But I couldn’t help but notice how crazy the installation scheme for one of Apple’s latest software updates is: download the new iPod updater and wonder at the number of layers of packaging you’ll have to tear through in order to actually use the update:

• MacBinary encoding (completely unnecessary if the web server is configured correctly) around…
• a disk image, containing…
• an Installer package, which installs…
• a new folder within /Applications/Utilities, containing…
• a single item, the updater application, which you have to find and run in order to update your iPod

This is ridiculous. The more steps in an unwrap-and-install process, the more difficult it get for novice users, and the more susceptible it is to failure (of the human or machine variety). Not to mention that all the intermediate-stage files are the digital equivalent of fast-food packaging — you’re just going to get rid of them once you get to the goodies inside.

They could have done this much more simply — either a disk image containing the app and docs (perhaps with some prompt included to “double-click this”), or an “internet-enabled” disk image that just dumps the app onto your desktop and then goes away. Why didn’t they?

When you present the user with a choice, you force them to make a decision. Choices are generally good, but forcing decisions is bad. And the more choices the user has to make, the more time they spend weighing decisions and the less time they spend actually using your software for its purpose.

If you’ve ever had to deal with a waiter asking too many questions when you haven’t even opened the menu yet, you might recognize this problem. Good software, like a good waiter, lets you think at your own pace and in your own order — and is immediately ready to grant your requests once you’re ready to make them.

And for the love of Woz, don’t force a choice over something trivial. I swear, I’ve seen apps that pop up alert dialogs asking “Do you want me to put an alias to myself in the Dock?”. Thank you… you’ve interrupted my thought process to make me consider an action which, normally, can be done almost without thinking about it.

Actually, I discovered not long after my last update that there’s more than one other weblog with this title, of no relation whatsoever. So I’ve been spending much of these past two weeks trying to think of a new name for mine. Inspiration hasn’t yet struck, though… I’m open to suggestions.

NSRunAlertPanel(NSString *title, NSString *msg, NSString *defaultButton, NSString *alternateButton, NSString *otherButton, ...);

Back on NeXTSTEP/OPENSTEP, the first argument was supposed to be a short title (one or two words) that would get put in the title bar, and the second was supposed to the main message in the window. Nowadays, the first argument should be the primary message, and the second should be (optional) additional informative text. But the API declarations and documention still refer to things the old way, so we still see lots of unhelpful alert panels like first one below. The most eye-catching part of the message is the command you just entered — you don’t need to have that repeated at you.

A good alert panel is like second picture. The eye-catching bold part tells you all you need to know in order to make a decision, and the secondary text provides extra information about the available options and their effects. (Also note the button titles: they correspond to actions. If the buttons are “Yes” and “No”, you have to carefully read the question, but if they’re “Save” and “Don’t Save”, you know what they will do.)

Even Apple forgets this guideline of theirs occasionally. (Actually, so have we at Omni. Gotta hunt down and fix all those old alert panels…)

So there’s lots of webspace devoted to application icons, for end users, but my searching has left me empty-handed over where to get good toolbar icons for my app development. Am I going to have to make them myself? … So many toolbar functions are common or at least metaphorically similar.

I think borrowing toolbar icons is good when you’ve got a common function that doesn’t change from app to app, like Delete or Get Info. (You’re welcome to borrow Omni and icons.cx icons in such cases, BTW.)

Be careful, though — using the same icons for similar-but-not-quite-the-same functions can lead to usability problems. For example, in OmniWeb we use different-looking Back/Forward arrows on the browser and on the preferences window because they work differently: the browser buttons take you back through the history of sites you viewed in whatever order you viewed them, but the ones in preferences flip through the panes in a fixed order, like flipping pages in a book. If we used the same icons for both functions, one might be inclined to think they work the same way. Whatever you do, be sure to check out what the Aqua HIG has to say on toolbar icons.

Also, there are a few cases in which toolbar icons are part of the distinctive look or branding of a product. Apple would probably be unhappy if you wrote a mail or mail-like application and used their set of postage-stamp icons for reply, forward, etc. And we’d defend our copyrights if you were to write a browser or browser-like app using our icons for all four main functions (back/forward/reload/stop), because customers come to recognize our product by seeing those icons at the top.

“Borrowing” application or document icons is a different question, though, so I’ll save it for another time.