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. 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.
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.
MOBILE WEB EXAMPLES
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 tran-spired 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 theplaces 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.
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 restau-rants. 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 devel-oped 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.
UNDERSTANDING NATIVE VERSUS WEB PLATFORMS
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 applica-tions, 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.
PROS AND CONS OF NATIVE VERSUS WEB PLATFORMS
Pros Cons
Exposure and accessibility via an App Store High cost to develop, upgrade, and support Access to native features such as the Camera, Code is deployable to one platform only Contacts, and network conditions Monetization and revenue Dependence on App Store restrictions and submissions 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. Cheap, fast, and easy to build. Performance tends to be an issue with intensive web-site pages running in the mobile browser. Can be deployed to multiple platforms / devices, Debugging and testing becomes hard to do on a with the same code base. mobile device. Easy to perform maintenance. Hard to monetize since there is no App Store. Access to native features via third-party solutions, such Even with PhoneGap, not all native functions are as PhoneGap. available. 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
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 workaroun ds 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.
WEB-TO-NATIVE SOLUTIONS
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 restric-tion 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 platform. 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 gap.com/about/feature) 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 at http://build.phonegap.com. 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.
DEVICES AND OPERATING SYSTEMS
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 com-monly 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% (http://techcrunch.com/2012/01/09/ios-marketshare-up-from-26-in-q3-to-43-in-octnov-2011/).
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”
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.
DESIGN AESTHETICS
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.
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.
IOS DESIGN PATTERNS
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.
ANDROID DESIGN PATTERNS
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.
VIEWPORTS
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: width=320)
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: maximum-scale=0.25) 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: minimum-scale=1.6) Introduction to Mobile Web Development Initial-scale: A floating-point number between the minimum-scale and maximum-scale. 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:user-saleable=False) 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;
minimum-scale=1.0;
user-saleable=false;”/>
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.
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.
ORIENTATIONS
Most modern mobile devices provide numerous ways to view a web page. Luckily for devel-opers, 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” :
“resize”;
window.addEventListener(orientationEvent, function() {
alert(‘We just detected a screen resolution change!’);
}, false);
</script>
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.
FONTS
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. 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.
<html>
<head>
<link rel=”stylesheet” type=”text/css”
href=”http://fonts.googleapis.com/css?family=Tangerine”>
<style>
body {
font-family: ‘Tangerine’, serif;
font-size: 48px;
}
</style>
</head>
<body>
<div>This is test of Google Web Fonts!</div>
</body>
</html>
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’),
url(‘http://themes.googleusercontent.com/static/fonts/tangerine/v3/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.