Android Masterclass final: Building Mobile web sites


Building Mobile Web Sites

There are around 500 million smartphones out there in the world (early 2012). Android is growing at 850000 device activations per day. Apple’s iOS devices are in the range of 500000 per day and
a recent study by Gartner suggest that within the next 2 years more people will use mobile devices than traditional computers to go online. Furthermore web only companies like Facebook and Google are already reporting that well over a third of their usage is from mobile devices. If you are reading this article these numbers may not be surprising but the stunning part is that only a small fraction of web sites are optimized for mobile. The reasons are varied but the short version is that web capable mobile devices are spreading far faster than anticipated — and most companies have just started to consider mobile optimization a core requirement. The good news is that this gap creates opportunity for people with the skills to create a mobile optimized web experience.

The skills tools and techniques required to create a web page are quite mature. However many of these techniques were conceived and designed for use on larger screens with a keyboard and a mouse rather than for a small screen with a touch interface. Thankfully over the last 5 years many of the early adopters of mobile web identified a number of useful patterns and techniques.

In this master class we look at the core areas to cover when create a mobile optimized web page. The article is presented with the assumption that the reader has a basic working knowledge of HTML and CSS. We will discuss the accepted best practices and highlight issues that one should address when creating mobile web sites rather than purely presenting code snippets. Additionally a typical question that arises when designing mobile application is — “Should we build a native application or create a mobile optimized web site?”. This article ends with some guidance on how to answer this question when it arises in your own projects. All resources used in the master class series are available on GitHub at http://github.com/rvasa/medroid.

A Short Recap

Before getting into the details of mobile web here is a recap of the core Android concepts covered in the previous masterclasses. An Android application is made up of Activities that map to an individual window / screen of functionality in an application. We place UI components (called Views) inside a container called a layout and attach this layout container to an activity. The UI is described in an XML file and paired with a Java class that provides the interactivity. The Android framework mandates conventions which specify a set of folders that every Android project must have. The conventions specify location of resource such as images and data for the development tools to process them and generate references to use these resources from within the XML UI description files and Java code. The framework is designed to help developers construct UI that works on devices with varying screen sizes with minimal pain.

Every activity in an Android application has its own life cycle and activities communicate between each other using short messages known as intents. The Android architecture allows any application to send a message to another other application via intents. This flexibility permits developers to make use of functionality provided by other applications with minimal pain. For instance we can broadcast a message requesting display of a web page and all registered browsers will respond – the user then has the choice of selecting the application that they want to use (we will make specific use of this feature in this master class).

As elaborated in previous master class articles Android applications can make use of Maps via the use of Google APIs that are available as a free add-on from within the Eclipse IDE. We can also build applications that incorporate image galleries video and audio by using the media APIs provided as part of the SDK. The platform also provides us with a rich data persistence layer including a light weight database management system that allows us to use SQL. Furthermore as discussed in the previous master class Android allows us to style and theme applications globally as well as at the activity level.

Mobile Web Vs Traditional Web

Many smartphone users initially start by having fun with games and the new apps. However as soon as they start exploring the web on their new devices they find the whole experience frustrating. An example of how a traditional web site will render on a mobile phone is shown in Figure 1. In effect the entire web page will render in a 3″ or a 4″ physical screen and feels like a caricature rather than a site that provides useful information. The only way a user can use these unoptimized sites is via a pinch-zoom and then wandering around to find what they want. If the user is familiar with the web page they may be able to issue sufficient touch gestures and squint their eyes into various angles to get some information out of it. Of course a safe assumption is that most users will move on to a competitor that offers an optimal mobile web experience.

Figure 1 – The web page of Australian Securities Exchange (Stock Market) as it will render on a smartphone

The differences between mobile web and traditional web boil down to the following:

  • There are many different web browsers for the mobile — each of them with its own personality.These browsers have varying levels of maturity and support web standards ever so differently. More importantly many users never update the browser or the operating system of their phone. In fact most users would not even know what an operating system is.
  • Mobile devices are smaller and also slower. In fact much slower than a traditional computer if they have to render a complex page.
  • There is no physical keyboard and we all have fat fingers (compared to a mouse pointer)
  • There is a significant font size difference in what we can read on screen and what we need to touch. We often can read a 14 pt font but will not be able to touch a hyper-link in that size accurately especially if there are 3 links nearby.
  • Embedded frames and windows that respond to Javascript pose additional challenges because of the nature of touch gestures.
  • The mobile network is comparatively unreliable and the bandwidth varies with signal strength.
  • A good chunk of mobile devices are incapable of Flash and embedded plugin scripts (e.g. Youtube) may not work.

In practice due to these differences a traditional web page will take a long time to load may have links that are just too hard to click may not be able to show embedded videos and most likely will render inaccurately on many devices. The bottom line of course is that the unoptimized website is sending an “off limits” signal to many existing and new users. So what are the key areas that one should address? Is it just a matter of changing the CSS as is generally recommended? The short answers first – ideally you should cut the content down and use a single column layout with mobile optimized images. Also simply switching CSS is insufficient. A more detailed answer to these questions and more is in the sections that follow.

Why do web pages need mobile optimization?

A traditional web page used to be simple back when the web was young (circa 2000). These days a web page may appear quite simple but there is significant amount of detail that the browser has to process and render. The latest version of Firefox ships with a 3D page visualizer that highlightsthis complexity and Figure 2 illustrates the point by showing a 3D break-down of the APC home page. A traditional computer often has the grunt and more importantly the RAM to load all of the objects needed to determine the proper layout for a web page. Unfortunately mobile devices do not have the RAM and only recently have started to carry serious CPU power. So how much RAM do we really need to render a web page? The precise answer will depend on the actual page but a crude benchmark shows that Firefox needed nearly 40Mb of RAM to load and render the non-mobile optimized APC home page. That number may appear quite small but on a mobile phone it is quite a big chunk of the RAM available and very much precious.

Figure 2 – 3D visualization of the APC home page. There is a lot more complexity than is visible to the user.

A critical factor that also needs to be considered is that mobile broadband is not as fast as the wired alternatives and it still comes with a relatively frugal download quota. In practice this means that images have to be optimized to reduce their file size along with their rendering dimensions. We also often need to prune Javascript files that accompany most contemporary web pages. Although theoretically the mobile broadband is just as good as a wired connection in reality smart phones are not as effective when dealing with loading many small files — and it is quite common for many popular web sites to send 50-70 small files as part of a single web page. Mobile broadband is also highly inconsistent with speed variations when the user is moving (like on a train). This inconsistency and variability adds a small amount to the latency for each file downloaded. Together these minor concerns add up and eventually you get a web page that takes about 30 – 40 seconds to load on a mobile phone rather than the 2 seconds it may take on a traditional wired network. In fact load up a non-cached non-mobile optimized web page over WiFi on your smart phone and repeat this on a normal computer (without the adblock plugin). You will be able to see the limitations of the mobile web specifically in terms of the speed with this short experiment and in most cases the traditional computer (even over WiFi) will be faster than a mobile device.

The most obvious feature (a curse and a boon) of a mobile device is its relatively small screen. The implication of this is that the traditional two or three column web page layout just does not work on smart phone even for young eyes (of course it is the classic fail scenario for anyone with a more mature eye sight). Furthermore any link or zone that we want the users to touch has to be fairly large. In practice this means that if a web page has too many hyper-links in close proximity then the user cannot click them without using a zoom-in gesture. Figure 3 illustrates this exact point using the web site of Roget Ebert a well regarded movie critic. The links in the right half of the image cannot be clicked without a pinch-zoom. Unfortunately if your zooming-in skills are in need of practice you are quite likely to click on one of these links unintentionally while attempting a pinch-zoom.

Figure 3 – A web site that illustrates the difficulty of selecting links when they are too close to each other.

 

Mobile Optimized Web Page

Given the constraints discussed so far a mobile optimized web page should have a simple layout make use of mobile optimized images reduce the use of Javascript and ensure that the links are sufficiently separated from one another to minimize accidental clicks. Before we jump in and have a look at some of the technical aspects it is good to start off with a short overview of good practice.

Keep it Quick: Studies on behavior of mobile users show that the typical user tends to look at a mobile site for only a few minutes. This will mean that the design has to ensure that the content is properly targeted for mobile use with small paragraphs of content that make minimal use of images. It also has to rely on a simple layout to speed up rendering and reduce the need for RAM (see Figure 4 that illustrates a mobile optimized web page from NineMSN).

Figure 4 – A mobile optimized web page has minimal rendering complexity and fewer objects.

Fit the Mobile Context: Users tend to use their mobile devices to find information on the go. In practice the design has to be focused to get the user to key information in the least number of steps and also any data input fields should be sufficient large with as many fields as possible automatically filled in. In particular try not to ask the user for too much information and anything that they need to look up from another source other than their memory.

Simplify Navigation and Prioritize Content: The traditional two or three column web page layout model emphasis navigation either at the top of the page or to the left. On a mobile device when you are using a single column layout the best option is to prioritize the core content and move all navigation down to the bottom of the page. In general users tend to look up specific information on their mobile devices rather than use it to graze for information (although it may happen on a long commute). Even when using navigation links it is best to keep the number small — as in well under 10. The other good practice is to reduce the nesting hierarchy of the navigation and to communicate the depth using bread crumbs or similar design hints.

Be thumb friendly: Links should be large and touch friendly. We said that earlier as well — but another design choice is to make the web page single-hand use friendly. That is make the touch zones large enough for the thumb — although this is not always practical.

Seamless Interactions: This aspect is best illustrated with an example. Consider the design of a mobile optimized web site with a shopping cart. In the early days of web commerce when users added a product into their shopping cart they got moved to a different page and had to navigate back to the product listing. These days many sites use AJAX to ensure that they can add a product into the shopping cart in the background. On the mobile a similar AJAX like interaction is needed along with a strong visual cue to confirm the interaction. Additionally it is also important to provide access to the shopping cart icon (with a number next to it to indicate the size) through out the web site.

Visibility and Contrast: Mobile phones are used in a range of lighting conditions. But the light often reflects off the surface much differently to a computer screen as well. In effect this means that we have to select colors that work well in the external (natural) environment rather than under artificial lighting conditions. The other limitation is that the font often has to be larger than on the traditional desktop with an option to potentially change the font size if needed.

We covered the issues facing mobile web as well as suggested good practices. But what are the technical aspects? The short answer is that we need to create a mobile CSS and set the view port carefully. We also have to serve optimized images for mobile devices and be aware of the fact that Flash video may not work on many devices. The rest of this article addresses each of these in some detail.

Switching CSS for Mobile Web Page

The browsers on even older generation smartphones have excellent support for HTML and CSS standards. Hence when creating a web page we can certainly change the styling for mobile devices using a great deal of precision. The typical way to achieve this is via the use of CSS media queries. Currently many web sites use this feature for creating printable pages but this feature can also be used for supporting a mobile device. In fact these queries are powerful enough to allow us to create different style sheets for different mobile screen sizes allowing us to target tablets as well as a range of different screen sizes more precisely.

A CSS media query is shown in the code snippet below and this is inserted into the header section of the HTML document. The link tag is used to connect a HTML page with a CSS style file but the real power is that it also allows the developers to specify rules to select different style files. The code below translate to — if you have a screen with a horizontal resolution equal to or less than 320 pixels then apply the mobile style sheet. If the device has a larger screen this particular line has no effect.


<link rel="stylesheet" type="text/css"
  media="screen and (max-device-width: 320px)"
  href="mobile.css" />

The media query standard allows quite a bit of flexibility. In fact we can specify orientation DPI minimum width and combine the rules using both OR and AND conditionals. Depending on time available for designers and importance of mobile customers you can create CSS files for different mobile devices and orientations that you want to support. See http://bit.ly/xD1jeS for a complete reference of the various rules that are possible and how to mix them for your needs.

A short note is warranted regarding media queries. Sadly IE8 browser (or below) do not understand media queries. They support linking to a style sheet but do not understand the query component and hence you need to put in a bit of hack around for it. The following lines of code in the HTML head section will provide that work around. If you have ever wondered why web developers dislike older IE browsers this is just one of the many reasons. Microsoft claims to be a changed company these days — you can see the reality of support for current and emerging technologies by loading http://html5test.com/ using a MS browser.


<!--[if lt IE 9]>
<link rel="stylesheet" type="text/css" media="all" href="style-ie.css"/>
<![endif]-->

Using Viewport to Control Layout

Using mobile specific CSS is one part of the story. However in some cases we want to explicitly tell the browser the intended dimensions for the content and more importantly the scaling (zoom level) to use. In HTML we have a meta tag specifically to control this behavior and we can use that in combination with CSS media queries as needed.

One feature that we get with view ports is that we can disable the pinch zoom gesture on certain pages. If you are wondering why one would want to do this — it all comes down to allowing components like maps to work properly. That is when the user issues a touch gesture on top of a map view we can pass that information to the scripts and get the zooming to work as expected. An additional reason is that in some devices if we zoom in and then rotate then the content gets cut off rather than get loaded again for that orientation.

The code snippets below shows how to control the view port. These lines are also placed as part of the HTML header section. The first line shows how to set the initial zoom level of ensure that the content is styled for the device width (as opposed to getting the 980px default from the browser). The second line shows how we can set the maximum scale and in effect disable zooming in.


<meta name="viewport" content="width=device-width initial-scale=1" />

<meta name="viewport" content="width=device-width initial-scale=1 maximum-scale=1" />

Serving Optimized Images

We mentioned earlier that we need to serve images optimized for mobile web. Sadly the HTML standard does not allow us to serve different images based on device capabilities. So what is the way around this? If you are using a content management system that support mobile web then the CMS software will do the magic for you (to some extent). However if you are serving a smaller web site then you can make use of a cloud service called Sencha.io which will serve the most optimal image based on the device user-agent information. As a developer you upload the image to Sencha’s servers and then point to them from the IMG tag. The service offed by Sencha is quite powerful and allows a great level of control on how the image is resized as well as optimized. A detailed discussion on how to make use of Sencha’s service is provided at http://bit.ly/xXCcCY.

Video on Mobile Web

The use of video on the traditional web is near ubiquitous and is slowly starting to increase on the mobile web. Interestingly many mobile devices do not have Flash support — the most widely used technology for delivering video. The added problem is that Android devices (in theory) support Flash but iOS devices do not. Though tempting to punish iOS users with the “no video for you” message we need to serve all mobile web users to ensure a large customer base for our services. So what is the way out? We can rely on the video tag supported by many of the new browsers but most video streaming services prefer to use the iframe tag. The motivation is that using this tag the streaming server will auto-detect the device and its capabilities and will serve content either using Flash or built-in HTML5. The following code snippet shows how to make use of this tag to embed a Youtube video — you have to provide the video identifier. Other streaming services have their own documentation but the model is similar.


<iframe class="youtube-player" type="text/html" width="310" height="160" 
src="http://www.youtube.com/embed/VIDEO_ID" frameborder="0">
</iframe>

Server Side Detection

Mobile web sites should aim to load faster and fit the context and usage profile of the users. A typical starting point for anyone with an existing web site is to adjust the CSS and retain the content as much as possible. This is an excellent starting point and better than serving the traditional multi-column page. However if you study the web sites that are attracting great usage via mobile they adjust the layout and serve different content for mobile. They also change the entire navigation structure to suit a mobile context. The content change is often needed because we need to communicate a different story often using different images to ensure strong engagement. However how do we serve mobile users their special content automatically? The safest and best option is to place the content is different locations on the server and point to that via the use of a script in the web server. Although this may appear hard there is a web service called Detect Mobile Browsers that will do the actual hard work by generating a script to direct traffic based on device capabilities. We have to tell this service the language that we want the script to be and it does the rest with support for scripts in PHP Apache scripts C# and a number of other languages including Java.

Native App or Mobile Optimized Web Application

In this master class series the focus has predominantly been on constructing native applications. A popular question that is receiving a lot of attention is — “Are native applications better than mobile optimized web applications?”. The best way to respond to this question is to say “it depends” — and then quietly run away from the scene. However if you are still pressed to answer then the following information will help. Sadly you will still have to perform a trade-off based on the actual situation and problem at hand.

Existing traditional web sites with a regular user base should work on providing a mobile optimized version of their content. At a minimum a mobile CSS. If resources and budget permit create a site designed for mobile users that loads fast and has a navigation designed for mobile users. The same advise applies to existing web applications. However this often involves fairly serious design work especially to find an elegant navigation model as well as adjusting content to fit the smaller screen space.

The decision for new services is much harder of course. Going for a mobile optimized web application allows the business to target both iOS and Android users. However the primary downside is that smartphone users are used to launching applications from an icon rather than going to a web site like we tend to do on the traditional computer. Research also shows that mobile users do not make use of features like bookmarks on smartphones making it clumsy to navigate to a web application. A work around that offers the launch icon as well as the ability to serve a web application is possible by using hybrid technologies — essentially these involve creating an application with a WebView component that is hard wired to pull in a preset web site. We made use of this technique already in the Masterclass series to display the twitter feeds in the MeDroid application. We can do the same but for our own web site. If you intend to go down the hybrid path frameworks like PhoneGap and Sencha Touch also help web developers create applications using web technologies — the best part is that these frameworks help us make use of the touch interface effectively and also offer some access to the device sensors.

Mobile optimized web applications do offer some compelling benefits: (i) they allow us to make changes on the server side without having to ship a new version of the application (ii) we can create a single application and ship to both Android as well as iOS users and (iii) we can build these application using web technologies that are more accessible. When we combine this with a technology like PhoneGap we get the best of both worlds — so why should we bother with native application at all? The simple answer is that users expect silky smooth user interface and a robust experience. Currently the best way to achieve it is via the use of native applications as they have direct access to all the sensors on the device. Native applications also do not need to download static resources like application images and media used for sound effects. A mobile web application will hit the server each time to get a lot of resources again and again (although the cache will help if it is not cleared). The elephant in the room really is that mobile broadband is erratic. Currently native applications can be constructed carefully to deal with this erratic network much better than mobile web applications. Frameworks like Sencha are making progress and are close to offering a solution for this problem but for now if you want users to have a great experience and feel like the application is responsive and behaves well when connections drop out for short intervals then native applications are the way to go.

Another compelling reason to consider a native application over mobile web is that you can create applications that feel natural to the platform. For example Google and Facebook build applications using the native toolkit and adjust the UI is subtle ways to take advantage of the platform and ensure that the application fits in with the rest of the system. On Android native application also have access to a range of services via the Intent mechanism in that they can make use of features offered by other applications easily (e.g. Camera Photo gallery etc.). These small factors add up and the users get a better experience when using native application. As you can see there are benefits for going down both path ways and the final choice should depend on a careful trade-off analysis. Although currently many developers lean towards building using native toolkit the future will very likely be heavily based on HTML5 — even on mobile. Just don’t ask me for a specific date.

PREVIOUS: How to take your app to the Android marketplace | NEXT: Home

Home: Main masterclass index