Gulliver Beans: Generating Device Optimized and ...

Gulliver Beans: Generating Device Optimized and Individualized Content for WAP Applications

Seite 1 von 7

Gulliver Beans: Generating Device Optimized and Individualized Content for WAP Applications Gerhard Austaller, Andreas Hartl, Gerti Kappel, Christoph Lechleitner, Max Mühlhäuser, Siegfried Reich, Rimbert Rudisch The Gulliver Projekt Team University of Linz, Austria [email protected]

Abstract The ever increasing popularity of the Internet results in a growing number of users being connected to the World Wide Web with new types of devices ranging from PDAs to mobile phones. However, existing content has not been designed with the benefits and limitations of these devices in mind and thus various approaches have been established to overcome this issue. Our approach strictly separates between content, presentation and behavior in order to be able to dynamically generate adapted and individualized content. Besides device information our prototype system takes other context data into account including location and user preferences. Our approach allows us to semi-automatically produce content which is not only optimized for the target platform but also designed for the individual users and their specific needs.

1 Introduction In today's world of the Web it is very common to (manually) create content for various browsers (and versions thereof). For instance, many HTML pages contain markup which can only be processed by specific browsers and which is optimized for specific platforms ("best viewed with browser version X and a resolution of Y"). This very much contradicts the idea of platform independence [8]; it prohibits certain users from viewing content; and it is a tremendous effort to maintain these pages. The situation is to become worse with WAP (Wireless Application Protocol) which allows to access the Internet with small devices such as mobile phones. The hard limitations set for instance by today's generation of mobile phones (e.g., size of display, non-multimedia capabilities, restriction of buffer size, etc.) will prevent many interested people from using content available on the Web. Therefore, the need for browser and device optimized presentation of content is obvious. Moreover, we argue that content should be optimized according to the users' specific needs by taking various types of context data into account. The Gulliver project addresses these issues by providing an application environment that separates content, presentation and behavior (cf. the MVC Model [6]). The name Gulliver follows Jonathan Swift's novel "Gulliver's Travels" indicating the system's support for mobile users. This paper is structured as follows. Section 2 presents related work. Then, in Section 3 we describe the Gulliver platform. Next, Section 4 discusses the approach presented. We finish with a summary and conclusions.

2 Related Work Several approaches for creating device-optimized code from an abstract representation of content can be identified. Figure 1 presents an overview. The axes denote client side vs. server side processing and http://www.ifs.unilinz.ac.at/ifs/projects/gulliver/papers/www9workshop/

10.03.00


Seite 2 von 7

dynamic vs. static generation of content. In the following we will briefly refer to these approaches; then, in Section 3, we will describe the Gulliver system in more detail.

Figure 1: Overview of Approaches for Creating device-optimized Code. z Structure and style sheets: This approach implies that content is stored independently of the target

language by using XML as a declarative specification language. XSL style sheets can then be used to define the replacement of XML element types with tags specific to the target language. The transformation is done dynamically either on the server side or at the client. This idea is a simplification of using Composite Capability/Preference Profiles (CC/PP) as proposed by the W3C [9]. z Scripting code: Using this approach the presentation is calculated at the client side. Pages transmitted consist of content and scripting code. At runtime, the scripting code is executed and compiles an appropriate presentation of the content by generating the required target format (e.g., WML or HTML). This approach is not feasible in situations where for instance mobile devices set restrictions in code size or computing power. z Pre-generation: It is common practice on the WWW to pre-generate static Web pages so that they can be accessed at prime time [5]. While the WAP architecture does not prevent this approach it does not meet two major challenges: firstly, browsers for WAP devices are even more heterogeneous than today's Web browsers; secondly, most WAP applications are expected to deliver dynamic content with a high update rate thus leading to a humble lifespan for a single static page. In summarizing, none of the approaches presented above seems feasible for today's generation of mobile devices. The main reasons are the lack of computing power and the limitations in screen size.

3 The Gulliver Platform Gulliver (see: http://www.ifs. uni-linz.ac.at/ifs/projects/gulliver.html) is an open platform for the development of WAP based applications. One goal when designing Gulliver was to provide mechanisms to easily create pages which fit best to the output device. WAP devices are expected to range from watches with small displays to mobile phones and organizers with comparatively big displays. Hence, the most important design decision was to divide the content representation from the target languages (i.e. different versions of WML, HTML, etc.). Therefore, programmers only need to create a content model (i.e., a content tree containing so-called Gulliver Beans) and a semi-automatic mechanism (explained later in Subsection 3.2) cares for http://www.ifs.unilinz.ac.at/ifs/projects/gulliver/papers/www9workshop/

10.03.00


Seite 3 von 7

generating device optimized markup code. Figure 2 shows the Gulliver architecture. All Gulliver components have been implemented in Java with the communication between components realized with RMI. Requests generated by WAP-enabled devices are converted into HTTP requests by a WAP-Gateway and forwarded to the Gulliver IO-Interface. This interface is implemented as a Java Servlet. It translates incoming HTTP requests into events which are processed by the Application Manager. The Application Manager handles a set of Gulliver applications, ranging from simple directory services such as timetables up to more sophisticated services like guided tours [2]. All components that need to store and retrieve persistent data use a dedicated database interface which abstracts from the underlying storage mechanism [1,7].

Figure 2: The Gulliver Architecture.

3.1 Gulliver Beans Gulliver Beans provide the infrastructure for modeling content and feedback independent of target languages and output devices. The advantages of this approach are as follows: z No restrictions on target languages or output devices: Gulliver Beans enable the creation of

content presentation and navigation without the need of knowing output device or browser. Programmers are able to choose from a set of pre-defined Beans including Label, Input, CheckBox and others (see also Figure 3). But there exist also more sophisticated Beans for modeling complex user interaction such as Dialogs or Menus. A dialog for example is used for guiding the user through several inputs; menus let users make their choices. By combining these Beans a device and browser independent content tree is built (see also Figure 5 b)). Browser requests and user feedback are different events that can be evaluated by Gulliver Applications in order to determine state information and to create new content trees. z Dynamical creation of content: State-of-the-Art applications which support personalized

presentation of content demand for dynamic content generation. This is supported on one hand by parameterizable Gulliver Beans and on the other hand by the possibility to create the content tree at runtime by the application. z Building blocks of well-known GUI elements: During the design of the suite of Gulliver Beans it

became apparent that not only primitive widgets needed to be supported but also more sophisticated ones. With these group widgets it is possible to represent a coherent user interaction. By that well established user interface guidelines such as [4] can be implemented. z Provisions for reuse: Gulliver Beans can be reused in several ways. Firstly, the object-oriented

http://www.ifs.unilinz.ac.at/ifs/projects/gulliver/papers/www9workshop/

10.03.00


Seite 4 von 7

nature of Java supports reuse by inheritance. Secondly, individual Bean objects can be reused. E.g., the authentication widget will always look the same and therefore it can be created once and then reused every time it is needed. The widgets' names and functionalities were adopted from those known of desktop applications. This allows programmers to reuse existing knowledge and avoids learning overheads. As will be shown in Subsection 3.2 programmers do not need to care about generation of output for specific devices. Figure 3 shows an excerpt of the Gulliver Bean class hierarchy.

Figure 3: Part of Gulliver Bean Class Hierarchy. The classes shown can be characterized as follows: z z z z z z

GulliverBean: the abstract root class; BeanBox: contains the root Bean of the content tree to be generated; Input: used for asking users for inputs; (Multiline-)Label: used to display information on the device's screen; Group: used to group Beans together to composite objects; StaticGroup: like Group but can only include static Beans, i.e. Beans which do

not allow for user

input; z Dialog: a more sophisticated Bean for grouping user inputs; z InfoBox: a composite Bean for displaying information.

Next, in Subsection 3.2 we will describe the inner workings of the Bean lookup procedure in more detail.

3.2 Gulliver Beans' Internals Besides data describing the content Gulliver Beans also contain the specification of the event which is passed on to the application in case a component support user inputs. In other words, Gulliver Beans provide knowledge about the interaction model used. It is the IO-Interface's task to generate code for the target language. The interface relies upon Behaviors to accomplish this goal. Behaviors are classes which contain knowledge how to convert a given model into a view (i.e., markup language code). Behaviors are identified by their class name and must conform to the naming convention described in Figure 4. BehaviorName ::= GulliverBeanPackageName+BehaviorClassName. BehaviorClassName ::= [Modifier]+GulliverBeanClassName+"Behavior". Modifier ::= [ProductID]+MarkupLanguage. GulliverBeanClassName ::= "Label" | "Dialog" | "Input" | ... ProductID ::= Vendor+[DeviceName+[DeviceVersionID]]. DeviceVersionID ::= "V"+MajorVersion+MinorVersion


10.03.00


Seite 5 von 7

Figure 4: Naming Conventions for Behaviors. For example: a label should be rendered for the Siemens S35i mobile phone with firmware version 1.2 using WML as target language (Note that minor versions are restricted to the numbers 0 to 9). The search for the appropriate Behavior is done in the following order: z z z z

gulliver.beans.SiemensS35iV12WMLLabelBehavior gulliver.beans.SiemensS35iWMLLabelBehavior gulliver.beans.SiemensWMLLabelBehavior gulliver.beans.WMLLabelBehavior

In case no specific Behavior can be found a default Behavior is used. The example also demonstrates that different versions of the firmware can be supported.

3.3 Gulliver Applications In order to proof the benefits of the Gulliver Beans concept several applications were developed. These range from simple directory services such as timetables or snow reports up to more sophisticated services like the "Vienna Guided Tour" service [3]. From a programmer's point of view the suite of Gulliver Beans can be used as shown in Figure 5 a); Figure 5 b) shows the according content tree. private GulliverBean buildAuthentificationPage(){ gulliver.beans.Dialog dialog = new Dialog("dialogIdentifier"); gulliver.beans.Label l = new Label(); l.setCaption("Willkommen bei Gulliver"); dialog.addElement(l); gulliver.beans.Input in = new Input("phoneNumberIdentifier"); in.setCaption("Bitte Telefonnummer eingeben"); dialog.addElement(in); in = new Input("passWordIdentifier"); in.setCaption("Bitte Passwort eingeben"); in.setPassword(true); dialog.addElement(in); return dialog; }

Figure 5: a) Sample Gulliver Authentification Bean.

b) Content Tree.

The content tree is rendered by the IO-Interface and device specific output is generated. Figure 6 shows the result after rendering the content tree for a typical mobile phone and for a standard Web browser.


10.03.00


Seite 6 von 7

Figure 6: Output on Mobile Phone (left) and Web Browser (right).

4 Discussion By implementing several applications using the Gulliver development environment we have tested our approach and we are able to discuss first results. In particular we would like to mentoin the following points: z Abstraction from target language: There is no need for programmers to bother about target

languages. The specific output format is generated automatically at runtime by the IO-Interface. z Adaptation to new devices: The Gulliver concept allows the implementation of device specific

bindings of abstract widgets to be done by the manufacturer of mobile devices (or also browsers). They know best how to realize GUI objects such as buttons, labels, etc. for the specific platform. This implies that Behaviors only need to be programmed once. z Runtime processing: The dynamic nature of Gulliver implies that the approach cannot be as efficient

as for instance pre-generation of static web pages. However, first experiences in using our sample prototype applications have not revealed any major performance issues.

5 Summary As the Internet goes wireless the need for platforms will increase that support content providers in creating applications that are optimized for the target device and that are individualized for the users' specific needs. We have introduced Gulliver Beans as part of a platform that addresses this problem by creating a device independent content representation with additional device optimized target language code generation. First experiences are promising and show the suitability of this approach.

Acknowledgements The authors would like to acknowledge the support by Siemens PSE, Vienna. In particular we would like to thank Siegfried Grabner and Alfred Karner.

References [1]

Ambler, S. W. The design of a robust persistence layer for relational databases. http://www.ambysoft.com/persistenceLayer.pdf, 1998. AmbySoft Inc. White Paper.

[2]

Davies, N., and José, R. Scalable and flexible location-based services for ubiquitous access. In Handheld and Ubiquitous Computing (1999), pp. 52-66.


10.03.00


Seite 7 von 7

[3]

Hartl, A., Austaller, G., Kappel, G., , Lechleitner, C., Mühlhäuser, M., Reich, S., and Rudisch, R. Gulliver - a development environment for WAP based applications. In The Ninth International World Wide Web Conference. Amsterdam, NL (May 2000).

[4]

Laurel, B. The Art of Human-Computer Interface Design, 1. ed. Apple Computer Inc., 1990.

[5]

Pröll, B., Retschitzegger, W., Sighart, H., and Starck, H. Ready for prime time - pre-generation of web pages in TIScover. In Second ACM SIGMOD Workshop on the Web and Databases WebDB'99, in conjunction with SIGMOD'99, Philadelphia, Pennsylvania, USA, June 3-4 (1999).

[6]

LaLonde, W.R. and Pugh, J. R. Inside SmallTalk. Volume II. Prentice-Hall International, 1991.

[7]

Stoiber, S. Datenbankanbindungsmuster - Untersuchung alternativer Ansätze und Realisierung im Rahmen eines verteilten Kalendermanagers. Master's thesis, University of Linz, Department of Information Systems (IFS), Linz, Austria, 1999.

[8]

W3C. Web Accessibility Initiative (WAI). http://www.w3.org/WAI/.

[9]

W3C. Mobile Access Activity Statement, Feb. 2000. http://www.w3.org/Mobile/Activity.

File translated from TEX by TT H, version 2.00. On 01 Mar 2000, 13:49.


10.03.00