|
Developing Applications for Mobile Devices – Part 2 Recommendations for Design by Sharee English |
Nothing is more exciting than seeing your Web page on someone’s mobile device, and nothing is more frustrating than trying to figure out how to get it there. The number of devices, screen sizes, operating platforms, and support levels for mobile devices can make a developer downright dizzy.
Developing a Web page or application for a mobile device may be easier said than done. There are many hoops that a page has to go through to get from the server to display on the mobile device, such as the wireless technology that sent the page, the protocols the devices support; the proxy server involved and what sort of data it filters out (such as flash, images or tables); and the code the device supports. With all that in mind, sometimes you just have to take a leap of faith, sit down with an energy drink and get to work.
There are several approaches to take when deciding to port your Web site or application to a mobile device. The most extreme is to design a whole separate version of your site. But for those of you die-hard developers who typically borrow much of the code that it took to develop your original site to begin with, this approach goes against your core beliefs. Duplicating your work simply is not a good choice.
The second approach is to try to develop your site to support only the features that will work in a mobile device. But that takes a lot of the fun out of really cool code that you spent so much time trying to find on the Internet, in addition to the fact that the graphics would look like pixilated images from 20 years ago.
So, as you can imagine, the third approach will probably fall somewhere in between. This in between approach relies on Cascading Style Sheets (CSS), where you use the HTML 4.0 media="handheld" attribute to direct mobile devices to load a style sheet designed with their needs in mind. It does, however, require you to separate your content from your design and use CSS the way it was meant to be used. Utilizing CSS allows the developer to provide access to everyone, with the information formatted on the fly in a manner appropriate to the viewer’s connectivity.
You should be aware that some mobile devices do not support CSS. So if it seems like we still have a way to go when it comes to developing for mobile devices, you are correct. But the statistics support that the mobile device community is growing every day and developers need to learn to work around the current limitations of the technology. Today you can check the traffic report on your Pocket PC while you are stuck in the traffic on a freeway and determine that you need to take the next exit because of an oil spill up ahead. You have to love this technology, limitations and all.
This article will discuss some of the design recommendations and general guidelines for developing a Web site that can be viewed with mobile devices. There are many suggestions and ideas floating around on the Internet, as well as some great resources for tips and tricks I have listed in the resources section at the end of this article. The ultimate goal in developing applications for mobile devices is to optimize the information displayed and enhance the user experience.
Handheld computers restrict the amount of screen space available to an application, so, when developing applications for small screens, keep in mind that horizontal/vertical scrolling is not always the best solution. Instead, consider providing quick drill-down navigation via hypertext links that easily and intuitively allows you to navigate forward and backward. You can also use proportional widths to help prevent horizontal scrolling.
Unfortunately due to the screen size, those high-resolution graphics that look so terrific in our desktop browsers take up a lot of real estate on a mobile device. One of the suggestions that will require some rework is the graphics. First, you should limit the graphic content to only necessary images. You can utilize the Alt tag for your images to provide a text link and use CSS to turn off the image display for mobile devices. When creating Alt tags, keep in mind that you are trying to convey the message of the picture, not describe it. Some mobile devices do not support images, in which case the only thing the user will see is the Alt tag text.
When choosing images for use on devices, it's important to remember the size of the display. For example, the actual size of the Palm Pilot connected organizer screen is 160x160 pixels, while Windows CE-based devices can be up to 640x480. Some software can scale images to fit inside the viewing area, but scaling reduces the quality of many images, so you should generally avoid using images wider than the handheld's viewing area. Use "large" images sparingly and only when appropriate, as they not only consume screen real estate, they consume bandwidth. Designing graphics for small, bitmapped screens is something of an art. However, once mastered, the graphics you create can make the difference between an adequate page and an outstanding one.
Client-side image maps can be used even if images are not rendered so developers may include client-side image maps into their contents. But this is acceptable only when alternative descriptions are provided via "Alt" attribute of AREA element. Server-side image maps should not be used.
The need to have the core code as small as possible is a benefit when adapting the browser to mobile devices. Components can then be added to achieve the desired functionality for a specific device. The amount of memory (RAM and ROM) needed directly corresponds to the functionality desired in the browser. Without taking too in-depth a look into the requirements of any one particular browser, the ranges start around 250 KB of ROM for core browser features and extend up to 900 KB when accommodating the full feature set. RAM resources vary from 200 KB to support core browser capabilities and up to 1000 KB when utilizing all optional features.
Other storage related issues needing consideration are the method for caching Web pages and dealing with the storage of cookies. Web page caching allows the user faster access to content previously downloaded from the Internet. By providing a mechanism to cache web pages, when a user back tracks during a browsing session, the Web page can be retrieved from local storage rather than resubmitting a request for the page over the Internet. Since most mobile devices have limited bandwidth capabilities, the ability to retrieve Web pages quickly is a concern.
One possible solution is to provide caching with a limitation on the amount of memory used. Older Web pages are discarded first based on a memory limit devoted to storing Web pages. The amount of resources used can be dynamically set based on the currently available memory in the system. Cookies present a similar problem where most Web sites want to use device memory resources to store information.
The widely-varying characteristics of mobile devices can make it difficult for a Web site to provide an acceptable user experience across a significant range of clients. For example, different clients support different markup features, and the different screen sizes may demand images of different sizes. As a result, it is very common when delivering content to mobile clients to vary the details of the markup, format of images, image sizes, color depths, etc. to suit the characteristics of the client in question. This process of content adaptation is described in detail in this section.
Styles
When style sheets are used, external style sheets are recommended from the viewpoint of content size and separation of structure and style. In this way, mobile devices that don't support style sheets don't have to load unnecessary style sheets. The STYLE element can also be used, but inline style sheets via "style" attribute is not preferred. Contents should be readable without style sheets so that devices which don't support style sheets can still render contents reasonably.
Fonts
At the time of writing, Pocket PC is the only platform that ships more than one font face. Palm users may choose to download extended font packages, but it may be too much to ask from an average Palm user. Nearly all devices currently default to a proprietary sans-serif font. If you are still using the "font" tag to set colors, font faces and styles you may notice that it bulks up your code for no reason.
Scripts and Event Handlers
Most mobile devices have limited amount of memory storage and CPU power, therefore, in many cases scripts are not supported on mobile devices. It should not be assumed that scripts will always be executed. Contents should be readable even if scripts are not executed.
Forms
Most mobile devices support basic forms, but they don't have keyboards like desktop computers. Device data entry is typically a challenging process for a user for several reasons. First, the input methods ("thumb keyboards," soft-keyboards, and "graffiti") are restrictive when compared to full-sized keyboards and mice. Input rates are significantly lower for these methods, and in some cases the user must often take two extra actions to open, and then close, the keyboard feature. In addition, when presented with a data-entry field, novice users often expect to be able to handwrite (using the stylus) the requested information in the field provided, typically causing confusion and frustration. Another problem with the use of forms containing multiple data-input fields is that display space is rapidly consumed by the empty input fields.
An alternative to displaying all input fields and associated text prompts at the same time is to display the text prompts alone. After the user knows which field they wish to fill, they can tap the corresponding text prompt, at which point the input field is revealed.
Another alternative to the excessive use of data fields is to provide a user with a series of hyperlinks that begin with a broad scope which narrows with each successive set of links. An example of this would be searching for a hotel in a given geographical location. Instead of requiring the user to input the name of the hotel and its location, the user could be presented with a list of hotels, followed by a list of potential locations.
Developers should keep in mind that it will be hard for users of mobile devices to input many characters. Since some mobile devices don't have local file systems, some features, which depend on local file system, such as file upload, should not be used.
Frames
Mobile devices have small screens, and some of them support only textual information. Frames strongly depend on screen interface, and are not part of the HTML 4.0 Strict. Therefore, frames should not be used when developing Web sites for mobile devices. If there is a compelling reason to use frames, make sure that those contents have the descriptions below:
Tables
Some mobile devices will support table layouts, but they will typically resize your cells such that your Web page design looks as if it was developed by a kindergartner. It is difficult for mobile devices to process complex tables due to their hardware restrictions and table display can create unexpected text wrapping or scrolling issues. In addition, some mobile devices do not support tables at all. It is best to avoid tables whenever possible. Consider using alternative structures such as lists, the div tag, or CSS positioning, whenever appropriate.
Objects and Images
The OBJECT element, which is designed to embed various objects, including images into HTML documents, are also useful in mobile devices. For example, contents which have voice (speech) for cell phones and contents which have graphical maps for car navigation systems may become typical for those devices, as these contents match essential needs and functions of them.
When embedding objects via OBJECT element, alternative contents should be provided by the fallback mechanism of OBJECT element. These alternative contents should end up with texts, as shown in the example below:
|
<P> <OBJECT data="MainNavBar.png" type="image/png"> <OBJECT data="SDMap.gif" type="image/gif"> text describing the image such as... Map of San Diego </OBJECT> </OBJECT> </P> |
In general, images should be embedded via the OBJECT tag, as it has a better fallback mechanism, but IMG tag may also be used. In this case, alternative description via Alt attribute should be provided for user agents which cannot or do not render images. If the image represents important information, a long description should be provided via longdesc attribute of IMG tag, in addition to alternative text via Alt attribute.
The APPLET tag, which is not part of the HTML 4.0 Strict, should not be used in favor of the OBJECT tag.
Access keys
In general, it cannot be assumed that input methods, which consist of a (full) keyboard and a pointing device such as a mouse, are available in mobile devices. From this viewpoint, assigning access keys via "accesskey" attribute (for A, AREA, BUTTON, INPUT, LABEL, LEGEND and TEXTAREA tags) will be effective when it is available. This may improve accessibility of links or form-related operations. But the use of "accesskey" attribute needs careful consideration.
In many mobile devices, available keys are limited. It cannot be assumed that all keys in "full" keyboards are available. Available keys differ among mobile devices. For example, cell phones will usually have "0"-"9", "*" and "#" keys, but the same assumption cannot be applied for most pagers or mobile game machines. There may be some mobile devices that cannot use "accesskey" attribute at all. For example, devices only for voice browsing will not use access "keys". Content authors should not rely on access keys for navigation.
Do not assume your applications will be perfect because they look good on a Web site. It is always a good idea to test your applications on all of the devices you are deploying as today's devices range in screen size, resolution, memory and storage.
An important part of every development project is testing, but this can be quite
a chore when targeting handheld devices. There are so many devices on the
market, it is almost impossible to test with every conceivable application. Most
manufacturers provide a Software Development Kit (SDK) to test applications on
their platforms. A few notable platforms include Symbian, Palm, Motorola, and
the BlackBerry. Some of these even provide emulators so you can preview your
pages using the emulators (see Additional Reading at the end of this article).
With the need to incorporate Internet access in mobile devices, the browser has already become a standard application for many of these devices. Putting a little forethought into the design when developing for mobile devices will allow your application to meet your user's needs and accommodate future features. Developing for multiple devices seems to take us back several years in our development cycle, but as new technologies become mainstream; they all seem to have to go through this initial pain of development. With the suggested recommendations and tips in this article, I hope it provides a little pain relief.
Part 3 (coming soon)
Sharee English (MCSD, MCAD, MCT) is the Director of Information Services at SeattlePro Enterprises, an IT training and consulting company. She started her career as a programmer, delving into Web technologies almost twenty years ago. Today she is a highly educated executive with background in software development, training, authoring, management, operations, administration and sales. Sharee holds a Master of Arts in Management (emphasis in Information Systems), a Bachelor of Science (B.S.) in Computer Science and a B.S. in Mathematics.
If you would like to provide feedback on this article, please click here.
Copyright ©2006 SeattlePro Enterprises. All rights reserved.