Chrome Beta is just another browser choice for Android

Donovan Colbert compares the native Android browser with Chrome Beta for Android, using Google Docs as the experimental app. Find out why he's not impressed.

After I upgraded to Android 4.x (Ice Cream Sandwich - ICS) on my ASUS Eee Pad Transformer TF101, I immediately downloaded Chrome Beta for Android. My first destination was Google Docs, which is arguably a cornerstone of any Google effort to offer SaaS cloud-based solutions to compete in the enterprise.

I was really excited, because the native Google Docs app for Android stinks. Web access isn't much better. For example, the mobile web version of Google Docs is missing critical features, and the desktop version doesn't respond very well to a touch-based interface. I was hopeful that the Chrome Beta would address these issues, but that wasn't the case. In fact, I don't see much difference at all between Chrome and the native Android browser.

The native Android browser

Opening the Google Docs web app displays the mobile version by default. The app shows a number of tabs across the top for Google+, Gmail, Docs, and more. Beneath this, there's a bar that allows you to "Sort" or "Narrow by," to search, or to compose a new document. The main window contains an abbreviated list of your most current documents, with a button for "Show more items." Directly under the window, there are tabs you can click to either sign out or request help. You'll also see a switch to change between Mobile|Desktop (as shown in Figure 1). Figure 1

The mobile version of Google Docs on the native Android browser.

After you click a title in the main window, it brings up the document in read-only format. The bar buttons are then replaced with "All Docs" and "Edit," as well as a down arrow with a print option.

When you press Edit, the "Edit" button changes to "Refresh." The editor is plain and lacks many features. You can't spell-check, alter the format (font, bold, or italics), insert images, or retrieve a word count. However, you can type.

The desktop version of the app (simply click "Desktop" on the bottom of the screen) looks exactly like it would on a desktop browser (see Figure 2). The title appears in the top right right, and below that are menu items for File, Edit, View, Insert, Format, Tools, Table, and Help. The toolbar has icons for print, undo, redo, clipboard, fill, text style, font and point size, bold, italic, and all of the rest of the normal tools. There's also a margin rule, and a window that illustrates your page where you type. Figure 2

The desktop version of Google Docs on the native Android browser.

Sure, the desktop version looks great, but it doesn't work right. Pulling down menus is hit and miss. When I entered the desktop mode on my tablet's native browser to take these screenshots, it kept redrawing every element on the page (except the text input area) multiple times before it finally stabilized. When I clicked on "Tools" to do a word count, the whole bar highlighted before the Tools menu drop-down appeared.

On the plus side, with the introduction of ICS, text input in the Transformer's native browser seems fast enough to make it useful for actual composition -- that is, when it works. One time, I had a flashing cursor and could click and move the cursor in the text area, but it wouldn't actually accept any text input.

The Chrome Beta Android Browser:

The only notable difference between the native Android browser and Chrome Beta for Android is that the browser border looks more like Chrome on your PC. Specifically, there's a Chrome tab and URL bar at the top of the screen (see Figure 3). Figure 3

The mobile version of Google Docs on Chrome Beta for Android.
When you open a document in the default mobile view, you experience the same limitations that I described above. However, if you switch to Desktop view, you'll get a warning, "The browser you're using may not support all features of the desktop version of Google Docs." You can "Continue to desktop version" or "Return to mobile version" (see Figure 4). Figure 4

You'll receive a warning message when switching from mobile to desktop view in Chrome Beta.

Unfortunately, the desktop version of Chrome Beta has the same erratic behavior as the native Android browser with pull-down menus. The cursor also lags, which results in typing mistakes -- and the backspace isn't responsive, so I find myself erasing too much. This constant back-and-forth of making an error and then correcting too far back drops my speed and disrupts my train of thought.  Ironically, there isn't a lag when you enter the feature-limited Edit mode of the mobile version of the page.

On a positive note, Chrome Beta doesn't seem to suffer the native Android browser problem of redrawing the app elements multiple times. However, that's a small consolation when the native browser actually performs better -- when it performs at all.

Figure 5

The desktop version of Google Docs on Chrome Beta for Android.

In a recent article on TechRepublic, Ian Hardenburgh argued that Chrome for Android furthers Google's goal to grow in the enterprise. That may be Google's goal, and Chrome on Android is an important step, but the beta release isn't there yet. Perhaps this is a hardware issue -- the current processing power of Android tablets may not be enough to support the features of a full-fledged web app like Google Docs. Ultimately, there's still a long way to go before Chrome is anything more than "just another browser choice" for Android.


Donovan Colbert has over 16 years of experience in the IT Industry. He's worked in help-desk, enterprise software support, systems administration and engineering, IT management, and is a regular contributor for TechRepublic. Currently, his profession...


I would love to know how Google Apps perform on the Asus Transformer Prime and the iPad 3. It is indeed disappointing that Google Docs performs poorly on tablets (and smartphones). One would expect it to perform better, since its cloud based, and that a lot of the processing happens on servers. Surely the only bottleneck should be the network connection? And how do Chromebooks perform so well, with not so much processing itself?


The Chrome Web Store is also unsupported on Chrome Beta for Android at this time. Chrome does introduce direct sync between desktop and mobile browsers for most visited, bookmarks, and "omnibox" data. This is something like Chrome to Phone, except bidirectional and with broader coverage than just sending a webpage link from Chrome on your desktop to your browser. This is a beta release - so I'm hopeful we'll see more from Chrome as the Android version matures.


Was very similar. There was no native app at that time, and the Mobile Safari experience was the same limited experience as the mobile render on the Android browser and Android chrome beta. On the original iPad - at the time, this was further compounded by very limited choices in alternative browsers to Safari. Rendering the desktop page instead of the mobile revealed the limitations with Google Apps and multi-touch devices. I think that these problems have more to do with how the Google Docs web app works with multi-touch input methods - so I can't imagine that it would be much different with an iPad 2 or 3. I'll revisit tonight on my iPad and report back with my findings here in the forum. As for the issue with poor performance in general, I've got lots of ideas, but they would all be just wild guesses. Chromebooks are generally running Atom processors, so they're going to have a performance increase over most mobile processors. I'm not sure how much of the processing is on the server host and how much is on the client with Google Docs. I don't think it is a traditional client/server model though. I think you download the app and execute it locally and run it on local resources, and it syncs changes back up to the server side. This allows you to work offline. I know if I get disconnected from my Google Docs session, I can continue to write, but it will warn me that my changes are not being saved back to the Google servers until the connection is restored. If it were a true client/server model - a network connection would disrupt the application and require a reconnect. Based on that, I'd suspect that part of the problem lies with the hardware on the client side, and how efficient the OS and browser engine are. In a nutshell, it may be the Transformer TF101 dual core Tegra just doesn't have enough umph - and it might be that Android and/or the browser engine aren't operating as efficiently as they could be. Right now I am writing this on my TF101 in Chrome beta rendering the TR site as a desktop browser, and there are a few glitches, but overall it is doing a good job. It is having a lot of trouble with capital "B"s and "C"s for some reason. I wonder if anyone else has noticed that.

Editor's Picks