Personalization of End User Software on Mobile Devices

Personalization of End User Software on Mobile Devices Timo Blechschmidt, Thomas Wieland

Christoph Kuhmünch, Lars Mehrmann

University of Applied Sciences Coburg Department of Electrical Engineering and Computer Science 96450 Coburg, Germany {blechsct, wielandt}@fh-coburg.de

Siemens Corporate Technology Software & Engineering Division 81739 München, Germany {christoph.kuhmuench, lars.mehrmann}@siemens.com

Abstract Applications for mobile devices, especially mobile phones, are rarely used today – apart from games. They neither take the special features of each device into account nor the individuality of the user who has commonly a much closer emotional relationship to his mobile phone than to many other technical devices. Really useful and successful mobile applications can thus be presumably only those that address these deficits. In this paper we present a novel approach for solving these problems by personalizing Java based mobile applications. The concept centres on a powerful and flexible XML information model that can easily be utilized for adding personalized data and features to an application. The information is weaved into the code by a pre-processor prior to compilation. We also present an example of its usage and discuss some of the consequences.

This software shows even further deficiencies: It rarely takes the variety of the devices' technical features into account, not to mention the individuality of the user. Successful mobile applications will certainly be the ones that support their owner in an optimal way – make best use of the device's capabilities and of the user's preferences and interests. In this paper, we present a novel approach for personalizing mobile applications in these two respects. We start with a short discussion of the general goals of personalization, with a particular view on mobile devices and currently known solutions for this problem. For the better understanding of the following sections we then take a look at the specific technologies and challenges in the context of mobile applications. Afterwards we present the information modelling approach used in our software and the sequence flow of the program. As a proof of the concept we finally give a detailed example of the personalization process of a mobile application.

2. Software personalization 1. Introduction Mobile phones have become very wide-spread in recent years. To remain individual and unique, users often try to adapt their devices to their personal preferences. Almost all current devices allow installing background images, ring tones, or even complex themes, which change the entire appearance of the user interface. The demand for personalization of mobile phones and other smart devices is undoubtedly large. More and more of them are not just cellular phones, but also embedded computers capable of running applications written in the Java programming language. The chance of using such applications as a mean for personalization is, however, not taken by many users. One reason is that today's software for mobile devices cannot compete with software on a PC – neither in utility nor in usability. Moreover, many users are not interested in installing software on their mobile phone since the majority of the currently available applications are simple games and there are only very few programs that offer a real added value.

Software personalization in general means the adaptation of a software program to the context of the user (cf. [1]). The personal context can be defined as the entirety of all data corresponding to a particular individual, including statistical information like name, date of birth, address, occupation, hobbies, personal preferences, available technical equipment, etc. But it comprises also very dynamic data like the present location, current needs, his mood or current activity. Most of these pieces of information are relevant for a multitude of applications. In order to allow several distinct programs to access data about a user's context, a standardized representation is necessary. This requires in turn a consistent modelling of all pertinent information.

2.1. Goals of personalization The need for personalization usually arises when the usage of a certain device or service alone is not enough to differentiate oneself from the others. As long as mobile phones, e.g., were very uncommon, the ownership alone

made a person somewhat different from his or her fellows. As these devices are mass products today, other means are required to sustain one's individuality. Another driver for personalization is the overflow of information. On internet portals, for instance, a lot of different data and service offers are available, usually much more than a single user seeks. Thus providers have started to personalize their web site to allow users to filter the content according to their individual interests [2], [3]. In this way knowledge about the users can be gained that helps to optimize electronic marketing. From this perspective the goal of personalization is to know as much as possible about a customer such that he is only offered these goods and services that he is very likely to desire. So the marketing can become much more effective, avoiding the usual broad-band offers. Another advantage is that the customer retention of a personalized service is significantly higher than the one of all-purpose service. Users learn to appreciate offers that are in line with their interests and needs. They tend to use it more frequently and to return more often. This observation is particularly valid for mobile devices. "PC" is the abbreviation for "personal computer"; yet more and more users share one PC. The personal relationship to a mobile phone is much more intensive, for it belongs to the few intimate items that are carried at the body or in the handbag, respectively. Software running on these devices is thus expected to be individual at least in the same degree. As a minimum it should have some basic knowledge about the user. It is, e.g., not helpful if a route advisor on the mobile device recommends a way that includes many stairs to a person sitting in a wheel-chair. So personalization is certainly one of the keys to leverage mobile commerce. The consumers' satisfaction depends also on the technical quality, usability, and design of the mobile application. The successful realisation of an application idea is a major challenge for the developers, especially due to the great variety of the technical features of mobile devices. They differ considerably in processing power, memory, resolution and colour depth of the display, or in input capabilities. On the software side there is a large diversity in the support of various formats of image, video, or audio data as well as of the different application programming interfaces (for example for sending short messages from a program).

2.2. Common forms of personalization Today software is hardly offered in personalized form. There are, however, numerous examples where some information of the personal context is used or can be introduced. A very common feature of PC programs is the ability to adjust the appearance of the user interface in terms of

colour, shape, and arrangement of the components to the user's wishes. A well-known example is the music player Winamp (http://www.winamp.org) for which a plethora of "skins" and extensions, so called plug-ins, are available. As noted above, internet portals frequently offer the chance to make an individual selection of information sources [2]. Some providers go even further. At the portal site of the Deutsche Bahn, e.g., the user can create a personal timetable as an application for his or her mobile phone (http://persoenlicherfahrplan.bahn.de). In each such application the requested connections between two stations are individually integrated such that there is always a detailed train schedule available off-line on the mobile phone. The research project Heywow (http://www.heywow.de) has created a configurator for individual packaging of suite of mobile applications. The programs as such are not personalized, but the selection from a variety of different applications is personally configurable. All these examples have in common that they are only using their own application specific data and that personalization is thus rather rudimentary. Usually just one aspect is adjusted to the user.

2.3. Overview over approaches

different

personalization

Personalization of a software program can be done on various levels. Therefore the numerous approaches differ widely with respect to abstraction level, potential, development time, run-time behaviour, and usability. The following possibilities are generally not limited to personalization, but enable program manipulations in several directions. One idea is personalization by aspect-oriented software development [4]. Here the actual code is written in an impersonalized form and afterwards personalization information is weaved into it through certain aspects. There is support for this paradigm available for several programming languages; for Java the AspectJ package has become quite popular (http://eclipse.org/aspectj). The aspect-oriented development works on a rather high degree of abstraction. The development of complex software can be simplified by decomposing it into different aspects which are implemented separately. But the developers must first learn the AOP paradigm and the required programming tool. This approach is currently not feasible for mobile applications for another simple reason: It requires some run-time libraries which are not available for a mobile platform at the moment. The XApproach transfers the source code, which can be written in any language, into an XML tree, performs several transformations on that tree, and converts it finally back to source code [5]. The advantage is that this conversion allows almost any modification on the code provided

that the XML transformations are smart enough. It has, however, the drawback that the transformations are getting quite complex even for small examples due to the very detailed XML structure. The compiler for Java programs does not produce native machine code, but an intermediary byte code. So a possible personalization technique is the manipulation of Java byte code [6]. There are powerful tools for byte code engineering, like the BCE library from Apache (http://jakarta.apache.org/bcel). The change of values of class attributes is quite easy and fast, but more sophisticated manipulations like including or omitting certain code sections are hard to realize. Personalization statements in the Java code must be mapped to their positions in the byte code in order to adjust them. The most classical approach is certainly the modification of the source code prior to compilation by a precompiler or pre-processor. This technique is well-known from C compilers. It is very effective, easy to learn, and can be confined to a small number of constructs. If the pre-processor commands are added as Java comments, even the usual development tools can be used. Due to these advantages, we have selected this approach for our realization. A lot of the functionality of our pre-processor might also be achieved by a single application file and additional on-device configuration files. This possibility has, however, several drawbacks: An application that includes specific code for all supported devices can blow up so much that it gets too large to be launched or even stored on certain devices. Also including any possible resource (i.e. all images available) can make the JAR data extremely big. The pre-processor allows limiting the code to the parts that are actually required and thus permits more extensive applications or slim MIDlets with faster transmission, respectively. A static vendor site compilation also deprives the application of the possibility to be adapted to the user’s context at transmission time. Moreover functionality the user has not paid for or code parts that contain somewhat confidential information are definitively left out. They might otherwise be revealed by a reengineering attempt.

2.4. Personalized software vs. adaptive software The next step in personalization would be adaptive software, i.e. programs that try to optimize usage and their behaviour during run-time by learning from the way it is used (cf. [7]). The advantage compared with personalized software is that the adaptation is not done only once, but continuously, taking the current situative context fully into account. So it is possible to react to quickly changing context information like time, weather, or mood and desires of the user. The clear downside is that this personal context must be determined at run-time. This requires

extensive computations and data bases what is not reachable on mobile devices at the moment. Another disadvantage is that the development becomes even more complex, as the optimization has to be fully automatic. An adaptation at compile-time is then just very preliminary for almost all possibilities to which the program should be able to react have to be integrated. So from the present point of view, personalization seems to be to some extent superior to adaptation. Not every program has to adapt itself to the user again and again. The information gained once can be used for personalizing other applications, maybe offered by other vendors. A central off-line information model about a certain user provides a much more consistent view on the user's preferences. If it is known, e.g., that the user is handicapped, a larger font or speech output can be integrated in every application he buys without him having to enter this information each time. Such functionality is detected by adaptive software only a posteriori which leads to a difficult adaptation procedure.

3. Challenges on mobile devices The most common way to produce third-party software for mobile phones is the Java 2 Micro Edition (http://java.sun.com/j2me). The structure is somewhat different to desktop or server editions such that we will give a brief sketch for introducing the relevant notions.

3.1. The Java micro edition The ability of personalizing applications is especially interesting for mobile devices, as the technical differences between them can be rather large and the release cycle of new models is quite short. The fast evolution of the hardware makes it necessary to standardize new program application interfaces continuously. The Java Community Process (http://www.jcp.org) which specifies and publishes new APIs as Java Specification Requests (JSR) is sometimes not fast enough for the phone vendors such that they add proprietary implementations that may be quite close to the standard, but not portable. Moreover it is left to the manufactures, which Java standards they include in a certain device. So the developer of a MIDlet for a particular device needs not only to know which version of CLDC and MIDP are supported, but also which APIs of additional JSRs are accessible (for the J2ME notions see http://java.sun.com/j2me). At the end of the day he has to decide on which range of devices the software is required to run. The development is then limited to the smallest common denominator of them.

Fig. 1. XLM structure for a person profile (extract)

3.2. Privacy and acceptance Another major challenge for creating personalized mobile applications is the acquisition of the required personal data. These can be gathered in different ways: Some pieces may be detected by sensors or by other automatic means, some have to be asked from the person. Other data may be determined through observation of the user. Especially collecting and storing personal data in the background unattendedly leaves many people with a sceptical feeling. The danger of misuse should not be underestimated as experiences from the internet in terms of spam e-mails and phishing attacks show. So it should be evident for every user which data about him is stored. In addition, he or she should be able to correct or delete a certain entry. If the personalization process cannot be performed at the site of the owner of the data, but has to be carried out at a third party site, personal information should always be transmitted in an anonymized form, instantly informing the user which information about him is currently sent to which sink. He should be able to fade out certain data completely, even at the price of a less accurate personalization. A successful business model based on personalized mobile software depends crucially on the trust of the customers.

4. Design of the pre-processor For realizing the personalization of program code for mobile software applications, we selected a pre-processor approach. This technique is relatively easy to learn, smooth to integrate in typical development chains, as well as very flexible and powerful. But before going into de-

tails about the personalization process, we have to make clear which kind of data we want to use at all. In fact, we need a sound information model that represents the entire range of relevant user-specific data [8], [9].

4.1. Modelling the information One of the most extensive information models for representing properties of mobile devices is the User Agent Profile (UAProf) defined by the Open Mobile Alliance (http://www.openmobilealliance.org). Corresponding profiles are available for most mobile phones currently on the market, storing many details about a certain device. They can be used for selecting compatible applications, adapting content or as a reference during software development. The profile comprises, e.g., data about display size or keyboard layout, the supported Bluetooth services, and known data formats used in handling MMS messages or displaying WAP pages. But the UAProfs do not include any user-related information. A model for this purpose should not assign discrete values for many properties of human behaviour, but should offer a numeric range for them [10]. Especially when representing interests, discrete values like "interested in politics: yes/no" are inappropriate. There are different sub-areas of a particular field of interest, like global, domestic or local politics which in turn depend on various factors, e.g., the situation in the Middle East or the closeness to the next local elections. Moreover it has to be considered that some data changes continuously. If a hiking guide selects a certain tour according to the physical condition of its owner, the latter is likely to change when he goes hiking regularly. So, gradual adjustments must be possible.

The model has to be open in any sense. The list of available attributes must not be pre-defined and thus limited and static, but should be extensible if some applications want to use specific data which was previously not anticipated. Within the model, some way must be offered to define how this new information can be determined or asked from the user. We used XML for all data used for personalization (cf. Fig. 1). Thus it can be easily structured and exchanged, even partially, between the different components. Even the required extensibility can be achieved this way. The relationship between different entries and XML nodes is expressed in terms of a simplified XPath addressing scheme [11]. For referencing the first name, e.g, in an XML document following the structure from Fig. 1 the address would be "/person/name/firstName". These XPath expressions are used whenever certain pieces of information must be referenced. If XPath is used for evaluation of a value, the full functionality of XPath is supported. For collecting information from the user, several dialogues must be used. These dialogues are also defined as XML entries for flexibly describing how the user should be asked for a particular detail. The dialogue elements comprise the references data as XPath address, the question, a description – if necessary –, and an element specifying the possible answers (see Fig. 2). Do you have a nickname? Please enter your nickname so the program can address you directly. Fig. 2. Example of a definition of an input dialogue

Many values can be calculated from previously known data. For example, the age of a person can be evaluated as the current date minus the date of birth. It can then be used to grant or deny access to adult content – provided the date of birth is correct and verified. For such evaluations, a similar XML definition is used. It includes the XPath addresses of related data as well as the type and formula of the calculation (see Fig. 3). Fig. 3. Example for a definition of an evaluation

For representing data about the Java platform, the device capabilities, available codecs, display quality, etc. we use a refinement of the UAProf mentioned above. For simplifying handling and XPath addressing, we have restructed the UAProf content to some extent. The user agent profile is once read and converted so that the access to this data later integrates smoother in the entire system. Details that vendors do not include in the UAProf can be added by hand to this file.

4.2. Program flow of the personalizer For controlling the personalization process we use the tools Ant (http://ant. apache.org) for the automation of recurring procedures and Antenna (http://antenna. sourceforge.net), a collection of Ant tools for wireless Java development. The personalization of a MIDlet is done in the following steps: • First all pre-produced content is copied to the output directory. This includes the byte code of classes that are not personalized as well as locally available resources like images or sounds. • Then the pre-processor is run on the source code, evaluating and removing IF statements, along with computing necessary values. • At this state the JAD file is created. This file type is required by the MIDlet specification as an application descriptor for the application management system on the mobile device. • Now the source code is actually compiled by the usual Java compiler that comes with the J2ME Wireless Toolkit. • Afterwards the byte code is checked for references to classes in order to determine which classes of the package are actually used. The list of all used classes that are required for the application is written in a file for production information. • Having completed this, the required resources for the classes in use can be determined and collected. This may include downloading external files, e.g. multimedia files.

• Finally the byte code is checked with the J2ME preverifier and the JAR archive is created. Now the application is ready to be copied to the mobile device. If desired, the package can additionally be optimized by an obfuscator (like ProGuard, http://proguard.sf.net) which removes unused code parts and renames identifiers to complicate re-engineering.

4.3. Code personalization The main tasks of the pre-processor are including or removing code parts and assigning values to certain variables. In the source code the programmer can include or omit a code block depending on Boolean expressions (see Fig. 4) //@IF person/preferences/guidance/ useAudioGuidance // user wants speech output for route information Display.getDisplay( this).setCurrent(audioPlayerCanvas); //@ELSEIF person/preferences/ guidance/useMap // user wants a map for navigation Display.getDisplay( this).setCurrent(textGuideForm); //@ELSE // user get textual instructions Display.getDisplay( this).setCurrent(textGuideForm); //@ENDIF //@IF person/age >= 18 System.out.println( "User is 18 or older"); //@ENDIF Fig. 4. Example code for selecting code parts by Boolean expressions

The assignment of personal values to a variable can be done with the ASSIGN statement. It may be given along with the declaration or at any other position of the program. Even default values are possible. An example is:

source code directly or in the application description. Files of images, videos, sounds, etc. can be references a entries in the local file system of the production computer or as URLs for downloads from the internet.

5. Example As an example we created a Tourist Guide application. It should plan a sight-seeing tour through a city for the user. Start of the tour is either the current location or the user’s residence (hotel). The selection of the places of interests depends heavily on the user’s actual interests. He might have visited some places already; thus parts of the application history have to be taken into account. If he is on vacation in a foreign city, for example, and wants to make such a tour each day, he certainly wouldn’t like to see the same places over and over again. The selection of the means of transport is also dependent on his interests. Maybe he has rented a bicycle and wants to ride this or he prefers to take taxis. Perhaps there are even rickshaws or horse-drawn carriages available for which, however, the costs play an import role.

5.1. Description of realized showcase The application we developed as a showcase is, however, still somewhat simpler. For means of personalization, the following issues can be set: • • • • •

The name of the user The name of the city through which guidance is wished Image of the city central (or another landmark) Switch between map-based and text-based guidance Maps for the surroundings of certain points of interests, in a user-friendly orientation

The code in Fig. 4 is taken from this example. The resources, i.e. maps and guide texts, are also inserted by the personalizer. This means for the text, e.g., the following commands: /* * @RESOURCE * @image.src.name = 'textGuide.txt' * @image.dest.name = 'guide.txt' * @image.isMandatory = 'true' */ InputStream is = getClass(). getResourceAsStream("/guide.txt"); // further processing of input text

private String name; //@ASSIGN person/name/nickname Moreover, external resources that are required for the execution of the program can be defined either in the

The same part for the map based guide is a little more complex as the map image probably must be resized for the device display size.

/* * @RESOURCE * @image.src.name = 'images/karte.gif' * @image.dest.name = 'map.jpg' * @image.resize.width = device/hardware/screen/width * @image.resize.height = device/hardware/screen/height * @image.resize.keepRatio = true() * @image.isMandatory = 'true' */ InputStream is = getClass().getResourceAsStream( "/map.jpg" );

Fig. 5. Production.xml file for the personalization process

The MIDlet as such is not very spectacular, but it illustrates how personalized information can in principle be woven into mobile applications.

When the data about the user and its device has been determined, a file production.xml is generated that contains all details used for the personalization process. In our case it could like in Fig. 5. Munich 12 34 bob 45 56 true north false false 128 128 Siemens/S65 MIDP_2_0;CLDC_1_1

Fig. 6. Welcome screen of the Tourist Guide application

Fig. 7. Screenshot of the map part

A major advantage of the pre-processing approach for this application is that the maps and city information can be kept and produced separately from the MIDlet code. They are generated in the very moment the application is compiled, i.e. when the user starts to download the application to his device, e.g. in the railway station or at the Tourist Office.

5.2. Possible distribution scenarios The last question is: How should the application come to the mobile phone? The most common distribution channel for MIDlets are SMSs. This has a clear disadvantage for personalized applications: The user has to either identify such that his stored personal data can be taken or he must go through various questions in specific dialogs, e.g. in form of a separate MIDlet or even WAP pages. All

these perspectives are not very attractive and not suited to broaden the number of users considerably. A much more promising alternative is in our opinion a software kiosk. This means a stand-alone terminal with a touch-screen display, like the usual ticket machines. Here the interaction with the user can be designed very simple and effective. If the actual personalization is run on the same machine, the user's anonymity can be kept – for all the data she entered is deleted after the production process. Moreover, it is easy to integrate several payment options in such a terminal. The application may then be transmitted to the mobile phone via Bluetooth. Another scenario is a subscription for specific news a user is interested in. He orders such a subscription on a web site where he gives detailed information about the news he would like to read about. When he rides to work on the subway in the morning, a Bluetooth node at a station can detect and identify his mobile phone. A personalized news application is generated and transferred to his device. So he can read the latest news he is really interested in every morning (maybe also every evening) during his subway ride. As personalization is a relatively new approach for mobile applications, there are certainly many more usage scenarios and business cases for this technology.

6. Evaluation and conclusion Software personalization has benefits and risks for the developer and the user as well. A disadvantage for the developer is that the development is more complex. It has to be determined in which aspects the application should be personalizable and which factors should be taken into account. This leads to more work in the design and implementation phase. Also the definition of requirements and the testing become considerably more complicated as any possible value and the resulting application variant might need to be tested. The big advantage is more economically: Applications are addressing a much large group of customers, satisfying each of them with an application following his very own needs. From a technical point of view, the program can use the full range of available APIs that is actually supported on the mobile device, even if the interface is vendor specific. Moreover the packages are somewhat smaller than conventionally developed ones, offering the same benefit to the user. There are not apparent disadvantages for the user. But the question may arise if his needs are really followed as precisely as possible. There is always the risk that the collected data is misused for other business purposes. So the entire concept depends on the trust that the user is willing to give to the system. If users are not feeling safe when entering their personal details, they will probably not pay for personalized applications. On the other hand, they

know that the benefit of certain services can require abandoning some privacy. The more people become convinced of its usefulness, the more it will be taken for granted.

7. References 1.

Blom, J.O.: Designing Personalized User Interfaces in Ecommerce. Kluwer Academic Publishers, Norwell, MA, 2004. 2. Manber, U., Patel, A., Robison, J.: Experience With Personalization of Yahoo!. Comm. ACM, Vol. 43/8, 2000, pp. 3539. 3. Langley, P.: User modeling in adaptive interfaces. Proc. 7th Intern. Conf. User Modeling. Springer, Banff, Alberta, pp. 1999, pp. 357-370. 4. Kiczales, G., Lamping, J., Mendhekar, A. et al.: AspectOriented Programming. European Conference on ObjectOriented Programming (ECOOP), Springer, Heidelberg, LNCS 1241, 1997. 5. Reichel, C., Oberhauser, R.: XML-based Programming Language Modeling: An Approach to Software Engineering. Proc. SEA 2004, MIT Cambridge, MA, 2004. 6. Dahm, M.: Byte Code Engineering. Proc. JIT '99, Springer, Berlin, 1999. 7. Robertson, P., Shrobe, H., Laddaga, R. (eds.): Self-Adaptive Software. Lecture Notes in Computer Science, Vol. 1936, Springer Verlag, New York, 2001. 8. Bonnet, S.: Model Driven Software Personalization. In: Proc. Smart Objects Conference (SOC 2003), Grenoble, 2003, pp. 114-117. 9. Banavar, G., Bernstein, A.: Software infrastructure and design challenges for ubiquitous computing applications. Comm. ACM, Vol. 45/12, 2002, pp. 92-96. 10. Card, S., Moran, T., Newell, A.: The Psychology of HumanComputer Interaction. Lawrence Erlbaum Associates, Publishers, Hillsdale, New Jersey, 1983. 11. World-wide web consortium: XML Path Language (XPath) 2.0. http://www.w3.org/ TR/xpath20/, 2004.