Great article about Mozilla Fennec and taking the browser fight to handhelds.

One has to wonder where the innovation should be in mobile browsers, as opposed to plain performance, which should dominate the initial design criteria. No use putting a slow browser on an already slow phone. Time and again, the mistake is made to assume that faster pipes mean faster browsing. Wrong! Browsing a web page is a sum of many software/network processes, each of which incurs a delay. It is the overall delay budget that really matters for the average surfing experience. Once a stream gets going, then the speed of 3G+ networks kicks in, so YouTube ought to work better on the 3G iPhone, when we get one.

The problem is that we are putting more functionality into the mobile browser, especially Javascript to enable richer web pages and to support AJAX. Therefore, Javascript execution speed really matters. Mobile browser implementation is one of those areas where good old-fashioned code-crafting for speed still matters. From what we’re hearing so far, Fennec is going to be blisteringly fast.

The case for local caching and storage continues to be made. From my own recent experiences with browser-based mobile app design, design patterns are required to support pithy one-off status updates to various sites, be it Twitter, Facebook or something else. In other words, we need a fire-and-forget form submission. However, implementation of this will rely on access to underlying multi-tasking support to ensure that a fire-and-forget operation completes after the user submits and closes the browser. This isn’t guaranteed on today’s devices: close the browser and all its processes are suspended.

Otherwise, apart from these various performance-related issues, the innovation in mobile browsers will come from two directions. Firstly, there’s integration with the underlying APIs, so that web pages can do clever stuff with the device, just like the Opera Platform (now defunct) once promised.

The other direction will be in tight and useful integration with the desktop browser(s). I say browsers because there are an increasing number of users who have desktop and laptop machines, or want to access their browsing environment via a corporate PC (not on company time of course). We should expect a data-portable network-based means to support portable user environments, such as bookmarks and saved form-data (usernames, passwords etc.)

I’d like to see better support for saving for offline mobile viewing. In other words, I see something I like on the desktop/laptop and then bookmark it for offline viewing on the mobile. A good example is a web-based travel itinerary. If I bookmark this for mobile viewing, then I’d like the content to “flow over” to my mobile, preferably whilst it’s in local-network mode (i.e. WiFi connected) and be available for instant viewing on the device, even if I don’t have coverage. This is a common usage pattern already. Blackberry users will be used to emailing themselves stuff, like web-pages, just so that they have a copy on their device for later.

I’d also expect browsers to become more savvy about how they handle connections between social data in the page and my address book. For example, whenever I surf a page with someone’s content in it, or about someone, I ought to be able to instantly ‘connect’ with that person in which ever ways my mobile is capable of supporting, be it phone call, text, Twitter, or whatever. This kind of fluid at-my-finger-tips control is what the mobile experience ought to be like, especially to avoid such dumb ideas as taping paper phone lists to the back of the phone.

There are tons of other mobile browser innovations still to come and I look forward to some of them appearing soon on my iPhone. Safari has certainly got better on the desktop, but has some crazy limitations on the iPhone itself. For example, why can’t I save images from the browser (or the email client for that matter)? Seems almost as dumb as the ongoing lack of SMS forwarding. Will they let Fennec run on their beauty? Not according to the SDK limitations, supposedly.