Бөлісу құралы:


Defining the mobile web app experience

patterns & practices Developer Center

On this page: Download:
Lightweight and responsive | Designed to suit device capabilities and constraints | Rich, platform-agnostic user interface | Forward thinking | Summary | References Download code samples

As mentioned earlier, this guide focuses on building mobile web apps. In this section we will examine the defining characteristics of a modern mobile web app. These characteristics are born of best practices and provide a useful framework upon which you may plan and design the features of your own app.

Mobile web apps should be

  • Lightweight and responsive
  • Designed to suit each device's capabilities and constraints
  • Include a rich, platform-agnostic user interface
  • Built with forward-thinking practices

Lightweight and responsive

Mobile devices may be more powerful than the computers we owned in 1995, but they remain quite constrained compared to the desktop computers we use today. A slower processor not only impacts the overall speed of the browser, but can also influence the speed at which content is accessed from the network, the redraw rate for effects and animations, and the responsiveness of the view as a user interacts with it. Mobile devices are also often used in contexts where bandwidth may be poor or prone to unexpected latency.

Mobile apps should therefore be lightweight and not impose additional latency through unnecessarily heavy markup, poor data management, or use of gratuitous and unnecessary effects. A good way to determine an appropriate size for your app is to consider how long you would like users to wait as the page loads.

The table below illustrates average wait times for a 1MB web page moving at an average data rate on various network types. These times are average and do not account for network latency and the time it will take for the browser to render the content once it's downloaded. (1)

14.4Kbps

568 seconds (~10 minutes)

Typical of a 2G connection

77.5Kbps

105 seconds (~2 minutes)

3G connection

550Kbps

15 seconds

4G connection

Recent statistics indicate (2) that a size of 1MB or greater is now quite common on the desktop. And while 3G is now widely available in many developed economies (reaching over 56% in the US), global 3G penetration stands at only 45% (3). When targeting mobile devices, it's therefore wise to limit the average initial page weight to well under 100KB.

Designed to suit device capabilities and constraints

A common misconception is that there are standard, easily classified categories of devices, and that all devices in each category are alike. This is far from the truth. Smartphones come in different shapes and sizes, ship with many different browsers, and have varying CPU power. Tablets also greatly vary in size. In fact some are not much larger than a phone.

A similar problem applies to platforms. For example, although many devices use the Android operating system, the platform can be integrated into all manner of devices, from tablets, to televisions, to in-car entertainment displays. The manufacturer can also choose which of several platform versions to implement (for example, Android 2.2 vs. 2.3), and can make changes to the user interface and platform settings. For this reason, it's unlikely you would be able to design one app that would work seamlessly on all Android devices.

Rather than develop a web app specific to a particular platform's browser (such as Windows Phone), rendering engine (such as WebKit) or device grouping (such as smartphones) it's best to deliver a flexible app targeting the lowest common denominator app, then layer additional features and enhancements in accordance with the capabilities and constraints of each browser and device.

This level of adaptability is best achieved through the use of future-friendly, backwards-compatible practices such as unobtrusive JavaScript and progressive enhancement. These will enable you to broaden your reach today, while more easily supporting the browsers and platforms of tomorrow.

Rich, platform-agnostic user interface

It's sometimes hard to define what we mean by a "rich interface" or why an app should have one to begin with. The richness of an interface does not guarantee that an app will be stable, well thought out, or have well-chosen features and good performance. These characteristics should certainly be the primary concern of a product team as they will greatly impact users (and the viability of your product).

A well-designed product can, however, benefit greatly from a richer interface. A feature may be well designed, but still hard to use. Users may not understand how to find a feature, what that feature is for, or the language used may cause them to make mistakes. Features may also be hard to use due to external factors such as hardware and screen quality.

A rich user interface is therefore one that works well with (and enhances) the back-end business logic, permitting users to effortlessly complete their tasks. A rich app also embraces unique device or browser characteristics, working with the device or platform, rather than against it.

For example, some apps choose to mimic the design of the iOS platform, and include a back button at the top of each app view. This may be familiar to native iOS app users, but is counterproductive for a browser-based app. Most mobile browsers have their own built-in back button, and those that don't have purposely omitted it as their platform includes a mandatory hardware-based back button.

So while a separate back button may make the app look like a native app, the developers now have the added burden of ensuring this button's behavior is identical to that of the browser or hardware version. This effort could better be spent improving the overall cross-browser compatibility of the app, or implementing enhancements for users with more powerful or standards-compliant browsers.

Forward thinking

The goals of each app will vary; however, developing for mobile always provides a unique opportunity. Our existing patterns and practices were designed in an age of large, stationary desktop computers. Many of these practices are being challenged by the new diversity in connected devices. While some of these devices are smaller and more portable, others—such as Smart TVs—are larger and more social. And these changes will only accelerate. In fact by 2015, Morgan Stanley predicts (4) the number of mobile Internet users will overtake those using fixed Internet connectivity.

Developing a mobile version of your web app is therefore an opportunity to examine older practices and determine which may no longer be appropriate. It's also an opportunity to redesign your product from the ground up, with the aim of making it more adaptable to future change. In this sense, designing a mobile app should be considered a long-term investment in your product's future.

And although your mobile app may start small, it may through iteration achieve feature parity with your original desktop app.

You may even discover that features you considered important when the legacy app was developed become less important, when transposed to smaller and more portable devices. Your mobile app may even cause you to replace the legacy app altogether, opting for a more feature-based development approach that will enable you to support new contexts such as web-enabled TV.

Summary

Understanding the constraints of mobile devices can help you build fast and responsive web apps. The practices gained from this understanding can also improve your web development in general. It’s important to realize that the classification of browsers into "mobile" and "desktop" rapidly changes as the number and types of devices continually grows.

References

(1) Calculated based on data from http://web.forret.com/tools/bandwidth.asp?speed=550&unit=Kbps

(2) http://gigaom.com/2011/12/21/hold-those-caps-the-average-web-page-is-now-almost-1mb/

(3) http://www.slideshare.net/kleinerperkins/kpcb-internet-trends-2011-9778902

(4) http://gigaom.com/2010/04/12/mary-meeker-mobile-internet-will-soon-overtake-fixed-internet/

Next Topic | Previous Topic | Home | Community

Last built: June 5, 2012