Design Communism

Some innovations transcend short term competitive advantage

Since capitalism and design are, for the most part, governed by market forces, there’s symmetry between them. Capitalism tends to be most effective at its lowest levels, meeting demand through efficient supply. Companies that do that well succeed and those that don’t fail. The same is true for design: At its “lowest levels,” a clean look, a simple flow, and an elegant layout are fairly well understood and valued. Products that reflect these low levels succeed and those that don’t fail.

This isn’t foolproof of course. Just as capitalism doesn’t guarantee all companies will be profitable, there is no guarantee good design will always happen either. What I’m saying is that there are clear market forces operating for basic UX design, but only at these “lower levels” of design.

However, it is at the opposite end, when we get into the “higher levels,” that things get sticky. For capitalism, monopolies warp our comfy view of “the market,” which prompts contentious laws to pass. The parallel with design happens when proprietary technologies gain a broad audience. When companies get control of a market and have a lock on users, it is in their financial and—dare I say it—capitalist best interests to use that market power to make a profit.  This cannot only lock out choice, but can prevent innovation. It’s at moments like this that the quiet capitalist in me transforms into a design communist.

Why this matters to mobile
Like many of my neologisms, don’t take “design communism” too literally: I’m certainly not asking for state control of technology. We need to stop assuming that pure market forces will blissfully take us towards an innovative future. We need a deeper understanding of where we are going in order to encourage more innovation. Raw capitalism is fantastic at improving quality and driving down costs but it also rewards a monopolistic lock-in that tends to discourage companies from playing nice with others.

The entire purpose of this “Beyond Mobile” blog is to discuss and explore unlocking the future of smart devices. I feel strongly that this is being held back by a number of forces, but a critical one is being able to liberate web applications on handsets. I’ve discussed this in greater detail in my App Myopia post where I make the case that providing a discovery service to all smart devices around me, through HTML, is a fundamental shift that can unlock huge potential.

We’ve seen big shifts like this in the past. The standardization of railroad lines and universal container ships were broad efforts that reduced proprietary lock-in, but revolutionized their respective industries. Mobile web technology is in a very similar situation. It is not an alternative to native apps, but a basic, core technology that works on many levels. It’s a lingua franca of functional expression that can work not only on multiple devices but even as a service between multiple applications.

The mobile web matters for the simple reason that it doesn’t require an install process. This also means that users don’t need to manage the storage of that app: once used, it can quickly fade away with no uninstall necessary.

Companies like Apple and Google appear to be locked into a race of application dominance. They are like the grand railroad barons of the 1800s, arguing over whose gauge rail is best. Yes, they both also have excellent browsers, but we are in need of deeper innovation in mobile web technologies. They don’t appear to see this as in their best interest to push it forward.

The patient always stops bleeding
So what’s the alternative? The evolving HTML5 standard is clearly a good start. Unfortunately, it is a slow, plodding beast. It may be attempting to create a set of non-proprietary solutions, but damn, it feels like it’ll never get there at times.

Medics in World War II had a rather grim saying about field injuries: “the patient always stops bleeding” (whether they survived or not was a secondary point). In many ways, capitalism is the same way; companies always stop using proprietary technology. Design communism is about pushing hard on companies to be more enlightened, realizing that there are issues that, on the surface may not give you lock in, but raises the playing field so everyone wins.

The Browser Ghetto
I will understand if you think I’m a bit crazy. Apple, after all, embraced the CSS3 standard aggressively on the iPhone. In fact, the first iPhone didn’t initially have native applications, it was all web based. How can I possibly claim they don’t care about mobile web? To this all I can say is of course they like the mobile web, but they like it in a tightly little fenced in ghetto, a browser ghetto.

The Browser Ghetto is effectively a subpar OS with it’s own incompatible user conventions. What is needed is a deep integration of mobile technologies into the OS of a phone, done in a way that works across multiple platforms. This is where my design communism comes into play. Both Apple and Google seem unlikely to consider this. Their fear is that doing so would cede much of their app market away, turning their handsets into commodities. A naive form of capitalism dictates that they keep control and not embrace any approach that gives away their lock in.

But this is shortsighted and ultimately counterproductive. The mobile web, by its very consensus-based approach, will always lag what a native app can do. Besides, why does it have to be a winner-take-all argument in the first place? Native and web apps actually complement each other. All I’m asking for is that the mobile web doesn’t have both hands tied behind its back. Many others have discussed what’s needed to improve HTML5 and JavaScript. These are critical ‘within the window’ technologies that are well in hand. But let me give you three examples that are more about integration with the mobile handset:

1. Basic Window parity
Mobile web pages live within a completely parallel universe of windows. If I have a web game open and want to switch to my contacts app, that is fairly trivial on any mobile phone. But if the reverse is true, it’s a completely different experience. First, there is no identity of my app anywhere; I have to switch to my ‘browser’ first. Why should I care what technology I’m using? Imagine if switching apps on a Mac made you choose “Cocoa” first (Cocoa is a basic mac technology). Once I’m in the browser, and if I’m *lucky*, the web app I want will be front most. Otherwise I have to open the browser’s menu to find the subset of browser windows that will get me to the web app I want.

What do I want instead? I want mobile apps to be first class citizens to native apps. If I leave a mobile web version of Angry Birds, when I switch back, I should see Angry Birds in my list of choices. I’m a bit shocked that I even have to argue for such a basic feature, or that others don’t see this as a profoundly ‘ghetto-izing’ aspect of living within the browser.

By the way, I understand that classic web browsing creates a slew of windows and I’m not asking that ALL of these windows ‘pollute’ my application switcher. But as soon as a web page wishes to be considered an app (most likely by using some combination of HTML5 technologies) it should graduate to a full-fledged application window.

2. Background processing
I worked on the GoogleTalk mobile web app while I was at Google. It was doomed from the start as it only worked when the app was front most. Again, there is a ray of hope here, in that web workersprovides a technical means to peel off background processing but it is hobbled by the fact that it only works when the browser is open. It is locked within the browser ghetto. Web Workers need to run even when the browser is closed, on par with any OS background process.

There are many good reasons why this hasn’t been done yet. There are some who even claim it is a security risk. While it might be true today, is giving a web app access to background processing *so* different from a native one? If so, what can we do to make sure they are the same? It’s hard for me to believe we can’t solve this so web apps can have the same background processing that native applications do.

3. Access to all sensors
This is a much trickier issue and one that, by the nature of technology, will always be changing as new sensors and capabilities will likely be added to mobile devices. Fortunately, there is a strong community in the mobile space working on this and this will eventually get addressed, albeit in stages.

The reason I include this point is political. This *will* be solved in the near future by the HTML5 community, but how quickly will the mobile handset companies support it? I’m actually taking aim at Google Android here as it has a fairly decent mobile browser but it’s horrifically slow at even catching up with where Apple was 2 years ago (e.g. hardware accelerated CSS3 transforms). Having a spec is one thing, but fully embracing it is entirely different. Slow adoption by handset manufacturers just prolongs the browser ghetto.

But will these changes ever happen?
The mobile web community is a crazy, amazing, determined bunch and they are fervently working on making the mobile web reach it’s potential. In many ways this community feels a bit like barbarians at the gate. What will hold this crowd back isn’t their energy but the foot dragging that we’ve already seen in this industry. The Browser Ghetto isn’t an accident, its more ‘abuse by neglect’ on the part of Apple and Google. They’ll get around to it, but only eventually.

Design communism is about pushing this conversation, making it clear that there can be alternatives. It’s not always about competition or lock in. A rising tide can indeed raise all boats. Can we push this discussion forward? Can we get web technologies built deeply into mobile handsets to create this common platform? This is where I feel capitalism can actually save the day, as some handset manufacturer will eventually turn this into a competitive advantage.