When developing content for mobile devices, it's important to look beyond simple XHTML/CSS pages and even beyond the browser. The interplay between web content and mobile user can occur in a variety of ways, some of which are often more efficient, affordable, or universal than browser-based interaction–even some of which are not delivered through the web but through other content delivery channels. This chapter exposes a few approaches for developing a well-rounded mobile strategy.
Mobile messaging, quite simply, is a far more prevalent mobile activity than viewing web content with a browser. To ignore messaging is to ignore the largest slice of the content consumer pie and a potentially profitable opportunity. Messaging comes in a variety of flavors: Short Messaging Service (SMS), which is text-only messaging; Multimedia Messaging Service (MMS) for sending photos, audio, video, and rich text in addition to plain text; Enhanced Messaging Service (EMS), a technology older and less capable than MMS, but marginally more capable than SMS.
Of particular interest as it relates to mobile web content is text messaging. More than 10 billion text messages are sent worldwide every month, and estimates for SMS support on handsets in use today range as high as 98%.1 In the U.K. alone, 41.8 billion text messages were sent in 2006.2 Because of its prevalence, person-to-person (one-to-one) text messaging is a familiar activity: A user types a message on her handset, sends it to a personal number, and the intended recipient receives the message on his handset. However, texting can also be a one-to-many or many-to-one relationship. Content providers big and small have leveraged the power of texting as a means of serving web content to mobile users in this way. For example, mobile users can conduct a web search by texting their search query rather than entering a query in a browser search field.
Google SMS (http://www.google.com/sms) offers SMS search, and the process combines texting and search query (see Figure 6-1). A user types keywords, e.g. "hotels san francisco," as a text message, sends the message to Google's SMS number (466453 in the U.S.), and search results are sent back as a text message. Only a few relevant results are sent, often as multiple text messages due to the recommended 160 character limit for SMS messages. Yahoo! oneSearch (http://mobile.yahoo.com/onesearch) and 4INFO (http://4info.net ) offer similar services, among others.
Figure 6-1. Using Google SMS Search with a Nokia 6800 in my trusty Jeep Cherokee. (Yes, of course I was parked.)
PayPal (http://www.paypal.com ) has also embraced texting as a means for extending its popular web payment service to mobile phones. PayPal's Text To Buy (http://mobilewebbook.com/shorty/98098) allows consumers to send money via phone merely by texting an amount and email address to PayPal's SMS number, which is 729725 in the U.S. (see Figure 6-2). In addition to texting, PayPal Mobile Checkout (https://www.paypal.com/IntegrationCenter/ic_mobile-checkout.html) offers PayPal's traditional payment services via mobile browser.
Figure 6-2. Sending money using PayPal's Text To Buy. (Nokia 6680)
SMS search and Text To Buy are only the tip of the proverbial texting iceberg. Imagine if the University of Texas directory (see chapter, Mobile Web Fundamentals) were also available by SMS. One could text "amy miller" to a number for the university and receive matching directory results by text message. The options are seemingly endless for employing text messaging to serve web content. Although I personally recommend you seek professional assistance if considering a custom messaging solution, DevelopersHome.com offers a very thorough SMS Tutorial at http://www.developershome.com/sms. A less replete but more digestible overview is How SMS Works by Howstuffworks.com, located at http://communication.howstuffworks.com/sms.htm.
The SMS numbers mentioned thus far–Google (466453), PayPal (729725)–are commonly known as Short Codes. They differ from phone numbers in that they act as a numeric domain name for text messaging, and they're often shorter in length than phone numbers, typically 4-6 digits. The numbers often map to letters (e.g. 82267 = "tacos"), much like toll-free advertising phone numbers. However, while Short Codes function irrespective of carrier or operator, they are not as universal as domain names because they are generally restricted to continents. So while 466453 is the Short Code for Google in the U.S., in the U.K. the Short Code may be an entirely different number. Further, because Short Codes are meant to be short, the quantity of available codes is limited. In North America, for example, Short Codes are five-digit numbers in the range 20000-99999, which results in 79,999 total numbers available.
To register a Short Code, visit one of the following:
Alternatively, if you are an organization based in the U.S., TextMarks (http://www.textmarks.com) offers a generic Short Code (41411) that can be used by any organization to send on-demand, customized messages to users, such as a web address, a marketing promotion, and so on.
Java Platform Micro Edition (Java ME), formerly termed J2ME but still commonly referred to as such, is perhaps the most common platform for mobile application development today. Though somewhat riddled with marketing speak, the description from Java creator Sun Microsystems' website describes Java ME as follows (http://java.sun.com/javame):
JavaTM Platform, Micro Edition (Java ME) is the most ubiquitous application platform for mobile devices across the globe. It provides a robust, flexible environment for applications running on a broad range of other embedded devices, such as mobile phones, PDAs, TV set-top boxes, and printers…. Applications based on Java ME specifications are written once for a wide range of devices, yet exploit each device's native capabilities.
Because of this ubiquity, mobile developers have relied on Java ME for years, largely due to the number of devices that support the two platforms (rumored to be in the thousands). Developers also cite the learning curve as being relatively manageable compared to developing for other platforms, such as Symbian OS. A thorough resource for all things Java ME is Sun's Java ME Reference section (http://java.sun.com/javame/reference), which provides code samples, APIs, technical articles, and more. Also consider J2ME Polish (http://www.j2mepolish.org), an advanced build tool and GUI for Java ME applications.
Java ME is historically popular for mobile game development, yet many other types of productivity-related applications have been developed with it. Opera Mini, highlighted throughout this book, is a Java ME app. So is Google Maps Mobile (see Figure 6-3).
Because Google Maps Mobile retrieves data from the web each time a request is made, it classifies as what is sometimes referred to as a "smart client." The term smart client refers to an application whose processing model lies somewhere between a "thin client" and "thick client." A thin client performs minimal to no client-side processing and data storage and then relies heavily on a central server for these two activities, whereas a thick client offers extensive client-side processing and data storage relatively independent of a central server. A simple example is the installation, processing and data storage differences between Microsoft Outlook (thick client) and Gmail (thin client).
A smart client, therefore, is a hybrid technology that offers a mixture of server-side and client-side computing. Typically smart clients require a fairly light client-side installation of software, offer basic client-side processing, and rely on server-side data storage and retrieval, though the mixture of client-side vs. server-side elements may vary from application to application.
|Screen 1||Screen 2|
|Screen 3||Screen 4|
Figure 6-3. Google Maps Mobile (http://www.google.com/gmm), a Java ME application, installed on a Treo 650. User enters location (screens 1 and 2), receives search result (screen 3), and requests directions from first location to last location (screen 4).
Some of the advantages offered by smart clients over mobile browsing alone are evidenced in Figure 6-4, which shows user interface differences between using the Gmail smart client (left column) and Gmail accessed through a mobile browser (right column). First, greater visual control is extended to the designer for positioning elements, delineating messages, and organizing complex screen data. Second, application menus can be opened, closed, and overlaid within the viewable screen area, rather than embedding menu items at the top or bottom of a long, scrollable page. Third, developers can label and utilize a device's native soft keys, which are buttons located just below the screen that perform functions based on the screen label above the key, e.g. Options, Back, Close, etc.
Of the disadvantages of smart clients vs. mobile browsing, the most significant is the installation requirement. Mobile smart clients require software installation, which can be facilitated by visiting a web address provided by the content provider. However, the fact that a user must install software prior to consuming web content for each preferred content provider (e.g. Yahoo, BBC, ESPN) surfaces at least two problems: Users frequent dozens of content providers, and the software storage capacity of mobile devices is fairly limited. Imagine having to download a smart client for every website you would otherwise visit with a browser. All things considered, Java ME and smart clients remain a viable option for serving and exchanging web content. Loyal users will often have no issues with downloading a smart client and may even prefer the user experience over browser-based interaction.
For additional reading, see Thin and dumb, or fat and smart? (http://www.w3.org/blog/MWITeam/2007/07/26/thin_and_dumb_or_fat_and_smart) by Dominique Hazael-Massieux, Activity Lead, W3C Mobile Web Initiative.
| GMAIL SMART CLIENT
||GMAIL VIA BROWSER|
| Message View
| Application Menu
Figure 6-4. User interface differences between the Gmail smart client (left) and Gmail accessed via browser (right). (Nokia 6680)
1 CellSigns, "Text Messaging Statistics," http://www.cellsigns.com/industry.shtml.
2 Text.it, "41.8 Billion Text Messages For 2006," http://www.text.it/mediacentre/press_release_list.cfm?thePublicationID=351A37F2-C5A0-881E-03C5B18AAC2AE745.
[This is an extract from "Mobile Web Design" by Cameron Moll, chapter title "Beyond Simple XHTML Pages", pages 63-74]