native 3

So you’ve made it to part 3.  Well done. Part 1 set the scene with some definitions and user experience, design, and testing. Part 2 delved into product development and business model, finishing with a hybrid option.

In this the final part, I will give you my recommendation for how to make this vital decision.  Then, if you dare, I’ll get a bit more technical and explain some of the details I skipped over in the first two posts.


Instead of a long discussion of all the options, I’ve made a (hopefully) pretty picture.  So we’re clear, this is my opinion and I am trying to push you to the right side of the image.


(Note: speed is processing speed.  Meaning calculations.  It’s not download speed.  If your app has to get data from a central place then there’ll be little difference between a native and a web app.)

HTML5 is not what I said it was

OK so I lied.  In previous posts, I’ve made out like HTML5 is some kind of all-powerful ‘Esperanto’ that can be used seamlessly to ensure your app is understood by any device that speaks it.  True, but only to a point.  Imagine Esperanto was a language in widespread use.  There’d still be misunderstandings, and different people would have different ideas about what certain words mean and whether or not they are Esperanto or not.  So it is with HTML5.  Different devices, different browsers, have different ideas of what functions to support.  Eduardo Galeano’s famous quote comes to mind:

“Utopia lies at the horizon.  When I draw nearer by two steps, it retreats two steps.”

HTML5 is not even finished.  In fact, not even the specification is finished.  Indeed each time we get closer to the specification, it changes.  (But then what languages are finished??)

I’ll give an example of this different behaviour, but first let’s understand what I was really talking about when I said HTML5.

3 basic building blocks of the web

These are the 3 basic parts of the web that we see in our browser: HTML, Javascript, and CSS.

HTML: What to display, and how it is organised.  Think of this as your document’s content and structure (but not its layout).  Example:

<h1 id="title">
    Native Apps vs. Web Apps: The Great Debate Pt. 3 of 4

This HTML tells your browser to create a heading of class ‘h1’ (heading 1), with the text above, and give that element a name of ‘title’.

Javascript: How it behaves

document.getElementById("title").innerHTML = “Native Apps vs. Web Apps: The Great Debate Pt. 3 of 4”;

This Javascript changes that element named ‘title’ to the text above.

CSS: How to display it.  This is a way for your programmers to keep all the styling information in one place.

h1 { font-family: Helvetica, Arial, sans-serif; }

This CSS tells your browser to display all ‘h1’s in Helvetica if possible, and if not Arial or any kind of sans-serif font.

But this is still way too abstract, right?

Well, I’ve set up a little place where you can have a play with this code here.  Change anything you like, make any mistakes you will.  You can always just hit refresh.  (FYI there’s no point editing the brown text – that’s just comments for explanation.)

Testing and browser compatibility

As promised, here is an example of different browser/device behaviour.

Go to the Google homepage on your computer.  Notice how you don’t need to click inside the text box before you start typing?  That’s because it auto-focusses. Now go to the Google homepage on your mobile.  Chances are you had to tap inside the box before typing.  That’s because Apple and Google think it’s bad user experience for the keyboard to just pop up when you didn’t specifically ask for it by tapping in a text box.  So, if you disagree (and I do), then hold your breath because Google and Apple already made that design decision for you.

In this particular case, Apple and Google agree.  In other cases, they don’t.  And then there’s Internet Explorer.  The idea, and the point of this post, is not to explain every case.  Even scary graphs like this don’t do that.  It’s your web programmers’ job to manage this and tell you what’s possible* and what’s not.  Hopefully this just helps you understand why.

*Note: the autofocus problem does not exist in a PhoneGap app.

So that’s it.  Post your questions below or on Twitter.  As a rest from this series, my next post will be an irresponsible rant.  Unless someone has a kill Lindsay question below…

Featured Photo Credit: Nimbuzz via Compfight cc. Text and recolouring by eltjam.

Join our mailing list

Get new ELTjam posts & updates straight to your inbox.

You'll also get news on our events, training and webinars.

We won't share your data with anyone else, and you can unsubscribe at any time. Here's our privacy policy.

Powered by ConvertKit