HTML5: The New Minimum for Mobile Web Devices

October 15, 2010 | Michael Mullany

We designed Sencha Touch as a framework for building rich applications for HTML5-enabled mobile devices. Back in 2009 when we started our development, this meant Google Android 2+ and Apple iOS 2+ devices. Since then, these devices have been joined by the Apple iPad, the Blackberry Torch, the Blackberry Playbook tablet, the Google Android tablet, and the forthcoming WebOS based HP tablet and Nokia Meego phone.

Of course, we could have built something that worked on more primitive devices, but we chose not to do this for a variety of factors. The biggest being user experience and performance. You can’t build rich web apps on older devices that have basic browsers and incomplete and often buggy JavaScript. A rich app experience is the new minimum user expectation on mobile.

For this, we blame iPhone and Android. iPhone and Android native apps have set a new standard for mobile performance and experience. People love using these apps. And now it’s up to the mobile web to meet the new, higher, expectations. This means delivering web apps with polish, dynamism and performance. And the only way to do this in a mobile browser—without Flash—is with HTML5 family technologies.

“Mobile is Not a Small Desktop”

A mobile device is not just a small desktop. Taking something that works in a desktop browser with a mouse/keyboard interface and shrinking it down to mobile doesn’t cut it. What’s different? Two things: limited screen real estate, and your finger is your only input device. These two things have deep design implications.

First, when screens are this small, even the simplest apps have to provide for fast and easy navigation through content and data. This means that the app has to pre-load content that falls outside the current view and bring it quickly onto the screen when needed. Ajax has made this very familiar to us on the desktop, but most legacy phones lack Ajax support. Should you really plan an app where you make a user wait for a page fetch every time you want to show new content?

And then there’s animation. When the screen is this small, animating navigation actions becomes very important. Animating a content transition tells the user where the new piece of content is located relative to previous content in the extended “content space”. Without animations, you will burn a lot of screen real estate with breadcrumbs and other location aids.

Finally, on-screen widgets on a touch-screen device have to be very large to allow for touch control. Apple Human Interface Guidelines recommend a 42 pixel minimum height for buttons. That’s a huge amount of real-estate taken up by navigation. If tapping buttons is the only way to get around your app, you’ll end up with screen-clutter: lots of UI widgets and a tiny amount of content.

However, if you have advanced gestures, you can reduce the amount of UI chrome. Android & iOS native frameworks give you lots of tools for navigation without widget clutter:

• Components like carousels, that let you gesture directly on content areas for navigation
• Complex gestures such as pinch/spread on content to zoom in/out
• Modal dialogs and action sheets to confirm/cancel actions
• Pop-over menus that overlay the main content area
• Modal input widgets  - e.g. date spinners
• And much more…

Luckily, these native functions are also possible using a mobile web browser as long as it has a solid Javascript implementation and good CSS3 support.

And Let’s Talk About Offline

And we haven’t even talked about web apps that need geolocation or offline support. Being able to use a mobile app even when you’re on 3G in San Francisco (aka offline), means it needs to have local storage for both data and application assets. Again this requires HTML5.

By the beginning of next year, all new smart-phones from Apple, Android, RIM, and Nokia will be HTML5-ready. In market share terms, most of them will be cheap Android-powered HTML5 mobile devices. They’re already in the delivery pipeline of all the major carriers. This is why we chose the design strategy that we did.