Thinking about the internet – at least the internet since the invention of the web – it strikes me as a long journey from general-purpose to highly specialized uses. The first websites were broad, serving lots of purposes. They were muddled & messy, very amateurish – much like the industry was. We first few web developers did not have a vocabulary to work with – we had to make it. And the early web reflected that. In many ways, more than anything else, this is what the Web 2.0 “revolution” was about – standardizing the vocabulary of the web. This lead to web standards, common conventions. It is no coincidence that around this same time, the publishing industry was rife with books like “Don’t Make Me Think!” (2000) and “Information Architecture for the World Wide Web” (1998) – we as industry were maturing. Along with this came specialization. Until the late 1990’s, it felt to me that everyone working on the web could, and did, do a little of everything. While I was already primarily a programmer, it was expected that I would do some design work. Designers were expected to markup and code as well. This is much less the case now – this is specialization comes with industry maturity as we all learned the particular roles and skill-sets that make up a web-team (this is not to say that people do not work more than one role now – lots of people do. But it is less common, and people now will identify more by a particular role (designer, programmer, front-end devloper) than as a generic “web developer”, which was an insanely common title in the 90s).
There was an axiom (that probably still holds true) that in order to make a good web app, you just needed to “look for a unix command-line tool & slap a web-interface on top of it”. Many, many useful web applications grew out of this ideal: Do one thing, and do it well. Sure, there were, and are, sites that do lots of things. But looking around at my fellow web professionals, we all are completely comfortable with using best-of-class tools for each problem – whether or not they interrelate particularly well. Just as we have specialized our skillsets, we are specializing our tools as well – but, all to be done in our browser. Our time-tracking software is different (though it may well talk to) our invoicing software which is different from our project management software. In many ways, the 37 Signals suite of apps embodies this the most. The trend of the “open” web (by this I mean the low-barrier-of-entry of web apps (intuitive, cheap, ubiquitous, interconnected via APIs) has in some ways run counter to the professional development of those of us working in the medium (most programmers can no longer design at a high level and vice versa). But we have gotten, thanks to an increasingly sophisticated & shared vocabulary gotten very good at inter-skill communication, much like websites have gotten very good at sharing data between themselves.
The Mobile Internet is taking specialization a step further, and in a very different direction from the web itself. Due in no small parts to the design constraints of the GUI on current-generation smart phones (Android, iPhone, Palm, Blackberry), most apps tend to do one thing, and one thing well. But here’s where things are different again – while our browser was historically a very-general tool, single-serving apps are replacing the browser. For instance, I use the New York Times app to read American News, The Guardian app to read European News, The Globe & Mail app to read Canadian news. I use the I Can Haz Cheezburger apps for that suite of blogs, etc. I use Now Playing to check theatre times & buy tickets. I use Tweetie to interact with Twitter ,the Facebook app to interact with Facebook, and so on and so forth. Each time I want to perform a different action online, I now use a different app, not just a different URL. And there’s a very good reason for doing this: each app has a highly-specialized UI that is designed to optimize my experience using it. Each app, while drawing from the same general syntactical rules of the Apple iPhone HIG (I expressly say the Apple HIG, because, from the few other smart phone apps that I’ve seen, they are all reading from this same playbook), may have it’s own dialect of interaction rules, but overall, I know what to expect. But this specialization allows for my experience to be improved more than any web-app (to date) has been able to do. Content producers love this because it creates lock-in. In order for me to switch phones now, not only would I want every single app I commonly use to exist on my new mobile device, but I’d want there to be a better experience with some of them to make it worth my while.
We have reached a curious point in the development of our industry: To build a good mobile App, look at an existing web app and wrap a more-customized, specialized UI around it, and you’ll have a good mobile app. But, while on the surface this sort of looks like a continuation of the old unix-command-line axiom, there is a difference: For the most part, mobile apps tend to exist in silos, unaware of other apps, similarly to how web apps used to exist. There’s also the matter of lock-in. Because these apps are almost always platform-specific, it locks their consumers onto a particular platform. And because the languages used to create for each platform are (and will most likely remain) different, there’s a huge expense in porting an app from one platform to another. And, much like cross-platform development tools for the desktop create experiences that somehow fail to work great on any (see: any Adobe AIR app), the same will happen on mobile platforms (this is a very good argument in favour of Apple’s infamous section 3.3.1 update). I’m not sure what this means for the future, but I have a feeling that with the exception of “utility” apps that will be ubiquitous, we might see shaking out in the mobile environment what happened in the desktop environment. One platform will become thought of as particularly “good” for a certain segment of apps. Blackberrys might be good for “business”, Android for “development”, WebOS for “social”, iPhone for “gaming” – who knows. Right now, the iPhone(/iPod Touch/iPad) app market is so dominant that it shows up in all catgories. But already, friends who are sysadmins or in the support/service side of IT seem to be all buying Android phones (and the number & diversity of IT-related apps for Android is stellar). My colleagues in sales & HR seem to be happy to just upgrade their RIM phones. I really don’t know anyone who’s buying the Palm Pre, to be honest, but hopefully it’ll find a niche soon.
We, as an industry, still seem unsure about when to build an app, when to build a mobile website. I don’t believe the answer is always “build both”. But I’m not sure that as an industry, and more importantly, we as a culture of users of the mobile web (which already has a different flavour from the desktop web) have developed a strong enough syntax to know how to answer that yet. But I do see an continuation of this trend of specialization in skill sets & in what web sites and apps do.
My belief is that Single Serving Web Sites which today exist as mostly joke sites may actually be signs of the future to come: ever-more-specialized web sites & apps. My hope is that this, combined with semantic markup, structured data and smart APIs will actually benefit the user: I may use 200 different beautiful, optimized, specialized apps & websites in a day, but hopefully they will exchange data in a manner that I control (via things like 1Password (which if you aren’t using – why aren’t you)), but I suspect will be controlled via things like the existing authorizations schemes of Twitter, Flickr, Facebook & Google.
