As smart mobile phones such as the iPhone or the Palm Pre offer a better Web-browsing experience, it becomes easier to offer access to enterprise Web applications from these devices. Designing Web content for mobile devices isn’t that much different than designing Web content for desktop users.
Since these devices can browse the Web, for the most part, you can reuse your existing Web applications. There are a few issues due to the size of the device screens, and so on. These include:
* Identifying the device, or otherwise providing a mobile-specific URL for the application.
* Dealing with page scaling.
* Handling UI restrictions, the main ones being that there is no mouse and textual input is typically harder for the user.
* Creating a page with less content, and a smaller footprint in terms of kilobytes needed to download.
Identifying the Device
The iPhone’s Web client is Mobile Safari, a browser built on top of the open-source WebKit project (and WebKit is in turn, built on KDE’s KHTML browser component). Android and Palm Pre phones also use WebKit (as do other platforms), so the results will likely be similar for all.
These platforms all provide a fairly reasonable Web browser that supports quite a few Web standards. Also, you can test your pages on Safari on a Mac or Windows system to get a good idea of what the page rendering will be like (not exact, though).
navigator object, or the HTTP request headers to identify the browser’s user agent and version. This gets more complex, in that you’ll find all sorts of the traditional text in these values to provide for compatibility. An iPhone, for example, tells you:
* The browser is Mozilla/5.0 (not really)
* It is an iPhone and uses iPhone OS 3_0
* iPhone OS is like Mac OS X
* It runs on the AppleWebKit
* The AppleWebKit is based on KHTML, which is like Gecko (not really like Gecko)
The Gecko and Mozilla mentions are there to deal with legacy code.
You can search the string for the WebKit part, iPhone, or terms like that. The Palm Pre also mentions AppleWebKit in its user agent string.
It can be easier to instead just provide a mobile URL. Many firms due this, often using “m” in a short URL, such as m.facebook.com and m.cnn.com. The short URLs are handy due to the difficulty to type on these devices when compared to a desktop keyboard.
The mobile part of your enterprise application can then serve up pages designed for smaller devices. Using a separate URL can make this easier to test as well, since you can use your desktop browser to test the mobile content pages. Note that you should still test from mobile devices, but a lot of development work can be tested from your desktop system, reducing the time it takes to finish your application.
Dealing With Scaling
In an effort to show the “real Web”, the WebKit browser defaults to showing a very small version of a page, so that it can fit a full page of nytimes.com on the small display, as shown in the iPhone advertising.
Thus, if you do the right thing and design your mobile-facing pages with just a small amount of content, you may find the page renders with tiny text and an unreadable display after scaling to 960 pixels.
To get around this default scaling, add the following meta tag to your mobile pages:
<meta name = "viewport"
content = "width = device-width, height = device-height">
This sets the viewport to the width of the device. Note that device-width and device-height come from the iPhone and are not supported on all devices.
You can also put in a fixed size:
<meta name = "viewport" content = "width = 320, height = 480">
But, users can rotate their phones, defeating this approach.
Dealing with UI Restrictions
The main restriction is that you have no mouse, so any mouse-over effects won’t be effective. In addition, the keyboards on mobile devices, whether they are virtual on-screen keyboards or hardware thumb keyboards, are not condusive to lots of text entry. Limit the amount of user input required.
Furthermore, you can send URLs via email or SMS text messages to avoid the user having to type in the URL to the application.
You can see some other restrictions of the iPhone browser at pages such as: http://www.mediawiki.org/wiki/Mobile_browser_testing/iPhone.
Creating a Page With Less Content
Mobile devices load Web content over a cell-phone network, or if you are lucky, a WiFi access point. Both are typically slower than normal hard-wired links. In addition, phones tend to have less-powered processors than desktop computers.
So, you’ll want to shrink the amount of data needed to render your pages. Each HTML file (or CSS, and so on) should be less than 10MB in size (at least, this is a large limit).
Use less images, and shrink the byte-size of the images you do use.
Shrinking the amount of data also helps with the small screen resolutions of these devices. 320 by 480 pixels is a common size for modern smart phones, a size that hasn’t been seen on desktop computers since the mid 1980s.
Phones such as the Pre or iPhone allow you to rotate the device, allowing for a slightly wider display (480×320). Even so, you don’t have much room for multi-column tables of data. Design the mobile content to show as little as possible, with just a few navigation links.
A List Apart describes how the full screen is shrunk even more on the iPhone with the browser’s location bar and other UI elements. See http://www.alistapart.com/articles/putyourcontentinmypocketpart2/.
For example, the default amount of vertical space on the iPhone is:
356 pixels high =
480 (full screen)
– 20 (top status bar)
– 60 (location bar)
– 44 (bottom status bar)
I’d suggest creating forms without most site navigation links. Instead, each form should sport just Save and Cancel buttons. This also helps focus the user attention and reduces the problems you need to deal with. View pages can contain application-wide links.