Because it’s partially responsible for the delay on pieces concerning the IBM conference and Microsoft’s Azure launch, I thought I would take a second to detail more precisely today’s criticism of Firefox’s offline paradigm. Clearly I’m explaining myself poorly, because David‘s a smart guy and even he couldn’t parse my terse, 140 character explanation. And I might as well comment, as the Mozilla guys have been politely interested in feedback on the subject in the past, even when responding to a comment like “Mozilla’s browser is still fairly stupid when offline.”
So, here’s what I would have from Firefox: on startup, in an offline setting, do nothing more than render my previous sessions tabs from the cache. That’s it. Let me, for example, open a bunch of tabs I need to finish an entry on Azure on the plane, and recover those later even when cold restarting the browser lacking a network connection. Put more bluntly, do not serve me a browser full of tabs that look like the above.
One of the problems in this space, I think, is the tendency to overthink the problem. Those of us who spend a significant amount of our day using offline applications have long craved a browser that would allow those web based apps to function offline. That, in part, is why so many of us were excited about Gears.
But a year later, the available evidence would indicate that persisting web based applications offline is just what developers told me it would be: exceedingly hard.
Not for a lack of tools, of course. Gears, or even Derby/JavaDB or native SQLite, offer much of the raw functionality a developer might require to allow an application to function in an offline context. But how to subset the data?
Neither traditional rich client (mobile being a notable exception) nor web developers have a great deal of experience in designing applications that function with but a portion of the typical dataset. Rich clients typically rely on a server in the traditional client/server context, while SaaS applications live on the same network as the data, typically. So how do you, as an application developers, choose the data to persist to the client for offline usage? And worse, how do you handle questions of synchronization, and the inevitable collisions between conflicting updates?
Gears has been out for about a year and a half now, and it’s still exceedingly rare amongst mainstream web applications. Even Google web applications; Reader has an implementation, clunky though it may be, while Mail – a logical candidate if ever there was one – does not.
You may conclude what you wish from that observation, but to me it means simply that the technology is difficult to apply.
Which is why I am not calling for, as David Berlind put it, “Seamless persistence of browser-based applications.” That implies – to me – the ability to browse a web app locally, rather than just render a single cached page. Offline would be more than welcome, of course, but it’s hard, and things that are hard take a long time to build. In the interim, I’m asking for something pretty basic.
Much like collaboration vendors overshot simply group scheduling by focusing on what could not be done, so too have the browser developers, I think, by trying to deliver the once and future offline persistence mechanism. Which, if they could deliver it, would be game changing.
But while I’m not willing to bet on that outcome, I would be willing to bet that simply tasking the browser with the far less complicated job of preferening the rendering of a given tab with the content from its cache over the ugly “Offline Mode” page would dramatically improve the experience for millions of users.
Or at least those of us users that have to fly occasionally.
