I'm not categorically against apps. On the contrary, I think apps are quite suitable for a variety of purposes; in particular, productivity, gaming, communications and one-way, consumable media are all types of applications that work quite well in the mobile context. But apps are not an ideal format for wide and unmonetized content distribution. In addition to a format mismatch, the economic and practical factors surrounding creating and distributing the apps themselves are, in my opinion, indicators that the long-term sustainability of the app paradigm is unlikely. I have three main complaints in my case against apps:
1. Economic Oligarchy
The charge of economic oligarchy is, admittedly, more of a political complaint I have with the way in which the overall apps marketplace has been established. But in that it is political, I feel that it fundamentally contributes to the imbalance and unsustainability of the apps economy. Presently, there are only two companies that control almost the entirety of consumer app-related commerce -- Apple and Google. And while scores of developers are understandably excited about their 70 percent cut of the revenue generated by the sale of their applications, the economic conditions will always remain drastically in favor of the very tippy top.
At the time I last investigated, there were over 400,000 unique mobile applications available for download. That's a staggering number considering the relative recency of the launch of the two app marketplaces, which, by the way, have already seen over 10,000,000,000 downloads! The activity and the revenue have been far beyond anyone's expectations. Since there's so much money to spread around, all the application designers and developers must be doing quite well, right? Not exactly. Consider this: The average price of a mobile app is a paltry $1.65. Only an unusually prolific individual could expect to get rich developing apps, whereas the owner of the entire marketplace has only to open the doors, so to speak, to generate significant wealth. Additionally, Apple and Google have tight control over which apps make it into their inventory. These factors result in a system that is not exactly an innovation breeding ground. The real innovation has already happened -- the creation of the marketplace itself. The next big thing is much more likely to come from outside the app marketplace (like, say, on the Web), where fewer controls exist to stifle such things.
2. Unnecessary Redundancy
If you are a designer or developer, the pain of inefficiency should resonate with you, even if you have never created a mobile app. Because of the platform division between the two major marketplaces, developers are forced to build their mobile apps twice in order to make them available to the largest number of potential users. The Apple and Android platforms are proprietary systems with unique technical requirements. Economic competition, of course, is the only real reason for this -- and, in my opinion, it is not a good enough reason to validate the resulting doubling of effort. Surely there are plenty of competitive angles that could be pushed as far as the devices themselves are concerned (e.g., form factor, feature sets, and network carriers) that a standardized approach to app development could be possible. But for now, that is not the case. It's not only the developers that suffer under these conditions. If I were considering green-lighting the production of a mobile app, I would be frustrated enough by having to fund essentially the same thing twice to consider it a legitimate barrier to entry. It is only a matter of time before that pressure results in developers either limiting their capabilities to one platform or the other (which, in and of itself might make sense -- Michael Surtees had some thoughts on this recently), or rebelling en masse and forcing the app dictators to tear down the wall between them (hyperbole intended). My hope, of course, is for the latter.
3. No URLs
As a Web enthusiast, the lack of URLs for apps and the information they contain is my biggest complaint against the app marketplace. Without a protocol for locating the information contained within an app, its ability to be found and shared is nonexistent. As an example, I'm showing an image of the WIRED magazine app for the iPad, which I eagerly anticipated after seeing many demo videos and generally buying into the hype that preceded it. When it did finally launch in May of 2010, I immediately looked it up in the Apple App Store, paid the $3.99 for the first iPad-friendly issue, and waited several minutes for it to download. I spent some time "flipping" through it, but it was not long before I gave in to disappointment -- you know, the kind that you deny for a while in order to avoid the sting of shame that comes from naive capitulation to undeserved hype. Yes, I thought it was going to be wonderful. No, it was not. Here is just one reason why:
Suppose I read the center article in the "timeline" interface above (a meritable UI idea, to be fair) and then wanted to share it with a friend or among my social network. There is really no good way to do so; the article itself doesn't have a specific address of its own, nor does the issue as a whole. The best I could do would be to link to Wired Magazine's listing at iTunes. The article I read is an undifferentiated, un-locatable piece of the issue -- the 500mb glorified PDF that we're calling an "app." Sadly, this is not just a hypothetical scenario; this very conundrum presented itself to me within an hour of downloading that first issue. Being the savvy and resourceful Web user that I am, I went to Wired.com, found the article I liked, and sent a link to that URL -- the Web version -- to my friend. Just a second or two later, after clicking "Send," I thought, Why didn't I just start here in the first place? You know, on the Web, where, for the most part, the exact same content offered by the $3.99 app is available for free, along with additional sharing and engagement opportunities the app version lacks.
This is my central objection to "appified" versions of content that have a more natural, flexible and indexable incantation on the Web. Rushing to hop on the mobile app bandwagon has resulted in an unthoughtful trend of cramming content into impenetrable shells. If you searched for information that would best be supplied by content in a mobile app, you wouldn't find it with Google. (And sadly, you would be just as unlikely to find it using Apple's App Store search tool, which falls far short of being useful.) But you would find it in plenty on the Web. For those creating content simply to share or for marketing purposes -- as a means of describing expertise and educating prospects about a product or service that could be useful to them -- the locating and sharing limitations of apps undermine the very purpose of content, whereas the inherent nature of the Web provides the platform upon which it can fulfill it.
Between the economic factors, the practical inefficiencies of development, and the lack of URLs, apps are currently subject to a system that almost seems intent on stunting the potential of content. Of course, looking at the sales numbers of mobile apps, you might not think anything was wrong. I certainly don't want to rain on anyone's parade, but something is wrong when the outcome falls far short of the promise. When it comes to apps, we should be clear in admitting where they lack many of the things that make the Web great.
The Case for the Web
If apps are not the best format for content, then how does one account for mobile in a comprehensive digital strategy? My belief is that the Web provides a strong answer by naturally accounting for the weaknesses of apps in its most basic attributes. In particular, there are three Web-centric principles that can provide strong guidance as you are assembling a mobile approach:
1. Content First, Context Second
Most of the conversations we have with our clients about mobile involve planning for how to account for existing Web content in an overall mobile strategy. The key point here is that, in the context of these discussions, the existing content has already proven itself and there is a recognized need to extend its accessibility across wider conditions -- namely, to mobile users. But invariably, as we work on adapting content templates for mobile devices, we start getting requests to build new types of unique content -- essentially, separate, mobile-specific versions of websites. That's where the logic gets unproductively circular -- why are we all of the sudden talking about creating new, unique content when the entire conversation started around making the existing content easier to consume for mobile users? If we were to take that route (for which there could be good reasons), the new content would be untested -- a risk. But the existing content has already met the demand test. That is why mobile strategy should proceed from content, not the other way around.
By the way, this principle extends to particular technologies, as they can become a barrier, too. For instance, video, which might generally be accessible on the Web implemented with flash-based players, won't work on most mobile devices. The solution, of course, isn't necessarily to create new video content. Rather, it should be to facilitate wider accessibility to the existing video content by choosing the right technology that works in all contexts. YouTube is a good solution for this.
2. Use Unique URLs
I hope I already made clear why a lack of URLs is a weakness of apps. On the Web, the question of where a piece of content exists is almost always relevant -- to the humans that search for it, interact with it, share it, and save it for later, as well as to the search engine bots that crawl the Web indexing it. In short, addresses matter. Imagine if you went to visit a friend at an apartment building but did not have their apartment number. The best you could do would be to knock on every door on every floor until you found the right one. We take this for granted on the Web, but had there not been a Web version of the Wired article I mentioned earlier, I would have had no way to direct anyone else to it.
In January, Matthew Ingram, a writer for GiagaOM, was interviewed for an episode (#35) of the Spark podcast about this very issue and had this to say:
... apps as individual, controlled experiences are good for some things. I'm pretty convinced it's not the best thing for things that have to do with media, with content. The whole lifeblood of content is the sharing, the linking. Whether it's apps or websites, if you look at the ones that don't do that I think you quite quickly come to the realization that they're missing something fundamental.
I completely agree, and couldn't have said it better myself.
3. Create Seamless Experiences
The first priority for creating content in a long-term digital strategy should be to facilitate seamless user experiences across a variety of contexts -- from desktop, to tablet, to smartphone. A working example of this comes from Google Books (I first mentioned this in a blog post last March), which successfully preserves the essential reading experience regardless of the device you use. It is difficult to express how incredible and revolutionary that really is -- that I can read a bit on my desktop and pick up exactly where I left off on my tablet or phone without giving any thought at all to bookmarking. Google has made seamlessness innate to their books experience. Of course, the book itself is closer in nature to an app like the WIRED magazine example, in that it is one file without a master URL or locations for individual chapters or pages. But, it still serves as a great standard to strive for in terms of seamlessness of use. Just imagine what that could mean for content on the Web that is truly optimized for reading. I'm confident that we will be able to bring the same level of fluidity to all Web content in the not-too-distant future. In fact, that is what the responsive Web design movement is all about.
Responsive Web Design
If you are unfamiliar with what "responsive" means as far as Web design is concerned, a recent Design Shack article by Joshua Jackson provides a useful explanation -- showing how responsive Web design works by employing CSS media queries to reorganize page elements based upon the maximum screen resolution available to the user. Jackson goes into a bit more depth by showing a specific example -- the charming site of Megan Fisher, Owltastic.com -- which has up to five different layout options based upon maximum resolutions of 960 to 480 pixels, and reviews the CSS and media queries that make its flexibility possible.
This approach certainly makes a lot of sense given the technical issues at play, and provides a proactive solution for ensuring usability across a wide (and growing) array of contexts. But it is also likely to challenge the process that many designers and clients are used to right now. I can imagine that going through traditional rounds of design to determine how a page will look on screens of differing resolutions -- especially once you surpass more than just a couple of options -- would be too costly and inefficient to make sense for most projects. Instead, it seems that the final, approved design would have to instead provide standards and enable the developer to have latitude for reorganizing and redistributing content based upon an agreed set of priorities within a more iterative process. Because this approach is so new, there are likely to be a multitude of practices to integrating responsive design into project workflows. I am on the lookout for an effective, tried-and-true process that can be scaled across projects of significantly different scopes. In the meantime, we have been exploring techniques for providing alternate templates and stylesheets that reformat existing website content for mobile users, which is a step toward the responsive method that still allows us to follow more traditional design and approval procedures with our clients and partners. Mobile is more than just a format; it is a complete paradigm shift. To make the transition feel more secure and manageable to our clients, we've found this intermediate step to be necessary for the time being.
The Future...
The Web is a work in progress. This is my mantra for all things Web (as you have probably already read), so it is not going to be any different with mobile. While we are not quite at the level of seamlessness that Google Books offers, it will one day be possible and is certainly a decent standard to strive for even now.
Copyright F+W Media Inc. 2011.
Salon is proud to feature content from Imprint, the fastest-growing design community on the web. Brought to you by Print magazine, America's oldest and most trusted design voice, Imprint features some of the biggest names in the industry covering visual culture from every angle. Imprint advances and expands the design conversation, providing fresh daily content to the community (and now to salon.com!), sparking conversation, competition, criticism, and passion among its members.
Shares