tecosystems

Get Thee Offline, Firefox

Share via Twitter Share via Facebook Share via Linkedin Share via Reddit

offline

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.

10 comments

  1. Offline is very hard indeed for all applications that have to do more than read-only. The case that you mention, showing the last bit of state, that can be easy enough.

    As soon as you do more (most cases) then it gets harder. Look at how well Zoho has done though. Their office suite continues to do more and more offline, including their Mail product.

    Offline isn’t “free”. It comes at a price, that of rethinking your architecture. But, our expectations of what Web applications can do continues to change, and that will include expecting apps to work offline.

    Cheers,

    Dion Almaer

    Formerly, Gears team
    Currently, Mozilla

  2. Offline web-apps aside: The specific problem of being able to read the articles you opened in tabs while on the plane does have a solution: It’s called suspend/hibernate. That way, FF pops up just the way you left it. The only problem: What if it’s one of those articles that is spread over many individual pages to increase ad-views? You need to check that ahead of time and open those subsequent pages as well.

    But that aside, suspend/hibernate is the best solution I have found so far.

  3. Sounds like you’ve laid a challenge on the table. if you didn’t, then you should 🙂

    One of the difficulties, as always, is the unbelievably sucky “browser” model that we are forcing applications to live in. Another view of this problem would be the “time-travel button” problem (ie, “the go to the previous page button”). For many web 2.0 apps, if you traverse away from the page the app is running on by clicking a link, when you come back, you don’t get dropped back into the state you were in when you left the “app”; the “page” is basically reloaded anew. A smart web 2.0 based app will do things like leave state in a cookie or in a hash tag in the location bar, and then use that to re-orient itself in time, so you have the appearance of coming back to where you were. Takes work at the application level to make this scam viable.

    In much the same way, reloading a “page” on startup is going to go through the same motions. But now the problem is that if you’re off-line, that app probably isn’t going to be able to re-orient itself, because it was probably pulling stuff from the web to do that in the first place.

    To do this right means having reasonable Gears or other local persistence in place, with the application actively taking advantage of it.

    The alternative would be for the browser to actually remember the state of the “page” transparently. This isn’t just remembering, for instance, the current version of the DOM being displayed; it’s the state of the JavaScript runtime. Almost do-able, I think. You’d need to define what happened to things like XHR requests which were outstanding during the “page save” (probably ignore them – don’t try to “revive” them during a “reload”). Seems like a worthy experiment to try, but I’m guessing it wouldn’t be a pretty picture. We did this sort of “freeze the runtime state so it can be revived later from a cold start” in Smalltalk. Do-able. But not all scenarios were revivable.

    In the end, the blame needs to be laid on the app developers, not the browser developers. Don’t think this is really fixable in the browsers, as we know them today.

    Or, you could say the blame is on the browser developers not giving us a suitable application runtime platform. While I think there will always be some amount of work an application will have to do to make it cold-start revivable, the runtime platform could make this a little easier than it does today. For instance, exposing specific “I’m about to suspend” and “I’m reloading” events sent to an application.

  4. I would take your suggestion for FF (“do nothing more than render my previous sessions tabs from the cache”) one step further: FF should also tell you that the sessions are not reloaded, that they are from the cache, to avoid confusion on your part.

    Of course, this problem will lessen when we get wifi on airplanes! Whenever that is…

    I was at a conference a few weeks ago and wanted to update my Google Notebook session at the end of the last day. At 5pm sharp, the wireless shut down and Google Notebook became useless. I lost my context, and my notebook. Darn.

  5. Take a look at this. CouchDB could be the solution for what you’re talking about.

    http://jchris.mfdz.com/code/2008/10/standalone_applications_with_co

  6. Hey Stephen, great post and look at whose commenting!!! You have quite the audience. I’m jumping in late with my own post, here:

    http://www.informationweek.com/blog/main/archives/2008/10/persistence_is.html

  7. […] on his Tecosytems blog, Redmonk principal analyst Stephen O’Grady picks up a conversation that he and I first batted back and forth on Twitter. Twitter, with its 140 […]

  8. Speaking personally I would settle for a “do not under any circumstances go into offline mode” option so that I can still access apps under development running from localhost when the LAN goes offline. Grrr!

  9. […] application and, after Twitter failed us in the ability to carry the dialog, we took to the blogs (him, me) to continue the […]

  10. […] on his Tecosytems blog, Redmonk principal analyst Stephen O’Grady picks up a conversation that he and I first batted back and forth on Twitter. Twitter, with its […]

Leave a Reply to David Van Couvering Cancel reply

Your email address will not be published. Required fields are marked *