It’s a common scenario that I find myself in all-too often: a room of product planners and creative thinkers, marketing managers and technologists plotting out their mobile experience. Invariably there is a PC browser solution in place and now the discussion has turned to how to transfer it to mobile. Then someone asks the question: Native App or Mobile Web?
It’s common for everyone has an opinion on the subject, but surprisingly nobody gives the obvious answer: both. A smart strategy understands the differences between Native App and Mobile Web and works with the benefits and limitations of both environments.
The problem is, it’s not an either-or decision. In his recent blog, Brad Frost drew the comparison to the Print versus Web debate in the 90’s. It’s the perfect analogy to what we see now. The print world was doomed –surely within five years or less– spelling the end to traditional publishing. It didn’t happen of course, and while the predictions of the death of Print are still made the passion is gone. The world realized that both mediums matter, and as it turned out people like to consume their information in many different formats.
At the surface, there is one technology difference between Web Applications and Native Applications: on the whole, Web Apps are more dependent on the network than native applications. While Web Apps evangelists point out that developers can access local storage, very few do and it’s far from simple or dependable in the way Applications are. But getting past the technology, it is this philosophical difference that is core to the user experience.
Native Applications are often faster. But it’s not because the code is more efficient somehow, but because native applications are more likely to use local storage for graphics, or process client side. Calling to the network for files is a slower process, and you have the added factor of the network speed. But most Native Applications use the network as well, and without smart caching and local storage, there is no real benefit in terms of performance. Put another way, a poor architecture can make any native environment slow.
There are several Wikis, blogs and discussions around the current limitations of HTML5 compared to the native space. Quora and Google+ have several discussions on the topic, with developers providing helpful lists of how to navigate the mediums. Many catches involve the Camera, Storage, or deep-level UI customization. On the Android OS for example, HTML5 web apps cannot change the device’s wallpaper, replace the homescreen, replace an app, add ringtones or device files, access the local filesystem or the menu button. Messaging is another area that HTML5 struggles with; push and local notifications are not allowed, nor are customizations around the camera involving overlays or augmented reality. The Mobile Web doesn’t provide access to many device-level APIs, and while this is rumored to change someday, it’s hard to plan a product strategy around “someday”.
But frequently the HTML5 versus Native Application discussion often wanders in what feels like a religious debate rather than a technical one. Even though the discussion is one where facts are readily available, core to the controversy sits the frequent lament of technologists throughout the decades: “I want to believe”.
One of the biggest clichés in the industry is “write once, run everywhere”. It’s amusing to see this applied to HTML5 and Web Apps since it’s far from accurate, and it’s actually the exact same thing people said about Android prior to its launch. It’s a long-time dream of developers and a common boastful claim of technology companies. But it’s not a factual statement and will never be, or at least not in the next decade… not soon enough to matter. Devices and technology are moving too quickly, and device manufacturers are financially motivated to keep the world fragmented. The lure of HTML5’s “write once” story is an illusion, and too often it limits products to a lowest-common denominator approach that nobody enjoys.
But even getting around the technology issues, anyone with a creative background will tell you that “write once, run everywhere” falls apart the first time you take an Application or Web Page designed to the iPhone and put it on an Android device. It feels funny… just like a Mobile Web page embedded within a Native Application feels funny. Your users notice the difference, and it doesn’t feel right to them. In a world where device makers are desperate for differentiation, the UI becomes the most important part of the game.
The hybrid approach (a Native Application wrapper that uses HTML5 content embedded inside of it) is appealing, but has some of the same UI issues and really doesn’t fully address the problem. It’s a good approach for a small company wanting to do something quickly, but it’s not the solution to the problem. At least, not yet. Hybrid applications written poorly often feel like the worst of both worlds; all of the trappings of an application with the strangeness and speed of a browser. Hybrid applications are an answer, but they aren’t THE answer.
One of the biggest mistakes developers make when they use the Hybrid approach is that they are attempting to “trick” the user into thinking that their Web Application is a Native Application. There are even blogs and websites that aim to teach users how to do exactly this: build a Web App to look like a Native App. This is a colossal waste of time and extremely questionable strategy; bending over backwards to make one technology appear like another ignores and wastes the inherent values in both. Design the perfect mobile solution for your customers; don’t play games with technology.
While it might be tough to swallow, the simple answer is that some things are done better on the browser, and some things are done better natively. In the end, it all comes back to the same answer: design the right product for your customer. The technology decision should never be the starting place, but be the tools you use to execute your vision. Native Applications and Mobile Web Applications both have a bright future; making a brilliant product is up to you. You can’t ignore either while you wait for a future that may never come.
The future of mobile is much like the PC revolution in the 80’s and 90’s; a world where many types of products will exist and thrive, with the best ones using the technology options available to them to build amazing experiences. Amazon.com doesn’t need a desktop application any more than Adobe Photoshop is a web service. There are excellent online games, and desktop executable games.
To that room of product planners and creative thinkers trying to make the next great product? Build to the advantages of mobile, Native and Web, and your customers will be delighted. Your product and the experience of your users is what matters, not the technology.
Like this:
Like Loading...
Making the best products: Native App versus Mobile Web
It’s a common scenario that I find myself in all-too often: a room of product planners and creative thinkers, marketing managers and technologists plotting out their mobile experience. Invariably there is a PC browser solution in place and now the discussion has turned to how to transfer it to mobile. Then someone asks the question: Native App or Mobile Web?
It’s common for everyone has an opinion on the subject, but surprisingly nobody gives the obvious answer: both. A smart strategy understands the differences between Native App and Mobile Web and works with the benefits and limitations of both environments.
The problem is, it’s not an either-or decision. In his recent blog, Brad Frost drew the comparison to the Print versus Web debate in the 90’s. It’s the perfect analogy to what we see now. The print world was doomed –surely within five years or less– spelling the end to traditional publishing. It didn’t happen of course, and while the predictions of the death of Print are still made the passion is gone. The world realized that both mediums matter, and as it turned out people like to consume their information in many different formats.
At the surface, there is one technology difference between Web Applications and Native Applications: on the whole, Web Apps are more dependent on the network than native applications. While Web Apps evangelists point out that developers can access local storage, very few do and it’s far from simple or dependable in the way Applications are. But getting past the technology, it is this philosophical difference that is core to the user experience.
Native Applications are often faster. But it’s not because the code is more efficient somehow, but because native applications are more likely to use local storage for graphics, or process client side. Calling to the network for files is a slower process, and you have the added factor of the network speed. But most Native Applications use the network as well, and without smart caching and local storage, there is no real benefit in terms of performance. Put another way, a poor architecture can make any native environment slow.
There are several Wikis, blogs and discussions around the current limitations of HTML5 compared to the native space. Quora and Google+ have several discussions on the topic, with developers providing helpful lists of how to navigate the mediums. Many catches involve the Camera, Storage, or deep-level UI customization. On the Android OS for example, HTML5 web apps cannot change the device’s wallpaper, replace the homescreen, replace an app, add ringtones or device files, access the local filesystem or the menu button. Messaging is another area that HTML5 struggles with; push and local notifications are not allowed, nor are customizations around the camera involving overlays or augmented reality. The Mobile Web doesn’t provide access to many device-level APIs, and while this is rumored to change someday, it’s hard to plan a product strategy around “someday”.
But frequently the HTML5 versus Native Application discussion often wanders in what feels like a religious debate rather than a technical one. Even though the discussion is one where facts are readily available, core to the controversy sits the frequent lament of technologists throughout the decades: “I want to believe”.
One of the biggest clichés in the industry is “write once, run everywhere”. It’s amusing to see this applied to HTML5 and Web Apps since it’s far from accurate, and it’s actually the exact same thing people said about Android prior to its launch. It’s a long-time dream of developers and a common boastful claim of technology companies. But it’s not a factual statement and will never be, or at least not in the next decade… not soon enough to matter. Devices and technology are moving too quickly, and device manufacturers are financially motivated to keep the world fragmented. The lure of HTML5’s “write once” story is an illusion, and too often it limits products to a lowest-common denominator approach that nobody enjoys.
But even getting around the technology issues, anyone with a creative background will tell you that “write once, run everywhere” falls apart the first time you take an Application or Web Page designed to the iPhone and put it on an Android device. It feels funny… just like a Mobile Web page embedded within a Native Application feels funny. Your users notice the difference, and it doesn’t feel right to them. In a world where device makers are desperate for differentiation, the UI becomes the most important part of the game.
The hybrid approach (a Native Application wrapper that uses HTML5 content embedded inside of it) is appealing, but has some of the same UI issues and really doesn’t fully address the problem. It’s a good approach for a small company wanting to do something quickly, but it’s not the solution to the problem. At least, not yet. Hybrid applications written poorly often feel like the worst of both worlds; all of the trappings of an application with the strangeness and speed of a browser. Hybrid applications are an answer, but they aren’t THE answer.
One of the biggest mistakes developers make when they use the Hybrid approach is that they are attempting to “trick” the user into thinking that their Web Application is a Native Application. There are even blogs and websites that aim to teach users how to do exactly this: build a Web App to look like a Native App. This is a colossal waste of time and extremely questionable strategy; bending over backwards to make one technology appear like another ignores and wastes the inherent values in both. Design the perfect mobile solution for your customers; don’t play games with technology.
While it might be tough to swallow, the simple answer is that some things are done better on the browser, and some things are done better natively. In the end, it all comes back to the same answer: design the right product for your customer. The technology decision should never be the starting place, but be the tools you use to execute your vision. Native Applications and Mobile Web Applications both have a bright future; making a brilliant product is up to you. You can’t ignore either while you wait for a future that may never come.
The future of mobile is much like the PC revolution in the 80’s and 90’s; a world where many types of products will exist and thrive, with the best ones using the technology options available to them to build amazing experiences. Amazon.com doesn’t need a desktop application any more than Adobe Photoshop is a web service. There are excellent online games, and desktop executable games.
To that room of product planners and creative thinkers trying to make the next great product? Build to the advantages of mobile, Native and Web, and your customers will be delighted. Your product and the experience of your users is what matters, not the technology.
Like this:
Related Posts
The increasingly important need to win
What will it take to move mindshare to Android?
Google releases “find my phone” feature
Xbox One revealed, Sony’s stock rises
About The Author
Travis
He has a twenty plus career in product creation, which includes writing and describing an endless series of bad decisions.