Why mobile apps are a step backward

The Web has given us the opportunity to share context freely and openly. Mobile apps takes us back to the days of the proprietary client all over again

businessman foot stepping on banana peel
Credit: Thinkstock

A few years ago I attended a conference organized by Brian Fitzpatrick. Here's part of the email Brian sent to attendees:

This year we've worked out a discount rate of $119 a night with the Marriott which is about two blocks away from the Innovation Center. You can make a reservation at this rate by following this link: http://www.marriott.com/hotels/travel/chidm-chicago-marriott-at-medical-district-uic/?toDate=1/22/12&groupCode= ORDORDA&fromDate=1/20/12&app=resvlink

Beautiful! Rather than describing where to go on the Marriott site and what information to plug into the form when I got there, Brian composed a URL that encapsulated that data and transported me into Marriott's app in the right context.

complex URL encapsulates data

The Web used to routinely encourage such interactions. HTTP is stateless, URLs can carry all sorts of data, application states can be represented in compact strings of text that people can exchange in email. To exploit those capabilities in the way Brian did you had to be a bit of a geek; capturing and relaying a link as he did wouldn't occur to most people. But it was often possible, and we might have evolved the Web in a way that would open up such possibilities to a wider population.

Marriott mobile apps

Instead, pictured left is the future that Marriott (and everyone else) is rushing toward.

Call me a grumpy old fart for saying so, but this shiny future shuts the door on the sort of user innovation that Brian's little hack demonstrated. Links are the connective tissue of the Web. When we suppress them, we prevent users from discovering unanticipated ways of working together.

Sharing context is one of the benefits you get when application state is externalized as a set of URLs. Automation is another. URL-driven interactions can be scripted and replayed in a platform-agnostic way.

It isn't only native apps that foreclose these possibilities. JavaScript frameworks seldom map application state to URLs. Either way, the URLs still exist because, under the covers, native or not, these are still Internet applications. Open up an HTTP debugger and you'll see those URLs fly by. But they are increasingly unlikely to map cleanly to application states or to be accessible to users who want to save or exchange those states.

Of course, many users, much of the time, won't want to see or interact with raw URLs, even ones that are elegantly clean and literate. That's fine. But let's not do away with them entirely. Why not recapture, and extend, the original architecture of Web apps? URLs that map to application states are dual-purpose APIs. For expert users like Brian Fitzpatrick, they enable customization without coding -- or, if you prefer, a simplified form of coding that requires mastery of nothing more than URL syntax.

The same kind of API enables programmatic customization -- again, crucially, in a platform-agnostic way. I can imagine exposing a common URL-oriented interface to the core capabilities of the iOS and Android and Windows and HTML5 versions of the same app. I can also imagine frameworks for all these platforms that make it easy to do that.

I'm not naive -- I know that's unlikely to happen. But let's pause for a moment to reflect on how the Web first changed our minds about software. Prior to the mid-1990s, deep magic was required to enable saving and sharing of application state or common automation. Then suddenly it all became not only possible, but easy. Every application was, by default, a user innovation toolkit open to creative reuse.

Could the modern, mobile Web still be a user innovation toolkit? Of course. Why isn't it? I see plenty of reasons, but no good ones.

From CIO: 8 Free Online Courses to Grow Your Tech Skills
View Comments
Join the discussion
Be the first to comment on this article. Our Commenting Policies