Getting data from a public place onto a mobile device—whether that data is a discount coupon, a museum map, a restaurant menu, or any other kind of mobile web site, is a problem with no shortage of solutions. Location-based services, NFC systems, and even Bluetooth 4.0 each offer a handful of promising possibilities, but the clear leader is the simplest: QR codes. Yet while the QR code has long been a staple in its native Japan, it has a ways to go to find popular adoption elsewhere.

The QR code likely owes no small part of its popularity in Japan to a long history of integration into mainstream mobile handsets. Even within the infamously labyrinthine UIs of popular clamshell handsets, QR code scanning generally isn’t much harder to find than the camera mode itself. Yet nearly everywhere else outside Japan, you’re on your own.

Working out of the box

Engagement with QR codes in the US is on the rise—to a towering 5%, according to a recent Forrester study. Percentages are higher with smartphones (pushing 20% with the iPhone, higher still on power-user-focused Android), but the Japanese example makes it clear: making QR codes a reliable way to connect with the majority of mobile users will require a better, more integrated user experience from phone manufacturers and mobile OS vendors. The question for them, then, is how to integrate that experience.

Most Japanese phones have the equivalent of a discrete menu item or app for QR code scanning. But there’s really no reason for it to be stuck outside the phone functionalities that bookend the QR code experience: the camera (the external end) and the browser (the internal end). Ideally, it should be integrated into one of them.

Exploration 1: The browser

As QR codes will generally lead to a mobile website, it follows to attach the acquisition of the code to the beginning of the web browsing experience. Why not integrate QR code scanning right into the browser’s address bar?

In this concept, the camera icon appears when Mobile Safari’s address field is clear, replacing the circular “X” button: The user has signaled an intent to enter a new address, and so the camera icon augments the affordance of the keyboard as an additional input channel for a web address. This vocabulary could be used for QR codes’ less-popular applications as well, as a channel inside a contacts app or calendar.

Exploration 2: The camera

Many phones have a dedicated camera key, and even the iPhone gained a soft-key to launch the camera in iOS 5. This rapid access to the camera makes it a great candidate for reducing friction to the acquisition of a QR code. But how do we balance ease of recognizing codes with the other, non-code-reading functionality of the camera?

One solution is to make it modal: The iPhone’s bundled camera app offers an obvious place for such a switch.

The ideal solution, though, might be to simply make the functionality transparent. Rather than require mode selection or input from the user at all, why not simply detect QR codes as they come into view? The potential pitfall here is unintentional activation, should a QR code accidentally come into the field of view while the user is trying to use the camera for something else. The intrusiveness of the scanning affordance must be minimized.

An augmented-reality-style pop-up with a preview of where the QR code will navigate to offers a clear path to the link, but without interrupting normal camera usage. This approach does, however, lack some affordances. Without a mode selector, how is the user to know the camera app is capable of scanning QR codes?

In the wild

Anecdotally, the camera app as starting point seems to be the most intuitive context for a QR code reader. I recently assisted a co-worker who was attempting to test a QR code one of the designers at the office had prepared. She was concerned the code wasn’t set up correctly, as it wasn’t registering on her iPhone.

The problem? She had never installed a reader app. The seamlessness of the iPhone experience and the growing popularity of QR codes logically led her to believe the built-in camera app would read them.

Perhaps it’s time for Apple, Google, and other leaders in the mobile industry to make that logic hold.

In the fall of 2009, I was afforded a rare opportunity: I got to start a lot of people thinking about something in a new way. A video I had spent my spare time producing that summer hit TechCrunch and subsequently all the major tech blogs, spreading the idea of a new kind of desktop user interface: after 25 years of mouse pointers, windows, and desktops, I proposed a new set of conventions that were in some ways radically new, and in other ways quite legacy-compatible. I called it 10/GUI, and it struck a chord with people across many disciplines.

The goal of 10/GUI was always twofold: to comfortably expand our tactile interaction with computers beyond the single pair of coordinates offered by the mouse, and to deal with the complexity of the modern multitasking operating system in a more elegant way than through fidgety stacks of windows. It solved some problems, but introduced others, perhaps the most prominent being “how would we actually transition to this?”

Indeed, the state of the desktop right now often seems unable to advance upon either of the fronts 10/GUI proposed, so bound are we to existing conventions and patterns. Or at least it seemed so—until Apple announced Mac OS 10.7 last year, releasing it this past month.

Window cleaning

Apple is no stranger to combating the scourge of messy desktops. Even as far back as System 7’s window-shade effect and OS 9′s “spring-loaded” Finder windows, designers and engineers in Cupertino have experimented with ways to ease multitasking’s cognitive burden. With OS 10.3 in 2003, Apple introduced Exposé, perhaps the first mainstream attempt to address the inherent clutter of the window paradigm, refining its behavior in subsequent OS releases.

By the late 2000s, Apple’s foray into the mobile world had paved its own course, demonstrating, as Steve Jobs proudly classified them in 2007, “desktop-class apps” that adopted the full-screen paradigm of decades of purpose-built devices, embedded systems, and terminals. Now, in 2011, OS 10.7 has adapted this approach back to the desktop, synthesizing full-screen apps and multitasking into a linear application space to be swiftly navigated via multi-touch gestures.

Swiped?

Some have found this combination of linear application management and gestural navigation familiar. A common theme in email and Twitter correspondence I’ve received recently has been the similarities between Lion’s “Mission Control” UI for managing full-screen applications and 10/GUI’s “Con10uum” UI. There are indeed similarities. But I’m reminded of the infamous “rich neighbor named Xerox” story, the rich neighbor in this case being pre-HP Palm.

Palm’s WebOS and its “cards” model inspired the Con10uum linear desktop. I think it’s fair to say it inspired Mission Control to some extent as well. When you don’t need to manage applications in two dimensions—which, barring a few edge cases, describes everyday use for most users—one dimension makes the most sense. Palm knew this, I learned from it, and so has Apple. Did 10/GUI inform Lion’s design? It’s flattering to imagine, but it’s impossible to know. The question that interests me is where Apple may take Mission Control next.

One away from 10

I don’t see this as a controversial claim: Apple is setting the stage to deprecate the windowed desktop. The timetable for that is open to debate, but given Lion’s emphasis on Mission Control, the new full-screen APIs, and what can be seen as an eventual replacement for the dock, the preparations are clearly in motion.

What is most fascinating to me is that with the full-screen APIs in Lion, Apple is really not that far away from a full, 10/GUI-style solution. Once every app can be relied upon to work in a scalable (by screen resolution), full-height UI, there’s no reason they can’t begin to coexist on the same screen. The three-finger swipe currently used to navigate between full-screen apps could, in a pinch, resize them. The present “desktop” space could become a compatibility pen for old apps, leaving the Mission Control spaces to become the new un-desktop. Given that the menu bar is now only a part-time resident of the screen, even that could be reconsidered.

Of course, if this happens, I can then truly consider 10/GUI Xeroxed. But such is the history of technology: Experimentalists will experiment; innovators will innovate.

Visual identity takes many forms, from the most superficial of trademarks to the most integrated of design signatures. Shapes are part of its language. At their most basic, shapes are universal, untetherable to any name, product, or brand. But in context, in their intersections and in the synthesis of forms, they are powerful.

Illustrated above are four shapes: a square, a roundrect, a squircle, and a circle. Bilaterally symmetrical and geometrically simple, each shape’s popular associations are innumerable. Yet in a particular space, the context of a particular market, this is inverted: In the world of mobile software, each of these shapes has a definite association, some quite strong.

To the victor go the squircles

Microsoft’s Metro UI owns the square. Apple has a corner on the roundrect, from the Springboard launcher to the iPhone hardware itself. Nokia, despite its late entry with MeeGo’s Harmattan UI, found the squircle unclaimed and ran with it beautifully. Palm has used the circle from the early days of PalmOS, and in WebOS, HP continues the tradition with care (one might even note that both Palm and HP structure their wordmarks around the circle).

And yet there are pretenders to every throne. Samsung’s Bada may use the square, but it can’t hold a candle to Microsoft’s Mondrian-esque masterwork. RIM may use roundrects pleasantly enough, but not with the subtle consistency Apple does. The lone standout is Android, which doesn’t really have a unifying shape – a symptom of fragmentation?

Like color, which also despite limitless associations has a history of strong associations within a market, shape is a powerful, yet subtle differentiator. Owning a shape isn’t easy – by itself, as demonstrated by Samsung and RIM, a shape is hardly potent. Those who have successfully laid claim to a shape have used it as a building block rather than as window dressing. Use the power of shape to reinforce good design with coherence and identity – and that shape may one day be yours.

It’s that time of year again—speculation is running rampant as to the makeup of the next iPhone, even if this one might be late. Will we see a leap in 3D graphics processing as with the iPad? Will Apple embrace 4G wireless for a new generation of data-intensive apps? What new capabilities will developers have at their disposal? There’s no doubt that the new iPhone will be a powerful device, but there’s one thing it won’t be like: The first.

The old world of apps

Four years ago, such questions about a new phone might have been hard to even imagine. Mobile software was an established market, but its products tended to fall into one of a few limited categories: largely offline-focused apps from the PDA era of PalmOS and PocketPC, simple, BREW-based featurephone apps emphasizing carrier-selected games, and a smaller market of newer, connectivity-focused apps for smartphone-equipped business users.

This is the world into which the iPhone arrived in 2007, rightly earning criticism that it itself was not a smartphone as it was not set up to run third-party binaries. Today, with 350,000 apps in the App Store, 2007 looks like a brief transitional period. But to consider it that is to fail to recognize what was lost when the iPhone became a smartphone: a phone that was, in many ways, an almost platonic ideal of a telephone, personal media player, and internet communication device. It wasn’t a smartphone, yet it wasn’t a featurephone. It was a smart-enough phone.

Blissful unsmartness

When the iPhone SDK was announced in 2008, it had already been clear for months that to compete in the smartphone market (a market into which, at least from a technological perspective, the iPhone appeared to have always been an entry, even if it was not from a practical, end-user perspective), the iPhone would need more than the original “sweet solution” of web apps proposed at the iPhone’s unveiling. This was founded on two assumptions, one obvious and one less-obvious: first, that the iPhone was always intended to be a smartphone, and second, that the market for smartphones could expand beyond the business world and into the general public. The latter has obviously been proven many times over in the past three years. The first? Despite its unparalleled success as one, it’s not so clear.

Before iPhone users had a dozen home screens full of everything from Twitter and Angry Birds to Deluxe Kitchen Timer HD Universal and Angry Birds St. Patrick’s Day Edition, the iPhone was a marvel of simplicity. Twelve icons, meticulously arranged into a harmonious, balanced grid, covered the core of any user’s needs while out away from a desktop, while four at the bottom forged a novel bridge between the concepts of mobile phone, internet phone, and portable media player. Anything else you might want was out there beyond the Safari icon, but everything you needed–it was all right there, unchanging, unambiguous: A smart-enough phone.

Once in the highlands

The smart-enough phone is a user experience the market has clearly stated is less preferable to a device packed with third-party features and software. But has the market as a whole really spoken? The smartphone is obviously preferable for the part of the market that bought iPhones and other iPhone-paradigm devices. But what of the people who don’t want apps, for whom a smartphone is superfluous and a distraction? The featurephone market has tried to metamorph its product into an image of the iPhone-era smartphone, with large touch screens and minimal physical buttons, but nothing has approached the formal and functional purity of the 2007 iPhone.

Will we see a smart-enough phone again? There have been attempts at radical simplicity, such as John’s Phone, or the Peek, but these have been highly niche. And a minimalist phone or a minimalist email device is a far cry form a minimalist phone-media-player-internet-device. Perhaps the “smart-enough phone” will be a Brigadoon—lost to time until another company of forward-thinkers happens upon its misty fields.

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.