Visitor Monitoring Developing for the Ever-Changing Mobile Web | Keynote

Developing for the Ever-Changing Mobile Web

A conversation with author Maximiliano Firtman

Just six years ago, mention of the “mobile Web” would be met with a blank stare; for practical purposes, it just didn’t exist. Today, you can’t have a conversation with a marketer or website owner without some discussion about the best way to get content onto mobile devices. Developer and author Maximiliano Firtman pulled together a wealth of information and guidance on that topic in his book, Programming the Mobile Web, first published in 2010. A completely updated second edition is just off the press.Benchmark recently caught up with Maximiliano to learn how the mobile Web has changed and is changing, and to get a few free tips from the new book.

Benchmark: When will the new, second edition of Programming the Mobile Web be available?

Maximiliano Firtman: The Kindle edition is available now. The paperback should be available in early April.

Benchmark: Can you give us a quick overview of the book?

Maximiliano Firtman: Programming the Mobile Web is for Web developers, mainly. Basically the book is a reference guide — it’s not a book for learning HTML from scratch. It’s for developers who want to understand the mobile environment, how complex it is, and all the things you need to know — coding, markups, tools. I have replaced more than half of the book, and it is still 250 pages more than the first edition.

Benchmark: What do you think are the most important things that have changed in the three years since the first edition was published?

Maximiliano Firtman: If I had to pick just one thing, it would be HTML5, but there are a couple of new concepts. We have platform changes — we have Google Chrome now on the mobile side, we have more tablets, we have BlackBerry 10. We have new platforms, new tools, new APIs. We can access more hardware, like the accelerometer, and the battery.

Benchmark: What, in your opinion, is the best thing that’s happened to the mobile Web since your last edition of the book?

Maximiliano Firtman: The best thing? Maybe vendors realizing that they need to support Web developers, not only native developers. That means better tools, better information. I’m feeling that things started to change last year. I believe that’s the best thing.

Benchmark: And the worst thing?

Maximiliano Firtman: The worst part is that this is still a market that changes so fast that you need to realize that it’s not like the ‘normal’ Web, and it’s not like when you work with only one platform. New doors are being opened all the time. Now we have five versions of iOS, and we have Blackberry 10.

Benchmark: Where are you landing in the whole native versus Web versus hybrid discussion? We know that last year, for example, Facebook backed off of its strong dependence on HTML 5 and reintroduced native apps for the major platforms. Do you think that’s particularly significant?

Maximiliano Firtman: Let’s split the answer into two parts. First, by native I mean using the native SDK, like C, C++, Objective-C, Java — they will always be faster than the Web, right? There is no discussion there.

The other thing is that sometimes we are discussing 15 milliseconds versus 20 milliseconds, and sometimes we are discussing three seconds versus one second. So on the first difference, there is no real UX problem. Only when you’re talking about seconds, or even hundreds of milliseconds, are we talking about a problem.

And Facebook had problems in that way. But besides that, the second part of the answer is that it’s not true that Facebook has really changed the whole app from HTML — from a hybrid — to fully native. It’s still hybrid and that’s something that the Facebook team has said, even in conferences and on their blog.

So basically the Facebook app for iOS and Android today is still using WebView. That means they’re still using HTML5. They have replaced the main view, the timeline, from WebView to a native implementation. But the thing that is coming from the server is still HTML. And some other parts of the UI are still WebView.

So this is still a hybrid, but they have replaced the main problem, which was the timeline. The speed increase was around 2x, so it’s twice fast as the previous version. And that’s with twice the traffic. These people care about performance — performance is really important.

I will not tell you that HTML 5 should be used always. It depends on the person, it depends on what you are doing.

I’m not sure if you’re aware of the Sencha team, but they have created FastBook, a Facebook version from scratch in HTML to prove to Facebook that HTML5 wasn’t the problem. It was a problem of how it was implemented.

So FastBook is using some hacks to improve HTML5 performance, and basically it performs exactly the same as a new, true native app. So sometimes it’s not the technology you are using, it’s how you are using it.

Both are going to co-exist for a while. The Facebook website is HTML5. More than 50 percent of Facebook users on mobile are using the mobile website, not the app, and that’s only HTML5.

So that means that the HTML5 version of Facebook is still used more than native apps by mobile users. The media took just a part of what Mark Zuckerberg said. But it’s true, HTML5 is a problem on some platforms — basically Android 2-point-something.

So WebView in Android 2 is not good, really — it’s not good enough for an app that is being used by hundreds of millions of people. If Facebook can afford creating and maintaining different native apps, that’s okay. I’m not against that.

But that’s not the situation for all the apps or all the companies out there.

Benchmark: Responsive design is obviously a big new topic since your last edition came out. What’s your point of view on responsive design and how did you deal with it in the book?

Maximiliano Firtman: My vision is that some people are seeing responsive design as the ‘only’ solution to follow. Some designers want just one solution —they don’t want to understand the whole picture.

I have to say that creating one version of your website or your app for desktop, smartphones, feature phones, smart TVs, tablets — sometimes it’s not a good idea. Why? Because of performance. Again, performance is the biggest problem on mobile devices because of the wireless networks, because of the mobile CPUs, because of latency.

When you’re delivering the same HTML for desktop and tablets, that means lots of frameworks and hacks are still necessary, maybe for IE7 or IE8. And then you’re delivering the same document for a smartphone, even if you are rearranging and changing the layout. I don’t think that’s a good idea.

There are some specific scenarios and websites where your content is OK to be served as one HTML. But for complex websites, it’s probably not a good idea. You can try a mix between responsive design on server-side components — so server-side, you can string the HTML or select which parts you are going to deliver to the client.

And of course, I like responsive design, for example, when you are creating the mobile version. You can use responsive design to adapt to different contexts, like different screen sizes, different screen densities, different screen aspects, and different screen orientations. That’s okay.

But I try not to be so enthusiastic about responsive design as the ‘one Web’ solution. Because it’s an ideal, right? But in the real world, when we are seeing how mobile phones perform and how important performance is there, it’s not always the right solution.

Benchmark: So what you’re saying, though, is that while it may not be a great universal solution to cross desktop and tablet and phones, if you’re looking at simply a mobile solution, it could have utility in terms of being able to adapt to the smaller nuances of screen size in an area where everybody is dealing with the same bandwidth restraints and latency, et cetera.

Maximiliano Firtman: Yes. I’m saying that crossing desktop and mobile is not always a good solution. There are some specific scenarios where it’s okay and you’re not harming mobile performance. But as a general solution, to use responsive design to serve one HTML for everybody, maybe that’s not a good idea yet. Maybe in 10 years it’ll be a good idea. But today, I’m not seeing that as the big solution.

Benchmark: Okay. We have some questions from our technical staff, starting with this one: When approaching responsive design, many developers pick JavaScript frameworks or toolkits, like Bootstrap from Twitter or Foundation from ZURB. Which of these many platforms are developers using more of? What impact do you think that the JavaScript framework could have on the download time on a mobile device?

Maximiliano Firtman: Which of these frameworks are developers using more? I’m not seeing one of these particular frameworks as the one that everybody’s using. I would say on mobile websites or mobile apps, you should try to avoid frameworks by default, and then try to see where a framework fits. Because if you start every site with a framework — because you’re used to it or because it’s the thing you feel you need to do at the time — maybe it’s a problem.

 It's not just the download time that’s a problem. You need to think about the execution time, because even if you are not using the whole framework, the whole framework needs to be parsed by the browser.

Even if it’s cached, every time they are reloading the page or changing pages, the whole framework needs to be reparsed by the browser. And that means execution time, and that uses battery.

So you should use frameworks with care, that’s my advice here.

Benchmark: OK, and to follow-up: As more and more logic ends up being executed in the browser, the JavaScript and front-end code bases — like those ones you just talked about — grow larger and more difficult to maintain.

As a way to solve this issue, developers have been turning to MVC frameworks, which promise increased productivity and maintainable code — for example Backbone, AngularJS, Ember.js, et cetera. Would you recommend using these frameworks? How do you think these affect maintainability and also the testing side of mobile Web applications or sites?

Maximiliano Firtman: Let’s start by saying that MVC is a design pattern, not a framework. So that means that the MVC pattern is useful when you have a medium to large app. So MVC will make your app on your website more maintainable by default.

Then you can decide to create your own MVC micro framework. Or use one of the frameworks that are out there. Again, it’s the same answer as the previous question.

First, there are lots of drawbacks to frameworks that are not mobile-optimized. They have a lot of features that, on the desktop, don’t cause any harm. But on mobile, having lots of features —more than you’re going to use — is a problem.

Benchmark: Since the last edition of your book, have there been any changes in the way that you view mobile testing? What best practices do you recommend in your new book?

Maximiliano Firtman: Mobile testing has, let’s say, grown a lot. We have new tools available, such as remote debugging, from the vendors. So that’s Safari for iOS, Google Chrome, BlackBerry 10, Firefox, and Opera until they moved to Webkit. So basically, you can debug your apps from your machine. And for the others, we are still, let’s say, waiting for the best solution.

And companies like Keynote DeviceAnywhere are offering new solutions, like their free solution where you can test a website on different devices for free for 10-minute sessions.

Benchmark: As far as using real devices or emulators for testing, do you think there’s an ideal mix where you may want to use an emulator for X percentage, and real devices for validation? Is there a balancing point?

Maximiliano Firtman: Yes. I can say that you have three levels of testing. So the first testing that most people do is just to use your desktop browser, maybe with some simulation, a feature to simulate the mobile phone. That is useful for seeing problems with your CSS or if you’re having some errors from JavaScript that are affecting both desktop and mobile.

But that’s not good enough, because you don’t have support for most of the mobile-specific features, like the viewport. So then you need to move to something else. And the next level can be emulators.

With emulators, you have official emulators and those from other vendors. Other vendors usually are Webkits with something that looks like Blackberry or looks like an iPhone, but it’s not really the same experience or rendering.

Basically, these tools will help you to see a more realistic rendering of your app and your website. But then you need to go all the way to the third level, and that’s a real device.

You’re going to see real performance there. You are going to use real fingers and real touch to see how smooth your app is, how responsive it is. Sometimes there are APIs like the accelerometer or geo-locating that are not so easy to emulate — you need the real device to see if your app is really working okay.

It’s different levels that you need to test at different stages. Every time you change something, you’re going to start with a vector browser, then jump to an emulator, and then jump to a real device.

And when I’m saying real device, I’m saying a real device in your hands or sometimes it’s a real device through a cloud solution, a remote testing lab.

Benchmark: What changes are you watching in the marketplace that you think will impact the next edition of your book when it comes out? What are you excited or scared about?

Maximiliano Firtman: We have two kinds of things that will impact things in the next three years. One is the screen — and I’m not just talking about resolution. I’m talking about flexible screens, dual screens. We are going to see changes in how we interact with our devices. Flexible screens may be something that we are going to see, maybe not just for smartphones, but with some tablets, like an e-book reader, so it would be like a magazine.

And then of course, we have all the things that we can wear, like Google glasses and all of these kinds of devices. I’m excited about them, but let’s say that I’m still skeptical and I’m not sure if everybody in three or four years is going to use Google glasses or any other vendor glasses. I’m not sure how the market’s going to react to these. If I am the market, maybe it’s going to happen, because I’m excited about them. But I’m not the market.

So it’s glasses and wearable devices or watches with flexible screens. What I’m seeing is that kind of stuff is going to happen somehow, and that means that we are going to see more push-based services, and that means that your data needs to be prepared for that. It won’t just be HTML on a website; we need to prepare every service, all the data you have to be served in different ways.

The information we have on Google glasses right now, it’s called a mirror API, so it’s a service-based API. It seems like everything is going to be service-based. Preparing your data for the future is something that I’m excited about.

Benchmark: And our readers will be excited to read the new edition of Programming the Mobile Web. Congratulations and thank you for your time.


About Maximiliano Firtman

Maximiliano Firtman is a Web developer, consultant, author and trainer. He is author of Programming the Mobile Weband jQuery Mobile: Up & Running. He is a Nokia Developer Champion, an Adobe Community Champion, and a BlackBerry Elite developer. Firtman’s home base is Argentina, but he often travels the world for speaking and training engagements.

Back to Top