Building Microsoft ASP.NET Applications for Mobile Devices, Second Edition [Electronic resources] نسخه متنی

Basic Design Principles

It might seem strange to discuss design in a chapter called "Getting Started." But because handheld devices all have small screens and limited input capabilities that present special design difficulties for mobile Web applications, it's important to keep these design issues in mind from the very beginning

Consider the following poem, which is a haiku, an ancient form of poetry originating in Japan. A haiku consists of three lines—the first line contains five syllables, the second line contains seven syllables, and the third line contains five. Haiku is challenging to write in part because of its brevity. A haiku should express simple, clear images, and its concise message should be easily understood.

My house has burnt down.

Now I own a better view

Of the rising moon.

—Matsuo Bash (1644–1694)

Try to evoke the spirit of haiku in your mobile applications: be simple, clear, and concise. If your applications read like poetry, you can consider yourself a very fine software engineer!

When you are designing and building applications for mobile devices, keep in mind five general guidelines. First, be economical with screen display space. If mobile phones with smaller screens will access your application, the viewable area could be as small as four lines, each containing 12 characters. Consequently, you should keep text as short as possible without sacrificing clarity. You might want to provide terse prompts on a small-screen device and fuller descriptions on other devices. In Chapter 9, we'll describe a useful technique for providing prompts appropriate to each particular client's display screen: implementing device filters that can be used in DeviceSpecific/Choice constructs to test whether the requesting client has a small display area.

The second design guideline is to use graphics sparingly in your mobile Web applications. You should consider your use of graphics carefully for the same reasons you must be economical with screen display space. In addition to consuming valuable display space, the overuse of graphics can cause your application to perform poorly. First-generation WAP-enabled mobile phones operate over a wireless link at only 9.6 Kbps. More important, wireless communications links exhibit higher latency (the delay network entities introduce when delivering a message) than wired communications links. This increased latency is often a few seconds, and every graphic you display on your Web page causes an additional round-trip to the server. Although the industry is rapidly upgrading wireless communications capabilities, this latency promises to remain an issue for many devices.

The third guideline is to limit the amount of input you require of your users. Mobile device manufacturers have yet to solve the problem of how to provide easy-to-use, reliable input to a handheld device. The only devices that offer input comparable to that of a PC are personal digital assistants (PDAs) and mobile phones that support plug-in portable keyboards. Most PDA devices support input using a stylus, using handwriting recognition or a virtual keyboard display. Most mobile phones allow input through the alphanumeric phone keys. Figure 2-15 highlights the input support of several mobile devices.

Figure 2-15: Various ways to input text on a mobile device, all of which are more difficult than using a PC keyboard

Whatever handheld device you're targeting, your users won't appreciate having to enter a lot of information. Try to keep the data requested to the minimum needed to complete the application's function. If the architecture of your application allows it, you might want to let users register preferences or certain information about themselves, perhaps through a PC-accessible Web site. You can store this information on your back-end servers and then offer default inputs on the mobile device based on those preferences when applicable.

The fourth design guideline is to keep individual pieces of functionality short and concise. In the spirit of haiku, keep mobile transactions as brief as possible. This guideline varies somewhat depending on the application, but in general, mobile devices will likely serve remote users who have a small window of time available to access information or perform a transaction. Your traveling users and your business's mobile personnel won't appreciate lengthy, tedious procedures. Short, snappy applications add real value to a busy person's day!

And finally, learn how to use the customization features of the ASP.NET mobile controls to provide a richer interface on devices that support such capabilities. Chapter 9 describes how to use property overrides and templates, and Chapter 10 describes how to use the List and ObjectList control templates. But keep your priorities in order. When working with an abstraction of a mobile device, as you do with the ASP.NET mobile controls, concentrate on the bare functionality of the application. You should focus on presentation only after the application is functioning correctly.

The default output of the ASP.NET mobile controls yields good results on monochrome devices with limited displays, such as mobile phones with WML 1.1 browsers, color devices such as the Pocket PC, and large-display smart phones such as the Microsoft Smartphone or Nokia Communicator. Figure 2-16 shows some of the PDAs and smart phones that are rapidly gaining acceptance among corporate users as effective devices for mobile solutions. The larger display and color support of the latter devices allow you to create much more visually appealing applications. You can take full advantage of their presentation capabilities by using the customization features of the ASP.NET mobile controls. Such capabilities will make working with your applications more pleasurable for your users.

Figure 2-16: PDAs and smart phones are becoming increasingly popular for business applications.