Whitepaper - how to spot the ignorant whitepaper author

I just read [this wonderful gem of a "whitepaper"](http://developerlife.com/theblog/?p=1482). Please go read this piece of masterful writing. It's about how stupid mobile web applications are, just your thing. I'll wait here until you return. Go ahead.

Done? Good, because I got the adrenaline rushing through my body. In this white paper, I will take the annoying approach of quoting snippets of text out of context and responding in various semi-clever to clever ways, as bloggers tend to do.

> The term "mobile web" is used interchangeably with the word "mobile app", but in reality they are not at all the same and these terms cannot be used interchangeably. "Mobile web apps" aren't "apps" at all, they are just tiny webpages you view in your smartphone's web browser

Sssh! Here's a secret... native apps aren't "apps" at all, they are in fact just a series of bits that magically show pixels on your screen!

> Mobile websites are a cheap and easy way to let people view some parts of your website on their smartphone, and they are inexpensive to build.

So, cheap, easy to build and inexpensive (yes, those are three things), sounds like a winner to me. No?

> However, these mobile websites cannot do very much, and usually only allow people to read static content and do not integrate with a smartphone's native applications or functionality. They are VERY basic and very "one way" as in the content flows from the owner of the website, to the reader. There is hardly any engagement that is possible with this content viewing scenario. Very little interaction is possible. And hardly any capabilities of the smartphone are leveraged.

Yes, [WAP](http://en.wikipedia.org/wiki/Wireless_Application_Protocol), those were the days... that have long since passed.

The example of the modern web app, which I use to describe my vision of the future of mobile apps, is the Gmail web application. If you haven't used it and you own an Android, iPhone or WebOS phone, be sure to go to gmail.com and have a look at it. Quickly you will realize that:

1. This is a pretty advanced application, pretty close to the desktop browser version of Gmail in functionality; 2. It is very much a very two-way application, you read stuff, you reply to e-mails; 3. It is equally as engaging and just as interactive as a native application; 4. It leverages a lot of smartphone capabilities (including off-line operation -- it caches messages on the phone and operates without an internet connection as well)

I have an iPhone, but I don't use its native mail application, instead I use the Gmail mobile web app, _because I think it's better than the native iPhone mail app_. Can you believe it?

> As a software engineer, and CTO of a software company, I do not like mobile web apps at all, and here's why: > > * They do not constitute a legitimate product offering – they are not acceptable for your customers/users in 2010, and they do not pass as a mobile app. Smartphone users are intelligent and it is insulting and a waste of their time to ask them to use such a dumbed down app/product. It makes the company that has published the app looks stupid and cheap. It looks like they aren’t trying at all and don’t really care about their product/offering, so why should a customer care? Why should a customer care and waste their time with your mobile web app, if you don’t care?

It is all about the quality of the application, not about the technology used to implement it. If you have crappy developers and designers, your native application will look crappy, cheap, be extremely slow and have a bad user experience. The same goes for mobile web apps. It doesn't matter.

> * They provide no user experience for customers - smartphone web browsers have even fewer capabilities than regular web browsers, and many mobile devices don't support flash or web plugins, so they are the worst possible choice for delivering an experience. The web browser on a smart phone is literally the worst technology you can imagine for delivering an experience.

Don't you know that smart phones have _even fewer_ capabilities than desktop computers? They don't have keyboards, usually, and if they do, they're very small. They have tiny little screens, they're 10x slower than a desktop PC. I would say the smart phone is literally the worst technology you can image for delivering an experience.

> * They cannot utilize 95% of what the smartphone can do – if you are going to deliver your mobile experience via a mobile web view, your customers might as well use a feature phone with keyboard, like a Pantec, or a BlackBerry with OS 5.0 or prior. Smartphone users love their smartphones because of what they can do! NOT for what they can’t! They love features, capabilities, customization, and the excitement of their smartphone! They want to be engaged and delighted by mobile applications! Mobile web views negate all of the awesomeness of mobile devices that users love and want to interact with.

95%? Do you realize how much that is? Just to make sure we know what we're talking about here. This is 95%:

Ergo, 95% is a lot.

If web app can utilize 94% of what a smart phone can do, I think that is pretty good as well. In fact, I would argue certain phone manufacturers don't allow you to do utilize 82% of what a phone can do, even with _native apps_. They don't allow customization, they don't allow access to things that their own software _does_ have access to.

And to be perfectly clear, this is 82%:

So, let's see what are all the things (supposedly) impossible with mobile web applications:

> * Make location based apps that use GPS to display accurate location information, and deliver relevant information to users based on their current location.

[Really](http://dev.w3.org/geo/api/spec-source.html)?

> * Use push notifications to create in-app payments, realtime interactions, realtime communications, and ecommerce transactions.

I don't really see the connection between push notifications and all the examples that follow. But push notifications, [yes, yes you can](http://notifo.com/).

> * Implement in-app advertising with detailed statistics from attention profiling.

[Really](http://www.google.com/mobileads/publisher_home.html)?

> * Use Android notifications in the notifications bar since your mobile web app can’t push updates. And sending an email or text message is NOT a push update!

Not yet for Android, but [notifo](http://notifo.com/) will come out with an Android and Blackberry app soon. Plus, I think that yes, technically, e-mail and text messages are perfect examples of push updates.

> * Use cool UI elements to engage users like lists, buttons, layout managers, animations, etc. that users love and want, that make an app look “Android-y” and make users feel engaged and excited to use the app.

[Re](http://code.google.com/p/iui/)[al](http://jqtouch.com/)[l](http://jquerymobile.com/)[y](http://www.sencha.com/products/touch/)? (maybe not all native-looking, but definitely rich)

> Not to mention, you can’t really handle DPI independence and multiple screen/display resolutions and sizes (ranging from tiny screens, to 4” screens, to tablets, and netbooks, and in-dash car displays).

If there's something that web applications have been good at is scaling to the size of screens, because so far every computer screen has had exactly the same size, which has been very convenient.

> * Integrate with smartphone’s native apps. These mobile web apps or web views cannot integrate with native the media app, native PIM apps (email, contacts, calendar), or any other native apps on the smartphone, which is the entire point of making a mobile app! They can’t replace the default apps either to handle media, browsing, etc.

True. But again, iOS apps also hardly do this (only in a limited fashion).

> [ Rant insulting web application developers, Russian, Chinese and Indian engineers. ]

Whatever you say, ma'am.

> * Make fast, high performance apps. Mobile web views are very slow, laggy, and get slower (or require disproportionately more network, server, and wireless bandwidth resources) the more users you have.

Sure they're somewhat slower, but it's not a world of difference (if executed well).

> * Create apps that are resilient to drops in network coverage, or laggy networks.

[Really](http://www.w3.org/TR/html5/offline.html)?

Just for the fun of it, I looked up the definition of white paper on [Wikipedia](http://en.wikipedia.org/wiki/White_paper):

> A white paper (or "whitepaper") is an authoritative report or guide that is often oriented toward a particular issue or problem. White papers are used to educate readers and help people make decisions, and are often requested and used in politics, policy, business, and technical fields.

I suppose authoritative does not imply "remotely correct". And let's just hope this particular one hasn't helped anybody make a decision.

Why I'm qualified to write this white paper -------------------------------------------

I can think critically. I can check facts. I can use excel to draw a chart. I have tried a mobile web application more recently than 5 years ago.