Much to my surprise, the number of visitors to my blog providing thoughtful commentary far outnumbered spambots. It was great to see your ideas on how to solve the problem of interacting with tablet web browsers.

Now I’ll take you through mine.

In my humble opinion, the best implementation of basic browser functions we have seen on mobile devices to date is the “gesture area” as implemented on all webOS phones since the debut of the Palm Pre in 2009. For those of you who are unfamiliar with the Pre (you’re missing out btw), the gesture area is a capacitive touch-sensitive strip below the display where one can simply swipe their finger in a certain direction to trigger an action. In the browser, swiping left was the equivalent of hitting the “back” button in the browser, while swiping it was the equivalent of hitting the “forward” button.

This is like hitting the 'back' button, except way easier.

I am particularly enamored with gestures as opposed to onscreen buttons in mobile devices, for reasons I will expound upon in a future post. For now I will just say this is my preferred way to interact with the browser. webOS nailed it with the gesture area in their phones.

And so of course HP/Palm went and ditched the gesture area in their first tablet. *facepalm* *faceHP*

Can't touch this (bezel)

In their defense, there are many good reasons the gesture area that works so brilliantly on phones simply doesn’t work well on a tablet, but that’s a topic for another post altogether.

But back to the point at hand: If we do not have a hardware gesture area, what can we do?

Make the whole screen your gesture area

That oughta do it

Heh.

Anyway, since that’s obviously silly, let’s refine the idea some more. Obviously we don’t want the whole screen looking or acting like a gesture area all the time or we can’t actually use the device. Rather, we need a way for the touchscreen to interpret when you want to be using it as a gesture area.

I have two distinct ideas on how to do this:

1. Multitouch gestures

I like this, but the main problem that I see is that Apple has probably patented it. That wouldn’t stop the Android team of course, but it’s enough to give me pause.

2. Touch-and-gesture

Right now lots of touchscreen interfaces have a means of bringing up a contextual menu: hold your finger down in a single spot for a second and the contextual menu pops up next to your finger.

an example of a contextual menu that pops up on holding a finger down

I think this is an area of opportunity for solving the browser nav issue. And so I propose, the Magic Gesture Area (note to self: check if Apple has copyrighted the word “magic”)

First, I am going to reduce the number of steps required. Right now the contextual menu requires you to tap, hold, release, move finger to the desired menu item and tap again. Why not just position the popup options so that you can swipe right to them? I will change it to tap, hold, swipe. Once you trigger the menu, just swipe your finger to the left to go back, or swipe it to go up. Or swipe it up to reload. Whichever way you swipe, of course will have a visual cue to confirm it, just as the current webOS gesture area’s light pulses in the direction of the swipe.

But wait, John, you say. What about the functions that are currently in use by tap-holding, like “open in new card” or text editing features?

Well I’m glad you asked. The contextual menu’s original features still have a home here: on the bottom. Only now instead of tapping on them, you can drag you finger on top of them until the one you want is highlighted (kind of like the System Menus behavior in Mac OS 1 through 7.x)

I’ll post some cobbled together animations of how it works in practice later, but I wanted to get this out there to start and get your first thoughts on it.