There are a lot of great reasons to build a mobile Web app just as there are a lot of great reasons to build any Web app and I’m certainly not here to continue the great Web versus native app debate. It’s not native versus Web, it’s both and it depends on your situation.
But what I’m here to talk about are the pretenders. Pretenders are mobile Web apps that try to replicate the native experience. You’ve no doubt seen Web apps with iPhone-style back buttons, awkward attempts at implementing gestures, laggy scrolling and the like.
Pretenders have problems
They don’t meet user expectations
Users of pretender apps get an experience that falls squarely in the uncanny valley — it looks like a native app, but something isn’t quite right. Perhaps it doesn’t respond as expected or it doesn’t quite follow the conventions of a native app. Often pretender apps have both of these problems and then some. They simply don’t feel “at home”.
They are a huge drain on development resources
Development teams can spend countless hours trying to make the Web act native. How many times have you heard that HTML5 is “almost there” in providing a native-equivalent experience? But the gap between “almost there” and “all there” is significant and may never be closed. Just imagine how many hours have been spent trying to improve the performance of scrolling lists. It’s fine to tackle these problems as part of an open source project, but if you’re attempting to solve these problems in your product you are consuming valuable time that could be spent making your product better!
Embrace the Web
If you’ve decided to deliver your app via the Web, you should embrace the capabilities and constraints of the Web. Don’t spend time and resources making a pretender app, spend that time making a great app that works on the Web.
Bagcheck offers a good example of a mobile Web app that embraces the Web. Instead of using floating headers and footers in an attempt to replicate a native app, the page scrolls like any other Web page. A simple anchor link is employed to allow users to quickly jump to the bottom of the page where a set of menu options appears. Because Bagcheck doesn’t pretend to be native, performance is great and the app offers up a mobile-optimized UI that meets user expectations. In other words it acts like what it is — a website.
Bagcheck's Mobile Web app feels right at home in the browser
Stop Pretending
If you’re making a Web app, don’t pretend to be something you’re not. If you do, your users will notice right away and it will turn them off. Besides, it’s a lot of work doing all that pretending. It’s far easier to embrace the Web’s constraints and capabilities and doing so will result in a much better product.
See Also
- This article was featured on Daring Fireball. Check out what Jon Gruber has to say on the subject.
- John Allsopp wrote an interesting piece partly inspired by this post, partly a counter-point to this post. See John’s original post and my response.
- iOS5 Brings Native-Style Scrolling to Web Apps by ReadWriteWeb
- How to fail at mobile web by @sunpig
Agreed with your post, shame about the gratuitous use of the ‘uncanny valley’ buzz term. The point of the uncanny valley principle is that it’s slightly, and freakily ‘too real’ whereas a web app trying to be a native app is simply not real enough.
nice. completely agree. trying to replicate native behaviors takes a huge hit on performance. longer load time = lower conversion rate.
Couldn’t disagree with this post more – or Joe for that matter (and trust me when I say I know and think Joe is a rockstar). This type of stance is ONLY an ideal. What is an app UI anyway? Something with a back button on the upper left? Let’s be productive and try and boil it down to what REALLY SHOULD NOT be in a mobile web app. Is there really a list for this? Should I get rid of a back button in my web app because users look for it (cause they do)? We’ve developed an app back button (which in reality is a go to the appropriate parent) and still support the browser back in our HTML5 mobile app. Watching actual user testing has taught me that both are used and needed (with the upper left location being used in orders of magnitude more).
So, what are we really saying? We can’t have transitions? We can’t write scripts like Scrollability (*cough*)? We can’t make use of full-screen web apps?
A good UI is a usable UI (and yeah, it needs to perform well too – I’m not saying it doesn’t).
Do you realize that your blog, when viewed on an iPad, has a theme that attempts to imitate a native iPad app? Complete with re-implemented JS-scroll acceleration that doesn’t match the native Safari scroll acceleration.
The iOS version of this site is a default setting of WordPress which has now been turned off.
I understand where you’re coming from, but I disagree. When you install a web app for iPhone, there isn’t a “browser” back button anymore; you have to make your own, if you need one. Mobile web apps designed to fit–in with the iPhone UI won’t make sense in the browser, but once you add them to your home screen — the way they were designed to be used — they do just fine.
So should the jQuery Mobile team just give up? Are they doing the mobile web a disservice by making it easy to make pretend-native web apps?
I think Nick C. brings up some good points. The line between “app” and “web-app” is really a bit of a continuum.
I hadn’t really heard much discontent from tablet & mobile users on these “native” sites until today (c.f. a few DF links; here’s my questions on one). This is really important to me, as I’m building sites that I want to perform well on mobile & tablet devices. The last few sites I’ve built have used app-like experiences (using WPTouch Pro), delivering tailored sites to those devices.
I’m already moving away from that, though not for user-centric reasons. The reality is… building 3 or 4 sites instead of one is a lot of work! I’m drawn to using CSS3 media queries instead to “collapse” the content elegantly for various device widths.
Is it just that these device-specific sites aren’t executed well? Sounds like the author objects to performance, and (for some reason) the idea that mobile web sites try to behave like apps.
I do relate to a few points the author brings up, too: I’m not a fan of these non-hardware accelerated transitions (such as panning the viewport to the side – too chunky! CSS3 animation is accelerated; JS isn’t, I think.), and if it doesn’t load quickly… buh-bye.
It does seem to me that there’s a happy medium to be had with mobile web apps.
A real Pretenders fan would put up their first record cover…
Best thing is that these are in general a whole heap faster for the users too as their codebase is significantly lighter!
@David – Actually, I think his use of “uncanny valley” is just fine. My understanding of the term is that it describes something that is so close to real that the small difference that make it not real–even if you can’t exactly say what those difference are–makes it look REALLY freaky. Like if you were animating a person and the knees bent backwards just a bit. Since everyone knows real human knees don’t do that without a lot of pain, anyone would flinch the first time they saw it.
Non-native UI that tries to copy native UI often falls into this trap. I can’t count how many desktop-ish Flash apps I’ve seen where they make a scrollbar that looks and acts just like a regular scrollbar EXCEPT that you can’t click in the dead area to jump up or down one window-full. OK, maybe it’s not freaky, but it’s REALLY REALLY ANNOYING. But if someone is allowed to be “a Cadillac of men”, I say we can have an uncanny valley of UI.
In other news, I’m curious how Joe’s opinion relates to iUI, which he created. Does he think it’s wrong now? Sometimes OK?
I could not agree more strongly!
A great example is OnSwipe. I really fear this stuff is going to get entrenched, I can appreciate the work they have put into it, but it just ruins the reading experience for me as it is a classic ‘worst of both worlds’ compromise.
With all due respect we have to disagree greatly!
We are very far along in building a toolset based on html5/css3/JavaScript that will yield very native like
Business apps running on multiple and varied mobile platforms as well as on desktop/laptop browsers and delivering excellent performance.
This product is called alpha five v11. For more info please email Richard@alphasoftware.com
Totally agree. There’s still a gap between mobile web and native and I believe with the current speed of new developments this gap might even get wider in future.
Martin Fowler also had some thoughts on this:
“When you do the web app, don’t try to make it look and feel like a native app – make it look like a mobile web app” – Martin Fowler – http://martinfowler.com/bliki/CrossPlatformMobile.html
“Just imagine how many hours have been spent trying to improve the performance of scrolling lists”
Oh My! Don’t mention it!
There is a great difference between a web app, a browser app and an app made by native toolsets.
I am gonna take the opposite side of everyone here apparently
Idioms that have become popular in native apps, such as the fixed footer navigation, have become popular because they are good solutions for common problems on mobile devices. Lots of applications benefit from having an always visible global navigation and if it is a good solution for your application it should not matter whether it was implemented as a native UI or a web UI, it should be possible.
Todays hacks will become tomorrows features, I do agree that on time sensitive projects you need to understand the time and risks involved, and that trying to fight against current functionality is going to cost you, but I am thankful that there are so many people fighting it as it means there is a good chance it will actually be fixed.
@Dale — If you look at the Bagcheck example, I’d say they are doing just fine (better than most) without fixed nav. That said, I too am glad that there are devs hacking solutions and I hope that some day soon we’ll see a really solid implementation of fixed navigation and highly performant scrolling that everyone can use. But right now there are countless teams slaving away at solving this and other problems in an effort to mimic native apps and I think that for the vast majority of product teams that time would be better spent on delivering more value in their products. Also, think about how Apple has come along and addressed issues with position:fixed in iOS5. There may be better ways to spend your resources than solving problems the browsers will eventually address.
“It’s fine to tackle these problems as part of an open source project, but if you’re attempting to solve these problems in your product you are consuming valuable time that could be spent making your product better!”
Isn’t this true of every aspect of every program? That is, if it was open-source, you’d have a much larger pool of contributors and each person would have to do far less work to get the same result.
Or, what if you did it the other way, and made the domain algorithms open-source, but the UI proprietary? After all, that’s pretty much exactly what Apple has been doing for the past 10 years and they seem to be having some amount of success with it.
I’ve only run into one web/app that actually did a swish job of implementing a paged scroll-view (i.e. iOS’s Weather). I’m with you completely that this can probably get out of control. But I wish the article cited some bad examples.
[...] Why Mobile Web Apps Should Stop Trying to Act Like Native Apps [...]
[...] apps vs. native apps for mobile — this appears to be what everybody is talking about these [...]
@Brian at the risk of labouring the uncanny valley point: the fact that it the subtle differences are annoying rather than freaky is exactly what makes this NOT an example of uncanny valley. The uncanny valley refers to the dip in emotional resonance with robots in an otherwise upward trajectory once they reach a stage which lies in between approximation and perfection. This article seems to be about how web apps trying to be native apps are completely missing the point, rather than scarily almost getting the point.
How about the other way around?
FB on iOS is nothing more than a webapp hiding in native clothing, and it sucks.
@David Vogel: “once they reach a stage which lies in between approximation and perfection”
Yes, that’s exactly the point. They are at the point where it appears to be native, but differs in such minor details that they surprise and irritate us when they’re discovered.
One can criticize bad UI on anything that is built but I respectfully ask the author to be careful by not attempting to generalize when speaking about Mobile Web UI vs. Native apps UI. There are many poor executions on both sides, as well as many good ones. I don’t think it is a matter of one vs. another but rather, simply a matter of the execution on each.
The word “pretending” seems strong. Programming is, and has always been, about seeing something new, then copying it and making it better…..MS Windows was the best “pretending” Mac OS piece of software ever written….and look what happened.
Don’t forget that Apple also “pretended” to copy the mouse functionality from XEROX.
The Web is a huge sandbox for Mobile Development. Call them pretenders today, but improvements will continue and the benefits will keep on coming.
BTW, didn’t we have a “native” computer software revolution 25-30 years ago (we called them “applications” back then)? Then the web revolution came along and we said “Everything to the internet” the pretenders came and conquered and now we are going back to “native” mobile apps? One could argue we’ve gone full circle. Same concept, different device.
Keep pretending my friends…the mobile web needs you.
@CV — I don’t disagree that you can have bad UI regardless of the delivery mechanism. Here’s something I wrote in response to a post from John Allsopp that I think summarizes my take on the matter:
I saw this tweet from Joe too, and thought it was really weird to see that coming from the author of the iUI mobile web framework (with default theme beeing a total clone of native look) or a few months ago JS snippet Scrollability.
Those scripts goal is just all about being native look-a-like…
[...] Pretenders: Why mobile Web apps should stop trying to act like native apps « cvil.ly [...]
[...] why you don’t see ’em.Furthering the conversation about web and native app development, Craig Villamor calls web apps out on being Pretenders. Appcelerator promote Titanium cross platform development and slap a free-and-open-source sticker [...]
I’m with you on this one @cvilly. There are so many other issues that valuable time could be spent on vs. emulating a native app experience. I’m hoping a year from now, this won’t be an issue but not crossing my fingers.
There is one point that none of you designers have addressed, and I think it it be a valid point, though how valid of a point I think depends on how lazy you, as a person, are.
Battery Life. The so called “Uncanny Valley” experience is not such a bad thing if eventually better libraries are built, faster processors occur, etc, but designers generally are not concerned with performance until it starts visual impacting them. On a small scale, yes, slapping an interface together with a bit of C(++) vs HTML might not make much of a difference, but just as anyone who’s even taken a smidgen of algorithms knows, inferior methods start to show up in embarrassing ways after you reach a certain performance point. This also translate to less battery life. I know things are not what they once were, but I suspect there may be very real economical arguments that end up forcing out the “easy ways out”, out.
Where is this performance point? I don’t know, but it seems to me the author of this article thinks that the performance point isn’t high enough that web developpers should stop pretending its higher than it actually is. Which, in all fairness, it probably isn’t as high as you lazy webbers think it is. Even on the desktop, web-apps tend to run pathetically in comparison to something running on the bare metal. Guess which app I’d sooner run.
Not sure I entirely understand your argument, but yes, battery life is part of the user experience and taxing the browser with lots of JavaScript, etc. can have a significant negative impact. Thank you for raising it as an issue.
Do you know jquery mobile? They should give up? The project seems nice and works good.
[...] http://cvil.ly/2011/06/19/pretenders-why-mobile-web-apps-should-stop-trying-to-act-like-native-apps/ [...]
G’day, just wondering If anyone knows how bagcheck switches to the mobile version?
Hi Daniel, We use sever side detection as we deliver based on device not screen size. For example, 7 inch tablets get mobile but tablets above that range get the desktop optimized site.
PS: You can see the full tech stack Bagcheck is built on here: http://bagcheck.com/bag/382-bagcheck-technology
[...] couple weeks ago I posted Pretenders: Why mobile Web apps should stop trying to act like native apps. It generated a lot of interest and a lot of great discussion. While responding to comments from [...]
[...] valley” that results from porting an app design straight from one platform to another, or attempting to mimic native UI elements in a web app as closely as possible, is especially to be [...]