I participated in a very interesting panel discussion at Frontendconf.ch on Saturday with Robert Nyman, Bastian Allgeier, Markus Leutwyler, and Vitaly Friedman.
(Photo taken by Nadine Fischer.)
We talked about the pros and cons of using native or web technologies to develop mobile applications, as well as why it's disappointing to imitate native UI and the "write once, run everywhere" lie. I think the time is ripe for me to write down what I think about UI design for mobile applications. I want to point out that my opinion on this topic has not only been shaped by my own experience, but without doubt also by other great developers and designers that I have talked to or that have written about this topic, most notably Majd Taby.
Part 1: Are we learn resistant?
Do you remember Java Swing? Swing is the primary Java GUI widget toolkit. It enables you to write your app and its UI once and then run it on every platform that runs Java! Isn't that amazing? Quick! Call everyone you know and tell them about it! This will change everything! Oh no, wait. Swing has been around since roughly 1996. And it hasn't really changed anything. Do you know a single app that is using Swing? Or better yet: Do you enjoy using any Swing app? The answer to both questions is most likely No. Why is that? Isn't it a great idea to develop an app and its UI once and then run it on every platform? No, it isn't. Here's why: Cross-platform UIs suck. Cross-platform UI means that it looks and feels terrible on every platform.
People choose a platform for a reason (at least sometimes): They prefer the UX of one platform to the UX of another; they don't want everything to be the same, they like that their platform is different (sometimes unknowingly). They get used to how things look and feel and they shun applications that feel odd and alien, even out of place. If you want to create a truly great user experience on multiple platforms, you have to really know those platforms. The cross-platform UI problem can't simply be solved by making the buttons and windows look like native apps on the platform. There is more to it than style and color: Different platforms offer different UI concepts and elements (for example sheets and drawers on Mac OS X), but also things like the locations of "OK" and "Cancel" buttons are different on different platforms. Keyboard shotcuts are different. Menu layouts are different. Help systems are different. There simply is no such thing as a "one size fits all" UI.
On the desktop, this truth is pretty much established and accepted (and has been for quite a while). On mobile, however, this whole discussion has come up again and again and is still going on. Are we learn resistant? Cross-platform UI is a bad idea on the desktop. Cross-platform UI also is a bad idea on mobile. Period. Just because mobile is hot stuff (and will be for the foreseeable future) doesn't make cross-platform UIs a good idea again all of a sudden. We need to learn from the past. Cross-platform UI is a conceptual mistake. It can't be fixed by better technology.
There is, however, one big exception to that rule: The web. (Actually, there's another one: games. But we won't focus on those now.)
Part 2: The one exception: The web.
Surprisingly, cross-platform UI works on the web. People are used to it. People don't think it's odd that GMail doesn't look like Outlook or Mail.app. They don't complain that the buttons on Twitter look different from the button of the other apps they use. They are able to use Google+ and Facebook although the UI looks "foreign" in comparison to other apps on their platform. Strangely enough, all those things that make cross-platform UI a bad idea seem to be absolutely OK on the web. Why is that? It has to do with expectation. When users open their web browser, they know that they are entering a very diverse space: All web pages look different. That's OK. People are OK with that. They even like it. It's like entering a bookstore: You know and you expect that it will be full of books and magazines with different sizes, different layouts, different content structures, different colors and different content. You are not surprised by that at all. You would be unpleasantly surprised, however, if that next volume of an encyclopedia you're collecting (yes, that's far-fetched) would look totally different from the other volumes. Maybe they just used different, thinner paper. Or it's paper-back and not leather-bound. Or one issue of a magazine you're collecting would have a completely different shape, different style and different layout with the editorial in the back and the table of contents in the middle. That would be an unexpected unpleasant surprise: Just like apps with a foreign, cross-platform UI that run alongside your normal native apps. They don't fit in your collection. In the bookstore - the browser - that is OK, though. Users expect it.
So as a developer we are in a great space on the web: We have complete freedom to come up with one great UI (not multiple ones for every platform), it runs on every platform and we get away with it. However, we can ruin that great space for ourselves. How? By mimicking native UI in our web applications. When our web app looks exactly like a Mac or a Windows app, people will expect it to behave exactly like such a native app. The problem is that it won't. The mimicking can come quite close to the real thing, but it will never be exactly as good. It is and always will be an imitation. But users don't care how something is implemented: If it looks like my other apps, it should behave like my other apps. By making a web app look like a native app, we make the user forget that he's "in the bookstore" where everything is different. We take our own freedom to do what we want in terms of UI away from us if me imitate a native app. Worse yet, it will only look native-ish on one platform and will once again look foreign on all the other platforms.
So what should we do? "Build a UI and UX that is platform-agnostic." (Building the Next Generation of Mobile Web Applications by Majd Taby). Don't imitate native. You will only disappoint because you won't be able to fully satisfy the expectations users have of an app that looks native. Instead, pleasantly surprise your users by not looking native, but offering features, animations, and conveniences that they would not have expected of a web application.
So now what about mobile?
Part 3: What about mobile?
On mobile devices the same rules apply. Maybe even more so: The UI and UX patterns differ even more between mobile platforms than they do between desktop platforms. And on mobile people like the differences between platforms even more, too: They sometimes militantly defend Android against iOS or vice-versa. They don't want every platform to be the same. They want the apps on "their" platform to be different from apps on other platforms. They want their iPhone apps to be iPhone-y (no pun intended) or their Android apps to be Android-ish. So once again: The same rules apply: An app that has an icon on the home screen is perceived by the user as "an app", no matter if it actually launches the browser without the toolbar, if it is a web app wrapped in a PhoneGap shell of if it is a native app. To the user, it's an app. It has an icon, so it's an app. The rest are implementation details that the user doesn't (and shouldn't) care about. So if the user perceives it to be a native app like all the other apps, it has to behave like one. Otherwise the user will be disappointed. You hold your device in landscape mode and the toolbars aren't visible anymore or the UI gets messed up or there's no animation when you move from portrait to landscape? Disappointment. The thing that looks-like-a-table-view-but-really-isn't is jerky when you scroll it? Disappointment. The swipe gesture that should advance to the next page doesn't move the content underneath your finger but only triggers a page-move animation once you're completely done with the swipe and you have lifted your finger off the screen again? Disappointment. The element you are dragging around on the screen with your finger always lags behind and jerkily jumps to where your finger is every half a second instead of buttery smoothly following its movement? Disappointment. You're breaking the illusion with stuff like that. Touch devices blur the lines between the user and the content. They give the user the feeling that they can actually touch the objects on the screen and directly manipulate them. Don't break that illusion.
Imitating native UI with web technologies on a mobile device will only disappoint. It's just not on par with the native experience (yet). But fear not: You can still build great mobile applications with web technologies: Just don't fake native. The web has its own thing going. And once the user opens the browser or, as it were, "enters the bookstore," you have full creative freedom of coming up with a great, unique UI for your app. You will pleasantly surprise your users instead of disappointing them. For example, you could implement pinch & zoom in your mobile web app to let users zoom into an image: They'll be amazed because they wouldn't have expected that to work in a web app. If you fake native UI, however, they would take it for granted because it works in every other app and they would be disappointed if it's possibly not as smooth as in a native app. You can only lose if you try to fake native UI.
So, just like on the desktop, you can only get away with cross-platform UI in the browser and only if you don't try to make it look like a native app. So the big question remains: Should I use native or web technologies for my app?
Part 4: So... native or web?
The answer is: It depends. The first question you have to ask yourself is "What do I want to achieve with this mobile app?" If the answer is "I just HAVE to be in the App Store!", you're doing it wrong and you probably shouldn't make an app at all. If you have a restaurant and just want to display your menu and opening times, you don't need an app. People would hate it. People expect apps to either be useful, beautiful and stunning and/or entertaining. If it's neither of the above, don't even bother thinking about making one. No one would download it. You'd be much better off making a beautiful mobile website and maybe put some money into SEO instead of wasting your money on an app. Being "in the App Store" is no golden magic ticket to success: You can't just put anything in there. The days were people are amazed simply by the fact that you have an app in the store are long over. If, on the other hand, you hire an expert that makes your restaurant app a work of art, which gives the user a visually stunning experience, something that's fun to use and that they want to show off to their friends: Go ahead, make an app. But if you do make an app, make one that you would want to use. Otherwise, don't even bother.
But what if you have a great idea for an app and you want it to run on multiple mobile platforms? Once again, the same rules apply: If you want to put it in the App Store(s), users will expect it to be on par with native apps in terms of speed, UI and UX. Frankly, the easiest way to be on par with native apps is to be a native app: If it's in the App Store, people will apply the same quality criteria to your app as to every other app, no matter what technology you've built it with. Telling your customers "Well, of course the scrolling is jerky, it's built with web technologies!" will not fly. They don't care what technology you've used to build it. Also, to put the final nail in the mimicking-native-UI coffin: Building something with web technologies that's on par with native is hard and difficult work. It's a myth that it's so much easier and faster to build an app with web technologies. It could very well take longer and still have a worse user experience. Building a simple native app is, well, simple. It might be way more complicated to build it with web technologies (if you try to mimic native).
All that being said, I want to make one thing clear: I am absolutely convinced that you can build stunning and fast mobile applications with web technologies today. But I would not recommend to use web technologies today to create an app for the App Store. As an exception I might name Appcelerator Titanium which lets you use JavaScript to build your application, but creates real native controls and UI elements from your JavaScript code at runtime. So you end with an app with a real native UI that also feels and behaves like a native app. I haven't personally used it yet, but the concept seems to make sense. And you should also keep an eye on the things that Strobe is working on.
So if you don't want to sell your app, don't have a big budget, don't need any native-only device features like access to the camera and want to be available on multiple mobile platforms, you should consider building a mobile website or web app. However, make no mistake: Creating a truly stunning mobile web app is a challenge, too: Just because you use web technologies doesn't mean that everything is as easy as putting an img tag on a page. Creating a great mobile web app requires true software craftsmanship.
So putting ideologies and technology preferences aside and considering just your end user, I'm convinced that - when targeting the App Store - you can provide the best, smoothest, most polished experience if you create a native app. That might very well change over the next few years, especially when hardware accelerated CSS transforms and WebGL become available on all major mobile platforms. However, even then one thing will remain the same: Mimicking native UI will most likely be a path to user disappointment.
Of course big companies like Google and Apple could agree on a standard that provides web developers with standard UI elements like navigation controllers or table views that get rendered in an optimized indistinguishable-from-native way on different platforms. The problem is they won't. They have no interest whatsoever in making mobile cross-platform development easier. They want that your great app is only available on their platform. So I doubt that they will put any significant resources into making web technologies the more attractive choice for App Store-targeted development any time soon. Or ever.
Conclusion
My conclusion is as simple as it probably will be polarizing: If you want the best possible user experience for your users and you are targeting the App Store(s), build a native app. Otherwise you will most likely disappoint your users. If you don't need to be or don't want to be on the App Store(s) and your application is a good fit for a web-like application whose usability wouldn't suffer from not being able to use certain native UI elements or features, build a great mobile web app. Don't mimic native UI, though. The web has it's own thing going for it. Leverage that and pleasantly surprise your users by using advanced features that modern mobile browsers support already today.
So this post turned out to be longer than I thought. Please share your opinion and let me know what you think.
