Are Web Apps An Insult To Users?

Web apps vs. native apps for mobile — this appears to be what everybody is talking about these days.

I think native apps currently provide the best user experience, don’t you? As a user, given the choice between a web app and native app, which one would you pick? Unless you signed your life away to the web browser, it’s likely going to be the native one.

Still, reasons to develop for the web are there: portability, simpler deployment, perhaps simpler development — all developer reasons.

But ehm, who are we developing sofware for? Ourselves or our users?

Following that logic — aren’t web apps a statement saying to users: we favor ourselves over you?

On the desktop this is not really the case. Over the past decade, web apps have not become popular because of developers; they are convenient for users too: no need to install anything, access from any computer, no (manual) software updates, usually free, data “safely” stored in “the cloud” and easily shared with others. The fact that the user experience is a bit limited is a small price to pay.

On mobile, the story is a little bit different. Every smartphone comes with an application store of some kind from which you can easily install and update applications. Since a phone is a personal device, rarely shared with multiple people, it’s less common that you want to use somebody else’s phone to access your applications — which makes the “login from any computer” pitch less relevant. And mobile apps almost all store their data “in the cloud”. What is left of the web app advantages are developer specific: portability, easy development and deployment.

So, I ask again: is a mobile developer using web technologies choosing himself over the user?

As usual, it’s not that simple.

Let’s say I run a one-person company and I want to build a mobile app. I have three months to go to market. Effectively, I have roughly three options:

  1. Pick one mobile platform, say iPhone, and develop only for it.
    Advantage: I can focus on a single application and provide the best possible user experience to my users.
    Disadvantage: my users are going to be only iPhone users — Android, BlackBerry and Windows Phone users will be left in the cold.
  2. Instead of one, I pick multiple platforms, say four, and develop separate apps for all of them.
    Advantage: I reach a much larger audience with great, custom tailored mobile apps.
    Disadvantage: the mobile apps will only have about one fourth of the functionality I had planned, because I had to develop every feature four times as code reuse is barely possible.
  3. I develop my mobile application using web technologies.
    Advantage: I have to implement my app once and it runs on multiple platforms. In addition, my application has all the features I intended to build, because I only had to build them once.
    Disadvantage: The user experience is worse. The application doesn’t blend in or integrate with the OS.

So, what have we learned?

  1. Reasonable time to market
  2. Flawless user experience
  3. Big reach

Pick any two — a company with limited resources cannot have all three.

  • Malvolio

    It’s easy enough to say “we’re all about the customer”, but which would the customer prefer, a free restaurant next to his house with only one table, his, or an expensive one across town that seats 100? Clearly, the former but more restaurants are like the latter. It isn’t “insulting”, but merest reality to notice that organizations survive by serving their customers, but they exist to serve their shareholders and owners.

  • pwb

    Don’t forget the considerable user benefit of substantially faster iteration (which includes both bug fixes and service improvements).

  • Willem Bult

    I do not believe mobile web applications are insulting users. They have the potential to make development across platforms faster, which is good for developers and users alike as it moves the market forward in a higher pace. There is a high demand for mobile applications. People are making money off the simplest applications and the range of things we can do on mobile devices is still fairly limited. Yes, if we develop native apps the experience will be better and the user will certainly appreciate it. But, as you point out, as a developer or as a company there is only so much I can do in a certain amount of time. What does the user want at this point? Excellent experience, or a wider range of applications?

  • Matthew

    As a user, both options are terrible. What’s an insult to users is being forced to choose between two evils: either download yet another custom app for doing one thing, or deal with a crappy browser-based interface. I hate both options.

    I really hate downloading a whole bunch of apps just so I can rent movies from one place (Redbox), buy stuff online (Amazon), etc. I might like the functionality of native apps, but I hate having all this junk installed. My app list gets as bad as my list of bookmarks. Then, the damn things need to be updated all the time.

    While browsers on mobile devices are still immature and we’re in the infant stages of mobile applications, maybe what we need are better browsers/toolkits over time. I’d push in the general direction of browser-based mobile apps because I can’t deal with the app list continuing to grow.

  • Melvin Ram

    I was just going to say exactly what PWB said. Faster iteration time is not only the result of being able to deliver an updated version immediately since you don’t have to go through the App Store approval process, but also because you have to develop less.

  • Thomas

    It’s true that you can build a very slick native app with an awesome UX, not easy to imitate using only web technologies.

    BUT, you can build crappy native application and stunning web site (see on an iPad). And there is a lot of native mobile app with a crappy experience.

  • Allen

    Let’s call a spade a spade – you’re comparing polished iPhone apps to pretty much everything else, web apps and native; and you’re simplifying “great UI/UX” to using Apple’s core animation and OS libraries to make pretty page transitions and swipe behaviors.

    I don’t think UI/UX is limited to what you see – a lot of the time, a poor 3G connection or a stuck process will kill an app or freeze it, providing plenty of bad user experience. At the same time, native apps don’t guarantee a great experience either; like I said, it’s mainly been Apple’s platforms that have the easy-to-use UI libraries that make creating great-looking apps simple, and other native platforms haven’t fared as well.

    At the same time, you also cannot discount the discoverability and virality of each platform’s app store, which is just a compelling reason as what you’ve listed above.

  • Adam Żochowski

    Native might be nicer, when done right. I have a pet peeve with Facebook Native App. There are features on the website that are not provided through native mobile apps. Today was in a bar with friends. One tried to look up some contact of mine through native app. He couldn’t because that feature isn’t available on native app, yet is a normal part of facebook.

    As long as native apps will limit features, then users will be stuck with two bad inferior choices: use website not designed for mobile, or use native app that is crippled

    • Nobody

      Your friend is dumb. Browse to your page, tap Info, tap Friends, bask in the glory of your friend list.

  • Anonymous

    Being forced to go into an appstore to put an application on your phone is very user unfriendly as well.

    • Nobody

      Why is a store that makes it way easy to browse through all sorts of applications a “horror”?

  • LB

    This piece assumes a sort of “us vs. them” tone when it comes to the relationship between users and developers, which is a dangerous place to start. In fact, what benefits developers usually benefits users as well.

  • AP²

    There’s an extra alternative: instead of writing four mobile apps and still leaving other platforms in the cold, why not writing two apps: one webapp and a mobile app for the platform where most of your users are, possibly sometime after the launch of the web version?

    As an aside, considering most people write Android apps in Java, I wonder if a Android-like UI API could be written for GWT, enabling code reuse between the native Android apps and webapps.

  • Anonymous

    Native is only necessary when utilizing the devices hardware …and for that there are even some API’s. Native apps are a way for companies to lock users and developers into their non-standard environments. No thanks. HTML5/CSS3 is the way to go. Just look at everything going cloud based for proof of the direction of digital interaction. Long live standards.

  • Nobody

    Both options are right–and both wrong. It all depends on context. I don’t shop amazon multiple times a day, so the website is fine by me. I don’t spend hours on slashdot, so I want a website. But facebook has a lot of functionality that is better in the app, and I spend a lot of time using it, so it’s more sensible that it work with the native toolkit to make my usage more efficient.

    I don’t want a native app for every single website I visit! How frustrating would that be?! haha.

  • Iraê

    I don’t totally agree with you. I use both the native and web app for Facebook. I like the native app because of push and image uploading (tough image uploading can be done with a mininal app just for that, trough instagram, camera+ or many tird party apps). I like the webapp because it is more stable and has some features that the native don’t.

    For example: Someones comment on my photo. In a desktop browser I can “like” the comment. In the webapp too, but not on the native iPhone app. Sometimes the native web app will never load some new comments on a story, note or something, but the webapp is aways working. I know this is bugs that sould be fixed, but I happen to see more bugs on the facebook native app then on their webapp.

    The problem with the “like” button is complex: the cocoa developer can use a native NSTableView (I am not sure about the name) and display the comment as it is today. But to have a like button, witch will display how many likes and be clicable to show who likes a comment is a completely customized, hard to develop and bug prone component they will have to make. If they push this feature to the app they would have to maintain a lot of extra code.

    The same is not true to the webapp. This new feature, besides being developed once for many platforms, will be one HTML for all devices and may be separate CSSs or one CSS with rules based on the platform.

    As you say, this is an advantage for the developer, but will also be a huge advantage for the user to have all expected features in a bug-less environment.

    What I really want to see is apple provide us with better ways to make the webapps more slick and more feature compatible with the native apps. Not only apple but Android and other players too. Apple today released iOS5 beta2 with the most mobile safari developer asked feature: native scrolling: — Lets see if we can do some magic with it and change peoples impression that webapps can’t be awesome.

  • Pingback: State of Code « I am Zef

  • Pingback: facebook likes bot

  • Pingback:

  • Stophy

    Browser apps for mobile, downloaded apps for computers