Webkit versus, the iPhone beats Android

With the recent announcement of the first Android phone with the Snapdragon processor, the Acer Liquid, I had hopes that the browser would finally be up to snuff with the one found on the iPhone!   Instead of waiting for the Liquid to be released, I realized I could do some testing on my desktop.   The Android emulator, while not flawless, should be a pretty good indication of how the device would work with more CPU power.

The WebKit-based browser on Android has always bugged me, mostly because I’m used to the silky smooth browser on the iPhone.  Scrolling, flicking and nudging all work fantastically on the iPhone.   As I’ve mentioned before, it feels like the page is resting on a sheet of glass as there is no hesitation to the scrolling.  Also, the flick scrolling physics are calibrated to a usable level.   A full-speed flick will scroll down about two pages worth of data.  Any more than that and a user will lose context of where they are on the page.

I fired up the Android emulator and did some tests.   I found one glaring flaw and one issue that could be fixed quickly.  The reason why the browser seems so jerky is because it always starts with a jump!   Just try it:  the browser ignores the scrolling motion until a certain threshold is hit.  The threshold isn’t time-based but distance-based, 25 pixels to be exact.  Once that 25 pixel threshold is hit, the browser doesn’t just start scrolling but moves the page those 25 pixels immediately.  The iPhone has a threshold but it is much smaller and the initial threshold value is ignored.   The screen doesn’t immediately jump to have the screen position catch up to the finger.

The smaller issue is how far the page moves once it’s flicked.  Using Google REader as my test platform, a full-speed flick will scroll down by 10 list items on the iPhone but 29 items on Android.  It’s a tough compromise, trying to find a multiplier that works for all scenarios.  If a user is scrolling at normal speed, the page should move at a 1:1 ratio.  With a flick, the user obviously wants to move through the content faster but at what rate?  The iPhone takes a conservative approach and moves at roughly 2:1, scrolling down about two pages for a full-page flick.   Android takes a reasonable approach and scrolls at almost 5:1.  For a long page, you could flick through lots of content very rapidly on Android.  Unfortunately, 5:1 is just too great.   You can’t really process all five pages that just whipped past you.   2:1 might be too small but 5:1 is far too quick.

I can only assume the 25 pixel threshold was to keep the user from initiating scrolling too easily, especially if they were just trying to click on a link.   Initiating press-and-hold on an object would be even more important as the user needs to press a specific area for at least a second.  I think this 25 pixel threshold is too high and the jump is completely unnecessary.  Android is open source, right?  Where can I submit a patch to fix this?

Update:  Ha, I found the actual line in the code!

http://android.git.kernel.org/?p=platform/frameworks/base.git;a=blob;f=core/java/android/view/ViewConfiguration.java:

private static final int TOUCH_SLOP = 25;

25 is too big!