Building a Better Tablet Browser Part II: My Solution

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

How not to do a screen-wide gesture area

That oughta do it


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.


3 thoughts on “Building a Better Tablet Browser Part II: My Solution

  1. I like the idea. I like that it is where my fingers are at rather than a specific place on screen.

    However, tap and hold seems to add a pause to the flow of a persons actions. Since it usually takes a second or two to activate I wonder if the user may feel it is slow and cumbersome. Maybe I’m just too impatient :). How about using webOS’s original launch wave bar concept though? Instead of dragging from the bottom to show a list of apps to launch, dragging in from either side would drag out the context menu. It may not be as intuitive, but you can still perform the action even if you are using both hands to hold the device. Although it may take just as long to drag from the sides as it would to tap and hold I think the fact that you are doing something makes it seem faster even if it is not.

    Just a thought. Kind of combination of your idea plus everyone else’s.

  2. Great idea, John! Axing gesture area in webOS 3.0 was a very controversial decision, to say the least, but your solution is even better (visual cues for less advanced users as to “what will happen when I drag my finger….”. It is great UI design idea at it’s best – this piece of UI is intuitive, self-discoverable for users, and self-explaining – the core values of a great UI concept. As a previous poster, I am also slightly concerned about press & hold “stoppage”, and especially if it wasn’t something that you could customize (I think for me 100-200ms is a MAX that I’d like to wait for press&hold to activate, but could not imagine this as a mainstream user’s liking (too fast, I guess).

    Above concept of sliding out the menu, is also quite nice and worth considering, IMHO.

    Really impressed with the idea. So sorry I’ll not be able to use it on any actual device. Kindly, say my very special thanks to your boss, Mr. Leo “The Marathon Man” Apotheker, whenever you got a chance, for gutting webOS so thoroughly in 6 months since Feb “Think Beyond”!

    I appreciate all your hard work and great ideas you put into it, guys, and sympathize with you with all my heart, I can only try to imagine how frustrating it has to be to put your best skills and your hearts into a product, that is then systematically let down by incredibly incompetent leadership (or shall I say, the lack of it).

    Deepest Respect,

  3. …also, another (maybe far fetched) possibility to consider:

    -why we couldn’t use the back of the device, to put some kind of “gesture mode trigger” on it’s back?

    So that when it is activated (probably physical button/s, it has to be something giving haptic feedback), the whole screen became your “gesture area”

    A little wild, but hey, we are “brainstorming” here in slow motion, don’t we 😉

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s