“The Internet is everything” Deja Vu all over again « GartenBlog

Posted on July 10, 2009 by Ian Betteridge
“And perhaps to Mike, the Internet is *everything* and he can do all his work, communication and entertainment in a browser. I know for sure I can’t, even though connectivity is important to many applications I use, the browser itself leaves a lot to be desired. Even web based services like Twitter work better for me through an application like Tweetie as opposed to the the Twitter site (and a lot of user data suggests I’m not alone in this thinking).”

via gartenblog.net

You can take the enormous popularity of “native” applications for Twitter in one of two ways. Either Twitter’s site is so awful that people are desperate for an alternative, or the fact that Twitter has a pretty good API means people can build better ways to access it. I’d err towards the second.

Here’s a thought: If there were native clients which plugged into Google Docs as comprehensively as native Twitter clients do for Twitter, how many people would use them instead of the web clients?

My guess is that, given the choice, people would use the native clients far more than the web. And that has some interesting implications for the future of “web” apps, which I suspect might be somewhat different to how people usually imagine it.

Posted via web from Ian Betteridge’s lifestream

This entry was posted in Uncategorized. Bookmark the permalink.
  • http://www.snell-pym.org.uk/alaric/ Alaric Snell-Pym

    It's possible that the facilities offered by ECMAscript and the DOM may one day be sufficient to embed applications in web sites that work as nicely as native apps.

    There's a lot of confusing history about the difference between browser apps and native apps, but the limitations of browser apps have mainly been due to limitations of the available implementations of platforms in the browsers, rather than theoretical limitations.

    After all, at one extreme end of the spectrum, it's possible to just link to a .exe (security issues aside) and thus have a browser-'based' app that has all the power of a native app, as long as that .exe can run without needing to install stuff on your workstation :-)

    Forgetting all the historical issues of ECMAscript, Flash, Java, ActiveX, etc, the real question is one of trust and security (even issues of platform dependence can be avoided with an appropriate VM – such as just writing all your apps in ECMAscript). It's flawed that native apps are trusted with the full security context of the user (as it's all too easy to get somebody to download and install a native app from a Web page); but the whole issue of having to “install” something is really no different from downloading some Flash or a highly scripted page to display in your browser, and caching it locally; any user-visible difference between the two is, perhaps, just a flaw in the UI design. At most, users should have the option to make sure a page is available for offline use, effectively pinning it in the cache, if they are prone to working on underground trains or don't want to spend on mobile bandwidth.

    Something that would truly deserve the buzzphrase “A Web OS” would quite probably identify applications by the URL they can be downloaded from, would have no concept of “installed applications” (they are merely cached), and – this is the interesting part, an open research question – have some decent mechanism for managing trust. Previously unheard of apps would need the kind of restrictions we find ECMAscript apps hobbled by today, such as a total inability to access the user's private data, to escape the browser window, etc; but applications could request the right to submit a widget (as HTML!) to appear on the user's status bar, to have their own isolated section in the user's private data, or even to be granted varying levels of access to shared areas in the user's private data (which would contain things like the user's address book and other goodies).

    Less-obvious benefits of such an approach would be that the local storage on the device would be clearly split into areas – the OS and drivers, the cache, pinned cache entries (eg, things marked for offline use), and user data. Keeping them separate would make it easy to synch and back up such devices; in fact, all you need to back up is the user data, as the pinned items in the cache can just be downloaded again from the list of things to pin stored in the user data, making for quick restores, and transparent syncing of your installed apps between devices. Given access to a Web service that syncs your profile between devices, you could even log into a guest account on a friend's device and download your profile. Apps would be encouraged to make sensible decisions about how much data they actually store in your private data area (some kind of session cookie to identify you to the remote server without endless logins, and then enough to enable some level of offline operation?), keeping the private data area small.

    That's the sort of thing that I rather hope the Chrome OS will be – not a device that's totally useless without an Internet connection!

    Needless to say, if Google (or anyone else!) are at all short of innovative people keen on designing non-traditional operating systems, please do get in touch ;-)

  • http://www.technovia.co.uk ianbetteridge

    You know they're recruiting in London for it, don't you?

    http://chrome.blogspot.com/2009/07/google-chrom…

  • alaricsp

    Yeah, but the last thing I need's another job in London…

    And, besides, if they've got as far as going public, they'll have already made all their plans; all they'll be wanting for now are code monkeys. But perhaps their current architect will want to move on, one day…

    …or somebody else will want to write a competing product ;-)