Active Customization of GIS User Interfaces - Semantic Scholar

Active Customization of GIS User Interfaces Claudia Bauzer Medeiros Juliano Lopes de Oliveira IC - UNICAMP - CP 6176 IC - UNICAMP - CP 6176 13081-970 Campinas - SP - Brazil 13081-970 Campinas - SP - Brazil [email protected] [email protected] Mariano Ariel Cilia ISISTAN - FCEX - UNICEN Tandil - Bs. As. - Argentina [email protected]

Abstract This paper presents a new approach to user interface customization in Geographic Information Systems (gis). This approach is based on the integration of three main components: a gis user interface architecture; an active database mechanism; and a generic interface builder. The gis interface architecture provides the default interface behavior, while the active system allows customization of interfaces according to the speci c context. The generic interface builder relies on a library of interface objects to dynamically construct generic and customized interfaces. The main advantage of this approach is that it decreases the costs associated with developing customized gis interfaces.

1. Introduction A gis (Geographic Information System) is a software that allows capture, manipulation, analysis and display of georeferenced data, that is, data which are connected to the surface of the earth (e.g., vegetation and road networks). Applications of gis technologies range from public utilities management to environmental control [9]. gis interfaces are particular instances of complex gui (Graphic User Interface) applications. In complex interactive systems, such as gis, more than fty percent of the total amount of code is dedicated to the user interface [10, 12]. As remarked by [6], programming such  This

work was partially nanced by grants from FAPESP and CNPq, as well as grants from CNPq Protem project GEOTEC and from the European Community ITDC project GEOTOOLS number 116-82152.

applications is a complicated task that requires significant eort to build and maintain adequate code. In spite of the great advances in mechanisms for storing and manipulating georeferenced data, the user interface still presents a barrier to the ecient use of gis. There is often a mismatch between the users' understanding of the world and the models and operations provided by particular gis user interfaces. There are two basic ways to bridge this gap: either train users to adapt themselves to the gis interface paradigm; or customize the interface to dierent application and user pro les. Both approaches are very expensive. The rst is unacceptable from a humancomputer interaction point of view [19]. The second implies providing several dierent interfaces, unbearable from a software engineering point of view. A trade-o solution, based on customization capabilities, is adopted in many systems. However, in current customization approaches, the users' choices are usually limited to a small number of prede ned interaction mechanisms. Thus, the users have to adapt themselves to one of the available interface paradigms. The solutions proposed to improve interface development consist of adding new modules into the interface architecture, thereby increasing the burden on the interface system. An innovative solution was proposed by [6], and consists of incorporating dbms technology into the interface software, thus combining two dierent families of paradigms. Our approach is in the same direction, but follows a dierent philosophy. Rather than bringing database concepts into the interface architecture, we bring the interface into the dbms, by extending existing dbms modules in order to augment the power of interface development mechanisms. The idea is to provide a

mechanism to customize a generic gis architecture, rather than developing a completely new interface for each dierent application. This mechanism is based on the active database paradigm, associated with a database library of interface objects. Unlike traditional approaches, the customization options are not limited to a xed number of interface styles, and interfaces can be built dynamically. The remainder of this paper is organized as follows. Section 2 summarizes the distinctive features of gis user interfaces. Section 3 describes our active customization approach. Section 4 shows an example of the interface customization process. Section 5 presents conclusions and future work.

2. GIS user interfaces 2.1. Problems and related work

In modern gis, data are stored and managed by a spatial dbms component, which stores conventional textual and spatial data. Database queries may be standard or return data on spatial properties and relationships. The user interfaces of these gis may be considered as special layers which help the users interact with the database. In this sense, the desired features of dbms user interfaces should be present in gis user interfaces. These features include automatic display generation; support for dierent abstraction levels for data visualization; and support for database integration. As pointed out by [6], many features of db technology may be applied to solve interface problems. For instance, the volume of data manipulated in gis is usually very high and the interface has to provide large buers to temporarily store and manipulate the data retrieved from the spatial dbms in order to present it. Ecient management of buers is thus a typical dbms problem that the gis interface must deal with. This paper is concerned with interface programming for gis dbms. Suitable solutions have been presented for automatic display generation in conventional [17] and in object-oriented dbms [13]. In spatial dbms, however, this task is incomparably harder. Interface elements are often maps, which not only require elaborate cartographic production, but also complex interface programming from a user interaction point of view. Display and manipulation of maps is not the only complicating factor. Spatial dbms must provide a large set of sophisticated data manipulations. These are made available via the interface by means of combinations of textual menus, buttons and widgets. Thus, it is not only the cartographic part of the screen that

presents problems, but the control (widget) area as well. It is this control part which concerns us. There are many other diculties for developing gis interfaces [15]. Approaches for solving them may deal with interface architecture [20], language [2, 4], and human factors [5, 7]. Our emphasis is on the rst kind of issue. 2.2. Customization needs

A generic interface mechanism is software that provides basic, standard, interface look and feel characteristics. A generic interface is sucient for many kinds of application. For instance, a generic interface mechanism for a rdbms is based on the table metaphor, and user actions are interpreted and manipulated as actions on table elements (e.g., lines, columns). Idiosyncrasies of gis applications cannot be handled through a generic interface mechanism and must be customized. Two issues are specially important in the customization of a gis interface. First, gis users expect dierent answers to the same query, according to the context (e.g., scale, time, region, application). Second, gis require dierent interaction modes. In the exploratory mode, users search for the information, mainly through (database) metadata querying. In the analysis mode, the goal is to evaluate conditions, usually via query predicates. Other common interaction modes include simulation, where users build scenarios to test their hypotheses, and explanation, in which users want to know why and how the system presented a speci c answer to a query. Many solutions have been presented to deal with customization of gis interfaces. These solutions can be summarized in three main approaches: 1.Multiple interaction paradigms: the interface oers many interaction paradigms, letting users decide which one is best for their needs; 2. Stereotypes: the interface is adapted to each user's mental model. The interaction with the system classi es the user into an stereotype, which de nes the interface behavior; 3.Toolkit: the interface is formed by a generic interface basis, and a toolkit for customization. The user must rely on a programmer to get a fullcustomized interface. None of these approaches solves the problem. In the rst and second cases, the user is limited by the prede ned interaction modes or stereotypes. In the third case, customization cost is increased due to the need

of an application programmer to develop completely new interface code. Our solution is closer to the third approach. However, the programmer is helped by modules which are embedded in the geographic database.

3. Using rules to customize a GIS interface 3.1. Architecture overview

Our approach to the problem of gis interface customization is based on three main components: a generic interface builder, associated with a library of interface objects; an active database mechanism; and a gis user interface layer. The architectural and functional relationships among these components are shown in gure 1. User Events GIS interface

DB Events

Active Mechanism Interface Objects Library

Customized Interface Definition Geographic DB Generic Interface Builder

Figure 1. Architecture of the Customizable User Interface

The gis interface (Section 3.5) provides the framework for ad hoc interaction with the gis. In commercial systems, each application interface is \hardwired" into this gis interface. Our proposal changes this, by providing additional modules, which allow dynamic interface building. User interactions are interpreted by the interface and transformed by it into database events { requests for queries or updates { which are then passed on to the underlying geographic database. These db events (on data and metadata) are intercepted by the active mechanism (Section 3.3), which activates appropriate interface customization rules. These rules act on the appropriate interface objects of the interface objects library . The result is processed by the generic inter-

face builder (Section 3.2) which generates a de nition of a customized interface . This de nition is sent back to the interface, to dynamically generate the output screen objects (maps, widgets). The interface can be further customized by a customization language (Section 3.4), which allows the application programmer to de ne speci c look and feel behavior. Some of these ideas have already been tested in a major gis project, in the development of a dynamic user interface system [14]. We point out that the gure only shows details that are relevant to this paper. First, it left out all modules of the geographic database which are not directly used in interface construction. Second, the active mechanism is geared towards interface customization. It may, however, be used in other contexts (e.g., constraint maintenance), which will not concern us. Third, we are not concerned with the data management and retrieval aspects of this problem. In fact, the database event triggers a combination of interface and database operations. We assume that database operations (queries and updates) are treated appropriately by the geographic dbms, which will retrieve the relevant data and pass it on to be displayed on the screen within the customized interface. The notion of using active dbms for interface facilities has been previously proposed by [3]. In this particular aspect, it is similar to our approach. However, their emphasis is on dynamically re ecting database state changes in the interface (akin to a view refresh). We, on the other hand, concern ourselves with customization of interface control and display components. 3.2. Interface objects library and generic interface builder

Our gis interface architecture supports the exploratory interaction mode (see section 2) which allows users to navigate on schema and extension. To this purpose, there are three main interaction windows: Schema, Instance, and Class set to, respectively, allow interaction with database schema, extension, and set of classes. These window types re ect the interaction requirements of gis users. Each of these interaction windows is constructed from (and can be customized by) a hierarchy of interface objects, stored in the interface objects library. Interface objects can be used to compose progressively more complex interface elements, using object-oriented programming and design techniques. The library contains the de nition and generic behavior of interface objects . These objects are either atomic (e.g., a button) or complex (for instance a win-

dow, which is composed by other objects). Every object can be associated with several events, each of which can be linked to a callback function (special functions triggered by events on interface objects). Generic behavior can be dynamically customized by callback functions. The basic idea of dynamic interface construction is as follows. The generic interface builder uses objects from the interface library to build an interface speci cation. The choice of appropriate objects is done at run time (as opposed of pre-compiled interfaces). As we shall see later on, customization is performed in a subsequent step. This library promotes the reuse of both design and code in the domain of user interface systems, having been used in the development of a large gis user interface system ([14]). Figure 2 shows the kernel library classes and their relationships, using the graphical notation proposed in the omt methodology [18]. Window

Panel

Text

Drawing Area

List

Button

Menu

Menu Item

Figure 2. Kernel Classes of Interface Objects

An important feature of this kernel is its extensibility. First, it is possible to add classes to it, which corresponds to the incorporation of new interface elements. Alternatively, it is possible to specialize existing classes, rede ning and customizing their elements. The root of the hierarchy is the Window element (i.e., Schema, Class set and Instance interaction windows are built starting from a Window object class). Every visual interface uses some kind of window to interact with the user. The window may not be graphical, but it always contains the interface elements used in the user dialog. These elements are grouped in control Panels. Therefore, a Window is composed of a set

of Panels, each one aggregating functionally related interface components. The composition structure of a Window is represented by a recursive relationship in the Panel class and by the aggregations which associate Panel to Window and to the other basic classes (Text eld, Drawing area, List, Button, and Menu). The recursive relationship allows the speci cation of complex control panels using other panels and improves the reuse of interface components. Consider, for example, a control panel for selecting maps from a map collection. This panel is a complex interface component which may contain lists for visualization and choice, text elds for geographic region names, operation buttons, among other elements. This panel can be incorporated by the interface library as a new complex object and thereafter it can be used as a component of another panel, which reuses the design and the implementation of the map selection panel. The bene t of this approach is that it is not necessary to de ne these dialog components statically at compilation time; rather, they can be inserted, updated and removed dynamically. The interface model also contributes to the isolation of user interface and application codes, establishing a common protocol for information exchange. This reuse framework is based on object oriented principles of inheritance and composition. This is not, however, just another object oriented gui: we also introduce a new factor { the underlying database { from which the interface can be dynamically constructed. Most gui, even the object-oriented ones, are static because they do not contemplate this dynamic linking to a database. We stress, nevertheless, that we have been able to introduce database facilities because the application domain is database centered, whereas generic toolkits cannot use this assumption. The discussion in this section shows the main aspects of the library, and its interaction with the generic interface builder. Due to space limitations, a complete and formal description of the model is omitted. The reader should refer to [14] for a thorough discussion and a complete example of the utilization of this model in the development of a large user interface system (over 10000 lines of code and more than 100 distinct windows). 3.3. The active mechanism

The active mechanism is based on the idea of extending an active database engine to customize interface speci cation. Active databases are systems which respond to events generated internally or externally to

the system itself without user intervention. The active dimension is supported by production rule mechanisms, provided by the dbms. These rules are usually de ned using three components: Event, Condition, Action (E-C-A). The Event represents the signal for a predetermined situation. The Condition is a predicate that must be true in order to perform the Action. Events may be internal to the database (e.g., queries, updates), or external (e.g., application, hardware interrupts). Conditions are usually predicates over database states. Actions are expressed in the database programming language and may range from atomic actions to complete programs. When the active mechanism detects an event, it selects a set of rules to be executed. This execution consists of checking the condition and evaluating the action. A wide spectrum of gis functions can pro t from active features, in dierent semantic levels. For example, integrity constraints and data adjustments can be ensured by rules during spatial data entry and updates [8, 11]. In our architecture, the goal of the active mechanism is to customize interface development. A rule, in this context, is speci ed by:

On Event Ei If Condition Cj Then Apply Customization CTn

to database objects O1 ; :::; Oe involving interface library objects IO1 ; :::; IOk

Events are user requests via the interface. The Action { customization CT { is code for interface

customization, derived from declarative customizations speci ed in our customization language, which is described in section 3.4. This customization combines two types of database objects: those resulting from the user request on the geographic database (O1 ; :::; Oe ) and those retrieved from the interface library (IO1 ; :::; IOk ). Geographic data in fO1 ; :::; Oe g will be thus customized according to the speci cation of fIO1 ; :::; IOk g. Section 4 describes this customization. Condition Cj corresponds to checking a given application context . In a general gis framework, a context completely describes a user environment and mental model. This would be too complex, since one can specify as many mental models as there are users. This, in turn, would mean an exponential creation of interface customization rules. Therefore, we restrict context de nition to the tuple < userclass; applicationdomain >, where user class and application domain belong to well de ned partitions created by the application designer. This context

information can conceivably be extended to other contextual data (e.g., geographic scale, time framework). The important issue here is that Condition does not check a database state, but a user's working environment. In this extended context, the rule set may be partitioned into (at least) two subsets: rules for interface customization, and other rules. By the same token, events can also be considered according to this partition (interface and database related events). Thus, we do not require a special purpose active mechanism, but have only introduced a new type of rules and events to be handled. Events, in this extended framework, should be treated in two steps: their interaction with the interface and their eect on the database. In other words, a user interaction Ii on the interface is now treated by this extended active mechanism according to two components: an interface event IE i (e.g., mouse click, key pressing) and a database event DBE i . IE i invokes a callback function, such as the ones mentioned in Section 3). In the exploratory mode, database events DBE i can be restricted to primitives Get Schema, Get Class and Get Value. These primitives are invoked to retrieve data in order to build or populate presentations while browsing and querying the geographic database. In order to make this clear, we discuss the basic principles through a simpli ed example. Consider, for instance, that the user wants to see the schema of a database GEO by clicking a \Schema" button. The click is the Ii interaction, performed within a speci c < userU; applicationA > context. This click corresponds to an interface IE i event (\Schema button pressed by user U within application A") which invokes a given callback function CB . CB contains the code \Perform Get Schema(GEO) for Context (U,A)". This, in turn, is captured by the underlying active database mechanism for the database event DBE i (Get Schema). This event will trigger two active database rules { a query rule R1 and a customization rule R2: R1 will perform a database query Q1 (to obtain the schema of GEO) and R2 will perform another database query Q2 (to obtain the customization directives CT to apply to the result of Q1). The condition on this second rule checks on the context (U,A) information. The result of both queries forms a pair (Q1, Q2) = (data, presentation), returned to the Generic Interface Builder, which nally produces the desired display { see gure 1. Assume rst that no customization is required. In this case, the Q2 action in R2 is empty, i.e., no customization exists for that context. In this case, the Interface Builder uses generic (default) presentation code. If, on the other hand, some customization CT

has been encoded for this context, then Q2 will be executed, retrieving the desired customization. (Suppose for instance that the default display shows the schema in tabular format; a possible customization would be \display schema using a graph format".) It is important to note two points. First, con icts can appear with the use of an active mechanism, since rules can trigger other con icting rules. In our proposal, this is not the case for customization rules like R2: the action of a rule is limited to getting a customization for an interface object. Second, it is possible to have a set of customization rules activated by an event, one for each context. In our execution model, only one rule is selected for execution { the one which has the highest priority. We de ne the highest priority for the most speci c rule, that is, the rule whose condition (context) part is more restrictive. For instance, we can de ne progressively more restrictive context conditions such as a rule for generic users, for a particular category of users, and for a particular user within the category. 3.4. Customization language

The customization language is the means for specifying customization rules in a declarative way. A customization directive de ned in this language may spawn several customization rules, which allow the modi cation of the look and feel of the generic interface according to the needs of dierent users. The customization language provides only the binding of new functionality to the interface objects. The de nition of such functions is out of the scope of the language. The target user of this language is the application designer, who has knowledge about the database schema and user access rights. The language supports a declarative description of the controls of the interface, which must be available in the object library. The user can add or specialize controls in this library, as described in Section 3.2. Customizable interface controls correspond to schemata, classes, and instances (corresponding to parameters of Get Schema, Get Class and Get Value events). These are the most important concepts in an (object-oriented) geographic database, which is the expected underlying system. To make this customization feasible, the customization language has to be as simple and easy to use as possible, but at the same time, it has to provide reasonable customization power. The simplicity of the language is guaranteed by its declarative nature and by its trivial syntax. The power of the language comes from allowing the de nition of new behaviors for the

objects in the interface library (i.e., the coding of new callback functions to override their default behavior). Since the customization is based on a generic interface, it is not necessary to de ne all the controls via the customization language. The designer has to declare only the customized controls, and the omitted controls are represented with the default presentation de ned in the generic interface. Figure 3 shows an informal and shorthand description of the customization directives supported. A complete de nition of the language is omitted due to space limitations. Note that the context (Condition component of the rule) is speci ed by the directive in the For clause. This condition is the same for all rules derived from a given customization directive.

For [user ] [category ] [application ] schema [display as defaultj hierarchyj user-de nedj Null] fclass [display control as ] [display presentation as ] [instances f[display attribute as j Null [from fg [using ]] ] g*

]g+

Figure 3. The basic constructs of the customization language

A customization directive de nes the characteristics of Schema, Class set and Instance interaction windows for each context speci ed in the For clause. Schema windows assume the user just wants to look at the available class names in the spatial database to select the desired phenomena for browsing. The schema clause of the directive originates a schema presentation rule, triggered by Get Schema events. This rule de nes the contents of the Schema window according to the display modes (default, hierarchy, user-de ned, Null). Class set windows comprise a control and a presentation area, where the presentation area shows the extension of each selected class in some format (typically allowing the user to grasp the spatial relationships among class instances). For each class clause there is a class presentation rule, triggered by Get Class events, de ning the contents of the presentation and control ar-

eas of the Class set window. Finally, Instance windows let the user de ne display properties for each attribute of a given instance. Each window diers from the others to re ect usual gis users exploratory interaction patterns. The attributes in the instances clause are associated with instance presentation rules, triggered by Get Instance events. This rules manage the creation of the panel for each attribute in the Instance window, according to the display attribute clause of the customization directive. A given customization directive can thus be mapped directly into customization database rules, for events Get Schema, Get Class, Get Instance to window customization (for, respectively, Schema, Class set and Instance interaction windows) as follows:

Cust rule: On Database Event X

If < Context > Then apply customization to window of type X More details on this mapping are shown in section 4. The main points about the customization language are: (a) support for declarative speci cation of distinct user categories and applications; (b) separation of the de nition of control and presentation displays; and (c) association of multiple presentation formats to chosen class components. Customization rules stored in the database are derived from assertives written in this language.

3.5. The GIS user interface

Sections 3.2, 3.3 and 3.4 described features under responsibility of the geographic dbms. We now describe the user interface architecture, which corresponds to the topmost layer of gure 1. There are two basic approaches to integrate a user interface system to a dbms, and in particular to a geographic dbms: strong integration and weak integration [20]. In the former, the user interface is part of the geographic system, sharing its data model and taking advantage of the knowledge about the internal data structures. In weak integration, the user interface is considered an external module, and is therefore adaptable to more than one system. Weak integration demands the de nition of communication and data conversion protocols between the user interface system and the geographic system. In strong integration this is not necessary, but there is great diculty in using data from dierent sources, and it is not possible to adapt the same user interface to dierent gis. Therefore, our architecture is based

on the weak integration approach, following a worldwide trend towards the development of open gis (e.g., [1, 16, 20]). In a gui context, the architecture of the interface is organized according to three components: one component that re ects the underlying data Model; one component to provide users with speci c Views of the model; and a component that Controls the mapping across the other two (e.g., the MVC model). Our architecture encapsulates the model-view-controller principle, but a considerable number of functions are left to be performed by the database system. Each user action is captured by the interface where it is processed by a dispatcher, which is responsible for creating and maintaining the hierarchy of (Schema, Class set, Instance) windows. The dispatcher represents the generic interface control module, and de nes the default behavior of the interface. This module is also present in conventional user interface systems. Unlike these systems, our dispatcher allows the dynamic active customization of the interface windows. The dispatcher recognizes dierent types of database interaction requests (schema and extension manipulations), and generates the primitive events captured by the active database mechanism. We see two main advantages in our approach, in comparison with the conventional interface dispatchers. First, we have a single generic model for building windows, while conventional interfaces have a speci c code to generate each kind of window. Second, the customization of the interface windows is performed transparently to the whole interface system. All the modules in the interface have exactly the same behavior, with or without customization, while in conventional interfaces the customization involves the modi cation of the interface code. This transparency in the customization process is possible because we rely on the active dbms to trigger the customization rules.

4. Example of customization This Section describes the customization process, using an urban planning application concerning telephone utilities. The example has been simpli ed to show some details of our proposal. A telephone network contains aerial and underground network elements, such as ducts and poles. Network planning and maintenance demand an exploratory interface interaction. Consider a geographic database which stores maps representing the elements of the network. A typical browsing session on this database iterates through browsing (Schema, fClass, fInstanceg g) windows, in

Figure 4. Default interface windows

this order: 1. The user rst activates the generic interface, giving a db schema name as a parameter. The generic browser shows a schema window with a list of classes in the given schema. 2. The user next selects a class in that list and the system shows a class window, containing the class schema and a generic map with class instances. 3. The user nally selects an instance of the class in the graphical area or in the control area, which is shown in an Instance window. Figure 4 shows the windows which represent the default behavior of the interface. The rst type of window is the Schema Window , where the user can see the complete schema of the database ( gure 4, left). The selection of classes in this window causes the display of the second type of window, the Class set Window , where the user can manipulate and visualize the selected classes ( gure 4, center). The third type of window, the Instance Window , allows visualizing and manipulating individual (geo-)objects ( gure 4, right). The Class set Window is divided in two main areas: the control area, and the presentation (or display) area where poles appear as points. Each of these areas is composed, in turn, by a diversity of interface objects. For instance, the control area has a set of atomic widgets (menu buttons) and an extensible set of widgets that represent the database classes. Now, suppose we want to customize the interface for a user who wants to manage poles. This user is not interested in the complete network, just the poles. Moreover, the user wants another view of pole objects, dierent from the default presentation.

Class Polef pole type: integer; pole composition: tuple( pole material: text; pole diameter: oat; pole height: oat;) pole supplier: Supplier; pole location: Geometry; pole picture: bitmap; pole historic: text; Methods: get supplier name(Supplier);g Figure 5. Database schema for class Pole

(1) For user juliano application pole manager (2) schema phone net display as Null (3) class Pole display (4) control as poleWidget (5) presentation as pointFormat (6) instances display attribute (7) pole composition as composed text (8) from pole.material pole.diameter pole.height (9) using composed text.notify() (10) display attribute pole supplier as text (11) from get supplier name(pole supplier) (12) display attribute pole location as Null Figure 6. Using the customization language

Figure 5 speci es class Pole and gure 6 contains a customization of its presentation. Line (1) de nes the context; line (2) selects the (phone net) schema and states that no schema window will be displayed, just

Figure 7. Customized interface windows

class Pole, which is de ned in line (3). Lines (4) and (5) de ne the presentation of the Pole class: a prede ned composed widget (poleWidget, de ned as a slider) and a prede ned format (pointFormat). Line (6) introduces the attributes that are customized in lines (7){(12). This simpli es the customization of the three level window hierarchy, for the context < user juliano, application pole manager >. At the rst level, the database schema is not displayed (value Null, line (2)). Lines (4) and (5) customize the display of the Pole class, whereas lines (6){(12) customize instances of the class. In line (7), for instance, the attribute pole composition is customized to be represented as a prede ned widget named composed text. The omitted attributes (pole type, pole picture, and pole historic) are represented with the default presentation de ned in the generic interface (see section 3.4). This customization is used in the generation of several rules, two of which are described below. When the user connects to the application, an event Get Schema is generated to the active database. The corresponding rule, in a simpli ed notation, is

R1: On Get Schema

If < juliano, pole manager > Then Build Window(Schema, phone net, NULL); Get Class(Pole). The Generic Interface Builder builds the Schema window, since it de nes the windows hierarchy, but it is not shown to the user, due to the NULL parameter. This parameter also originates a Get Class event for the classes de ned in the customization directive corresponding to this rule (only class Pole, in this example). This event triggers the second rule

R2: On Get Class

If < juliano, pole manager > Then Build Window(Class set, Pole, Pole Widget, pointFormat). This rule results in displaying the left part of gure 7, which represents a customized version of the Class set window. Now, if the user interacts with the poles of this window, this will trigger the third presentation level, for event Get Value, and the action is the customization of lines (7){(12), resulting in the right part of gure 7.

5. Conclusions

We described a new approach to the customization of gis user interface systems. Whereas previous work in interface customization is centered on adding new modules to the interface, our approach is based on extending the underlying database with facilities for interface development. The main components are: (1) a generic gis user interface architecture providing the default look and feel of the interface; (2) a library of object classes which allows dynamic de nition and construction of interface components; and (3) an active database mechanism which guarantees the independence between the generic interface and the customization rules. Components (1) and (2) have been implemented in the Brazilian Telecom Research Center [14], but without customization facilities. A prototype has been developed to associate a gis with an active dbms, and it has been used for maintaining topological constraints in the gis [11]. Current approaches to the customization of gis user interfaces are directed to customization of the presenta-

tion of georeferenced data. This deals with open problems, such as cartographic generalization, for which satisfactory solutions do not exist. We instead deal with the problems of customization of controls and behavior of the interface, presenting an implementable solution for this problem. Our solution has the following advantages over the existing implementations: our customizations are not hardwired, they are extensible, reusable, and dynamic. Furthermore, it takes advantage of the underlying dbms to help the application programmer, rather than burdening the interface with extra modules. We are now working on the implementation of the compiler for creating rules from a declarative speci cation of a customized interface. The next step is to integrate these tools in a homogeneous framework. A very interesting outcome of this research is the appearance of a new family of rules to be treated by an active dbms { interface customization rules. They dier from standard rules not only because their purpose is dierent, but also because action speci cation is of a completely new nature. One limitation of our approach is that it does not consider customization of update requests, just of database queries. This is a direct consequence of the fact that we only support the exploratory interaction mode, for distinct contexts. The main problem in solving this limitation lies in the fact that other possible modes (analysis and simulation) often require map updates, which in turn implies solving a large set of open problems in electronic cartography.

References

[1] D. Abel, S. Yap, R. Ackland, M. Cameron, D. Smith, and G. Walker. Environmental Decision Support System Project: an Exploration of Alternative Architectures for Geographical Information Systems. International Journal of Geographical Information Systems, 6(3):193{204, 1992. [2] D. Calcinelli and M. Maingenaud. The Management of the Ambiguities in a Graphical Query Language for GIS. In Proc. 2nd Symposium on Spatial Database Systems, pages 99{118. Spring Verlag Lecture Notes in Computer Science 525, 1991. [3] O. Diaz, A. Jaime, N. Paton, and G. al Qaimari. Supporting Dynamic Displays Using Active Rules. ACM Sigmod Record, 23(1):21{26, 1994. [4] M. Egenhofer. Spatial SQL: A Query and Presentation Language. IEEE Transactions on Knowledge and Data Engineering, 6(1):86{95, 1994. [5] M. Egenhofer and A. Frank. Designing Objectoriented Query Languages for GIS: Human Interface Aspects. In Proc 3rd International Symposium on Spatial Data Handling, pages 79{98, 1988.

[6] N. Gopal, C. Hoch, R. Krishnamurthy, B. Meckler, and M. Suckow. Is GUI Programming a Database Research Problem? In Proc. SIGMOD Conference, pages 517{528, 1996. [7] M. Gould. Human Factors in Geographic Information Systems, chapter Two Views of the User Interface, pages 101{110. Belhaven Press, 1993. [8] R. Laurini and F. Milleret-Raort. Topological Reorganization of Inconsistent Geographical Databases: A Step Towards their Certi cation. Computers and Graphics, 18(6):803{813, 1994. [9] D. Maguire, M. Goodchild, and D. Rhind, editors. Geographical Information Systems - Principles and Applications, volume 2 - Applications. John Wiley and Sons, 1991. [10] A. Marcus and A. van Dam. User-Interface Developments for the Nineties. IEEE Computer, 24(9):49{57, Sept. 1991. [11] C. B. Medeiros and M. Cilia. Maintenance of Binary Topological Constraints through Active Databases. In Proc 3nd ACM Workshop on Advances in GIS, pages 127{134, 1995. [12] B. A. Myers and M. B. Rosson. Survey on User Interface Programming. In Human Factors in Computing Systems CHI'92 Conference Proceedings, pages 195{ 202, Monterey, California, May 1992. [13] J. L. Oliveira and R. O. Anido. Browsing and Querying in Object Oriented Databases. In Proc. 2nd International Conference on Information and Knowledge Management, pages 364{373, USA, Nov. 1993. [14] J. L. Oliveira, C. Q. Cunha, and G. C. Magalh~aes. Object Model for Dynamic Construction of Visual Interfaces. In Proc. of the 9th Brasilian Symposium on Software Engineering, pages 143{158, Oct. 1995. In Portuguese. [15] J. L. Oliveira and C. B. Medeiros. User Interface Architectures, Languages, and Models in Geographic Databases. Tutorial. In Proc. of the 11th Brasilian Symposium on Databases, pages 20{42, Oct. 1996. [16] N. Pissinou, K. Makki, and E. Park. Towards the Design and Development of a New Architecture for Geographic Information Systems . In Proc. 2nd International Conference on Information and Knowledge Management, pages 565{573, USA, Nov. 1993. [17] A. Pizano, Y. Shirota, and A. Iizawa. Automatic Generation of Graphical User Interfaces for Interactive Database Applications. In Proc. 2nd International Conference on Information and Knowledge Management- CIKM, pages 344{355, 1993. [18] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, and W. Lorensen. Object-Oriented Modeling and Design. Prentice-Hall, 1991. [19] B. Shneiderman. Designing the User Interface: Strategies for Eective Human-Computer Interaction. Addison-Wesley, 1987. [20] A. Voisard. Designing and Integrating User Interfaces of Geographic Database Applications. In Proc. ACM Workshop on Advanced Visual Interfaces, pages 133{ 142, Bari, Italy, June 1994.