Dead for doing one thing well

I’ve been meaning to write about Microsoft’s aborted attempt at the sublime called Courier for awhile, but today’s post-launch termination of would-be socialphone Kin puts the former into relief. While the two products had very different origins as well as demises, they have a lot more in common than their status as apparently-rogue Microsoft projects.

The ideal

Courier was a later-stage concept that never made it to market. Kin was the product of an expensive acquisition and a high-profile launch, shot down minutes after takeoff. But the profound link between Courier and Kin is not one of investing lots of money into something only to can it. Their unifying theme is something more noble, even quixotic: The pursuit of an ideal.

This ideal is the quest to find one thing to focus solely upon doing better than anyone else, to the expense of other features, use cases, and markets. It’s something that some of the best products in history have done, and unfortunately, it doesn’t seem to be something Microsoft encourages.

The platform of no platform

Courier would not have been an iPad competitor. The design philosophy of the iPad is to offer a 9.7″ window into anything its A4 CPU and App Store policies can handle; it is a blank slate ready to dedicate itself to whatever’s running. Courier was the exact opposite: a piece of hardware specifically crafted as a notebook for creatives. Its hardware was not built for versatility, and its software was, as far as anyone could tell, not built as a platform.

Courier was not intended to replace a netbook, tablet, UMPC, or anything else. I doubt it would have even run apps—it wouldn’t have fit its character. It was designed to fulfill its creative purpose better than any multi-purpose device could ever do with run-everything hardware and do-everything software.

Likewise, the potential of Kin was immense. In a market filled with phones where social networking is either an isolated smartphone app or a tacked-on J2ME disaster, the choice to build a platform upon a social core, with every piece of the user experience deriving from this priority, should have set Kin up for a shot at success in a niche market.

Doing everything or nothing

Microsoft’s history is obviously not one of perfectionistic products designed consummately to a single purpose. Broad, empire-building platforms such as Windows and suites like Microsoft Office are the company’s priorities, allowing only the occasional venture into the single-purpose territory when it’s already been proven by a competitor.

There was nothing proven about a high-tech mobile creative tool or a phone that existed only to socialize (although the latter is arguably a proven market). Perhaps, in a market where an iPad already supports a sufficient proportion of the uses a Courier could have plus many others, and a usable Facebook app for iPhone, Android, Blackberry, WebOS, and MeeGo fulfils enough of most socialites’ needs, the enhanced user experience of dedicated devices isn’t enough to justify the extra investment. Certainly the opportunity costs of buying such a focused phone today are numerous.

The simple wonder, though, of stashing a stylus-drawn sketch in Courier’s “binding” with your thumb or dragging a photo straight from the camera into Kin’s system-wide “sharing dot,” is still something you can’t quite get with platforms.

How Diaspora can succeed: Model real life

Whether they are cursed or simply in need of some sound advice, the four idealists at the helm of the Diaspora project have a lot of work ahead of them. The biggest question they face, though, is how to architect the system. Not just from a technical perspective, but from a social perspective. If they simply copy Facebook’s model, they probably won’t get far. The key is to identify what’s wrong with the design of social networking as we know it, and then to find a better way.

Life and SQL tables

The practical problem with every major social networking site is that its network model compresses our complex social circles into simple, one-dimensional tables. Your friends are melted and frapped into a homogenous quantity, and every post you make is broadcast to all of them, regardless of the context in which you relate to them in person. This is a problem for a variety of reasons: Content shared between members of one social group is generally irrelevant to those outside it, creating noise, and when a group’s exchanges require any degree of confidence or discretion, unintended overlap causes obvious problems.

To be fair, Facebook has addressed this—in its usual labyrinthine fashion. You can create groups of friends, and in an update made last year, you can choose privacy settings for each post you make if you’re willing to click through enough menus each time. Unfortunately, its cumbersome design limits its use.

The usefulness of Facebook’s friend grouping feature is perhaps most severely impaired, though, simply by its existence as a grafted-on user setting and not as a pattern of the system’s underlying architecture. This is the fundamental change Diaspora needs to make: Don’t build around a buddy list. Build around real life. We go to school, the office, the church, the bar, home, a friend’s home, and there’s a different crowd at each place. Sometimes they overlap, much of the time they don’t. Build Diaspora to fit that reality, not to fit a SQL table.

Privacy is precision

This won’t be easy. Precedent to build on will be in short supply. You won’t be able to get by with the hard-to-kick FOSS habit of copy-the-leader. You need to balance separation and overlap, to elegantly give users control over who they’re speaking to, and to cast their voice as wide or as narrow as they feel is appropriate.

I’ll gladly throw a UI suggestion into the ring, though. Put groups front-and-center. Think of them like tabs, if you must; these should form the solid walls between social circles, and whenever you’re viewing a group, your posts should go exclusively to that group. But hey, this is social networking—make them booleans, so you can view groups together. Add something like Twitter’s retweet functionality so you can shuttle messages quickly between groups, sharing freely but precisely. There’s nothing wrong with being open, as long as the user decides what “open” means.

The federated nature of Diaspora seems a perfect fit for the first successful, real-life social networking platform. A critical eye toward not just Facebook’s practices but the state of social networking itself will be what separates Diaspora from the also-rans.

Rise and fall of a UI convention: The search bubble

Like commodity markets, the markets for specific UI conventions sometimes go through a boom and bust cycle. Just as on the trading floors, an element’s ascendancy is often driven by popular enthusiasm for a few highly visible successes, and just the same, its downfall can come about in a flooded market that dilutes its value. Today, we’ll look at one UI convention in particular that has seen this pattern over the past decade: The search bubble.

For as long as GUI text fields have existed, there have been search fields. Originally restricted to modal boxes, the 1990s saw them increasingly integrated into non-modal UIs, a concept driven in part by the rising popularity and sophistication of the consumer-facing Web. As users became accustomed to initiating a search for web content right from Yahoo’s home page, or finding a book at Amazon without invoking a separate search window, the integration of the search field into the principal view of an interface grew to become a welcome and even expected practice. But these search boxes had no particular identity apart from other fields.

Identity for searching

iTunes 1.0 proposed a simple, visual code for the search box: semicircular endcaps. Only thing was, it was almost certainly unintentional: A look at the iTunes 1.0 toolbar area reveals a forest of circles; barely a right angle has been left unrounded. Yet this simple coincidence of an in-context search box and a rectilineophobic aesthetic struck a chord somewhere—it’s not clear (at least to me) whether Apple first ran with this or if Apple’s subsequent use of it was inspired by its adoption elsewhere, but either way, the “search bubble” grew to become a strong piece of UI vocabulary, a powerful vernacular for search.

A 2008 Smashing Magazine compilation of web-based search boxes includes frequent appearances of bubble-capped search fields, even outside the section dedicated to the convention. The bubble has found its way to multiple platforms, and essentially all modern Mac OS applications with a non-modal search feature use it, probably thanks in part to Cocoa’s NSSearchField class.

The bubble bubble

The search bubble began its existence as an arbitrary visual choice, and it has certainly found non-search uses even as it became popularly associated with search. But these exceptions tended to exist at the fringe of UI design; one might expect to see a page full of all-rounded fields in the over-enthusiastically decorated signup page of a scrappy web 2.0 startup, but in the mainstream, the style was, in general, dutifully reserved as a signifier for search.

With the release of Firefox 3.0, Mozilla began to chip away at this distinction: The browser’s loved-and-hated “Awesomebar,” a combined location bar and history search, brought the bubble look into a control that existed only partially for search. But next to an identically-styled web search field, and with a toolbar full of identically-rounded buttons, the Firefox 3.0 UI cloaked the significance of the rounded fields in the same mire of homogeneity as the iTunes 1.0 toolbar. The seeds of the search bubble’s undoing were planted.

The first full-on salvo against the uniqueness of the search bubble, though, was from an iPhone app. Not just any app, of course; many lesser-known apps have applied the bubble to non-search tasks; but a consistent chart-topper: Facebook. Unlike so many popular apps before it, Facebook used the same bubble style for status updates as for search, returning the bubble to its origins as an arbitrary visual style. This, however, was only a precursor to the ultimate dilution.

When Steve Jobs showed off iPhone OS 4′s folders feature, App-flush users marveled at the elegance of the solution. But a shadow was cast over this by the unfortunate use, by none other than Apple itself, of the bubble for a non-search feature. It had come full circle: From arbitrary style in an Apple UI, to a widely-used visual cue, back to arbitrary style in an Apple UI.

Like most markets, though, the search bubble may be down, but not out. It’s always had to struggle with the dilution of its meaning, and even if its struggle is harder today, it still has a great install base. Chances are, you won’t have to search hard to find it in the future.

Don’t press any key to continue

Last week, Coding Horror posted a good musing on the opposite of Fitts’ Law, observing how certain irrevocable actions should utilize the principle in reverse to make their UI elements harder to interact with. That got me thinking: How else can we make terminal actions just hard enough without becoming impediments to normal use? How can we most elegantly clarify user intention?

The classic intention clarification is, of course, the confirmation dialog, itself borne of the command-line “y/n” prompt. The confirmation dialog is actually the original reverse-Fitts’ implementation: Your pointing device must travel all the way from whatever you just clicked to the “yes, I really meant to do that” button. While still far from foolproof (this only clarifies the user’s intent to click the button and not necessarily to perform the action represented by the button), it quite effectively wards off accidental clicks.

Using a confirmation dialog can be considered “active confirmation,” utilizing modal functionality to take advantage of reverse-Fitts’, while simply using the principle by itself in UI layout becomes “passive confirmation.” The thing is, these two approaches are a long ways apart. Passive confirmation still results in an instantaneous action, while most approaches to active confirmation become cumbersome for frequently-performed actions. What else is there in between?

If this is OK, do nothing

There is a good solution, but it’s one that doesn’t get much attention in software UIs: Delayed passive confirmation. Taking a cue from the industrial “dead man’s switch,” it’s essentially a hybrid of active and passive confirmations. It uses active methods to delay the action and give feedback, making it safer, but as confirmation is implicit if left alone, it’s effectively passive, making it more convenient.

Below are two examples of delayed passive, one from logging out of Mac OS X and an essentially inadvertent one from Mozilla Thunderbird.

As before, these are rather polar examples. The sixty-second Mac OS X logout delay is really too long to be of much convenience to the average user, while Thunderbird’s outgoing-message progress bar is based on an arbitrary value (presence and size of attachments) rather than a specific time to give the user a chance to cancel the send. This points to a potentially useful middle ground, though: Why not employ a simple, short delay that appears somewhere out of the way?

Interruptible without being interrupting

Imagine clicking “send” for an email message and watching your message appear in a brief queue. Perhaps it counts down about ten seconds before sending, more than enough time to cancel an erroneous send, but little enough time in the scope of e-mail communication as to not interfere with normal usage.

I could actually see it fitting almost perfectly into Apple Mail’s activity pane:

As long as the confirmation doesn’t steal focus, such a solution requires no further interaction than sending an email without confirmation.

Delayed passive confirmation is a nice middle ground between avoiding accidental clicks only by minimizing their targets and making users confirm everything with a modal dialog. It’s not appropriate for everything, of course—permanently deleting your entire collection of Ladytron albums should always be actively confirmed, and editing a caption in a web gallery of your cat probably isn’t important enough to build a queue system for. But for those tasks that exist right on that edge, like sending an email, it can be a perfect fit.

Why the iPad is not for web browsing (yet)

The conclusion is counterintuitive: Mobile Safari is great, right? It transformed mobile browsing by bringing a robust, standards-compliant, usability-focused browser to a handheld, an act that’s still not easy for the competition to follow. The iPad scales up this experience to something approximating the desktop experience, so shouldn’t it be even better? I don’t think so. In fact, I’d say it’s the worst of both worlds. At least for now.

This fine article at RoughlyDrafted details how Flash encourages interaction conventions that are incompatible with touch, meaning Flash’s absence from the iPad runs deeper than Apple-Adobe politics. The analysis is spot on, but it’s only the beginning: The problem goes far beyond Flash. The web in general—from Yahoo to Facebook—isn’t designed at all for touch. It hasn’t been so much of a problem on the iPhone, whose ability to display and navigate desktop-targeted sites was so vastly superior to its predecessors that this didn’t matter, and is still a welcome fallback for when you need access to a site but lack access to a desktop. But the iPad’s scale invites one to think of its Mobile Safari implementation as a desktop web browser, which it is, substantially, far from.

Touching what isn’t there, and other UI paradoxes

Daniel Dilger’s aforelinked article points at Flash specifically for the frequent use of touch-incompatible mouse rollover events that it engenders—but take a look at the rest of the web. Look at Yahoo’s home page: Several major interactive components won’t work in a touch environment, from the rollover flyouts on the left to the news hovers in the center. Look at Facebook: Numerous parts of the UI, such as the selective hide options in the feed, will never appear unless you hover over their contextual elements.

Which is to say nothing of other mouse-based UI conventions that won’t work, such as drag-and-drop. How will you pan a Google Maps-style field when your drag gesture is already used for page scrolling? If a site starts in minimalist mode like Google’s home page, how would you know what’s there if you don’t have a mouse to nudge? Much of the debate over Flash’s absence from the iPad and how it spells doom for Flash’s future is misplaced: You won’t be getting used to the blue Lego tiles because your use of standard desktop sites altogether will be minimal.

Under construction

Ultimately, It’s a bit like the uncanny valley: The iPad’s browser (or any other tablet browser) looks a lot like a desktop browser until you see it close up. But, just like the early days of the mobile web and later of the enhanced mobile web, this is one more opportunity. Tablet-targeted web content, that targets fingers instead of mice, is probably a good investment right now. And just like on the iPhone, desktop sites will be accessible on the iPad as a fallback. You’ll be able to read news sites and blogs in reasonable comfort, but the real web action on the iPad and other tablets will be versions of sites built for the third screen.

You’ll still use your handheld device for the mobile web. You’ll still use your desktop for the desktop web. The web the iPad is intended for isn’t built yet—but I think it’ll be a fun one to build.