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.
Deciding
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 </h1>
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. 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.
Excellent introductory series Lindsay – much appreciated. If I may ask, can you suggest a functioning web app that we can browse. I want to know the extent of what’s currently possible, and what ‘speed’ actually means in practice. Can a web app run simple animations? Are there any beta native functions to assess or are they imminent? Do common, simple ‘fill in’ or ‘matching’ exercises respond swiftly? I understand you don’t want to introduce bias and judgement of sites into the neutral zone of ELTjam, so how about suggesting a handful?
I would suggest browsing Facebook on your mobile’s web browser. Notice the lack of ‘talking heads’ when you chat to people in the web app. That kind of functionality would be very difficult to achieve with HTML5. I also think the Guardian is an example worth looking at, partly because it’s so simple yet suffers from response speed problems.
A web app can run simple animations. Actually they can run more complex animations too. Try these and see if they work on your mobile:
http://isotope.metafizzy.co/
http://david.li/waves/
http://famo.us/ (my favourite – don’t try in firefox, and close the registration window)
Fill and matching exercises can be done in a web app. Cross-browser compatibility, response time, and load time (if there is a lot of code) could all be issues. I suggest researching the HTML5 canvas element.
(I didn’t quite get the beta/native question – let me know if what’s above doesn’t answer your question)
Thanks Lindsay, and sorry to be unclear about the beta/native function. What I meant was: are these functions (microphone, camera etc) completely impossible on webapps, or do you think they’re imminent. If yes, is there anywhere to see them working (in beta).
Hope that’s a bit clearer, though I can guess the answer must be “no”.
I made a small mistake in my last reply. The Guardian mobile site is a good example of a simple web app. The one that functions more slowly is my local rag – http://www.theage.com.au
I understand your question now. I’m sure there is a lot of debate and movement in web circles about this – I don’t know about those details. What I do know is that the getUserMedia API to get, say, access to the camera is not supported by Android or iOS. Try it out for yourself here: http://www.html5rocks.com/en/tutorials/getusermedia/intro/ (scroll down to demo)
You can see what browsers support this functionality here: http://caniuse.com/#search=getUserMedia
My view is that native-like functions will be more supported as HTML5 support improves, but I don’t think it’s a simple path to web apps working like native apps. Think about the security involved with giving access to your contacts for example.
So, let’s say you have this great idea for an app. And now you know that ultimately you want to produce it first as a web app. But before converting it from HTML5 to Phonegap you need to build it first in HTML5. First because obviously you need something to convert and second because you can first do user testing in HTML5 (before paying for conversion). OK, so, here is my question.
For the purposes of user testing is there anything cheaper or easier to build a prototype in before making the step to HTML5 (loaded question)? And second, in your opinion, is it significantly easier (and cheaper) for HTML5 developers to work from a working model than from paper-based flow charts? In all this I am assuming that someone beginning in HTML5 is nowhere nearly as accomplished as someone with 1-2 years in the field and as such will be limited in terms of what he or she can envision for his or her product.
Just a small thing first up – I wouldn’t use the word ‘convert’. I’d say ‘house’. ie house your web app in a Phonegap app.
As for prototyping, yes there are much easier and cheaper ways. I like https://popapp.in/ – you can start with hand-drawn images (and take a photo of them with your phone camera) or you can just make simple mockups and use POP to make them interactive.
Second: yes I think it’s cheaper to work from a working model. However the relationship between the programmers and the one with the vision is key. A prototype is never fully descriptive, coders need to make the right calls about when to infer what’s right and when to check.
Your assumption is correct, yes. I think it would be rare to simply go from prototype to finished product. The first prototype may merely serve as a tool to speak to someone with programming or interface experience.
I would suggest browsing Facebook on your mobile’s web browser. Notice the lack of ‘talking heads’ when you chat to people in the web app. That kind of functionality would be very difficult to achieve with HTML5. I also think the Guardian is an example worth looking at, partly because it’s so simple yet suffers from response speed problems.
A web app can run simple animations. Actually they can run more complex animations too. Try these and see if they work on your mobile:
http://isotope.metafizzy.co/
http://david.li/waves/
http://famo.us/ (my favourite – don’t try in firefox, and close the registration window)
Fill and matching exercises can be done in a web app. Cross-browser compatibility, response time, and load time (if there is a lot of code) could all be issues. I suggest researching the HTML5 canvas element.
(I didn’t quite get the beta/native question – let me know if what’s above doesn’t answer your question)
Here is a good discussion of this whole area if you’d like more:
http://www.html5rocks.com/en/mobile/nativedebate/