All mobile web apps today suck. Some mobile web apps come close to being good, like Gmail and Twitter, while some come really close, likeThe Financial Times and Basecamp. But all the examples fall short one way or another: Gmail’s scrolling is unnatural, Twitter hides the browser’s location bar, Financial Times is riddled with flashing/jittering/scrolling bugs, and Basecamp jumps when you tap on an item. For every one of these examples, there are 10 worse offenders I can point to, but they all share the same essential mistake: They all use the browser as an emulator of native apps. Trying to replicate the native experience on the web is a fool’s errand, and leaves users confused. To move ahead, the web needs to play to its strengths.
First, I’ll highlight the overarching problems with the current fleet of mobile web apps, then I’ll lay a framework for building the next generation of amazing mobile web applications.
Problem: Double-chrome
Consider that screenshot from Google+: There are three back buttons. What do you think will happen if I click the browser’s back button? Will it take me “Home”? or will it take me to the previous app? What will happen if I click the “Nearby” button? What about the “Home” button? Now let’s say I clicked on the “Incoming” link at the top right. What do the buttons do now? The answer is, the browser’s Back button will take me to the previous website, while the “Home” back button will take me to the main Google+ page, and the “Nearby” button will take you nearby. Once you click on a post, the browser’s back button and the button that will replace the “Home” button will do the same thing, but the “Nearby” button won’t. This lack of consistency and predictability is endemic of mobile web apps. This is a problem that native applications don’t usually have to deal with.
The counter-argument goes: If you make the user believe they’re in a native application, they will expect to have a back button in the top-left. Most of the time, this means having a navigation bar that is fixed to the top of the viewport. In reality, that argument makes the assumption that people are using the web app on iOS (navigation bars don’t exist on Android), and that they forget they’re in a web browser. Even assuming the argument is correct, it implies that the cost of learning the back gesture the first time outweighs the cost of having to make a decision on which back button to tap on every single subsequent page.
Solution: Browsers provide a persistent back button at all times that is impossible to get rid of. They also provide a title bar – which admittedly, isn’t persistent – but also provides a reliable way of telling your users where they are. Mobile web apps today suffer from platform-specific, ambiguous elements. Give the user their 50 pixels back.
Problem: Chasing your own tail
iOS has not had support for overflow-auto nor position:fixed until iOS 5. Instead, people resort to elaborate hacks to achieve the same fixed-bar-at-the-top UI of navigation controllers and tab controllers on native iOS apps described in the earlier section. If you’re ever used a web app that used that UI, you’ve probably noticed very quickly how unusual and weird the scrolling behavior is.
Scrollability is the best of the bunch, but it’s still not perfect, and it never will be perfect. The proper solution is the browser’s solution. You obviously couldn’t have used that feature before iOS 5, but my point is that web applications shouldn’t have a fixed bar along the top anyway, obviating the need for a scrolling hack (except on iPad for multi-pane UIs. That’s a technical limitation Scrollability is a good solution for). Moreover, for the scrolling hack to work, the scrollable area had to capture touches, which means when user scrolls to the top of the page, they get the scroll-bounce instead of getting access the address bar. For example, if you go to twitter’s mobile web app, you have to know to tap the title bar to scroll to the top of the page and reveal the address bar. 1My uncle Bob doesn’t know that tapping on the title bar scrolls his view to the top, so he’s essentially stuck in the app.
The fundamental problem is that people are trying to emulate as best they can what a bunch of engineers did at Apple 4 years ago. Apple can change interactions, behavior, and widgets between versions, and everyone who’s trying to emulate them, has to continue playing an endless game of catch-up.
Solution: Once you eliminate the double-chrome problem and the fixed-navigation-bar problem, you eliminate a lot of the issues that make mobile web apps terrible.
Problem: Forgetting what the web is about
Mobile web app developers seem to have forgotten that the web is inherently cross-platform. That’s the whole point of the web: Ubiquitous access to information. What’s the point of building a mobile web app if you’re only targeting iOS users? If you are targeting multiple platforms, why are you forcing the iOS UI on non iOS users? The navigation bar with a back button does not exist on Android, users won’t be expecting it, so save yourself the 50 pixels of screen real estate.
Solution: Build a UI and UX that is platform-agnostic.
Now that we’ve outlined some of the problems of the existing fleet of mobile web apps, let’s analyze how to build the next generation.
Build a mobile web app when it makes sense
Not every app is a suitable candidate for the mobile web. It’s important to analyze the strengths of the web and see if your application stands to benefit from them:
- No installation: The barrier to entry for a new user to your app is essentially zero. As soon as a user has expressed interest (by clicking on a link), they have instant access to it. This quality is essential for certain classes of applications that require either an impulsive action, or a trial. If your app needs to get viral, it needs to be a mobile web app. There are counter examples: Instagram, Angry Birds, etc. However, instagram still needs to build a scaled back web page to share with people, and in the case of Angry Birds, they had to build different versions for every platform (and ultimately, the web). I’m using Angry Birds here as an example for the virality argument, clearly, I don’t think Angry Birds should ship as a mobile web app today.
- URLs: This one goes hand-in-hand with the previous benefit. The fact that you have a URL to an application means you can a) encode the current state in theURL, and b) send that application in its current state to anyone in the world, on any device or platform. If your app stands to benefit from share-ability, it needs to be a mobile web app.
- Auto update: Mobile web app users are always using the latest version of your application. You can ensure 100% penetration of new features and bug fixes almost instantly (allowing time for caches to expire). If your application needs timely security fixes or a/b testing or iterative user feedback, it needs to be a mobile web app.
- Cross-Platform: Most people aren’t on iOS. Nor are they on a Mac. Those users represent real people, with real jobs, real bank accounts, and real user needs. The web is the only example of a wildly successful, healthy cross device and form-factor platform. If you app needs to reach a wide audience, it needs to be a mobile web app.
Notice how I didn’t mention performance. Performance on the web needs to only be good enough to deliver a great UX, it doesn’t need to be infinite. If you were instead building an oscilloscope app for the iPhone that needs to analyze large amounts of data quickly, please don’t build it as a mobile web app.
Uncanny Valley
Bill Higgins wrote in May 2007:
So I’d recommend that if you’re considering or actively building Ajax/RIAapplications, you should consider the Uncanny Valley of user interface design and recognize that when you build a “desktop in the web browser”-style application, you’re violating users’ unwritten expectations of how a web application should look and behave. This choice may have significant negative impact on learnability, pleasantness of use, and adoption. The fact that you can create web applications that resemble desktop applications does not imply that you should; it only means that you have one more option and subsequent set of trade-offs to consider when making design decisions.
Rasmus Lerdorf, the creator of PHP, once gave a talk to us at The University of Michigan where he was talking about performance. He gave us an anecdote from his time at Yahoo! where they asked users to use Yahoo! Mail and Gmail and asked them to rate which one was faster and which was slower. Although Yahoo! Mail was faster at a technical level, the users said Gmail was faster. His hypothesis was that users compared gmail’s performance to Hotmail, but Yahoo Mail’s performance to Outlook/Mail.app. The takeaway is, by copying a different platform’s UX, the users had a mental model that did not match what they were using. I don’t know the accuracy of the anecdote (I’m recalling it from two years ago), but I think the point holds true today.
Web developers today use iOS as a starting point for every mobile web initiative. It’s a great platform, I don’t blame them, but iOS is only one of the platforms the web supports. On Android/WebOS, most of iOS’s interactions don’t make sense, on iOS, if they’re slightly off, they’ll break the illusion to the user. It’s a no-win situation. The Web has achieved cross-platform dominance by not imposing a platform-specific UI on multiple platforms.
The Financial Times web app does a very good job of this. It doesn’t feel like an iOS-specific app, and scales well to multiple platforms.
This view may seem contradictory to you if you’re familiar with my work. I’ve been involved with the SproutCore project for some time now first building desktop-like web apps, and now building a new UI layer for mobile devices. SproutCore’s mission has been (until the recent 2.0 release) to build desktop-like applications on the web. That argument makes a bit more sense on the desktop: Most desktop computers share a keyboard, mouse, and across the different operating systems, most interactions will map from one to another. On mobile platforms, that’s not the case, the variety between platforms is huge, and sometimes, input devices exist that don’t on other platforms (trackball, physical keyboard, hardware-based gestures, etc.) Furthermore, desktop browsers are much, much more capable than their mobile counterparts. That’s not to say that in a couple of years when mobile browsers get fast, that uncanny valley will no longer be an issue. After all, although SproutCore (and Cappuccino) delivered very strong solutions, neither nor developers flocked to use them.
Conclusion
The web platform on the desktop is much more capable than its mobile counterpart. For a while now, we’ve been able to build incredibly complex, compelling UIs on the web with no compromises. Desktop browsers are much better today at compatibility than they were before, and we have much better debugging tools.
On the other hand, developing mobile web applications today is akin to developing a web application on the desktop in 2004. The saving grace is that the pace of progress on today’s mobile devices is far, far faster than it was on the desktop. iOS 5 on an iPad 2/iPhone 4 is ready for the mobile web, Android isn’t (but that’s a topic for another post). The next generation of mobile devices (and worst-case scenario, the one after) will catch up to iPad 2/iPhone 4 and the mobile web will be ready to kick some ass.
1 position:fixed in iOS 5 behaves correctly: When you reach the top of the scrollable area, the fixed bar moves down to reveal the address bar
Majd Taby 