“Our job is not to reinvent the world; it’s to take stuff that we know exists already — but hardly anyone’s got it — and get it out to them.”
-Steve Jobs, 1997 [link]
It’s all about managing complexity
When I was working on a natural language processing system at Johns Hopkins during the summer of 2005, I remember having a minor epiphany: I realized that the strategy our research team was using was essentially just a way of converting an intractably complex problem into a series of computable smaller problems. It didn’t take me long to make the jump to realizing that this is an essential part of all science and engineering.
I was reminded of this when watching a Steve Jobs video recording from 1997 (via daringfireball). Steve is talking about why he thinks better developer tools and APIs are so important to progress (around 25 minutes into the video):
It’s all about managing complexity. It’s like scaffolding, right? You erect some scaffolding and if you keep going up and up and up, eventually the scaffolding collapses of its own weight. That’s what building software is. It’s how much scaffolding you can erect before the whole thing collapses of its own weight. It doesn’t matter how many people you have working on it — doesn’t matter if you’re Microsoft, with 500 people on a team — it will collapse under its own weight.… These [new developer tools] allow you to not have to worry about 90% of the stuff you worry about, so that you can erect your 5 stories of scaffolding, but starting at story number 23 instead of starting at story number 6. You can get a lot higher.
This is related to the fundamental notion of abstraction, and to “the mythical man-month” (which Steve also references). It’s a good reminder.
In a related section, Steve responds to a question asking about how visual programming tools might fit into this. His answer (around 42 minutes in):
Here’s the deal. The way you get programmer productivity is not by increasing the lines of code per programmer per day. That doesn’t work. The way you get programmer productivity is by eliminating lines of code you have to write. The line of code that’s fastest to write, that never breaks, that doesn’t need maintenance, is the line you never had to write! So the goal here is to eliminate 80% of the code that you have to write for your app. That’s the goal. So along the way, if we can provide vizi-this and vizi-that and visual this and visual that, well that’s fine, but the high-order bit is to eliminate 80% of the code. When you ‘draw the line’ in interface builder, you’re eliminating code of one form. But that only goes so far. Maybe we can go further. I’ve seen a lot of demos of things that try to take it all the way back into the algorithmic part of the codebase, and none of them have ever been any good. If there are any good ones out there, show them to me — I’d love to see them.
In other words, abstraction is far more important to productivity than whether a language is visual or textual. Making languages visual is only a win if it can help solve the “higher order” issues: bugs, maintenance, and complexity. Steve’s 1997 claim is that he has not seen compelling demos of this in the visual programming space.
I think this is crucially important to keep in mind when thinking about visual programming languages that could be generally adopted. They have to provide an advantage in terms of abstraction. It seems that so far the opposite has been true: abstraction has been the main weakness of visual programming systems.
The cloud is part of the app
With so many people now watching for Apple information leaks and rumors, their big announcements rarely contain big surprises anymore. However, there is usually a twist or two that no one foresaw, because few are as good as Apple at radically simplifying their products and services.
For me, the twist today was that the cloud is not some separate thing that you have to manage and think about. Instead, it is simply a feature of an app.
Because existing cloud providers offer third-party services that are sold separately, these providers have no choice but to emphasize the cloud as a separate thing. For example, Dropbox—probably the most elegant user experience out there—gives you a special folder on your file system that you can drag files into to tell Dropbox to sync them with the cloud. All files that live in that folder are automatically synced. Because of this, Steve Jobs told us, “Some people think the cloud is just a hard disk in the sky.”
Alternatively, some cloud services are integrated with web applications. For example, Google Docs stores your documents in the cloud and lets you view and edit them using a web browser. (Indeed, Google’s general goal seems to be to move all computing into the web browser, so not just your data but also the apps themselves live in the cloud. I’ve written previously about why I think that is shortsighted.)
Apple’s new “iCloud” offering brings to native apps the cloud integration that we’ve previously only seen with web applications. Moreover, it does this so seamlessly that the user is not really supposed to think about it at all. At Omni we spent a long time wondering how Apple was going to solve the problem of document sync in their iWork apps on the iPad. Then, last week, they shipped updates to those apps with no sign of cloud sync. What we didn’t realize was: that conspicuous absence was the whole point. The synchronization happens automatically, invisibly. There is no need for any user interface at all. Any file updated on one device is updated on all devices within seconds.
To make iCloud even more invisible, it’s free. There need be no user interface associated with paying. There need be no decisions about value and purchasing. You log in once when setting up the device, and that’s it. From then on, your various devices simply feel more like different views onto a single device. The automatic syncing makes it easier to operate the devices, not more complicated. You can spend less time managing the device and more time thinking about your content, your work, your friends.
There are bound to be remaining issues with sync conflicts, offline access, data plan limits, etc. But fast internet access is becoming widespread enough that this seamlessness does not seem out of the question.
The cloud is part of the app. The app is part of the cloud. If an app is cloud-enabled, that just means all devices automatically stay up to date.
People don’t buy what you do, they buy why you do it
Apple just released their first iPad 2 commercial, called “We Believe”:
This is what we believe. Technology alone is not enough. Faster, thinner, lighter…those are all good things. But when technology gets out of the way, everything becomes more delightful…even magical. That’s when you leap forward. That’s when you end up with something like this.
It reminded me of the TED talk by Simon Sinek, “How great leaders inspire action.” Simon’s message, which he repeats constantly, is: “People don’t buy what you do, they buy why you do it.” He cites Apple as a master at this. None of Apple’s marketing dives into product specs. They say, “this is what we believe.” From the beginning, they believed in “thinking different.” Whenever they introduce new iPods, they bring a guest star musician onstage to play music. Steve Jobs introduces them by saying, “This is a reminder of why we make iPods: because we love music.” The new iPad ad is another textbook example.
Some great quotes from Simon’s talk:
What’s your purpose? What’s your cause? What’s your belief? Why does your organization exist? … Inspired leaders — and inspired organizations — all act and think from the inside out: why —> how —> what.
…
The goal is not to do business with people who need what you have; the goal is to do business with people who believe what you believe.
…
What you do simply proves what you believe.
…
MLK gave the “I have a dream” speech, not the “I have a plan” speech.
…
We follow those who lead not because we have to, but because we want to. We follow those who lead not for them, but for ourselves.
Technology alone is not enough
Steve Jobs, concluding the March 2, 2011 iPad 2 media event:
I’ve said this before, and I thought it was worth repeating. It’s in Apple’s DNA that technology alone is not enough. That it’s technology married with liberal arts — married with the humanities — that yields us a result that makes our hearts sing.
And nowhere is that more true than in these post-PC devices. A lot of folks in this tablet market are rushing in, and they’re looking at this as the next PC. The hardware and the software are done by different companies, and they’re talking about speeds and feeds, just like they did with PCs. Our experience, and every bone in our body, says that that is not the right approach to this; that these are post-PC devices that need to be even easier to use than a PC; that need to be even more intuitive than a PC; and where the software and the hardware and the applications need to intertwine in an even more seamless way than they do on a PC.
And we think we’re on the right track with this. We think we have the right architecture — not just in silicon, but in the organization — to build these kinds of products. And so I think we stand a pretty good chance of being pretty competitive in this market, and I hope that what you’ve seen today gives you a good feel for that.
Words for the wise.
iPad 2 will cost $399
I decided I would make some predictions about the upcoming iPad 2, since it’s hard to remember in retrospect what I (and the rumors) got right. Predicted iPad 2 specs:
- Updated design that is slightly thinner and slightly lighter.
- Same screen dimensions and resolution, but display is slightly brighter and fused to the front glass.
- Slightly longer battery life.
- Low resolution front-facing camera for video chat.
- Low resolution rear-facing camera for augmented reality applications.
- Dual-core A4 processor (“A5”?) clocked at about 1 GHz.
- 512 Mb of memory.
- SSD storage options of 16, 64, and 128 Gb.
- Ships with iOS 4.4 (iOS 5 waiting until iPhone 5).
- Supports to-be-announced iMovie for iPad ($9.99).
But I’m also going to go out on a limb and predict that Apple will cut the entry-level price of iPad 2 to $399.
Why is this possible?
From a component perspective, the iPad really is essentially a big iPod Touch. iPod Touches currently cost $299 for 32GB of storage. I can find component estimates for the latest iPhone 4 and the original iPad. The main differences are (iPhone vs. iPad):
- display ($38 vs. $95)
- case ($20 vs. $35)
- battery ($6 vs. $18)
The most expensive part by far in the original iPad was the touchscreen display, estimated last April to cost $95. This cost was largely due to the 9.7-inch capacitive touch sensor having only entered mass production just for the iPad. A year later, with tens of millions of these larger touch sensors manufactured, the cost has presumably come down dramatically, even when offset by new technology that fuses the display to the front glass panel. Let’s estimate that the touchscreen part now costs roughly $65 ($27 more than the iPhone retina display).
Assuming the other component prices are comparable to the iPod Touch (which seems reasonable to me, since they are essentially the same chips), the total price differential is just $48. So even with a large margin of error, it seems that Apple can afford to price the iPad at a retail price premium of just $100.
Steve Jobs has repeatedly said that Apple wants to price the iPad very competitively. The product’s tagline is still: “A magical and revolutionary product at an unbelievable price.” If they can afford to cut the price further, I think they will.
There is also some recent believable speculation that Apple will release another line of iPads in September. This will likely be a premium line with a higher entry price point (perhaps $599) that includes a retina display and correspondingly upgraded processor, graphics chips and memory. In other words, selling a cheaper iPad does not limit Apple’s ability to sell expensive iPads in the future, just as selling cheaper iPods and Macs has not limited Apple’s ability to sell more expensive lines of iPods and Macs.
Apple’s primary advantage in the tablet market is software, not hardware. By carefully optimizing iOS software for the specific chips built into iOS devices and by nurturing their platform of media, apps, and services, Apple has managed to squeeze an incredible amount of customer value out of relatively cheap and underpowered hardware (made even less expensive by Apple’s strategic use of cash reserves). I believe we have only scratched the surface of what is possible on the software side, even when relying on just the basic hardware of the original entry-level iPad.
Apple has stated that they do not currently know how to make a quality laptop for less than $999, but if they did, they would. It looks like they do know how to make a quality iPad for $399, and if they can, they will. The iPad does not need better hardware specs to be high-quality. Unless Apple has dreamed up truly amazing new functionality (which they occasionally do), I think consumers will prefer a lower price for an already high-quality product. A $399 iPad will really be hard for competitors to beat.
Update: Most of my co-workers think Apple will release a new iPad at $499 and lower the price of the original iPad to $399, as they have been doing with iPhones and have done in the past with some Macs. They don’t think there is much incentive for Apple to cut prices on the latest, greatest iPad. I wouldn’t be surprised if my co-workers are right. However, I still think my scenario above is not out of the question.
Update 2: My co-workers got it mostly right; the iPad 2 was launched with the same prices as the original. Original iPads are available starting at $399, but only while supplies last.
Just a big iPod Touch
The funny thing about the critics who derided the iPad as “just a big iPod Touch” is that they were exactly right. They just came to the wrong conclusion. The amazing thing about the iPad is that it has the same simple and intuitive touch-optimized functionality as the iPod Touch. But it’s bigger, so it’s that much more useful and that much more fun.
This was pretty clear to us at Omni from the beginning, since we had never been very satisfied with most (conceptual) versions of our apps that fit on an iPhone-sized display. By contrast, we loved our iPad-sized translations almost immediately.
Apps are the next medium
In recent months, App Store “apps” have continued to explode in popularity. iOS apps are currently being downloaded at twice the rate of digital music tracks from the iTunes store, with the average iOS user downloading five new apps per month. App developers have received $2 billion in revenue over the first 31 months (and that does not include ad revenue).
Horace Dediu recently made the important point that not only are apps here to stay, they are the next important medium. Apple designed iOS such that apps take over the whole device, each one “magically” transforming it into an object with a whole new set of capabilities. The device becomes a map or a compass or a video camera or a textbook or a game or a credit card or a newspaper or a radio or any new combination thereof. This new medium can be used for both art and productivity; charity and industry; form and function. It is not a fad. It is rather the logical next step for human-facing software.
Like music and movies, apps can be bought and sold as if they’re objects. The iTunes store already sells more music than any other physical or online retailer. The App Store is poised to become the de facto provider of consumer device functionality.
As this medium gains traction and more artisans learn how to create apps, I think we will find that we’ve only just scratched the surface of what is possible.
Compiled Software is Here to Stay
I sometimes hear claims that the web browser and web apps will replace traditional operating systems (like Mac OS X) and compiled native applications (such as iPhone apps). In particular, Google is developing a new operating system based solely on their Chrome web browser; and Palm/HP smartphones similarly use an operating system based on web technologies.
But while these web technologies are great and useful for many things, compiled software is here to stay. This is because the most innovative applications often require the most processing power and the latest features of a platform — attributes that can only be achieved with compiled software. Meanwhile, the networking technologies used primarily by web applications today can also be utilized by compiled software. Because of this, the most innovative user experiences are usually going to be compiled. And I think that’s bad news for web-only operating systems.
A little background
When I say “compiled software,” I’m talking about any application that is technically compiled and optimized for a particular hardware system. This includes most desktop Mac and Windows applications, native iPhone apps that you get from Apple’s App Store, and anything else that is written for a particular processor chip/operating system combination.
The alternative is called “interpreted” software. Examples include standard web pages (HTML, CSS), fancier web applications (JavaScript, Flash, etc.), Java applications (both web applets and desktop versions), and programs written in newer languages such as Python and Ruby.
Whereas compiled software translates programmer code into computer instructions at the outset before you even download the application, interpreted software translates into computer instructions in real time as you use the application.
The advantage of the interpreted approach is that it’s easier to run on many different devices. Since the translation to computer instructions happens at the last minute, you can write a program once and then run it on any processor / operating system that knows how to do the translation. (A web browser is one such “translator.”) In some cases, it can also be easier to write interpreted software.
The compiled approach, on the other hand, has significantly better performance. Converting to machine instructions requires processor time and uses up battery power. When you do all this work before you even ship the software, the app runs faster and drains less battery. It’s even better if the software is specifically optimized for the device (for example, taking advantage of special graphics chips).
“Fast enough”?
I did some performance tests six months ago and found that web applications run about three to 50 times slower than native compiled applications, depending on the task. Although incredible strides have been taken to narrow this performance gap, the gap is fundamentally here to stay — the tradeoffs between interpreted and compiled software are simple facts of computer science.
But, the argument goes, today’s or tomorrow’s powerful computers are “fast enough” to support many useful web applications despite the performance gap. And at face value, this is perfectly obvious. We had spreadsheets 20 years ago on machines that were literally a thousand times slower. You would certainly hope that we could replicate that functionality with web apps today.
And at any given point in time, it’s hard for us to imagine what we could possibly do with even more powerful computers. (Bill Gates famously once said, “64K should be enough for anyone.”) One of the easiest things to imagine doing is taking advantage of the new speed to allow web applications to run faster. The thinking goes as follows: “the performance gap is only 3-50x. So in [2, 5, 10] years, when computers are [3, 50, hundreds] of times more powerful, web apps will perform just fine, and take over from desktop apps.”
But history has shown that we have always been able to take advantage of more processing power to accomplish tasks that were previously impossible, if not unimaginable. For example, Apple famously transitioned the personal computer from a word-processing and personal-finance machine into a “digital hub” for your music, photos, and videos (all of which require substantial processing power to manage). Only now, almost a decade later, do web apps have the necessary horsepower to manage our digital media. And Apple is now in the process of bringing these higher-horsepower tasks to mobile devices.
Ongoing research in computer science makes it clear that this historical trend will continue. For example, “machine learning” algorithms for applications such as games, speech recognition, augmented reality, and many others all perform increasingly better as they are allowed to use more and more processing cycles.
The most innovative emerging applications will tend to be the ones that can make use of the most processing power now. For these applications, there is no such thing as “fast enough.”
“Write once, run anywhere”?
Cross platform frameworks come with the promise of letting you develop a single application that can be run on any supported platform. You write one code base, and the framework does the hard work of making your app work everywhere.
The problem with this claim is that each platform is different. If the differences were merely cosmetic, it wouldn’t be a big deal — make them look like Mac buttons on the Mac, Windows buttons on Windows. But new devices like the touchscreen iPhone and iPad make it clear how limited the whole notion of cross-platform compatibility is. User interfaces designed for mouse and keyboard simply don’t work well on a touchscreen. Interfaces designed for large screens don’t work well on small screens. Even with very similar platforms (e.g. Mac and Windows), there are subtly different UI paradigms that cross-platform frameworks usually fail to respect.
Each platform also has a unique set of available features, which limits the possibilities for cross platform frameworks. As Steve Jobs put it,
The [cross platform framework] may not adopt enhancements from one platform unless they are available on all of their supported platforms. Hence developers only have access to the lowest common denominator set of features. We cannot accept an outcome where developers are blocked from using our innovations and enhancements because they are not available on our competitor’s platforms.
Apple later relented, allowing apps to be built using cross-platform frameworks. But Jobs’ drawbacks still apply. Apps that use these frameworks are constrained to yesterday’s feature set.
Web applications face these same constraints. In theory, they can run on any web browser, whether it’s Mac, Windows, Linux; Safari, Internet Explorer, Firefox; laptop, tablet, or smartphone. But in practice, web apps have to be adapted to truly meet the needs of each platform (for example, Gmail and many other sites have smartphone- and iPad-specific versions).
For billions of websites, the least common denominator set of features is plenty. But if you want to write innovative software (as distinguished from innovative content), chances are that the features you need will not be readily available on all of the relevant platforms. For these important applications, “write once, run anywhere” is a myth.
“Cloud computing”
The user experience of installing and running software has traditionally been much better on the web than on desktop operating systems. Consider: from any internet-connected device in the world, one need only type “facebook.com” to access a powerful, extensive social networking application. There is no need to start a download, find it, decompress it, install it, and run it. Web applications are discoverable and viral since they can be shared with a simple URL.
But there is no reason in principle why compiled apps can not also be delivered in this way. Apple has demonstrated this with its App Store’s integrated download process. They could go even farther by letting developers split up their applications into discreet chunks that only get downloaded when necessary. The downsides of this browsing experience would be exactly the same downsides as on the web: the intermediary downloads can be slow, the internet connection can be broken, etc.
Web applications are also touted for their ability to push out updates immediately without the user needing to do anything. But this can (and should) be applied to native apps too; in fact, Google has finely honed the upgrade process for its Chrome web browser so that patches are securely downloaded and installed without the user even noticing.
There is no reason that compiled software cannot take advantage of all the “cloud” features that the Internet enables. Compare Google Docs, the productivity web apps, with Microsoft Office, the dominant compiled version. As I see it, the advantages of Google Docs currently are:
- Easy to access from any computer
- Easy to collaborate in real time and share documents with others
- Free (supported by advertising)
The interesting thing about this list is that these advantages once again do not depend on the web browser platform. Indeed, many of the most important iPad and iPhone apps are native clients to back-end web services (e.g. Twitter, Instapaper, Flipbook, NPR, etc). Not only do these apps make it easy to collaborate and share and view advertisements, they also take advantage of being compiled to provide innovative, responsive, battery-conserving user interfaces.
Conclusion
Ben Ward wrote, “If you want to build the most amazing user interface, you will need to use native platforms. A single vendor’s benevolent curation of their framework will always outpace the collaborative, interoperable developments of the web…. But the web will always be the canonical source of information and relationships.”
What will be the fate of platforms based around interpreted-only software? It already seems pretty clear that WebOS smartphones are not going to survive. The performance tradeoffs are too dramatic on tiny, power-hungry mobile phones. I suspect Chrome OS will fare at least a little better, because web apps on cheap laptops can now do most of what mainstream users need, with a user experience that’s not terrible.
Chrome OS targets essentially the same market as the iPad — people who have only light computing needs or who want a secondary, more portable computer. Apple has shown that it’s a viable market. And for now, most web apps have been designed for a mouse and keyboard (rather than touch). Chrome OS’ dearth of viruses, fast startup, and assumed price point below Apple puts it in a decent position.
But Chrome OS will never come close to replacing systems that are based on compiled software. Even if most of your computer time is spent in a web browser, why sacrifice the native applications that can do more with the same hardware? Games that are more responsive and more realistic; photo managers that are more powerful and flexible; office apps that use less battery; social media clients that are optimized for your screen size? Those native applications already exist on iPad, alongside an excellent web browser.
Today you can edit HD video on an iPhone via a native app; it will be years before the same experience is possible with web apps. And the cycle will continue — the video editing of today is the real-time artificial intelligence of tomorrow. Anyone who wants to be near the cutting edge will choose the products that have the new and exciting features.
I appreciate the simplicity of reducing everything to a web browser. But the iPad demonstrates how much more you can do with tightly integrated, compiled software running on relatively cheap and battery-constrained processors. Expect more web-like features to make their way to future iPad software, such as automatic upgrades and data synchronization. Expect web apps to remain important for lowest common denominator tasks. And rest assured that compiled software is here to stay.
—
Many of the ideas in this article are based on links and analysis I read on Daring Fireball and asymco over the past six months.
Update: Technology Review magazine published an essay by the CTO of the Opera web browser which follows the line of reasoning that web technologies will be “fast enough” in the future to overshadow native apps. I wrote a letter to the editor. (Update: they published part of the letter in the magazine!)
One of the things I like most about the articles in Technology Review is that they consider technology within the real-world context of business and politics. The authors rarely get lost in technological hype that ignores practical obstacles.
I thought Håkon Wium Lie’s notebook contribution “Web Wins” (TR March/April 2011) was an unfortunate exception to this norm. He concludes that “native apps will become a footnote in the history of computing.” Even allowing some room for hyperbole, this statement is foolish. Native applications have been the norm for decades on personal computers; similarly, native software has dominated the history of mobile devices since the earliest cell phones and PDAs. Even if the majority of apps do become web-based in the future, calling this long history a “footnote” borders on the absurd.
Worse, however, is that Lie’s argument is a purely technological one. He argues that new web technologies “handle many computing-intensive tasks” that now allow web applications to approach the performance of existing native apps. But any student of disruptive innovation theory can tell you that technological innovations tend to start out in proprietary systems where the full software and hardware stack can be tuned to meet the needs of the new application. Web standardization will always lag behind these path breakers. By the time today’s new web technologies become standard, the next wave of native applications will have emerged in areas such as augumented reality and machine learning, and it will take another few years for web technology to catch up.
There is plenty of room for debate about the extent to which important software will be ported to the web. But it would be delusional to believe that native apps will go away altogether.
Update 2: John Gruber points out:
We should perhaps use “web app” to mean any app that is built around HTTP communication, and “browser app” to mean a kind of web app written in HTML/CSS/JavaScript which runs in a web browser. Things like iOS and Android Twitter clients are web apps, in my mind, they’re just written using platform-native toolkits.
“Browser app” seems like a reasonable choice of terminology to me.
Update 3: Matt Gemmell wrote an interesting article comparing native apps and browser apps from the perspective of frames of interaction — how many windows you have to “reach through” to get at the app itself. He argues that the cognitive cost of this nesting negatively impacts the user experience for browser apps.
Update 4: (Oct, 2011) Apple has released a suite of “iCloud” services whose primary goal is to bring web-like data synchronization to native apps.
Still Magical
As part of testing our upcoming iOS 4.2 release of OmniGraphSketcher for iPad, I just threw together this graph — a more or less exact replica of a textbook economics diagram. All on the iPad, without any fuss.
I could email the PDF directly to a textbook publisher.
Despite the fact that I’ve been working on this app ever since the iPad was announced, the whole thing still kind of boggles my mind. Even though I know in detail how the app works, Apple’s term “magical” is the best way I know of to describe the experience of using it.