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.
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.
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.
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.