Next week, it’s anticipated that Apple will announce a successor to the Apple TV based on iOS. While this predictably inspires more speculation than a Rod Blagojevich verdict, the most interesting question it poses is how the onscreen user interface will be controlled.

While some sort of optional iPhone integration is a given, Apple’s multimedia standby, the traditionally-bundled Apple Remote, starts to look a little inelegant in light of the usability strides made on Apple’s mobile devices. Directional pads are older than Apple itself, and their usefulness falls off quickly with the number of elements they are used to navigate through. Click gestures such as long presses and double-taps can help, but they remain stop-gaps for a limited interaction technology.

Dan Provost’s suggestion of a Click Wheel remote is a very intuitive one. A logical progression of decoupled input for Apple, it works very well for navigating hierarchical lists, and to be sure, it even has plenty of creative potential for use in an iTV App Store. But the question of how to build a better remote is one that has intrigued me for some time, and I think it’s possible to go much further.

You mustn’t be afraid to dream a little bigger, darling

The one-to-one motion and gestural speed control of the Click Wheel make navigating in one dimension much nicer. But a trackpad takes out both dimensions at once. And with Apple’s mastery of intertial scrolling on mobile devices, it’s a perfect match for two-dimensional menuing on a new iTV.

It’s not hard to imagine an onscreen UI built around swipe gestures, inertial scrolling, and the snap-to-rest behavior of something like the iOS spinner input, across a two-dimensional menu system like Sony’s XMB. Add the Magic Trackpad surface-click to navigate, and you have a lot of potential in a very simple remote control.

With the addition of an iOS-standard home screen button and perhaps a play / pause button, this hypothetical remote could not only make 10-foot navigation as pleasant as using an iPhone, but extend a lot of its interaction vocabulary. Such a system might just be the closest one could get to mirroring the iPhone’s direct interaction in a decoupled context.

As the above might suggest, I had something in my head which begged to be mocked up.

Trackpad on top, surface click on both top and bottom, home key in the middle. Slight resemblance to sushi.

Playback or play

Dan Provost suggested the very slim possibility of a game controller for the new iTV. While it’s unlikely that Apple will make gaming a central pillar of iTV, Apple is nonetheless making serious inroads in the market. So how might they make this part of the out-of-the-box experience?

With something like the concept envisioned above, there’s already a game controller: Just turn the remote sideways.

Even without any other features, a trackpad and two primary buttons allow for plenty of latitude in designing gameplay. Add an accelerometer or another button or so, and you have something that can easily rival the twitch-friendly controls on major consoles.

Will Apple take the adventurous route, or will they play it safe with iTV? We’ll find out soon enough.

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.

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.

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.

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.

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.

However you choose to interpret the Buzz launch, though, its failings ride on top of a more fundamental problem with the most popular social networks: the entire model of social networking, from MySpace to Facebook to Twitter, is broken. It’s based on the interpretation of database tables, not on how humans naturally interact.

Honey, you forgot this at home

Here’s the problem: The dominant social networking paradigm is completely point-to-point. Our real-life social networks aren’t like that at all—they’re much closer to a hub-and-spoke model. Even from a young age, we meet different people in different contexts. We form discrete groups from discrete sets of people, generally with little overlap. Before the social networking revolution, the only time everyone you know would be present in the same forum would be at major events in your life, such as perhaps the end of it. Now it’s every day on the Internet.

Did you feel that slight trepidation the first time someone outside the first group of friends you connected with on a social networking site sent you a friend request? A vague tingling of memories of a parent showing up at school in front of your peers, or an older brother crashing the party with your friends? That sense is the result of a social flatland—to adapt a UI term from the estimable Bruce Tognazzini, who popularized it in application to Apple’s tendency to reject hierarchy and sorting for simplicity’s sake, it’s what happens when all your friends end up communicating with you simultaneously in the same space.

Unflattening your friends

Social networking sites have made attempts to address the inadequacies of social flatland. From the beginning, Facebook had its “networks,” which at least recognized individuals’ belonging to multiple, discrete groups, even if the groups were lumped together anyway. With the deprecation of Facebook networks, its “lists” feature with per-post privacy is the closest yet to real-life social networks—but the UI for it is far from intuitive and defaults to flatland.

There are some up-and-comers who get it. The closest thing to a real-life social networking site may actually be a blogging platform: Posterous, the email-powered blogging site, lets users create separate, multi-user private blogs and invite users to them. Tumblr provides similar functionality, if not quite as seamlessly. Even Twitter, partly by virtue of simplicity, doesn’t put any major roadblocks between you and multiple accounts to represent you in your different spheres, any of which can be easily made private. It’s not uncommon for Twitter clients to support fast account switching right out of the box.

Then again, it’s often fun to introduce friends to each other. It can be rewarding: Sometimes, the unexpected meeting of mutual friends can be a fortuitous pleasure. Other times, it can be a disaster.

Which is why, all things considered, it’s generally better to make those connections yourself.

Apple products expand scope gradually but deliberately. The 2001 iPod was a music player and a hard drive. The 2005 version could display calendars, play solitaire, display a slideshow on your TV, and run feature-length films. The 2010 iPad is a big iPhone. You know how this goes. But there’s more to Apple’s tablet than its own scope.

Evolution and adaptation

Let’s take a step back. The iPad will evolve, it will influence the design of other tablets, perhaps tablet computing will indeed be reborn and draw significant numbers of casual users away from desktop computing as the iPad’s strongest supporters suggest. But we are not all casual users. We don’t all have needs that can be met by an appliance solution. What becomes of the desktop? It seems unlikely that it should be left to stagnate.

Of course, I have my own ideas on how to proceed. But assuming we’re not ready for that yet, we still have a time of transition ahead for the traditional computer. And despite Apple bringing to market the first direct-manipulation UI for desktop-class applications, I’m not convinced that the tablet paradigm stands to actually replace our old PARC-derived one. Even if there’s a tablet in every home, I can’t see offices replacing desks with sofas to be worked upon eight hours a day. But each side can learn from the other. As we saw with the iPhone and OS 10.5, Apple doesn’t hesitate to adapt things from its appliance UI to its desktop.

XI and friends

The first major step will probably be to take a multitouch mouse for granted: You can see this happening in fits and starts with various bundled apps on MacBooks. If OS XI isn’t a fundamental rethinking of the desktop paradigm, it should at least require a Magic Mouse. Once the UI can make that assumption, there’s suddenly a lot more it can do even with old-fashioned scattered windows—plenty more if you start from the iPhone platform’s modal window approach and combine it with scalable Cocoa Touch interfaces and window tiling. Perhaps a roving-to-mouse-position, local 1:1 touch surface? If Microsoft puts its researchers and its appliance people in charge of a future Windows, we could see similar advancements from them.

Ultimately, the iPad points not toward a future of tablets for everything, but toward the porting of tablets’ successful experiments to the desktop realm. The future of tablet computing is going to make the current desktop feel increasingly inelegant, but it won’t replace it. Their relationship will most likely be symbiotic, leading to new advancements in both realms.

So, yes, I think I figured out the e-reader part of The Tablet. Me and approximately 47% of the Internet, I know. This isn’t anything new. But I do believe I have found a pattern.

The web as an iTunes Store

Apple is making an iTunes store for web content. Yes, you know this already, but hear me out: This is where the magazine and newspaper negotiations, the HarperCollins negotiations, the Quattro Wireless acquisition, iTunes LP, the podcast directory, the App Store, and iWeb all meet. The publishing deals aren’t the only part of Apple’s “e-reader strategy” because Apple isn’t going into the e-reader business any more than they went into the minidisc player business with the iPod.

E-readers strive to simulate paperbound books. The Tablet doesn’t bother. Apple has left it all behind for interactive text with animation, multimedia, maybe social networking. Which sounds a lot like the web as it currently exists. But you know how Apple hates to stop at how things currently exist.

The web is a huge mess of things. Which is great. But it’s not so great for some things, especially the monetization of editorial content, as we are reminded time and again as various major print publications make plans to charge for online content only to be heckled back to the ad-supported model. But if there’s one platform that has successfully induced people to pay for things this past decade, it’s the iTunes store.

On the design side: As powerful as the art of CSS is, the diversity of end-user contexts means web versions of print magazines rarely have the character of their paperbound counterparts. Look at the cover story in Wired on the newsstand and then look at it online—one is like seeing a play, the other like reading the script. Paginated HTML5 in a controlled, predictable environment, however, can make these both look archaic in the hands of a good designer. Look at iTunes LP. That’s how you do it.

Everybody now

So yes, you know all this and the above four paragraphs weren’t necessary. But there’s much more to it than just the media incumbents. Just like with the podcast directory, Apple is inviting everyone to the party. Just like with the App Store, Apple is giving everyone a chance to monetize. Just like with iTunes LP, it’s a content experience based on HTML5 and a controlled browser environment. And this is where the new iWeb comes in. Everyone will have the opportunity to build their content into this new HTML5-based format and container; the bundled iWeb will come with a bundle of themes and preset grids to guide non-designers; iWeb Pro will become the de facto InDesign of this new field. Adobe will build support into CS5.

And of course, the hub for this will be the iTunes Newsstand. Buy a multimedia-packed issue of a magazine for $1.99. Subscribe to a free newsletter supported by Quattro ads placed painlessly through iTunes Connect. Publish your own free newsletter and throw a party when it reaches 10 downloads, as I will. It’s a content platform based on existing web technology but all packaged seamlessly in Apple’s domain.

A body of standards

This is not to say that everyone will be locked in. The major publishers will produce content compatible with anything packing a WebKit browser and the right size frame. The Tablet’s resolution will become the new 320 x 480, and similarly-specced, competing devices will soon filter out from most of the major manufacturers. But content on those will have to either be free or use a competing store to the iTunes Newsstand, and Apple’s counting on theirs being the best experience for both consumer and producer. And, unfortunately, there’s the issue of DRM: iTunes Newsstand will offer FairPlay wrappers to piracy-paranoid content producers, making the alternatives a tougher sell.

Everything I’ve written above is almost certainly wrong. I will regret using the future tense instead of conditional, making this post look even more silly in a week’s time, though on the upside, I greatly doubt anyone has actually read this far. But there you have it. Apple reinvents the web as its own sequel to print.

I apologize if you have actually finished reading this, and will return to actually writing about design and usability next week.

Circa my last entry at no substance. all eloquence, 10/GUI was an ambitious, slightly daft set of ideas for the future of human-computer interaction that had recently found their expression in an unknown eight-minute video. In the first weeks of 2010, 10/GUI remains largely the same, though “unknown” may be replaced with “somewhat widely circulated.”

If you have, in the past couple of months, arrived at ns.ae. from the Twitter page that I hurriedly linked from the 10/GUI site the hour it hit Slashdot, you might have wondered why ns.ae. stood dormant with no mention of the project. To say that the whirlwind of activity in the wake of 10/GUI’s popularity prevented me from writing wouldn’t quite be accurate: I wasn’t short on time as much as on perspective.

In practical terms, I haven’t seen any huge changes in these three months, though my momentary fame brought me to talk with a number of fascinating people and even opened several exciting career opportunities, including a full-day interview at a tech giant many dream of working at (though alas, that one didn’t pan out). 10/GUI is still little more than an idea with a video, but that will have its chance to change given time.

The next step is a proper treatment of the keyboard problem, by far the most asked-about feature of the video. I’m wrapping up the conceptual phase for it, and I’m hoping to be able to give this its own video soon. It also looks like I’ll be speaking at a couple of conferences this spring, so I’ll be noting those here once everything’s official.

Also: I’d like to thank everyone who has reported on, commented about, analyzed, and critiqued 10/GUI. Those of you who have been inspired, those with criticisms, those who can’t wait to beta test something, those with oddly long e-mails I don’t quite know how to respond to. I appreciate all of you.