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.

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.