Towards a unifying Approach to Mobile Computing - CiteSeerX

Towards a unifying Approach to Mobile Computing Carsten Magerkurth and Thorsten Prante GMD – German National Research Center for Information Technology, IPSI – Integrated Publication and Information Systems Institute, AMBIENTE – Workspaces of the Future, Dolivostr. 15, D -64293 Darmstadt, Germany {magerkur, prante}@darmstadt.gmd.de ABSTRACT In this paper we address the diversity of mobile devices and the related problematic issues with a largely platformindependent approach to development. Our work is motivated by the amount and variety of mobile devices foreseen to reside in future ubiquitous computing environments. To reduce the development effort and to augment data exchange facilities , we present an application framework that abstractly defines common interaction objects in user interfaces on mobile devices. POINTS OF DEPARTURE Today, the domain of mobile computing is as diverging as the domain of desktop computing was some twenty years ago. Just like in the early days of home computing, when computer manufacturers enforced incompatibility even within their own range of devices, there are numerous excluding alternatives emerging for the mobile user. Purpose of Mobile Devices There is no widely accepted standard of what mobile computing should be like. Different device classes, such as palm- and pocket-sized PCs, or WAP enabled mobile phones with different operating systems, such as PalmOS, Linux, EPOC, or Windows CE support different paradigms regarding the purpose and applicability of mobile computing [1, 5]. From a developer’s point of view, it is crucial, whether a mobile device is to be used as a mere data viewer or a remote control, as e.g. Rekimoto’s “painter’s palette” [7] or, on the other hand, as an autonomous system that can operate independently to some degree [4]. The former approach moves most of the application’s functionality away from the mobile device requiring a tight connection to stationary computer systems. For instance, this is the case with the mobile phone’s WAP browser and the corresponding ISP. The latter approach enables more independent work, but puts higher demands on processing power and memory resources.

integrate with other technologies. This has led to the now highly cluttered market, where devices of different types are hardly able to work together in a useful way. Most of the proprietary platforms alone do not make up a market share worth investing development resources to a duly degree. Consequently, even though, there are sufficient similarities amongst most kinds of mobile devices, applications are mostly available just for a single platform. In addition, the possibilities of cross-platform data exchange are still moderate, even if similar communication hardware and protocols, as e.g. IrDA, are used. For instance, telephone numbers can be stored on every single mobile device, be it a mobile phone or a subnotebook. However, the applications provided to administer these data are different for each platform. Worse still, there hardly ever is a way to exchange these simple data. Even the largely device independent WAP technology has not yet gained enough attention to raise a sufficient software infrastructure. Many WAP internet offers are buggy or lack features [1]. UbiComp and CSCW In the context of ubiquitous computing [8] and computersupported cooperative work (CSCW) the lack of crossdevice availability of the software and the implied la ck of cross-device data exchange is especially harmful, because most interesting functionalities only emerge through using multiple devices together. For example, efficient and fluent work across platforms and different media can only be realized, if media breaks are prevented, i.e. if the user does not have to perform additional explicit actions associated with data transmission from one device to another [6]. Therefore, it is essential to provide a seamless application infrastructure on all of the devices in a CSCW setting, if the domain of mobile computing should contribute more than a collection of single-user toys. APPROACHES

Proprietary Platforms Currently, there are numerous mobile technologies on the rise and most of them come along with very proprietary programming interfaces and tools offering little facilities to

In our opinion, device independent application programming technologies like Java and to some extent WAP are not the most adequate answer to these problems of the mobile domain. Relying on common features that are

SIGGROUP Bulletin xxx 2001/Vol 22, No.x 1

available on any of the platforms and standards inevitably implies both losing the flexibility to cater to specific features of the various devices as well as introducing a performance overhead, provided that the underlying hardware is indeed heterogeneous and the software performance is a crucial criterion. As long as the scope is not extended to include more than handheld devices, the loss in flexibility may not be fatal for the mobile domain. However, for most of the upcoming CSCW scenarios where various devices with very different characteristics, e.g. large vs. small displays as well as different interaction facilities, have to be able to interact with each other, this will gain importance. On the other hand, the performance loss is a most crucial point and thus demands solutions implemented with regard to the underlying operating system. In the future this point might lose importance due to the advent of more powerful processors in mobile devices, but with respect to power consumption this remains to be seen. Our approach is to make use of the similarities in mobile systems’ user interfaces while refraining from any unworthy bytecode overhead that is especially fatal in the context of mobile devices with their heavily constrained resources. We opt for supporting various devices by introducing scaled implementations of user interface components that are applicable to more or less all mobile systems. For instance, a text button on a mobile phone might be made up of a simple sequence of characters surrounded by a black frame. To press it, users have to make use of the hardware buttons on the device, due to the lack of a touch-sensitive display. On an EPOC handheld PC, however, the button can be a more sophisticated control which can, e.g., easily be dragged about the display with a stylus. Nevertheless, from the application’s back-end view, a button is always just a button, i.e., a medium for communicating the user’s request to have a corresponding action performed. Likewise, the application itself does not need to bother, if the user is picking his theatre tickets from a plain combobox or a highly polished, rotating, zoomable listcontrol. In essence, it is about presenting a set of alternatives to the user so that he may make a suitable selection, i.e. a selection from which he anticipates the most desirable result. For the selection process and the further flow of the application it does not make any difference, if the device allows for advanced controls with built-in search functionality or just a few lines of plain text (see figure 1).

2 SIGGROUP Bulletin xxx 2001/Vol 22, No.x

Figure 1. Different list-controls share identical purposes. In our opinion, it suffices to abstractly define only a very limited set of user interface controls applicable to mobile devices and implement them differently with regard to the specifications of the respective mobile platform (see figure 2). We found that we actually never needed more than a button, a list/ menu of alternative choices, a text/ bitmap display, and an edit field. None of these controls are provided with exact positions or sizes by the respective application, since we are not dealing with user interfaces based on the windows metaphor, but mostly with modal interaction objects that have the exclusive attention of the user. This brings up the question how far one can g et with such a simplistic user interface definition with respect to the range of applicable devices. This is somewhat difficult to agree on, since the borders between different device classes are blurring. Not only are large computers of the laptop class shifting progressively towards mobile phones by reducing size and adding communication features. The formerly smallest class of mobile phones is correspondingly turning more and more into sophisticated computer systems with more CPU power; high bandwidth multimedia facilities will emerge once the upcoming standards such as UMTS are implemented. At least for today’s mobile phones and palm-sized PCs with display dimensions that cannot hold much more than one major control at a time, one can clearly apply this UI definition, while notebooks and laptops are rather out of range. Anything in between these extremes is prone to be subject to a gradient progress. Further gains come into play when the scope of this UIoriented approach is augmented to unify the non -user related parts of an application’s front-end. For instance, mobile devices differ significantly in the way data is accessed. While there is a full featured file-system on PocketPCs, a PalmOS system is limited to a database model that lacks the notion of traditional files and introduces several uncommon accessing concepts, instead. However, for both the end-user and the programmer, i.e. the “user” of the programming interface, it is irrelevant how data is stored. The user expects to assemble pieces of data that are somehow related and store them with an attached label that provides cued information about the actual data at a later point in time.

Therefore, in analogy to the definition of the UI components, it is desirable to only offer a basic and wellknown interface for dealing with files, no matter how distant the platform-specific implementation to this may be. We are developing a C++ application framework (independent application framework, iAF) that adheres to the principles described above. iAF currently consists of a number of abstract interface definitions for the supported user interface components as well as file I/O and additionally simple audio/ visual output. Class implementations are available for PalmOS, Win 32, Win CE with an EPOC port being close to usable.

Platform neutral Application

iAF Implementation

to limited resources. Thus, cross-platform compilers running on well equipped desktop machines have to be used, instead. This implies that the development process is subject to a permanent overhead, for testing cannot occur appropriately. While common development environments strive to support the debugging process with various elaborated tools, many of the mobile devices such as mobile phones are a black box, where proper functioning must be inferred. If useful emulators are available, the burden of uploading to real devices is taken from the developer and some sort of source -level debugging becomes an option. However, the inherently different architectures of most mobile devices cast a performance loss on the emulation which makes this a painful and frustrating experience [3]. Therefore, a very positive effect of the use of our framework is a noticeable acceleration of the entire development process ,working towards the goal of an effective cross-platform software infrastructure. This is due to the possibility of building native desktop executables which permits test-drives of native applications instead of crawling through emulated code or inferring from the behavior on real devices.

Implementation CONCLUSIONS

Figure 2. iAF overview

EXPERIENCES We use iAF not only for the development of a creativity support tool described in [4], but also in the development of a number of commercial PDA entertainment software titles. Even though it may not be the most representative application domain for mobile comp uting, for computer games it has been shown that using proper abstractions there is a surprising amount of similarities in user interface programming between full blown desktop applications and PDA software [3]. Keeping a high level of abstraction regarding the user interaction code still has another effect: The development cycle of a software title can be shortened significantly, especially when targeting multiple mobile systems. Provided that the user interfaces are implemented using scaled, system-specific functionality it becomes trivial to serve different platforms. Applications based on iAF are 100% source code compatible amongst all supported platforms. This is for the benefit of unifying the mobile software infrastructure by effortlessly targeting different platforms providing cross-platform data exchange facilities. Moreover, it addresses a further issue in software development for mobile computing: Mobile devices hardly ever host their own development tools due

We have discussed problematic aspects of developing for multiple mobile devices regarding user interaction and ease of development. We have proposed scalable interaction objects that are shared among the various devices. The issue of proprietary platforms is tackled by allowing to write and test native executables on powerful machines. This also reduces development overhead, when faced with the foreseen flood of mobile devices in UbiComp environments. REFERENCES [1] Bager, J., & Bleich, H. (2000): WAP-Galerie (in German). In: c’t Magazin 9/ 2000, S. 200 – 207. [2] Greenberg, S., Boyle, M. & Laberge, J. (1999): PDAs and Shared Public Displays: Making Personal Information Public, and Public Information Personal, in Print [3] Magerkurth, C. (2001): Programming Windows To Create Palm Games. In: Proceedings of the Game Developers Conference 2001. San Francisco: CMP Media, 2001. [4] Magerkurth, C. & Prante, T. (2001): Metaplan für die Westentasche - Mobile Computerunterstützung für Kreativitätssitzungen (in German). In: Tagungsband der GI-Fachtagung Mensch & Computer 2001 (MC‘01). Bad Honnef: Teubner Verlag, 2001. [5] Myers, B. A., Stiehl, H. & Gargiulo R. (1998): Collaboration Using Multiple PDAs Connected to a PC. In: Proceedings of the ACM Conference on Computer Supported Cooperative Work (CSCW’98), 1998, 285-294. [6] Prante, T. (1999): A new pen-centric user interface to support creative teamwork in roomware environments (in

SIGGROUP Bulletin xxx 2001/Vol 22, No.x

3

German). Diploma thesis, GMD-IPSI, Technical University of Darmstadt, Department of Computer Science. [7] Rekimoto, J. (1998): A Multiple Device Approach for Supporting Whiteboard -based Interactions. In: Proceedings, CHI’98: Human Factors in Computing Systems, 1998, 344-351. [8] Weiser, M. (1991) The computer for the twenty-first century. Scientific American, Sept. 1991, pp. 94–104.

4 SIGGROUP Bulletin xxx 2001/Vol 22, No.x