ABOUT 10 YEARS AGO, few people had a
mobile phone, and if they did, the phone did not
have a mobile web browser. Fast-forward to 2012.
Almost 30 percent of the world’s population now
has some mobile device that enables them to
browse the Internet, chat, or send text messages
lab/2011/11/smartphones-featurephones/). Millions of people depend on their
phones, not only as a device in which to hold
conversations, but also to search, discover, and
learn about new things while on the go.
With the total population of smartphones rising,
businesses should be conscious about this
opportunity to reach new customers. Once
considered a luxury device, the smartphone is
now readily available on most mobile networks at
a reasonable price. In some areas, such as the
United States, people use their cell phones as
their main phone lines instead of the once
common landlines.
More and more people are browsing the web
from their mobile phones, and businesses need to
find a way to reach new customers by making
their websites, now commonly known as “web
apps,” mobile friendly. Most companies develop
websites for a desktop experience first; it’s hard
for them to go back and rebuild the same
experience for the mobile platform.
This chapter discusses relevant background
information about devices and design patterns
for your mobile web app. It’s important to
understand these concepts at the start so you
don’t have to backtrack and redevelop your
application to make it conform to the design
standards for each operating system.
PA R T I • Introduction to HTML5/JS/CSS
You also learn some new techniques to conquer device orientation, viewports, and custom
fonts within mobile web application. Understanding these topics is essential to creating a great
experience for your users. In addition, this chapter explores other popular mobile applications
to provide guidance on the best practices and inspirations for your mobile web app.
Most people commonly think that it’s very difficult to build a mobile website. The fact is that a
mobile web browser has many tools and features that most people don’t know exist. At the
conclusion of this book, you will understand the concepts behind mobile web development
and be able to design and develop your own web app using the latest technologies very easily.
You can learn and draw inspiration from a plethora of mobile websites. Sometimes it’s even
hard to see the difference between mobile web apps and native applications. The following
examples demonstrate what you can do with the mobile web.
Facebook: Facebook’s user interface (UI) changed a lot over the last six to eight months,
but its developers are committed to providing the best user experience no matter what
device is being used. With a combination of CSS and HTML5 elements, Facebook
developers were able to mask their native iPhone app to look similar to their web app.
Facebook uses the geolocation element in HTML5 to grab your location and help you
check into your favorite spots. To help the website load faster, the user uses caching on
the browser HTML5. I touch on these features later in the book and explain how to use
them in your own applications. The difference between the Facebook web app and native
applications is so minimal that many users can’t tell the difference. When this occurs, you
know you’ve done your job right.
Twitter: Twitter’s UIs also changed significantly since launching in 2008. In fact, when
the service first launched there was no official mobile app to use this service. Developers
used the Application Programming Interface (API) from Twitter to develop the first
Twitter applications that became popular on the market. Realizing that sharing 140
characters is important on both the desktop and the mobile device, Twitter changed the
strategy to begin to develop mobile apps and websites to increase growth. What transpired was a brand-new mobile website that mimics the experience of browsing Twitter
on a desktop computer. Twitter uses HTML5 features like off-line access, which gives you
the capability to view tweets when you aren’t connected to the Internet. They also use
CSS3 transitions to ease navigation between pages. Also, just like Facebook, Twitter
allows you to tag your location when you tweet, thus using the HTML5 geolocation
feature. Since Twitter wasn’t a mobile application when it first launched, it does have to
compete with a bunch of native mobile applications maybe by third parties. This has
allowed Twitter to acquire many companies to help build their current platform.
Foursquare: Already having a flagship product in their native iPhone application,
foursquare decided to make a simple web app to help people find information about the
places they go. Foursquare uses HTML5 geolocation and input types that enable users to
automatically call venues by clicking the phone number listed in the description.
C H A P T E R 1 • Introduction to Mobile Web Development
Financial Times: Financial Times was originally a native application in the App Store
when it decided it wanted to charge a subscription fee outside of iTunes. Because that
didn’t comply with the iTunes Terms Of Service, it had to be removed from the App
Store. Instead of trying to work with iTunes, Financial Times decided to make their own
HTML5 web app, which worked on every single platform. There was no need to develop
a different platform for every phone. The Financial Times app pushed the boundaries of
web applications by using HTML5 local storage, which allowed them to store and cache
content in the background. It also incorporated off-line elements, enabling users to
browse the web app when they aren’t connected to the Internet.
Yelp: Similar to foursquare, Yelp provides a mobile website that allows users to quickly
access a favorite spot, and get ratings, directions, and more information about restaurants. Yelp uses geolocation as well, including Google maps, to see what places are nearby.
It also uses touch events to highlight rows when you select them, which is similar to
native experience.
Untappd: Okay. I’m a little biased, because I created Untappd. Still, I think it’s a great use
of mobile technologies in the platform. Unlike other applications, Untappd was developed as a mobile first. This allowed us to see what we could and couldn’t do with the
platform. It also allowed us to reach multiple devices on day one. This helped us grow the
platform and the service by gathering feedback from multiple users on multiple devices.
Untappd uses local storage geolocation and other HTML5/CSS3 that attempt to blend the
line between native and web.
Many people do not understand the difference between the native and web application. The
main difference is that a native application is downloaded from an App Store and is written in
different languages than web applications. Every device has its own proprietary language that
is used to power the phone. For example, on the iPhone the language of choice is Objective-C;
with Android devices, you program via Java. This is one of the downsides of native applications, because it requires you to hire a developer to build two different applications. That can
be very costly. A common myth is that web applications don’t look anything like their
counterparts in the native world; yet with modern technologies, including HTML5 ESS3, and
JavaScript, you have the power and the tools to make your applications look and feel native.
Table 1-1 lists many of the pros and cons associated with the web or native platform. :
Table 1-1
Advantages and disadvantages of native platforms
Exposure and accessibility via an App Store
High cost to develop, upgrade, and support
Access to native features such as the Camera,
Contacts, and network conditions
Code is deployable to one platform only
Monetization and revenue
Dependence on App Store restrictions and submissions
PA R T I • Introduction to HTML5/JS/CSS
When choosing between a native and a web app, it’s important to figure out your strategy for
the application. If you’re open to charging users for your application as a service, a native
platform might work. There are many ways to get around this, including subscription fees;
however, the base application will always be available on the web for free. However, some
applications inhibit different pricing models that can charge at every level.
On the con side, developing an application for a native platform is very costly to build and to
maintain. A common misconception is that once the application is built, you’re done putting
money into the application. This is wrong, because you have to continually update your
application and that requires keeping a developer on retainer. Another negative side to native
is its dependence upon the App Store or marketplace. When submitting your app to a store or
marketplace, you are subject to all the restrictions that the company decides to place on
applications. This means that at any time the employer application can stop you from making
money and stop people from downloading your application. In addition, most App Store only
give a portion of sales on your app. For example, Apple App Store and Google Play both take
10 percent of sales and the rest goes to the developer. While this may seem small, overtime
this can grow at a rapid rate.
Table 1-2 lists the pros and cons associated with using the web platform for your apps.
Table 1-2
Advantages and disadvantages of mobile web platforms
Cheap, fast, and easy to build.
Performance tends to be an issue with intensive website pages running in the mobile browser.
Can be deployed to multiple platforms / devices,
with the same code base.
Debugging and testing becomes hard to do on a
mobile device.
Easy to perform maintenance.
Hard to monetize since there is no App Store.
Access to native features via third-party solutions, such
as PhoneGap.
Even with PhoneGap, not all native functions are
Developing an application for the web can be rewarding. Making use of HTML5, CSS3, and
JavaScript allows you to develop your application easily. Since these are common languages,
the price of the application will be decreased. In addition, one application can be used across
multiple platforms. This means your web app can work on an iPhone, Android, or BlackBerry
device—all with one code base.
A downside to creating apps on the web platform is in the area of debugging and testing.
Testing your web app in a desktop browser may lead to quick fixes on bugs; however, testing
in a mobile emulator provides a more accurate assessment of how your web app performs. For
example, with the desktop web browser the performances match the speed of the computer;
on a mobile phone, however, your resources are strictly limited. Things like CSS3 transitions,
which are a great way to show navigation between pages, require a great deal of memory to
process. Pay attention to memory allocation; it is possible your web application will crash
C H A P T E R 1 • Introduction to Mobile Web Development
some browsers. While you have this situation with native applications, every Web Browser
appears to perform different while native OS controls may be consistent across devices. For
example, the web browsers in Android 4.0.x and Android 4.1 are very different and require
different levels of debugging to get your content to display correctly.
In addition, the on-click event on the desktop web browser performs much faster than a tap
on a mobile device. This is because the mobile browser sometimes waits to see if you’re
actually tapping a button or dragging your finger up and down the screen. This can cause a
small delay when you tap links, buttons, and other attributes on your mobile web app. Luckily,
there are workarounds to fix this problem. (I discuss them later in this book.). There are also
other tips to make your web app feel more native including Home Screen and Full App modes
on iOS and Android. These allow your web application to run without the chrome of the
browser window.
Some third-party solutions allow you to bring your web application to the native platform.
This enables you to access native features that you aren’t able to get when using your web
browser. The camera is the most common feature that you aren’t able to access via the web.
Mobile Safari users are not allowed to upload files to the web browser; however, this restriction is lifted on other platforms. This inconsistency leads to problems when developing your
application. It’s important not that you can use file input types on Android to upload files file
your file system, but it can’t capture a current photo from your camera.
One of the most popular third-party solutions is called PhoneGap. This is the only open
source mobile framework that supports seven platforms: iOS, Android, BlackBerry, webOS,
Windows Phone 7, Symbian, and Bada. PhoneGap breaks down their API support into 10
different native APIs. This allows users to easily connect to the operating system and access
the camera network, notifications, storage, files, and a whole lot more. The documentation is
straightforward, easy to use, and can help you transition your web application to a native
Many applications out there use PhoneGap to deliver their native platform to the consumer.
One example is Untappd—where it took its web application and transformed it into a
streamlined new application that allows users to take pictures of their beer and include them
when they check in. Untappd was able to port its application to Android and iOS within a
matter of months. The responses from the application were so tremendous, registrations for
the month they released their native app were 10 times the norm. With PhoneGap, you can
deploy your code to 10 different platforms. However, not every feature is consistent across
every platform. PhoneGap has a great chart that explain all the features (http://phone of each platform. It’s important to note that while you can use
the same code to deploy to 10 different platforms, deployment of these apps to their stores
might require additional software and steps. PhoneGap attempts to solve this problem by
offering PhoneGap Build, which allows you to send your application code to PhoneGap Build
which then provides you with app-store ready files. You can find more about PhoneGap build
PA R T I • Introduction to HTML5/JS/CSS
Other solutions out there provide the same experiences as PhoneGap, but in our experience,
PhoneGap has the best documentation for anyone to pick up and start coding. Pretty soon,
people will be calling you an ILS Android developer when all you’ve done is code in HTML5,
JS, and CSS3.
When developing for mobile, every developer must understand the number of devices an
app needs to support. On a native platform, you can restrict devices based on the operating
system that it’s running on. On a mobile app, however, you don’t have that luxury. You can
detect the type of browser the user has; but you still might not know which device he or she
is running. This is why it’s very important to understand the different types of devices and
operating systems. That knowledge will make your life a whole lot easier when developing
for mobile.
iOS: The iOS platform is a writer operating system from Apple. As of this time, the most
current release is IOS 5.0.1. iOS runs on the iPod touch, iPhone, and iPad. One of the
great things about the iOS platform is it is limited to two screen resolution sizes. All iOS
devices come preinstalled with Mobile Safari, a WebKit browser. On Mobile Safari, any
file upload control is disabled, preventing the user from uploading any files on a website.
Prior to version 5, developers could not use overflow scroll elements, which are commonly used to create fixed top and bottom navigational bars. With the most recent
release, web applications have become much more native with this new CSS element.
Between October and November 2011, iOS market share rose from 26% to 43%
Android: The Android platform is available on a wide range of phones and is copyrighted
by Google. It is an open source operating system, which means many phone designers
and developers can take it and customize it to their own needs. A prime example of this is
the Amazon Fire, which runs a custom build of Android, codename “Gingerbread,”
which is version 2.33. At the time of writing this book, the latest release was codename
“Ice Cream Sandwich,” version 4.0. All Android devices come with a standard WebKit
browser. In version 1.5, developers could use overflow scroll elements to maintain a static
header and footer. On the negative side, Android has multiple devices that run on this
platform. With large and small screen resolutions, virtual and physical keyboards, and a
native Back button, designing and developing for the Android platform can be a daunting
task. Luckily, the Android emulator enables you to view your app at multiple screen sizes
and with various operator versions. The emulator provides a great way to see what your
app looks like on a phone. Android holds approximately 47% of the market share as of
third quarter 2011. It’s also important to note that since Android is an open-source
platform, phone manufactures take the code and create custom versions of it to fit their
devices and the service provider. This creates greater fragmentation, which can result in
two different types of operating systems on the same phone. Google does offer the
Samsung Galaxy, which is known by the developer community as “Vanilla Android”
C H A P T E R 1 • Introduction to Mobile Web Development
which means that is not altered in any way by the device creator. This fragmentation leads
to many phones not being able to update to newest version. The majority of Android
devise are still on 2.3.x which is almost two full version releases behind the latest release
(Ice Cream Sandwich) at 4.0.x.
BlackBerry: BlackBerry is often considered the third most popular smartphone. Like
Android, BlackBerry has many different devices with many different screen sizes. Many
BlackBerry devices have a physical keyboard with trackball. Recently, the company
introduced touchscreen devices with virtual keyboards. As of BlackBerry OS6, all
BlackBerry devices come loaded with a WebKit browser, which makes life a lot easier
when developing for this platform. Prior to this version, all BlackBerry devices came with
a non-WebKit browser. That said, most web apps today do not support anything lower
than BlackBerry OS6.
WebOS: WebOS is a platform that was designed and developed by Palm. Palm was
acquired by HP in 2009 and has been committed to developing new phones to challenge
Android, iOS, and BlackBerry. In 2011, HP decided to provide webOS as an open-source
operating system with the hope that it would be an alternative to the Android for phone
manufacturers. The most current version of webOS is 3.0.4. As of WebOS 2.0, all
HTML5/CSS3 features are present in their WebKit browser.
Windows Phone: In 2010, Microsoft wanted in on the mobile phone market and
introduced a brand-new phone based on their operating system, called Windows Phone.
The operating system that powers the phone is Windows CE. Unfortunately, this meant
that the browser installed on the phone with Internet Explorer 7, while the current
release is Internet Explorer 9. This left web developers struggling with how to design and
develop for the platform because of lack of support for HTML5 and CSS3. In February
2011, Microsoft announced the release of the next version of the Windows Phone,
codenamed “Mango.” This update was significant because it allowed developers to access
HTML5 and CSS3 features in the browser. However, with the newest version of Windows,
phone developers are still unable to access some CSS3 features, including gradients. In
third quarter 2011, the Nelson report of U.S. market share for Windows Phone 7 was
only 1.2%.
The devices in this list are not the only ones out there, but they are the most common. When
developing your mobile app for devices, the key thing to determine is whether the mobile
device has support for modern browsers. Without this, you lack the basic HTML5 and CSS3
features that will make your app stand out. As we discuss later, there are many ways to
determine users’ browser agents and redirect them to a low-resolution version of your website
if need be.
The premise of mobile web development theory is to keep one code base across multiple
platforms. Still, it is important to look at different design aesthetics that power the differences
between each device. By paying attention to the details and designing your app to look and
feel like a native app on a platform, you provide a much better experience for your users.
PA R T I • Introduction to HTML5/JS/CSS
When designing for mobile web, you need to account for the bandwidth limitations of cellular
networks. Certain processes may take no time at all to complete on a desktop web browser,
but everything is different on a mobile device. As a best practice, always display the progress
of some action on the screen. This can be done with a loading symbol or other methodologies.
Without seeing this loading box, users may get discouraged with your app if they do not know
whether it is currently loading.
With iOS, typically most applications have two navigation bars: one at the top indicating the
page you’re currently on, and a navigation bar at the bottom, which has links to different
pages. Prior to iOS5, there was no way to keep your top and bottom navigation bars static
when the user scrolled the inner content between them. Now, by using the CSS3 property,
overflow-scroll: touch, developers have the option to create native-like scrolling
within their web applications.
On Android devices, the general design pattern is to have an action bar at the top of the
screen followed by a navigation bar immediately below it. Android devices typically lack a
bottom navigation bar like those on iOS. This is because most Android devices have native
buttons on the bottom part of their devices. When the navigation bar is placed on the bottom
of the screen, Android users tend to hit them by mistake when pressing the native buttons on
the actual device.
Typically with a webpage on a mobile device, users are going to pinch and zoom to their
heart’s delight. When developing mobile applications, you use an HTML meta tag called
viewport. This enables you to set a maximum or minimum width, depending on screen
resolution, so the user cannot pinch and zoom on your web app. The viewport is set at the
<HEAD> in an HTML document and supports the properties discussed in the following list:
Width: The pixel width of your web application. The default value is 980. (Example:
Height: The pixel height of your web application. (Example: height=320)
Maximum-scale: A floating-point number between 0 and 10 to which defined that
largest scale on your web application. The default value is 0.25. (Example:
Minimum-scale: A floating-point number between 0 and 10 to which defined that
smallest scale on your web application. The default value is 1.6. (Example:
C H A P T E R 1 • Introduction to Mobile Web Development
Initial-scale: A floating-point number between the minimum-scale and maximum-scale.
(Example: initial-scale=1.0)
User-saleable: A Boolean result that defines if the user is able to scale the size of the
screen (for example, by pinch or zoom). The default value is True. (Example:
It’s important to note that all width and height settings can be defined by device-width,
which enables the HTML5 to adapt the width to the device’s screen size. Following is an
example of a viewpoint tag that can be used in a mobile web application.
<meta name=”viewport”
content=”width=device-width; initial-scale=1.0; maximum-scale=1.0;
The preceding code sets the document’s width to be the device’s screen resolution. This is
useful because users may decide to load the application onto a device such as a tablet, which
has a large screen resolution. The scale is set to 1, which means it will scale to the device
width. A good way to visualize scale is to consider it a multiplier against your width. (See
Figure 1-1.)
Figure 1-1: If you set your initial scale to 2.0, your app is increased
by two.
PA R T I • Introduction to HTML5/JS/CSS
The user-saleable property, by default, is set to True. For most web applications, you
don’t want the user to be able to pinch and zoom the content. This is because most native
applications do not use this particular property; and their interface design scales to the
current device. After all, if you correctly set your initial-scale, there is no need for a
user to pinch and zoom on the app: Everything scales to the screen width. It’s important to
note that this viewport applies only to the initial page load, and can be changed by the user.
Once the user reloads the device it returns to the last-known zoom.
Most modern mobile devices provide numerous ways to view a web page. Luckily for developers, the operating system of the phone rotates the web browser depending on if the phone
is in a horizontal or portrait mode. It’s the responsibility of the developer, however, to handle
these events and make changes to CSS as needed.
<script type=”text/javascript” language=”Javascript”>
var supportsOrientationChange = “onorientationchange” in window,
orientationEvent = supportsOrientationChange ? “orientationchange” :
window.addEventListener(orientationEvent, function() {
alert(‘We just detected a screen resolution change!’);
}, false);
This code adds a document listener for a specific event that occurs across mobile browsers.
Unfortunately, this event is not standard so you need to detect which event is on the device
you’re using. The first line the JavaScript allows you to detect if the events onorientation
change are valid in the current window. If the browser supports this event, then use it;
otherwise, the event name will be orientationchange or resize.
After you determine the name of the events of the device, set an event listener. It’s enough to
know that the browser logs certain events for JavaScript to pick up and perform an action
upon. In this situation, when the device is rotated, the browser emits an event that JavaScript
picks up. Every time this event takes place, you are displaying an alert that indicates it has
detected an orientation change. In the previous example, you can replace this alert with
something that is more useful based on your situation.
With older browsers, fonts are pre-installed as part of the operating system. Currently, the
standard fonts vary across mobile devices. With modern browsers, developers have a wide
range of tools to display different fonts, depending on the design of their web app. These tools
use JavaScript to replace the contents of an HTML element to a special property that is
controlled by CSS to display the custom fonts.
C H A P T E R 1 • Introduction to Mobile Web Development
For example, Google Web Fonts API provides an easy way to quickly change the default font
to something that matches your style and theme. Google Web Fonts have a large range of
fonts to choose from.
<link rel=”stylesheet” type=”text/css”
body {
font-family: ‘Tangerine’, serif;
font-size: 48px;
<div>This is test of Google Web Fonts!</div>
In this example, a CSS file from Google, with a query string indentifying what type of font
you would like to use is loaded in the HEAD section. When opening that link in your browser,
you get the following syntax:
@font-face {
font-family: ‘Tangerine’;
font-style: normal;
font-weight: normal;
src: local(‘Tangerine’),
HGfsyCL5WASpHOFnouG-RD8E0i7KZn-EPnyo3HZu7kw.woff’) format(‘woff’);
Google uses a CSS3 property called @font-face, which allows your HTML document to
contain special fonts that are not locally installed on the users’ machine or device. Once
loaded, the special fonts display on the supporting browser. For mobile devices, I recommend
that you download these fonts to cache on your own site to maximize performance. It’s
important to note the Google Fonts API is compatible with all modern browsers, including
Internet Explorer 6 and higher. It’s important note that iOS supports only SVG fonts (which
Google Fonts supports). However, other font libraries may not be supported. While Google
Fonts is easy and supported, you can only use fonts that they have, so you can’t have custom
fonts that you may have purchased or downloaded elsewhere.
A great resource for @font-face is the fontsquirrel @font-face generate tool
( which can
help you generate the syntax for @font-face in your CSS file.
PA R T I • Introduction to HTML5/JS/CSS
In this chapter we discussed an overview of mobile devices, platforms and different ways of
interacting with the browser. In addition we discussed:
Mobile web and native platforms
Native versus web pros and cons
Custom fonts
OS design patterns