Ubiquitous access to information anytime, anywhere may be seductive, but it has yet to draw ubiquitous acceptance, that is, worldwide acceptance. Still, the appeal is strong. Imagine a powerful mobile phone with crisp color screen and small keyboard through which you could access email from any location, purchase items on impulse from an online store, manage your stock portfolio, instantly share vacation pictures with family and friends, or locate the nearest Starbucks when the sudden craving hits. This is a compelling vision already realized in Japan through wireless Internet services provided by mobile telecommunication companies, such as i-mode by NTT DoCoMo.
In the U.S., wireless applications have achieved success in niche markets, most notably with devices that access corporate email and in the area of transportation and logistics where the return on investment in mobile computing infrastructure is clear. To illustrate the difference in ubiquitous acceptance, consider the fact Japan sends more email through mobile phones connected to the Internet, while sending email via the PC far exceeds wireless devices in the U.S.
The choice of device and network for Internet access has been influenced in the past by availability, price, and quality of service/user experience. Current usage behavior is being driven by initial deployment complications due to the infrastructure rather than fundamental issues of application design. As these issues are resolved, four new challenges will emerge. Finding solutions to these challenges will spawn true ubiquitous acceptance of ubiquitous computing.
The challenges will result from the availability of multiple devices to access the Internet, powerful personal devices with substantial amounts of memory and processing power, the ability to access services through multiple networks, and the ability to work in offline and online modes interchangeably. Systems must evolve to provide better techniques for creating and deploying applications that run well on multiple types of devices; better utilization of resources on personal devices by allowing the user to store and manage information from the device; seamless roaming between different types of wireless networks; and seamless online and offline execution of applications.
In the future, people will use many different devices to access Web-based applications. For example, busy executives will access email from the PC while at the office, but will access email using a phone while traveling. There are many applications where the same interactions will be enabled for an application from a mobile device as well as through a PC. However, there are functions useful on phones, such as ring-tone downloads and location-based services, that are not as meaningful and effective on PCs. Applications will be built to exploit the special features of a particular device to provide the appropriate set of interactions. For example, an auction site's interface on a mobile phone may allow buyers to increase a bid or get notifications on items they have been outbid on, but may not allow a seller to list an item since that process requires setting up a complex set of pages to display the item to be auctioned. The PC-based interface, however, could offer complete auctioning functionality including complex auction setup features.
To illustrate the difference in ubiquitous acceptance, consider the fact Japan sends more email through mobile phones connected to the Internet, while sending email via the PC far exceeds wireless devices in the U.S.
Do the appropriate task on the appropriate device. Mobile phones are fine for time-sensitive, brief interactions, while PCs are good for browsing and more complex user interaction. In the future, there will likely be other devices people will use as well, such as PDAs, which may not provide long-range network connectivity. Also, all applications will be accessible through multiple devices and successful applications will exploit the uniqueness of each device and optimize their effectiveness. One of the key inhibitors of acceptance of wireless technology in U.S. is the lack of a significant number of multi-device applications.
What are the application development complexities of multiple devices? Writing applications for multiple devices is difficult. In order to create a multi-device application one needs to consider how to structure the application to take advantage of the features of a particular device. Devices vary greatly in their input and output characteristics. For example, a wireless application protocol (WAP)-enabled cell phone screen could have a monochrome screen with three lines on which to display text; a PocketPC PDA could have a rich color display; and a PC would likely have a large display. An application needs to be adapted to take advantage of the size of each of these three displays as well as take advantage of color when possible to provide the best possible user experience. Different input techniques make sense on different devices. For example, it is easy to input text into a PC but more difficult to do so on a PDA or a cell phone. It may be more appropriate to use a stylus for text input on a PDA that employs handwriting recognition and voice input on a phone. There are also some subtle usage differences in these devices. A user always carries a phone, making it a prime candidate for applications supporting time-sensitive interactions. For example, an application that monitors medication for a patient could send a message to a patient reminding the patient to take medication.
From a programmer's perspective, taming the device heterogeneity problem will be a major issue. Most approaches have focused on the presentation or user interface aspects only. We argue this is the incorrect way to address multi-device applications because in many cases the data or model that is being used for a device is different. Many approaches have suggested using the model view controller to address this issue, but the model view controller assumes different models for views. What if the model changes? Clearly this framework is not appropriate for multi-device application. A new framework is required.
Mobile phones can vary in the resources they offer. However, with the advent of microdrive and other storage media such as Flash, it is likely many phones will have large amounts of persistent storage and possibly fast processors. This will enable the devices to be truly personal; users will be able to store large amounts of personal information on these phones. Once stored, it must be processed, which could start at the phone since it no longer needs to be processed in the network. For example, multimedia messaging services (MMSs) require pictures be sent inside the network for storage and the sender must pay for the sending. What if the sender stores the picture on the device and those interested in those pictures retrieve them directly from the device and pay for the entire transmittal of the information and pictures?
One major problem remains: battery technology does not follow the same trajectory that processors and memory have followed and the available power remains a problem as more resources are added to mobile phones. The challenge will be to develop both software and hardware techniques that are power conscious. Advances will be needed at the hardware level, such as the ability to control the speed of the processor, and at the software level, such as consuming less memory to indirectly reduce power consumption. In addition, there will probably need to be much more collaboration between the hardware and the software to enable application- specific power management techniques in mobile phones.
As wireless technologies develop, it is clear a large number of network access technologies will be available for mobile phone users. For example, long-range wireless technologies such as wideband-code division multiple access (w-CDMA) have already been deployed to allow mobile phone users to get data access while roaming over large areas. On the other hand, 802.11x technologies are becoming more popular in corporate offices and in social locations such as coffee shops. Networks such as IRDA and Bluetooth are available for wireless interactions up to a few feet. From a mobile phone user's perspective this is good news—there are more chances a network connection to a service can be made. However, it would be a nightmare for developers if this heterogeneity were exposed. Imagine a situation where you are in a train working on a customer order. While you are at the station you would use the local 802.11b access points, but as you leave the station, you would begin using a w-CDMA network. If you're on a long journey, your application would have to switch back and forth constantly between two networks. At a minimum, this would entail maintaining a session between the client and the server (there are other lower-level networking issues not discussed here).
This type of roaming would mean the application must explicitly rebind to a service frequently, potentially spending all of its time managing connectivity. This is a major problem, but the more transparent this problem is to the application the better. This remains a major challenge for network protocol and network hardware developers. New standards such as Internet protocol version 6 (IPV6) and supporting technologies will significantly aid in making this problem tractable. There may be some limited cases where applications may decide to choose between networks if, for example, there is a significant quality of service difference between two networks. For example, a wide-area network (WAN) may provide much worse latencies than a Bluetooth connection if the client and the service are a few feet away. We see such optimization to be in the realm of very sophisticated programmers.
No matter how many cell towers or access points we deploy, and despite the existence of WANs, wireless local area networks. (wLANs), and personal area networks (PANs), end users may not be able to or may not wish to use the wireless network at all times. We can assume this for two reasons: First, network coverage will never be sufficient. There will continue to be dead spots with no coverage, and network coverage may not be sufficient for the task at hand. In such cases, it would be possible for the user to continue to work for short periods of time and then resynchronize as soon as the system detects a network connection to a desired service is available. The real challenge is to make sure this can be done while remaining transparent to the user or by requesting the user's assistance in a very user-friendly manner. Second, two characteristics of wireless networks are their unpredictability and they can induce long delays on network traffic. In this case the user may voluntarily move information and applications to a device and continue to work offline. Later, the user will want to resynchronize with a central repository that could be somewhere in the network. The major challenge of making voluntary disconnection useful is to let the user participate in the resynchronization process. Several models for resynchronization currently exist but they are coarse grain and for very simple personal information management style (PIM) applications. These techniques must be extended to more applications and new user interface techniques must be developed to make resynchronization easy to use.
The successful applications will be accessible from several devices. A mobile phone user will be able to roam freely between networks and continue working on an application, store information and share it from a personal device, and work disconnected from a network for a period of time before resynchronizing.
Of the four challenges we have discussed, three involve the application developer. We expect the network heterogeneity challenge to be addressed by network infrastructure developers and network heterogeneity should become transparent to the developer. However, application designers will have to be device- and connectivity-aware. A key element in the solution to this problem will be a new class of mobile computing aware design patterns and perhaps, over time, a pattern language for mobile computing.
The next "Thinking Objectively" column will discuss possible solutions to this problem.
©2003 ACM 0002-0782/03/0200 $5.00
Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee.
The Digital Library is published by the Association for Computing Machinery. Copyright © 2003 ACM, Inc.
No entries found