Selecting Application Technologies
The mobile platform offers a variety of technology combinations that can be leveraged to achieve a business goal. The author suggests that the choice of technology may be arbitrary - but ideally, it should be driven by the goals of the business: a technology that delivers a good experience, to the right recipients, it an efficient development cost. This chapter is geared toward helping the reader to consider those factors.
The author acknowledges that "by the time this book is printed, specific platform date is likely to have changed," but it should illustrate a process of evaluation that will be applicable regardless of the future state of technology.
INPUT MODALITIES
Many mobile applications seek to use a familiar method of input: a keypad. This is familiar to developers who are accustomed to building for desktop computers, and it is also a fairly safe assumption, given the popularity of text messaging, that most mobile devices enable the user to "type" data. But it's also important to consider that the text-entry method is very inconvenient for users.
Consider using the device's numeric keypad for input. Since most mobile devices are designed primarily to be telephones, the standard telephone keypad is typically less difficult to use than text input capabilities.
Also consider that most devices have point-and-click capabilities, analogous to the mouse, whether by means of a trackball, rocker, or touch screen. (EN: Multi-touch interfaces with "drag" are becoming popular on smart phones). It is typically easier for users to point-and-click than to type.
Speech would seem to be a natural input mechanism - but it is difficult to implement, as evidenced by "decades of research and failed products." Even if voice recognition can be worked out, vocal control will remain limiting to users who might wish to use an application in a polite and discreet manner. It's even been found that, when people talk to machines, they tend to speak more loudly and in a staccato manner, which is even more annoying to others in their environment.
Using audio as an output mechanism is less obtrusive, and using a combination of voice prompts and keypad inputs is a common practice in voice "applications," though navigating voice menus is often frustrating to users.
Visual inputs, such as a camera or bar-code reader, is currently uncommon but the author predicts its use will increase over time. If the user is able to scan a bar code, or take a picture of an object, to retrieve information. A few examples are photographing the VIN of a vehicle on a used car lot to retrieve a repair history, or taking a picture of a person's face to pull up their social profile. The ability of a phone to "read" a picture to recognize letters, numbers, or shapes is rapidly improving.
INTERACTION RESPONSIVENESS
The level of responsiveness necessary for an application (to prevent users abandoning it because they assume it is broken or are unwilling to wait) is largely dependent on the device (processing speed) and connection (data transfer speed)
These factors may be mitigated by storing data to the device rather than having constant packet transfer, and by shifting from web-based applications to native applications that run on a platform that is most efficient for the specific device.
Preference should be given to asynchronous applications, as they enable processing/transfer to occur while the user is occupied with other tasks, and are innately better suited to recovering from interruptions.
DATA STORAGE CONSIDERATIONS
Some applications may need to store user data between a temporary interaction (a single iteration through a task flow), whereas other may not. Storage of data germane to the session is advisable because of the unreliability of a connection - if a user steps into an elevator or other dead zone, the application may lose its state or session.
When data is stored, the choice is to store it locally on the device or remotely on a server. In addition to the usual considerations of efficiency (do only what is necessary), you must consider whether the application will require a network connection at all times.
It's also noted that local data storage varies among devices - where it is stored, and what "universal" information (e.g., address book or calendar data) is made available or accessible on a given device. Also, when the user switches devices (upgrades their phone), the SIM card does not store any user data aside of account information.
USER INTERFACE COMPONENTS
Audio output of a mobile device is often disabled by the user, to maintain privacy or avoid annoying others in a social environment. The use of headphones is not widespread, and if the telephone earpiece is used, the user is generally unable to listen to the audio and view the screen at the same time.
An audio-only application will generally be accepted by users, and if audio is supplemental (such that it "enhances" the experience but isn't essential), users will follow their own preferences. However, a mixed-media application in which audio is required for some, but not all, operations is unlikely to be useful in the truly "mobile" sense (the user will retreat to a private location and stop moving to use it.)
Video displays are common and users largely expect the display to be used for anything but speech applications.
Tactile output, such as using the buzzer, is possible but uncommon. Also, because the buzzer is notorious for consuming power, it's unlikely users will embrace its increase use. Typically, the buzzer is tolerated, and used, for getting the user's attention discreetly or in a noisy environment.
SUPPLEMENTAL TECHNOLOGIES
There are a wide array of technologies that are considered to be "supplemental," in that some manufacturers include them in certain models, but they are not widespread or common. Some may become standard features, others will not.
Location services (whether through GPS or signal triangulation) is becoming common, but is fraught with privacy and security issues. Users like having the ability to be able to determine locations of people, places, and things, but are wary of having their own location made known to others. It's an area of significant interest, but somewhat disorganized approaches.
Device-to-device communication via Bluetooth or infrared is sporadically supported. Often, a device will communicate with other devices of the same manufacturer only, and it's not uncommon for this capability to be restricted from access by third-party applications.
The ability to store user data on the device itself is also increasingly common, especially as data capacity is increasing and access is necessary for secondary functions (music, movies, etc.), storage is fairly common, but access to storage by applications is presently not (the user typically does not access the phone's storage in an analogous manner to a computer hard drive). Support for cookies and bookmarks is presently growing.
The author discusses additional display/output capabilities, but it goes quickly from the practical and probable (the use of projectors to display information, which is useful but probably not mobile) to the silly (the use of "odor-generating displays")
Additional input methods are also in consideration - but again, it includes the probable (the use of accelerometers is already increasing) to improbably (the use of spectrometers to let diabetics use the phone to monitor blood glucose). It doesn't quite make it to silly.
DISTRIBUTION METHODS
The distribution methods for third-party applications are varied. For device-specific software, it is generally pushed from the service or manufacturer to devices. For third-party applications, there are various models that include both push and pull broadcast as well as point-to-point application sharing. Additional models are also under consideration by various studios.
Cost of deployment is a significant factor - whether it is borne as a general expense by the developer or passed on incrementally to the buyers of an application. (EN: There are also likely stark differences between he consumer market, where individuals purchase applications for their devices, and the business market, where the company purchases applications for employees.)
It's also noted that "native" applications are developed for specific devices, but there are also applications where the same code is accessed or installed on a variety of devices - the latter is problematic in that a single interface will render "very differently" on different devices.
The notion of the "walled garden" refers to the device manufacturer or carrier attempting to prevent users from accessing or installing third-party applications unless they are authorized. This practice was originally predominate, and is still fairly common, though consumers are demanding greater flexibility in choosing their own software.
It's noted that this practice is as common among carriers (Verizon and Cingular) as it is among device manufacturers (Apple), so a studio seeking to develop applications must contend with the requirements of these organizations in order to make their software usable by customers.
Where third-party applications are permitted, the distribution channels are generally limited to a "store" operated by the carrier, the device manufacturer, or a third-party store that offers applications. Direct download from the developer's own site is uncommon, and obtaining software by other means (such as e-mail attachment) is very rare.
There is also the matter of revenue: whether the customer makes a one-time payment or a n ongoing payment (monthly fee, per-use fee), and whether the developer collects payment directly from the consumer or through another service (a "store" operator, or the service provider).
Marketing to users can be difficult, with most applications being available in online "stores" which house many other applications, which may prefer to cater to their users' interests in finding software rather than developers' interests in having their software promoted to users.
PLATFORMS
The author lists a number of the technology platforms that were available at the time the book was written, again disclaiming that this is time-sensitive information provided as an example of the kinds of choices one might have to make, even if the individual platforms change:
- VoiceXML - A speech/audio platform that works on multiple platforms
- Web - Use of the standard development and display capabilities for the Internet. Very familiar, but a bit clumsy, bastardized, and inefficient for the movile channel
- HDML (Handheld Device Markup Language) - A very old and very primitive method of delivering hypertext content to mobile devices and enabling keypad controls.
- Java ME - A version of Java for mobile devices
- BREW (Bianry Runtime Environemtn for Wireless) - Originally developed by Qualcomm, not common to several carriers, BREW is a mobile-specific set of features and functions
- SMS/MMS - Messaging services can be used as a "platform" for delivering text or media content
- Flash - Adobe's interactive multimedia application has mobile-specific code libraries and techniques
- uiONE - The author lists this separately, but it's really more of a technology that runs on the BREW platform, geared toward UI-specific functions
It's also noted that applications can be developed in the "native" platform for devices, which will differ by manufacturer.
(EN: the author gores into significantly more detail about the evolution and capabilities of the languages in use at the time the book was written, but my sense is that goes well beyond providing a simple example and more into detailed information that will quickly become obsolete.)