Options for building mobile web experiences

On this page:	Download:
Improving the mobile-friendliness of your existing app | Page weight and latency | Scripts and interactivity | Augmenting the experience with mobile-specific capabilities | Pros | Cons | Using a proxy-based solution | Pros | Cons | Developing a standalone mobile solution | Pros | Cons | Developing a responsive experience | Pros | Cons | Summary | Resources

Deciding which approach to use when developing a mobile app is never simple. There are many techniques available, each with their own pros and cons. It's also important to understand that there is also no single correct answer. The decision should depend on your circumstances and include careful consideration of all related factors, including your resources, timeline, back-end architecture, and data or content structures.

Improving the mobile-friendliness of your existing app

Mobile browsers are improving all the time, and if your users own a smartphone they may already be able to use your app on that device. While this may not provide a great experience, if your app is simple (or budgets and schedule are tight) you could opt to simply improve the mobile-friendliness of that app.

The goal in this case would not be to optimize the app for mobile use, but to simply address major issues that may be driving mobile users away, or preventing them from completing key tasks. Some of the problems that users encounter are common to all web apps, while others will be specific to your particular product. In either case, it's best to uncover these problems in context and with a bit of testing.

1. Check your analytics to determine the most common browsers and devices accessing your app.
2. Test your site using these devices. Be sure to test all key tasks and flows to ensure important functionality isn't broken and mobile users complete key tasks.

Note

If you're unable to test on device hardware, you may be able to test on a platform emulator. See Testing mobile web experiences for info about choosing emulators for testing.

These initial tests should provide you with a list of app-specific issues. In addition to these, you can improve the experience by addressing the following common problems.

Page weight and latency

Many mobile users will access your app on slow networks, and may be paying for each kilobyte they download. It's therefore important to reduce page weight and increase responsiveness wherever you can. This will make all users happy (even those visiting from a desktop computer) and won't tempt mobile users to immediately abandon your site in favor of others.

• A portion of the weight will naturally come from the images on your site so where possible, optimize these to reduce payload size.
• Be sure as well to review the number of scripts being used. These can be surprisingly heavy, and in many cases greatly exceed the weight of the markup, images, and other assets used to deliver the user interface. It's worth noting as well that if these scripts happen not to work on mobile, the experience might be further improved by preventing a user from even downloading them.

If your app uses large numbers of scripts and images, this can impact performance in an additional way.

Note

According to the Yahoo! Developer Network article, "Best Practices for Speeding Up Your Web Site," "80% of the end-user response time is spent on the front-end. Most of this time is tied up in downloading all the components in the page: images, style sheets, scripts, Flash, etc. Reducing the number of components in turn reduces the number of HTTP requests required to render the page. This is the key to faster pages." (1)

HTTP requests can be reduced in several ways:

• By combining CSS and script files
• By supplying images using data URIs which can be embedded directly within your mark-up or CSS
• By combining icons and other small graphics into one larger image (also called a sprite sheet)

Note

These techniques may not be supported across all devices, so they should be tested on the key browsers and devices accessing your site. See Delivering mobile friendly images for more info regarding the image techniques described above.

Don't forget to try techniques such as minification and gzip compression on your CSS, JavaScript, and HTML, in order to reduce the actual size of the file being downloaded to the client. For a full list of performance best practices, see Best Practices for Speeding Up Your Web Site.

Note

Many third-party services such as advertising, social media widgets, and analytics generate their own HTTP requests. This is worth investigating as they may generate more requests and result in latency that will be beyond your control.

Scripts and interactivity

An increasing number of mobile devices are manipulated using a touch screen. It's therefore important to check your app for features and content that can only be accessed using a mouse (or other pointer-based) event. Touchscreen users may still be able to trigger these events by tapping the screen, but the interaction may be more complex or confusing than it needs to be.

Augmenting the experience with mobile-specific capabilities

Typing on small screens can be awkward, so look for ways to improve data input.

• Don't force users to type if they don't have to. Look for opportunities to prepopulate data (based on past choices) or provide them with useful choices in a menu.
• Take advantage of the new HTML5 form input types, placeholder attributes, and built-in validation for common inputs such as email addresses and URLs. These are not yet supported on all browsers but are designed to degrade gracefully. Until these features are fully supported, it's important to keep secondary hints and validation in place. See Delivering mobile friendly forms for more info.

Unless your app is extremely simple, these types of improvements to your desktop web app should be considered an interim solution. Following these steps may improve the experience, but it's likely that many problems will remain unresolved.

Pros

• Adapting an existing app is typically quicker than designing and implementing a full mobile-specific version.
• While the resulting experience may not be fully optimized, it can improve the experience enough to suit many users and provide time to plan a longer-term solution.

Cons

• Reducing page weight, improving latency, and augmenting the app with mobile-friendly features are in most cases stopgap measures. This cannot replace a more comprehensive design process that may involve improvements to app flow, markup structure, and deeper integration of mobile-friendly CSS and JavaScript.
• As outlined when discussing images, many of the improvements recommended don't fully resolve the challenge of supporting devices with many screen sizes and capabilities. If your images are 800 pixels wide and 300KB, optimizing them will not resolve the basic problem that you are serving large, high-bandwidth images to smaller, resource-constrained devices.

Using a proxy-based solution

Migrating or refactoring a desktop app's back end to enable new, mobile-friendly features and functionality is not always possible. Some apps are highly complex, or may have been built by teams that have since moved onto other projects. This can make large-scale changes to the server-side code difficult, and if the app doesn't have a consistent and well-thought-out architecture (or doesn't contain unit tests) changes can be riskier still.

Business pressures may also mandate an aggressive mobile strategy that means the app must be available in a matter of weeks. In this case, you may want to consider using a proxy-based solution.

Proxy-based solutions vary in their implementation, but most use a combined approach including data collection, transformation, and optimization in order to dynamically generate a mobile-appropriate variant of your web site. This optimization and transformation "layer" (or app) is typically offered as a third-party service that intercepts the existing web site's outbound markup, and optimizes it for the mobile client. Certain proxy solutions specialize in adaptation of content-heavy sites, while others focus more specifically on e-commerce and transactional apps.

Pros

• Using a proxy solution is typically quicker than implementing a mobile site from scratch.
• Proxy based solutions don't typically require duplication of content, so they integrate well into your existing content management system (CMS) and production workflows. You update the desktop app, and the mobile experience takes care of itself.
• Part of the optimization process requires some sort of content collection, which can often be adapted to dynamically generate an API for an otherwise static web site.

Cons

• Proxy services work best when you wish to entirely mirror the desktop content and business logic. Aiming for consistency is great, but there may be times when you still need to serve different content or functionality to different devices. Doing so may not be possible when using a proxy.
• The more you customize your proxied site (and therefore fork desktop business logic or controllers), the more long-term maintenance you will incur each time your desktop site changes.
• Upgrades to your overall technology stack (payment services, remote caching, and so forth) may not be reflected in the proxy environment unless you incur the cost of a second implementation.
• Proxy services may offer less flexibility and control over the design, infrastructure, and the experience you deliver to each device.

Developing a standalone mobile solution

A standalone mobile solution is one that has been designed with mobile as the primary context. Standalone apps operate independently from any existing (desktop) web app, and are therefore often hosted on separate domains (or subdomains).

Pros

• The experience can be fully tailored to small/portable devices.
• Markup and template structures can be reassessed and optimized in accordance with good practice for mobile devices.
• Content and functionality can be implemented gradually, to suit user demand and budgetary constraints. The eventual goal may be to reach feature parity with the legacy app, but a standalone site provides the freedom to do this in stages.
• There may be little need for image adaptation as lightweight images (and media) can be served from the very beginning.

Cons

• Having a standalone site may require maintenance of a separate additional site (and potentially separate assets and content within your CMS).
• A standalone site will require a detection and redirection strategy to ensure URLs resolve gracefully regardless of the requesting device. If the standalone mobile experience doesn't contain all the functionality of the desktop experience, you may also need a strategy to convey this to users, and suggested alternative content or other means of completing their task.
• If the site operates from a separate domain (and despite the use of redirection) you may need additional marketing efforts to promote the site.
• If not designed responsively, you may need a separate site for larger devices such as tablets (and a strategy to determine which devices should receive each site).

To ensure the best experience, it will also be necessary to implement some manner of feature detection, to ensure the functionality and experience you serve is appropriate to the capabilities of each browser and/or device.

Developing a responsive experience

Responsive design is a technique that enables developers to adapt the layout and visual design of an app to suit multiple screen sizes. This is implemented using a series of CSS media queries that trigger layout and stylistic changes. These changes occur once a device property (such as screen width) meets the criteria defined within that media query.

Responsive design is most often applied to a single site (or app) enabling it to adapt to all contexts—from small portable devices, all the way up to desktop computers (and even larger screens such as televisions).

Pros

• Developers can design and maintain one set of markup (with the occasional variation), and in doing so, support a wide range of devices. This reduces the number of templates and resources that must be designed, and avoids duplication of any future design, implementation, and maintenance efforts.
• The app is easier to promote, as there is only one domain, and one URL for each article, section, or feature on the web site. This is particularly helpful in today's highly connected world as URLs shared by email or using social media will resolve gracefully regardless of the device.

Cons

• Responsiveness isn't something you can simply add to an existing web site. While it may be possible to inject some flexibility into an existing experience, most apps will require significant changes to templates, styles, and in many cases scripts and content.
• Responsive design is ideal for adapting layouts, but there is no built-in mechanism to target differences in browser or device capabilities. It's therefore necessary to pair responsive design with some manner of feature detection to ensure the most appropriate functionality and experience is served to each device.
• Responsive techniques enable you to scale images to suit different screen sizes, but do not address image weight or legibility. A separate image adaptation strategy may therefore be required.
• Some content may simply not be appropriate at certain screen sizes. You may therefore need to add, remove, or adapt the content (including advertising).

Note

The sample app included in this guide, Mileage Stats Mobile, uses, responsive design as a tool (and strategy), enabling us to better target devices with a wide range of screen sizes.
Users who access Mileage Stats Mobile from a desktop computer are still redirected to the pre-existing desktop app, which is fully optimized for larger screens and more capable browsers.
See Delivering a responsive layout for more details of our responsive implementation.

Summary

If you have an existing web app that was not optimized for mobile browsers, there are a few options for improving the experience for mobile users. Each option has advantages and disadvantages. You should consider how well each of these choices will work for your existing app, and think about the overall return on investment involved in any particular option.

Resources

(1) http://developer.yahoo.com/performance/rules.html

Next Topic | Previous Topic | Home | Community

Last built: June 5, 2012