ICWE 2008 Workshops, 7th Int. Workshop on Web-Oriented Software Technologies – IWWOST 2008 Multi-level Dialog Modeling in Highly Interactive Web Interfaces Efrem Mbaki1, Jean Vanderdonckt1, Josefina Guerrero1, Marco Winckler2 1 Université catholique de Louvain, Louvain School of Management, Belgian Lab. of Computer-Human Interaction, Place des Doyens, 1 B-1348 Louvain-la-Neuve, Belgium jean.vanderdonckt@uclouvain.be 2 IRIT, Université Toulouse 3, France, 118 route de Narbonne, F-31062 Toulouse cedex 9, France http://liihs.irit.fr/winckler/, winckler@irit.fr Abstract object that may appear in a UI. This definition will lead us to define five particular levels. As web user interfaces become more sophisticated both ƒ Lack of precise abstraction [8]: in principle, MDE sug- in functionalities and reactivity, the dialog of such user in- gests three levels of abstraction (i.e., computing inde- terfaces is highly interactive and therefore raises the need pendent model, platform-independent model, and plat- for abstracting these capabilities into an advanced dialog form-specific model). These three levels are rarely ob- model that enables modeling such dialogs. To address this served in the area of dialog modeling where the plat- need, multi-level dialog modeling enables designers to form-specific level remains predominant. model a dialog at two inter-related levels of abstraction ƒ Lack of continuity [12]: when two levels of abstractions (i.e., concrete and abstract dialog) and at five levels of are covered, it is not always obvious to see how model- granularity: object-level (dialog at the level of a particu- to-model mappings (whether it is achieved through lar objects such as a widget), low-level container (dialog transformations or not) are ensured to establish and at the last level of decomposition of user interface con- maintain continuity between them. tainers, such as a group box), intermediary-level con- ƒ Lack of expressiveness [20]: the demand for more so- tainer (dialog at any non-terminal level of decomposition phisticated dialogs stems for a dialog model that is ca- such as a dialog box or a web page), within-application pable enough to accommodate the description of desired level (dialog at the level of an interactive application), dynamic aspects, such as animations, transitions, the and across applications-level (dialog across user inter- two traditional forms of adaptation (i.e., adaptability and faces of different interactive applications). adaptivity). A modern dialog model should be expres- sive enough to model dynamic aspects. ƒ Risk for modeling complexity: it is likely that a more ex- 1. Introduction pressive model tend to be more complex to define and therefore to use in general. Among all models involved in Model-Driven Engineer- ing (MDE) of User Interfaces (UIs) of any interactive ap- In this paper, we attempt to address the problem of dia- plication in general or for a web application in particular, log modeling in a comprehensive way in order to address the dialog model is probably one of the most challenging the aforementioned shortcomings. For this purpose, Sec- remaining problems due to several reasons: tion 2 will report on significant work related to the area of ƒ Lack of ontological definition [12]: different terms, e.g., dialog modeling. Section 3 will define the semantics of dialog, navigation, behavior, dynamics, conversation, a dialog model respectively at the platform-specific level the “feel”, are inconsistently used to refer to the dy- (concrete UI) and at the platform-independent level (ab- namic aspects of a UI, as opposed to the presentation, stract UI) with a derivation from a computing-independent which refers to as the static aspects of a UI, e.g., its lay- model (task model). Section 3 will then define five levels out. In this paper, we define a dialog model as the of granularity. Section 4 will conclude the paper by pre- model that captures all dynamic aspects of a UI behav- senting some future avenues of this work. ior. This therefore includes dynamics at any level of any 38 ICWE 2008 Workshops, 7th Int. Workshop on Web-Oriented Software Technologies – IWWOST 2008 2. Related Work tangles called states. State changing mechanisms are represented with edges between states. State changing is Dialog models enable to reason about the UI behavior. triggered by events and can be further conditioned. Consequently, dialog models are often considered as Statecharts facilitate the representation of state nesting, a continuation of task model concepts. This explains why state history, concurrency and external interrupts. State- the task model has been extensively used to derive a dia- charts [10] propose solutions to the shortcomings of log model, for instance, in an algorithmic way [13] or in state transition diagrams: statecharts have representa- a logical way supported by model-to-model transforma- tional capacities for modularity and abstraction. The tions [12] and graph grammars [7,12]. We hereafter give number of states with respect to the complexity of the a brief survey of dialog modeling methods that percolated modeled system increases slower with statecharts than into the field of Human-Computer Interaction (HCI) de- with state transition diagrams. Statecharts avoid the velopment methods [3, 8, 9, 16]: problem of duplicating states and transitions. States in ƒ Backus-Naur Form (BNF) grammars: they are typically statecharts are hierarchical and capable of representing used to specify command languages [9]. Command lan- different levels of abstraction. Statechart are more con- guages express commands that modify the state of the venient for multimodal interfaces as they provide nest- UI on the user’s initiative. Grammars are particularly ing facilities, external interrupt specification and con- good in detecting inconsistencies within command sets. currency representation. Statecharts have been also spe- An inconsistent UI may contain unordered or unpredict- cialized for specifying the dialog of web interfaces able interaction. Inconsistency renders the UI error through StateWebCharts, that can be edited via prone and hard to learn. Grammars are both efficient a SWCEditor [22]. and effective for expressing sequential commands or ƒ And-Or graphs: borrowed from Artificial Intelligence, users actions in general, but become complex for mul- AND-OR graphs have been used to branch to various timodality. sub-dialogs depending on conditions, for instance in [3]. ƒ State transition diagram are a finite state machine rep- And-or graphs have been expanded towards function resentation that consists in a graph of nodes linked by chaining graphs [3] by combining them with data flow edges [21]. Each node represents a particular state of the diagrams [19]. system. Each edge species the input (i.e., event) re- ƒ Event-Response Languages: they treat input stream as quired to go from one state to another. State transition a set of events [9]. Events are addressed to event han- diagrams have been subject to several extensions [21] dlers. Each handler responds to a specific type of event and specializations, like Statecharts [10] that provide a when activated. This type is specified in a condition mean for specifying the dynamic behavior of the inter- clause. The body of the event generates another event, face. State transition diagrams present several draw- changes internal state of the system or calls an applica- backs for modeling the UI. Indeed, today's UI tend to be tion procedure. Several formalisms are suited for event- modeless where one state can lead to many states. Fur- response specification. They can be distinguished fol- thermore this can be done using many different widgets lowing their capacity in managing dialog state variables of the UI. Theses two requirements match the quality and concurrency control. Production rules and push- criteria of reachability and device multiplicity. In con- down automata [16] are often used to describe event- sequence, state transition diagrams are prone to a response specifications. combinatorial explosion and tend to replace nodes by ƒ Petri Nets are a graphical formalism associated with screen prints. In [14], the transition space is restricted to a formal notation. Petri nets are best suited to represent events and transitions that are triggered by window concurrency aspects in software systems. Petri nets rep- managers in graphical state transition diagrams, thus resent systems with state variables called places (de- supporting only simple windows transitions [20]. Many picted as ellipses), and state-changing operators called other forms of dedicated state transition diagrams have transitions (depicted as rectangles. Connections between been extensively used for dialog modeling without places and transitions are called arcs (represented by identifying which one is superior to another one with edges). State marking mechanism called tokens (repre- respect to various criteria: dialog charts [1], dialog sented by black solid circles distributed around places). flows [4], interaction object graph [5], Abstract Data State change is the consequence of a mechanism called Views [6], dialogue nets [11]. firing. A transition is red when all of its input places ƒ Statecharts: similarly to state transition diagrams, they contain tokens. Firing involves the redistribution of to- are supported by a graphical representation of dynamic kens in the net i.e., input tokens are withdrawn from in- aspects of systems [10]. Some work especially address put places and output tokens are added in output places. the modeling of UI behavior with statecharts [18, 22]. Like State Charts, Petri nets hold mechanisms to repre- Statecharts represent state variables with rounded rec- sent additional conditions and nested states. Petri nets 39 ICWE 2008 Workshops, 7th Int. Workshop on Web-Oriented Software Technologies – IWWOST 2008 have the advantage of being entirely formal [2]. Thus, in a system state change. The specification of a behavior model checking of interest properties of the dialog may be decomposed into three types of elements: an model could be applied [17]. event, a condition, and an action. An event is a description Fig. 1 graphically depicts some of these dialog models of a run-time occurrence that triggers an action. The gen- in families of models. Each family exhibits a certain de- eral format of a ECA rule is: (ON Event, IF Condition, gree of model expressiveness (i.e., the capability of the THEN Action). The Event specifies when the rule should model to express advanced enough dialogs), but at the be fired, the Condition specifies the logical condition when price of a certain model complexity (i.e., the easiness with it should be fired and the Action determines what methods which the dialog could be modeled in terms specified by should be executed for this purpose. Some canonical the meta-model). At the leftmost part of Fig. 1 are located events are described in Table 1. They consist of any sys- BNF and EBNF grammars since they are probably the tem event (i.e., issued from a process belonging to the least expressive dialog models ever, but they do not sup- domain), user interface event (i.e., issued in the context of port many dialog aspects. They we can find respectively the user interface). For instance movePointer([X], [device]) State Transitions Networks and their derivatives, then refers to an event that consists in moving a pointer in the Event-Response Systems. Petri nets are probably the most context of a CIO [X]. Events cannot make any reference to expressive models that can be used to model dialogs, but coordinates. The concept of context of an object (identi- they are also the most complex to achieve. Therefore, we fied by its id) is used to reference a display area where believe that we could be less expressive and complex than a particular object is rendered. Note that, the negative ex- Petri nets if Event-Condition-Action systems are consid- pression of an object context is also allowed. ered. For instance, depress(NOT[X]), [device]) refers to a de- press event (e.g., a mouse down) outside the context of Model Petri nets [X]. [X] is unimportant in the realization of an event in complexity ICO such a case a value null is referenced. The [device] pa- State charts, ECA rameter makes reference to the device from which the DISL StateWebCharts, event is generated. Each device or device part, is refer- ADV BNF, STN, ERS Our dialog model enced in a device model (not in the scope of this disserta- ESTN,… EBNF,… tion) with a unique identifier. Model expressiveness CIO Events Figure 1. Model complexity as a function of their ex- System event ellapsedTime(n), systemEvent(eventName) pressiveness. Graphical User Interface Events All graphical movePointer(X,device), CIOs pointerOver(X,device), moveOutPointer (X, 3. Semantics of Dialog Modeling device), click (X,device), doubleClick (X, device), depress(X,device), release (X, de- vice), dragOver(X,Y,device), drag- In this section, we present the most salient aspects of Drop(X,Y, device), hasFocus(X), lostFo- the two levels of dialog modeling with respect to the Final cus(X). User Interface (FUI). A FUI is hereby referred to as any graphicalCon- resize(xFactor,yFactor) UI running on any computing platform with any interac- tainer tion modality (e.g., graphical, vocal, tactile, haptic or mul- textComponent Change Slider move(cursor,x) timodal), whether it is rendered by markup language in- Spin spinUp, spinDown terpretation or by code generation. 3.1. Concrete User Interface Table 1. List of some canonical CUI events. A Concrete User Interface (CUI) is defined as the ab- Events can be composed into more complex event ex- straction of any Final User Interface (FUI) with respect to pressions using a subset of the LOTOS operators as used computing platforms, but with the interaction modality in IdealXML [15]. “|||” indicates a concurrence of events given. According to MDE, it is a platform-specific model (to be interpreted as a disjunction). “>>” indicates a strict (PSM). A CUI is made up of Concrete Interaction Objects sequence of events. “|=|” indicates an order independent (CIO), which are abstractions of widgets found in those sequence of events. “(n)” indicates a finite iteration of platforms. Any CIO may be associated with any number events where n is an integer indicating the iteration factor. of behaviors (Fig. 2). A behavior is the description of For instance, click (Button1, Mouse1LeftBut) |=| depress a Event-Condition-Action (ECA) mechanism that results (null, KeyBrd_Z) is an event that is an order independent 40 ICWE 2008 Workshops, 7th Int. Workshop on Web-Oriented Software Technologies – IWWOST 2008 composition of a mouse click on a button and a keyboard an action is performed. A condition may be positive or depress. A condition is the expression of a state that has to negative. hold true before (pre-condition) or after (post-condition) Figure 2. The semantics of the dialog model as a ECA system at the concrete user interface level. We express condition as patterns (i.e., a partial descrip- 3. A transition, also called navigation, is a description of tion of a state) on the user interface specification itself. a change in the container’s visibility property of a user Conditions may be composed using traditional logical op- interface system. A transition has a source (a navigation erator. “AND”, “OR”, “XOR” indicate respectively a con- individual component) and a target (generally a con- junction, a disjunction, an exclusive disjunction of condi- tainer). tions. “IMPLIES” indicates an implication between two conditions. An action is a process that results in a state 3.2. Abstract User Interface change in the system. An action can be of three types: An Abstract User Interface (AUI) is defined as the ab- 1. A method call is a call to a method that is external to the straction of any CUI with respect to interaction modality. UI. If a domain model exists, all method calls must ref- According to MDE, it is a platform-independent model erence a method belonging to this model. A method call (PIM). An AUI is made up of Abstract Interaction Objects is normally specified with the name of the method (un- (AIOs), which are abstractions of CIOs found in existing der the form Class.methodName), but other referenc- interaction modalities, and linked through abstract rela- ing techniques are not forbidden. The method call pa- tionships (Fig. 3). Therefore, an AUI only specifies inter- rameters can be specified by making a reference to the action between a user and a system in totally independent value of a property of an object belonging to the CUI. terms. Only later on, once the interaction modalities are 2. A transformation system is the expression of any prop- selected and once the target computing platform is elic- erty change at the UI level [25]. We use a mechanism to ited, this AUI will be turned into CIOs and final widgets, specify property changes on the UI. To avoid too much respectively. Abstract Interaction Object (AIO) may be of forward reference, it can be said that a transformation two types Abstract Individual Components (AIC) and Ab- system can be explained as follows: when a pattern is stract Containers (AC). An Abstract Individual Compo- found in CUI specification, changes should occur on the nent (AIC) is an abstraction that allows the description of elements matching the pattern. A transformation system interaction objects in a way that is independent of the mo- might be, for instance, “when a green button is found in dality in which it will be rendered in the physical world. the specification, change the color property of this but- An AIC may be composed of multiple facets. Each facet ton to red” or “For all text components belonging to the describes a particular function an AIC may endorse in the main window, double their font size”. physical world. Four main facets are identified: 41 ICWE 2008 Workshops, 7th Int. Workshop on Web-Oriented Software Technologies – IWWOST 2008 1. An input facet describes the input action supported by a CIO or a AIO. In most cases, UI toolkits and Inte- an AIC. grated Development Environments (IDEs) come up 2. An output facet describes what data may be presented with their own widget set with built-in, predefined to the user by an AIC. dialog. For instance, a push button comes up with its 3. A navigation facet describes the possible container native dialog (or behavior) that can be only modified transition a particular AIC may enable. by overwriting the methods that define its behavior. 4. A control facet describes the links between an AIC Most IDEs do not allow such a superseding, only and system functions i.e., methods from the domain toolkits allow the developer to redefine an entirely model when existing. new dialog for a particular widget, but this program- ming is very complex. A single AIC may assume several facets at the same 2. Low-level container dialog modeling: This level mod- time. The AIO that reifies this multi-facetted AIO will as- els the dialog at the level of any container of other ob- sume all those ‘functionalities’. For instance, a CIO may jects that is a leaf node in the decomposition. Typi- display an output while accepting an input from a user, cally, this could be a terminal AC at the AUI level or ensure a transition between windows and trigger a method a group box at the CUI level in case of a graphical in- defined in the domain model. An Abstract Container (AC) teraction modality. If the UI is vocal, then an auditory is an entity allowing a logical grouping of other abstract display should be implemented that marks the containers or abstract individual components. AC are said boundaries of this vocal group. For instance, by pro- to support the execution of a set of logically/semantically nouncing the beginning and the end of the group. connected tasks. They are called presentation units in 3. Intermediary-level container dialog modeling: this some cases or work spaces. An AC may be reified, at the level models the dialog at the level of any non- concrete level, into one or more graphical containers like terminal container of objects, that is any container windows, dialog boxes, layout boxes or time slots in the that is not a leaf node in the container decomposition. case of auditory user interfaces. Abstract User Interface For any graphical UI, this could be a window, a dia- Relationships (AUI relationship) are relationships that can log box, or the various tabs of a tabbed dialog box. be drawn between abstract interaction objects of all kinds. This level models the dialog at the level of top con- Various types of abstract relationships may be defined at tainers within a same interactive application such as this level: a web application or a web site. It thus regulates the ƒ Decomposition relationship allows specifying a hierar- navigation between the various containers of a same chical structure of abstract containers and abstract in- application. dividual components. 4. Within-application dialog modeling: This level mod- ƒ AbstractAdjacency relationship indicates that two AIO els the dialog at the level of top containers within are logically adjacent. a same interactive application such as a web applica- ƒ Spatio-temporal relationship allows a specification of tion or a web site. It therefore regulates the navigation a very precise layout in time or space in a way that is between the various containers of a same application. independent of any modality. For instance, SketchiXML [20] allows the designer to ƒ Dialog control relationship allows a specification of graphically specify within-application dialog by af- a flow of control between the abstract interaction ob- fecting predefined ECA rules between web pages. jects. Like for task models, LOTOS operators are used Each such ECA rule represents a dialog pattern, such for this purpose. For instance a relationship as Open-Close, Activate-deactivate. For instance, the AIC1.EnterCountry []> AIC2.EnterPro vince indicates Open-Close pattern means that when a web page is that AIC2 cannot be initiated while AIC1 is not closed, the next page in the transition is opened. achieved and that AIC1 has provided a value for the 5. Across-application dialog modeling: Since the action data on which the two components synchronize with. term of a ECA rule could be either a method call or an Like for tasks, an interpretation for each type of application execution, it is possible to specify a dialog LOTOS operator may be provided in terms of pre/post- across several applications by calling an external pro- conditions, termination, initiation states. gram. Once the external program has been launched, the dialog that is internal to this program (within- 3.3. Five Levels of Dialog Granularity application dialog) can take place. Based on AUI and CUI, five levels of dialog granular- 4. Conclusion ity can be identified and specified: 1. Object-level dialog modeling: this level models the In this paper, we have introduced a definition of a dia- dialog at the level of any particular object, such as log model at both concrete and abstract UI levels, which 42 ICWE 2008 Workshops, 7th Int. Workshop on Web-Oriented Software Technologies – IWWOST 2008 represent respectively the PSM and PIM levels in MDE. [9] M. Green, A survey of three dialogue models. ACM Trans- For both, ECA rules are used to specify the dialog at five actions on Graphics, 5(3), July 1986, pp. 244–275. different levels of granularity. Five levels of granularity of [10] D. Harel, Statecharts: A visual formalism for complex sys- this dialog model have been introduced. A dialog at any tems, Science of Comp. Prog., 8, 1987, pp. 231–274. level of granularity can be equally modeled in the terms of [11] C. Janssen, A. Weisbecker, and J. Ziegler, Generating user interfaces from data models and dialogue net specifications, an ECA system that consist of ECA rules. Depending on Proc. of InterCHI’93 (Amsterdam, 24-29 April 1993), ACM the UI level of abstraction (AUI or CUI), the events, the Press, New York, 1993, pp. 418–423. conditions, and the actions are different: the AUI events [12] Q. Limbourg and J. Vanderdonckt, Addressing the Mapping represent abstractions of CUI events, AUI actions repre- Problem in User Interface Design with UsiXML, Proc. of sent abstractions of CUI actions, etc. For a mono-device TAMODIA’2004 (Prague, November 15-16, 2004), ACM dialog or for a multi-device dialog but with the same in- Press, NY, 2004, pp. 155–163. teraction modality (like in [8]), the CUI level is enough. [13] K. Luyten, T. Clerckx, K. Coninx, and J. Vanderdonckt, For more interaction modalities, the AUI level should be Derivation of a Dialog Model from a Task Model by Activ- specified with an explicit mapping between the levels us- ity Chain Extraction, Proc. of DSV-IS’2003 (Madeira, 4-6 June 2003), Lecture Notes in Computer Science, Vol. 2844, ing the same support as specified in [12]. Springer, Berlin, 2003, pp. 203–217. In the near future, we are pursuing effort towards [14] E. Mbaki and J. Vanderdonckt, Window Transitions: specifying the dialog at multiple levels, separately or si- A Graphical Notation for Specifying Mid-level Dialogue, multaneously in a coordinated way. For this purpose, the Proc. of TAMODIA’2002 (Bucharest, 18-19 July 2002), cascading style sheet mechanism of XML has been ap- Academy of Economic Studies of Bucharest, INFOREC plied to the corresponding UsiXML models so as to form Printing House, Bucharest, 2002, pp. 55–63. a cascading dialog modeling [23]. In this way, it is ex- [15] F. Montero, V. López-Jaquero, J. Vanderdonckt, P. Gon- pected that high level properties and values are progres- zalez, M.D. Lozano, and Q. Limbourg, Solving the Map- sively propagated from one level to another while preserv- ping Problem in User Interface Design by Seamless Integra- tion in IdealXML, Proc. of DSV-IS’2005 (Newcastle upon ing quality properties, such as consistency. Tyne, 13-15 July 2005), S.W. Gilroy, M.D. Harrison (eds.), Lecture Notes in Computer Science, Vol. 3941, Springer- 5. References Verlag, Berlin, 2005, pp. 161-172. [16] D. Olsen, Pushdown automata for user interface manage- [1] G. Ariav and L.-J. Calloway, Designing conceptual models ment, ACM Transactions on Graphics, 3(3), 1984, pp. 177– of dialog: A case for dialog charts, SIGCHI Bulletin, 20(2), 203. 1988, pp. 23–27. [17] P. Palanque and R. Bastide, Petri net based design of user- [2] R. Bastide and P. Palanque, A Visual and Formal Glue Be- driven interfaces using interactive cooperative object for- tween Application and Interaction, J. of Visual Language malism, Proc. of DSV-IS’94 (Bocca di Magra, June 1994), and Computing, 10(5), 1999, pp. 481–507. Springer Verlag, Vienna, 1994. [3] F. Bodart, A.-M. Hennebert, J.-M. Leheureux, I. Provot, J. [18] State Chart XML (SCXML): State Machine Notation for Vanderdonckt, and G. Zucchinetti, Key Activities for a De- Control Abstraction. W3C Working Draft, 21 February velopment Methodology of Interactive Applications, Chap- 2007, http://www.w3.org/TR/scxml/ ter 7, in Benyon, D., Palanque, Ph. (Eds.), “Critical Issues [19] J. Vanderdonckt, J.-Cl. Tarby, and A. Derycke, Using Data in User Interface Systems Engineering”, Springer-Verlag, Flow Diagrams for Supporting Task Models, Supplemen- Berlin, 1995, pp. 109-134. tary Proc. of DSV-IS’98 (Abingdon, 3-5 June 1998), Euro- [4] M. Book and V. Gruhn, Efficient Modeling of Hierarchical graphics Assoc., Aire-la-Ville, pp. 1–16. Dialog Flows for Multi-Channel Web Applications, Proc. of [20] J. Vanderdonckt, Q. Limbourg, M. Florins, Deriving the 30th COMPSAC’2006 (Chicago, 17-21 September 2006), Navigational Structure of a User Interface, Proc. of Inter- IEEE Computer Society, Los Alamitos, 2008, pp. 161–168. act’2003 (Zurich, 1-5 September 2003), IOS Press, Amster- [5] D.A. Carr, Specification of interface interaction objects, dam, 2003, pp. 455–462. Proc. of ACM CHI’94 (Boston, 24-28 April 1994), ACM [21] A. Wasserman, Extending State Transition Diagrams for the Press, New York, 1994, pp. 372–378. Specification of Human-Computer Interaction, IEEE Trans. [6] D. Cowan and C. Pereira de Lucena, C., Abstract Data on Soft. Engineering, 11(8), 1985, pp. 699–713. Views: An Interface Specification Concept to Enhance De- [22] M. Winckler and P. Palanque. StateWebCharts: A formal sign for Reuse, IEEE Transactions on Software Engineer- description technique dedicated to navigation modelling of ing, 21(3), 1995, pp. 229-243. web applications. Proc. of DSV-IS’2003 (Madeira, 4-6 June [7] M. Goedicke and B.E. Sucrow, Towards a formal specifica- 2003), Lecture Notes in Computer Science, Vol. 2844, tion method for graphical user interfaces using modularized Springer, Berlin, 2003, pp. 61–76. graph grammars, Proc. of IWSSD’96 (Washington, DC, [23] M. Winckler, F. Trindade, J. Vanderdonckt, Cascading Dia- 1996), IEEE, Los Alamitos, 1996. log Modeling with UsiXML, Proc. of DSV-IS’2008 (King- [8] J. Gomez, C. Cachero, O. Pastor, Conceptual Modeling of ston, July 16-18, 2008), Lecture Notes in Computer Sci- Device-Independent Web Applications, IEEE Multimedia, ence, Vol. 5136, Springer, Berlin, 2008, pp. 12–135. 8(2), 2001, pp. 26-39. 43