Visiting = Installation

supermarket_rear_case_isles A couple of nights ago, I’m walking through the local market trying to figure out what to whip together for dinner when I quickly convinced myself to just order take-out and save my famed culinary skills for another night.

So I whip out my trusty iPhone (not the new one) and decide to use Modern Technology to order dinner via Seamless Web. So I hit the URL and I wait…and wait…ah here comes some of the interface…I wait some more. I’m still AT&T’s crappy EDGE network, so the damn thing is taking forever. But beyond the network, the entire experience of loading the interface before I can get at the content just plain sucks.

Cache Money

One of the slickest features of web browsers, desktop and mobile alike, is the ability to use some smarts to cache the assets that would typically have to go over the wire from servers scattered all over the globe. The dark world of exactly how browser caching works eludes me to this day, but it goes a bit like this:

  • Browser makes a request for a URL resource and it’s related assets.
  • As the content starts to get served up, the browser realizes that it has a lot of this content so instead of just swallowing all the assets wholesale, it actually has a little conversation with the server to find out if it can just use the same content it retrieved last time (since it hasn’t changed) or grab it anew. This is called a conditional GET.

highway02The result is a perceivably better browsing experience…maybe. The rub is that the browser has to do this for every resource – referenced graphics, stylesheets, etc. It’s admittedly more complicated than this. If you’re the masochistic sort, feel free to peruse the wildly engaging prose behind HTTP/1.1, RFC 261, Section 13.

The caching mechanisms built into today’s desktop and mobile browsers are designed to handle typically static content. Newspaper and magazine articles, blog posts, image galleries and the like.

"Please Wait While I Check For Updates To Your Software Every Three Seconds"

Now back to my ten minutes of pain in a supermarket aisle while I wait for Seamless Web to load up on my iPhone. What am I really waiting for? Listings of restaurants? Menus? Nope. I’m waiting for my iPhone and Seamless Web’s servers to have a long-winded conversation about how to deliver the interface around Seamless Web. Buttons. Drop-downs. Interface controls.

It’s a complete waste of time because for all intents and purposes Seamless Web is an application. It’s an application that should live on my iPhone and its content – restaurants and menus – should be the only thing that is delivered on request. Instead, I wait for an unnecessary dialog to occur.

There should be a way to tell a browser: "I’m not a magazine site. I’m a full-blown application. Don’t ever bother checking for new content until I tell you to (akin to a "Software Update"). When a user visits my URL, just load it locally." In other words, when I visit Seamless Web, it’s interface should pop up instantaneously on my iPhone. Forget the is-it-last-modified nonsense. It should just be there.

Taking The Long Way Home

I’m as excited as the next person about all the cool new applications springing up for the iPhone. Native, Internet-wired applications are cool. The way we’ve chosen to address the "Web application problem"  is to build native applications that tap data services. This way the interface and controls get delivered once and your computer or device only worry about data interchange. Still, it seems like we’re taking the long way to get there. Platform-specific SDK’s and development tools are a much bigger pain in the ass than straight-up web development with some new caching directives.

22844422 Beyond just caching it’s about treating certain URL’s like applications. Visiting the first time = installing the app. Visiting every time after that = loading the app locally. The primary responsibility for servers is serving up content. Yeh, they also deliver the app (that first visit) but just sometimes – and rarely. For mobile devices, this distinction takes on a whole new urgency. Such devices are ill-equipped to have a rambling dialogue about whether content is new for every graphic and stylesheet. Why bother?

This way I can quickly order Chinese food while loitering the produce aisle of the supermarket. Can you think of a better cause for such change?

1 Comment Visiting = Installation

  1. james kebinger

    Interesting idea.
    Conditional get isn’t a rambling dialog however – Even calling it a conversation is a little misleading, because (to me at least) that implies there are extra round trips where there are none. Its just an additional header and you get back content if the condition was not satisfied, otherwise you don’t.
    Here’s a half baked idea to skip adding that header field about versioned URLs for application resources – if the server sets an expiration date far in the future, then the client never asks for it again. So a request for application resource foo could be redirected or rewritten to v1.2/foo which is cached. If the app is updated, some root entry point could switch the redirect path and you’re downloading a new version.
    The downside is you’d probably end up loading all the resources again for even a minor release.


Leave a Reply

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