A Proposal to Validate the User’s Goalin Distributed User Interfaces

J. A. Gallud, A. Penalver†, J. J. Lopez-Espın†, E. Lazcorreta†, F.Botella†, H. M. Fardoun‡ and G. Sebastian†Center of Operations Research University Institute

Miguel Hernandez University of Elche, Spain‡Information Systems Department

King Abdulaziz University, Jeddah, Saudi Arabia

Abstract

Traditional user interfaces are evolving towards “distributed” user interfacesaccording to the new technological advances, allowing one or more interac-tion elements distributed among many different platforms in order to supportinteraction with one or more users. In this new scenario, the Abstract UserInterface model has been reviewed and modified to include specific char-acteristics from the Distributed User Interface point of view. This paperproposes a new Abstract User Interface (AUI) that takes into account thepossibility of distribution. Before presenting this new AUI model, the paperintroduces the definition of the Distributed User Interfaces (DUI) conceptand its foundations using a formal notation. Together with the new AUImodel, a double hierarchy of UIs and targets has been defined, so we canverify the type of distribution using the concept of finality introduced asan algorithm in this article. With this new algorithm it is possible to testwhether a given DUI (multiple devices, multiple user interfaces) supportsthe user’s goal in the system.

In the last few years, many types of new computers and devices have been introduced.Users can perform different tasks through a wide variety of computational devices likemobile phones, Personal Digital Assistants (PDAs), Internet enabled televisions (WebTV),tablet PCs, laptops, notebooks, and so on. New mobile devices allow ubiquitous access toinformation and the opportunity to accomplish more and more desktop-related tasks withthem, bringing the following new challenges to the Human-Computer Interaction (HCI)community (Eisenstein, Vanderdonckt, & Puerta, 2001):

• Applications must be developed and maintained across multiple devices.• Consistency between versions for different devices must be guaranteed.• Versions must dynamically respond to changes in the environment such as users’

location, ambient noise, lighting and network conditions, and so on.

Most tasks require a Graphical User Interface (GUI) so that users can tap buttons,

A PROPOSAL TO VALIDATE THE USER’S GOAL IN DISTRIBUTED USER INTERFACES 2

make selections, fill in forms, and so on; therefore, in order to address the new challengesmentioned above, user interfaces must be described independently of any concrete device. AUser Interface Description Language (UIDL) (Guerrero, Gonzalez, Vanderdonckt, & Munoz,2009) is a formal language used in HCI, a particular user interface can be described inde-pendently of any implementation technology. A UIDL should be declarative so that it canbe edited manually and it should also be formal in order to be understood and analyzed bysoftware. A UI involves mostly different aspects:

• Interaction modalities: such as graphical, vocal, tactile, haptic, multi-modal andso on.

• Interaction techniques: single click, double click, drag and drop, multi-tactile fingergestures...

• Interaction styles: direct manipulation, form filling, virtual reality...

A common fundamental assumption of most UIDLs is that UIs are modeled asalgebraic or model-theoretic structures including both a set of interaction objects andthe behavior over them. Recently, some authors have proposed different UIDLs: UIML(www.uiml.org)(Abrams, Phanouriou, Batongbacal, Williams, & Shuster, 1999), (Helms etal., 2009), useML (http://www.uni-kl.de/pak/useML/), MariaXML (Paterno, Santoro, &Spano, 2009), USIXML (www.usixml.org) (Limbourg, Vanderdonckt, Michotte, Bouillon,& Lopez-Jaquero, 2004), and XIML (www.ximl.org). They all have their pros and cons,mainly dictated by the goals they are intended. A deep review as well as a discussion anda comparative analysis of some of the previously cited methods can be found in (Luyten,Abrams, Vanderdonckt, & Limbourg, 2004), (Faure & Vanderdonckt, 2010), (Shaer, Green,Jacob, & Luyten, 2008). For instance, XIML has a very high expressivity, but it (currently)lacks of advanced tools support. On the other hand, UIML is one of the most restrictiveUIDLs, but it is rather supported by software (Souchon & Vanderdonckt, 2003) and it isbeing standardized by OASIS. UIML is also independent of a widget set and it claims tobe device-independent as well (Luyten & Coninx, 2004).

USer Interface eXtensible Markup Language (USIXML) is a UIDL allowing designersto specify and produce interfaces from different and multiple levels of abstraction, main-taining the mappings between these levels if required. Thus, the development process canbe initiated from any level of abstraction and proceed towards obtaining one or many finaluser interfaces for various contexts of use. In this way, the model-to-model transformationwhich is the cornerstone of Model-Driven Architecture (MDA) can be supported in multi-ple configurations, based on composition of three basic transformation types: abstraction,reification, and translation.

Although many UIDLs are based on the XML markup language that renders anddescribes graphical user interfaces and controls; this is not a requirement and does notnecessarily describe a graphical user interface (though most UIDLs abstract only graphicaluser interfaces).

In order to rigorously define the semantics of such a UIDL, various meta-models havebeen defined. These meta-models adhere to the principle of separation of concerns andcould be classified as context of use (user, platform, environment), task, domain, abstractuser interface, concrete user interface, usability and accessibility, work flow, organization,evolution, program, transformation, and mapping.

Alternatively, nowadays user interfaces are evolving towards “distributed” user inter-

A PROPOSAL TO VALIDATE THE USER’S GOAL IN DISTRIBUTED USER INTERFACES 3

faces, offering new interaction possibilities in agreement with new technological proposals.Distributed interfaces allow one or more interaction elements to be distributed over differentplatforms in order to support interaction between one or many users.

This paper presents a new Abstract User Interface model that takes into accountthe properties and features of the DUIs allowing us to validate if the user’s goal is wellsupported in the new DUI. Before introducing our proposal, we review the definition ofuser interface to give a more comprehensive approach. This is justified by the fact thatthe Graphical User Interfaces (GUI) no longer have much emphasis in the proposed newinteraction devices.

The use of formal models for user interface design can help to ensure coherency acrossdesigns for multiple platforms and prove properties such as consistency, reachability andcompleteness (Bowen & Reeves, 2007). Previous efforts dedicated to specify user interfaces(UI) (Chi, 1985) must be revisited and redefined in order to consider this new interactionenvironment provided by distributed user interfaces.

According to (Vanderdonckt, 2010), DUI concerns to the allocation of one or manyelements of one or many user interfaces to support one or many users carrying out oneor many tasks on one or many domains in one or many contexts of use, each contextof use consisting of users, platforms, and environments. Authors explain that where UIdistribution is supported, UI federation is needed. UI federation supports the concentrationof UI elements from distributed sources.

Other previous studies have addressed, not always from a formal point of view, thespecification of the essential properties of DUI’s, as well as reference model proposals (Cal-vary et al., 2003) (Demeure, Calvary, Sottet, & Vanderdonckt, 2005) (Demeure et al., 2008)(Reichart, 2004). In this paper, we define a user interface as a set of elements (input, out-put and control) that allows users to interact with different types of devices. The abovedefinition of DUI is the starting point of the proposal described in this article. DUI addsthe term distribution to the user interface concept.

We use the specification of distributed user interfaces (DUIs) that can be found in(Lopez-Espın, Lazcorreta, Gallud, Penalver, & Botella, 2011). This formal view covers awide range of descriptions from the most abstract to the implementation-oriented. Formaldescription techniques provide unambiguous descriptions of complex interactions that occurin DUIs (distribution of elements, including communication and distributed interaction),more precise and understandable than descriptions using the natural language. In addition,formal description techniques provide the foundation for the analysis and verification ofdescriptions. The analysis and formal verification can be applied to specific or abstractproperties. Natural language is a good complement to the formal notation to get a firstidea of description.

The remainder of this paper is organized as follows. First we introduce the charac-terization of the DUI concept. Next section presents the set of basic definitions that arethe foundation of our concept of DUI. Afterwards, we illustrate the previous definitions andproperties using several real applications. Then, both the new AUI model and its charac-teristics are presented in the next section. Finally, the concept of finality and an algorithmto validate this concept are presented. Last section details the conclusions and future work.

A PROPOSAL TO VALIDATE THE USER’S GOAL IN DISTRIBUTED USER INTERFACES 4

DUI Characterization

The definition of Distributed User Interfaces (DUI) is based on the definition of UserInterface (UI). Some authors have proposed a new definition of UI concept by using the termHuman User Interface (HUI) (Gallud et al., 2010) to underline the fact that the interfaceconcept is becoming an element that is “nearer” to the user than the computer.

In the traditional definition, the interface is “nearer” to the computer or part of thecomputer indeed. In this sense, a UI is a set of elements that allows users to interactwith computers. These elements can be categorized into input data elements, output dataelements and control elements. This definition of UI supports all kind of technologies andinteraction mechanisms. The task can be defined as a set of actions the user performsto accomplish an objective. A DUI system is an application, or set of applications thatmake use of DUIs, since these applications share the user interface. A DUI system canbe implemented by means of several kinds of devices, hardware and software platforms.Therefore, for the purposes of this paper, there is no need to maintain the difference betweendevice and platform.

Taking into account the former definition of DUI, we define the essential properties:portability, decomposability (and composability), simultaneity and continuity. The nextparagraphs are devoted to describe each property.

Portability: This property means that the whole UI, or parts of it can be transferredamong platforms and devices by means of easy user actions. For example, a user couldbe running a graphic editor in his desktop computer and then he could decide to transferthe color palette panel (UI element) to another platform (a portable device) with a simpleaction.

Decomposability: A DUI system is decomposable if given a UI composed by a numberof elements, one or more elements of that UI can be independently executed without losingtheir functionality. For instance, an application calculator can be decomposed in two UIelements, the display and the numeric keyboard. This property can be used together withPortability in order to allow the keyboard being executed in a smartphone, while the displaycan be showed in a public display. These two UI elements can also be joined together in aunique UI (composability).

Simultaneity: A DUI system is said to be simultaneous if different UI elements of thesame DUI system can be managed in the same instant of time on different platforms. Forexample, two or more users interacting with the same DUI from different platforms at thesame time. This does not imply that all DUI systems are multiuser as we will see later.

Continuity: A DUI system is said to be continuous if an element of the DUI systemcan be transferred to another platform of the same DUI system maintaining its state. Forexample, a user could be on a call in his mobile phone walking on the street and thentransfer the call to the TV without interrupting it when he arrives at home.

A PROPOSAL TO VALIDATE THE USER’S GOAL IN DISTRIBUTED USER INTERFACES 5

Basic Definitions and Specification of Essential Properties of DUIs

In this section a set of concepts is presented with the objective of obtaining a formaldefinition of a DUI.

Definition 1: Interaction Element An Interaction Element e ∈ E is defined as anelement which allows a user u to carry out an interaction through a platform p (denotedby u ∼e p). An element can be defined as an input-data element u ∼ e

→p, an output-dataelement u ∼ e

←p or a control element u ∼ ecp. In this work the generic notation e is used to

enclose the three kind of elements.

Definition 2: Functionality Two elements of interaction e and e′ have the same func-tionality if a user can perform the same action using them in his interaction with the device(denoted by e =F e′). In this sense, a button in a “Graphic Interface Unit” has the samefunctionality as a hand movement, if the computer receives the same order. In the sameway, a sound has the same functionality as an audible alert if the user receives the sameinformation in answer to any interaction.

Definition 3: Target A set of elements of interaction E0 ⊂ E have the same Target(e ∈T E0) if ∀e ∈ E0, a user u ∈ U obtains, through the functionality of e, an action of thetask whose goal is to reach this target. In this paper we use target and goal indistinctly.

Definition 4: User Interface Let UI be a user interface, and i ∈ UI a set of interactionelements i = {e ∈ E / e ∈T i}, then the user interface i is defined by a subset of the targetelements. From definitions exposed above it is possible to define a User Interface as a setof interaction elements which let a user carry out a task in a specific context.

After introducing the concepts of interaction element, functionality and target, wecan say that a user interface is simply a set of interaction elements that allows the user toperform a task in a context.

Definition 5: Platform An interaction element e ∈ E exists in a platform p ∈ P(denoted by ∼e p), if e can be implemented, supported or executed on p. Thus, thisdefinition also includes the existence of a framework that supports the interaction elemente.

A user interface i ∈ UI is supported by p ∈ P (denoted by u ∼i p) if ∀e ∈ i thenu ∼e p being u ∈ U . In addition, i ∈ UI is supported on a set of platforms P0 ⊂ P (u ∼iP0)if ∀e ∈ i then u ∼e p ∀p ∈ P0 being u ∈ U .

Essential properties explained in the previous section can be formalized following thenotation proposed.

Portability: A user interface i ∈ UI / u ∼i p being u ∈ U and p ∈ P , is portable if thereexists E0 = {e ∈ E/e ∈ i} ⊂ i such as u ∼E0 p′ and u ∼E0 (p being p, p′ ∈ P ) reaching thesame target than i. (This property can be extended to more than one user). i ∈ UI hasbeen ported if i is portable and this property has been satisfied.

A PROPOSAL TO VALIDATE THE USER’S GOAL IN DISTRIBUTED USER INTERFACES 6

Decomposition: A user interface i ∈ UI is decomposable if there exists E0 ⊂ i such asE0 = {e ∈ i/ e ∈T ′

E0} and E0 = {e ∈ i/ e ∈T ′′E0} obtaining the same target than i.

Thus, if through i the target T is reached, then T ′ and T ′′ are two subtargets of T whichcan be reached through E0 and E0 respectively. Note that from the definition of UI it canbe deduced that E0 and E0 are two user interfaces (denoted by User Subinterface as it isshown in the next definition).

Definition 6: User Subinterface Let suppose that i ∈ UI is a user interface that allowsa user u ∈ U to reach a target T on a platform p ∈ P , i.e. u ∼T p. If T ′ is a subtarget ofT , then the set i′ = {e ∈T i/e ∈T ′

i′} is a User Subinterface of i, and u ∼T ′p.

i ∈ UI has been decomposed if it is decomposable and this property has beenfulfilled.

Definition 7: Distributed User Interface A Distributed User Interface di ∈ DUI isdefined as a user interface which has been decomposed and ported.

Then, a Distributed User Interface di ∈ DUI is defined as

di =N⋃k=1

Ek =N⋃k=1

{ekj ∈ ik, j = 1 . . . Nk, ekj ∈Tk Ek}

such as there exist np > 1 platforms {ps ∈ P/s = 1 . . . np} such as

di =

np⋃s=1

{esj ∈ E/u ∼esj ps , j = 1 . . . nps , esj ∈T di}

for a user u ∈ U being Tk a subtarget of T ∀ 1 ≤ k ≤ N.

(1)

Thus, a distributed user interface is the collection of interaction elements embracing aset of user interfaces, which are also subinterfaces of the user’s distributed interface. Theseuser subinterfaces are distributed in platforms without loosing their functionality and theircommon target.

Using this new notation it is possible to express the user interaction through tra-ditional UIs as u ∼ ip, being i ∈ UI, the interaction of a user through DUIs as u ∼ dipbeing di ∈ DUI, and the interaction of some users through some platforms trough DUIs as{u/u ∈ U} ∼di {p/p ∈ P}.

Definition 8: State of a User Interface The State of a user interface i ∈ UI, denotedby S(i), is defined as the temporal point in which i lies after the user has used part of hiselements with the goal of reaching the target associated to i. The State of i is the InitialState (S0(i)) if none of the elements have been used or if they have been used withoutcontributing any step to reach the target of i. The Final State of i (SF (i)) is reached whenthe target of i is reached. It is said that this target is achieved in n steps or states, ifthrough the sequence S0(i), ..., Sn(i), the target of i is reached and this target is achievedwithout any of the referred states.

A PROPOSAL TO VALIDATE THE USER’S GOAL IN DISTRIBUTED USER INTERFACES 7

Note that to move from the state Sj(i) to Sj+1(i) is necessary to use the appropriateinteraction element e ∈ i. Others elements used do not change the state. There exists someelements which move from state Sj(i) to Sj−1(i), to SF (i) or to S0(i).

Definition 9: State of a Distributed User Interface The State of a Distributed UserInterface di ∈ DUI, denoted by ~S(di) = (S(i1), ..., S(in)), is defined as a n-tuple where eachelement corresponds to the state of each user interface in which di has been decomposed.Note that ~S(di) depends on the decomposition in subinterfaces of di and those which havebeen ported to different platforms.

di is in an initial state if ~S0(di) = (S0(i1), ..., S0(in)), and it is in a final state if~SF (di) = (SF (i1), ..., SF (in)). The number of states required to reach the target of di is

the product of the number of states required to reach each subtarget in each ported usersubinterface.

Simultaneity: A distributed user interface di ∈ DUI is simultaneous in p0, p1, . . . pn ∈ Pwith n > 1 for uk ∈ U with k = 1, ..., nu (nu ≥ 1) users, if di =

⋃Nj=1 ij with ij ∈ UI, and

uk ∼ij ps in the same temporal point, with j = 1 . . . N and s = 1 . . . n and k = 1 . . . n.

Continuity: A distributed user interface di ∈ DUI is continuous in p0, p1 ∈ P if ∀e ∈ di,u ∼e p0 and u ∼e p1 maintain the state of di, i.e., if Sj(di) is the state of di, then St(i) isreached in both cases (being able to be t = 0, j, j + 1, j − 1, F ).

Identifying essential properties in real applications

This section is devoted to show several applications of the previously proposed nota-tion in the context of different distributed user interfaces.

The first interface was originally proposed in (Vanderdonckt, 2010) and describes howto distribute elements of a GUI as these are the most studied interfaces due to the capacityof many platforms to support common interaction GUI elements. Decomposing a dialogis a good example of the essential property Decomposability. As the author describes, adialog can be split if it is composed of blocks of elements with their own functionality.With the proposed notation it could be expressed as ik ∈F di, k = 1, 2, 3. We mean, thethree different dialogs ik ∈ UI compose the di ∈ DUI, as a set of user interfaces sharing acommon objective.

As a second example we present the WallShare application (Villanueva, Tesoriero, &Gallud, 2010). WallShare provides a shared area displayed on a projector over a wall or bymeans of a long size screen. Users can collaborate through the shared area using their ownmobile devices, such as smartphones, PDA’s, tablets, laptops and so on. To use the sharedzone, users have their own cursors allowing them to share any kind of files, such as imagesor documents, by performing dragging gestures on the mobile device screen. WallSharealso allows users to post anonymous information notes on the shared zone as post-its. Thisis useful to highlight information that is relevant to the meeting. Also, a chat system isprovided in order to send information associated to an author that may be relevant to themeeting. Messages are displayed on the lower left corner of the screen.

A PROPOSAL TO VALIDATE THE USER’S GOAL IN DISTRIBUTED USER INTERFACES 8

A typical use case could be two users interacting with their own devices (platforms),i.e. u1 ∼i1 p1 with a PDA and u2 ∼i2 p2 with a tablet and a PC as the platform in chargeof the shared area p3, i3. In this case, the DUI would be denoted by di = {i1, i2, i3} offeringtwo kind of interactions, u1 ∼di {p1, p3} and u2 ∼di {p2, p3}. Regarding to the essentialproperties, we have the following situations:

• Portability. Considering the users’ pointer control as part of the i3 user inter-face, since this interface is distributed on the PDA p1 and the tablet p2, we can say thatWallShare fulfills this property.

• Decomposability. The user interface is divided into a set of common interactionelements and several distributed control elements. Each ik maintains not only its ownfunctionality, but also the general one. Furthermore, both the PDA and the tablet havetheir own cursors allowing users to interact with the shared zone.

• Simultaneity. A group of users uk ∈ U , k ≥ 1, can work in different platforms atthe same time. In this case, the user with the PDA u1 ∼i1 p1 could upload a new PDFdocument to the shared screen p3 while the user with the tablet u2 ∼i2 p2 downloads a textdocument previously uploaded by the PDA user.

• Continuity. The chat system provided by Wallshare also fulfills this property sincethe state of the shared area is updated in real time and the new messages from all users aredisplayed as they are introduced in the original device, PDA or tablet.

We consider a third hypothetical example related to the zoom control of an applicationthat allows to manage images or maps, where we can use different interaction elements: aslider, a text input, up-down buttons, a keyboard (Ctrl+-, Ctrl++) and so on. We couldtransfer two buttons from the main platform i1, p1 (a PC) to another platform i2, p2 (a PDA)for managing the zoom (the common target). Our DUI could be expressed as di = {i1, i2}and we can discuss how it could accomplish the four essential properties:

• Portability. The main application on the PC can receive the keystroke of eachbutton from the PDA and trigger the tasks Zoom-Out and Zoom-In.

• Decomposability. In this case we have decomposed the original UI on the PC intotwo new UIs (PC and PDA) that form our DUI di with the same original functionality andthe common objective.

• Simultaneity. This DUI can be used simultaneously by two users in order to managethe common zoom.

• Continuity. The i2 interface does not maintain the state (it consists of two buttons)but affects the overall state of the system. In this case, we say that the DUI should maintainthe state of the overall zoom in the different controls.

Another example could be the well-known application XMMS, a popular Linux audioplayer. Although it has its own UI, in (Vanderhulst, 2005), authors present a frameworkthat using markup languages is able to generate and distribute GUI descriptions for customapplications like XMMS, which can be rendered on a wide variety of (mobile) devices. Afterapplying their proposed framework, a distributed UI for XMMS is split among two clients.The first client (e.g. a PC) could have the main and settings service, while the second (asmartphone) could display the play list service. In this case, just one user could interactwith his own device (platform) at the same time with the same audio player instance,u1 ∼di {p1, p2}. The DUI would be denoted by di = {i1, i2} offering one type of interaction:u1 ∼di {p1, p2}. Then the essential properties are defined as follows:

A PROPOSAL TO VALIDATE THE USER’S GOAL IN DISTRIBUTED USER INTERFACES 9

• Portability. Not only the settings service but also the play list can be distributed ineach platform p1 (the PC) and p2 (the smartphone) either, so XMMS fulfills this property.

• Decomposability. As in the previous example, the original UI is decomposed in twoUIs that form our DUI di with the same original functionality and the common objective.

• Simultaneity. This DUI cannot be used simultaneously by two users because an-other user would have his own platform and different instances of XMMS: u2 ∼di {p3, p4}.

• Continuity. XMMS is continuous in p1, p2 as u1 ∼di {p1, p2} maintains the state ofdi when the original interface UI is decomposed in di = {i1, i2}. E.g. the song keep playingalthough the play list is ported to the smartphone.

An AUI Model to Support DUIs

This section presents the AUI model that supports our concept of Distributed UserInterface.

As we have shown in the previous section, the concept of Distributed User Interfaceis based on the concept of User Interface. In fact, from our perspective a DUI is a setof interaction elements distributed or distributable across different platforms. In order toconsider a set of interaction elements as a UI, it is required that all these interaction elementshave a common goal (target). This common goal is connected with the user’s task, that isto say a UI is the mean for the user to get the result of the task. This result appears in themodel as target.

Figure 1 shows the abstract user interface model proposed in this paper.

Figure 1. Abstract User Interface with the DUI perspective

A PROPOSAL TO VALIDATE THE USER’S GOAL IN DISTRIBUTED USER INTERFACES 10

A User Interface is composed of an abstract interaction object (aio) that can be eitheran interaction element or a user subinterface (uSubI). The interaction element can be usedto express input, output, navigation or control actions.

In this model two entities called ”target” and ”subtarget” can be found. These entitiesare present in the model to remark the importance of the common goal that is connaturalto the concept of user interface.

Figure 2 shows the abstract user interface model that has been proposed in theUsiXML project (Limbourg et al., 2004).

Figure 2. Abstract User Interface

If we compare both models it can be noted that the interaction element of Figure1 is equivalent to the abstractIndividualComponent of the Figure 2. The proposed modelis also similar to the previous one in the container element. The uSubI element of theproposed model is equivalent to the abstractContainer. The uSubI element is linked withthe subTarget element in the model to support the explained properties.

There is a significative difference between these two AUI models with the introductionof the target and subTarget entities in the model. As it has been explained, a DUI is a setof distributed interaction elements supporting a common goal (target). Before distributinga UI, it is possible to check if a set of interaction elements can be split and transferred toother platform (portability and decomposability properties) with a simple verification. We

A PROPOSAL TO VALIDATE THE USER’S GOAL IN DISTRIBUTED USER INTERFACES 11

have to test if the selected interaction elements have associated a sub-target.

We are going to explain this proposal with a simple example: the calculator. Thecalculator as a whole is a UI in order to allow the user to perform mathematical calculations(the final objective or target in our model). The calculator consists of an abstract interactionobject which also contains an interaction element (the display) and a user sub-interface (thekeyboard). The display has a subtask related to the main goal: to show the calculationsto the user. The sub-interface keypad consists of a set of interaction elements (buttons)with a common sub-objective: to allow user input. The display is framed within the outputinteraction elements, while each of the keys can be considered as an input element. The“key” interaction elements share a common sub-objective: to allow data input, so it makesno sense to be distributed separately but framed within its sub-interface, since they sharethe same input subgoal. To split or to distribute interaction elements that do not share asub-objective linked to the main purpose of the UI can jeopardize the attainment of thisobjective. Figure 3 shows the discussed concepts.

Figure 3. Decomposing the calculator interface

Verifying the finality on DUI

As it has been established in previous sections, a DUI can be seen as a set of in-teraction elements distributed on a set of platforms supporting the common user’s target.

A PROPOSAL TO VALIDATE THE USER’S GOAL IN DISTRIBUTED USER INTERFACES 12

The question is whether we have a mechanism to know how good is the distribution of theinteraction elements across the existing devices (platforms). In other words, is it possibleto conclude that a given distribution of interaction elements is better than other differentdistribution? and how? This section tries to answer these two questions.

Before presenting that mechanism, to test how good is the distribution in a givenDUI, the concept of finality is needed. Finality can be applied to UIs and to interactionelements. This concept shows if a UI or an interaction element is still linked to its targetor not.

When a UI, composed of a set of interaction elements, is distributed across a set ofdevices (platforms), the user splits and selects the interaction elements that will be executedon each platform. As a consequence, an interaction element can lose its objective or targetand we will say that it is an element without finality. If an interaction element loses itsfinality, it will affect to the finality of the DUI super set.

To illustrate this new concept, the same example of the previous section is used: thecalculator. The UI of the calculator is linked to the most general target: to allow theuser to perform computations. Two sub-UIs, linked to two sub-targets, can be identifiedin the calculator: the display and the numeric keyboard. A possible distribution of theinteraction elements could be to split the initial UI into two sub-UIs (the display and thenumeric keyboard) running on two different devices. In this case, the DUI does reach itsfinality because each sub-UI has its own sub-target linked to it. A different thing is totry to decompose the numeric keyboard UI in two interaction element sets (even and oddnumbers). In this last case, we have not a sub-target linked to each number of the numerickeyboard, so the finality of this DUI is lost.

The identification of the finality in a DUI is possible because of the implicit doublehierarchy that we have assumed in our model of AUI. In a DUI we have a hierarchicalstructure of UI and sub-UIs, linked to the hierarchical structure of targets and sub-targets.

It can be easily assumed that every UI has a target that is linked to the user’s needs.In the same way, it is possible to identify a sub-target associated to each sub-UI. When itis not possible to identify a sub-target associated to an interaction element, then it is notconvenient the isolated distribution of this element.

In a nutshell, the verification mechanism consists on testing that each interactionelement running on each platform of a given DUI keeps its original target or subtarget.

Formally, we can say that given a double hierarchy of UIs and targets, and given adistribution of interaction elements from these UIs on a set of platforms, the mechanismhas been called the Finality Algorithm:

Algorithm Finality:INPUT: di ∈ DUIOUTPUT: true (if di is decomposable) or false (if not)foreach (p ∈ P ) do

foreach (e ∈ di / u ∼e p) dodetermine E ⊂ di such that e ∈T Edetermine T = target(E)if ∃E′ ⊂ di and p′ ∈ P (E′ 6= E and p′ 6= p) such

u ∼E′p′ / target(E) = target(E′) then

A PROPOSAL TO VALIDATE THE USER’S GOAL IN DISTRIBUTED USER INTERFACES 13

return falseend ifend foreach

end foreachreturn true

The mechanism will not validate the finality of the given DUI whenever two differentinteraction elements running on two different platforms have been associated to the sametarget or subtarget.

A possible situation where finality is not achieved could appear in the case of thecalculator mentioned above. If a user decides to split and distribute the numeric keyboard ontwo different platforms (button-set1 and button-set2), assuming that the numeric keyboardis associated with only one target and there is not a sub-target associated to each specificnumber or button, the algorithm will detect that the target of the button-set1 and thetarget of the button-set2 are the same and the platforms are different, then the algorithmwill return false. On the other hand, if the user decides to distribute the numeric keyboardand the display on two different platforms, and each one has a different target, the algorithmwill return true.

Conclusions and Further Work

This work presents a new AUI model to support the Distributed User Interface (DUI)perspective. The introduction of the target hierarchy associated to every user interface sup-ports the distribution of user interface elements across different devices, maintaining thecoherence with the user task goal. This new AUI model is based on the characterization ofthe essential properties of Distributed User Interfaces: decomposability, portability, simul-taneity and continuity. We have employed a formal notation to describe these properties.The identification of essential properties have been proved useful in the analysis of differentreal DUI systems. The use of a formal notation to characterize Distributed User Interfacesis necessary to understand the essential foundation of these new kind of user interface and toanalyze different distribution mechanisms. As we have shown, a DUI is a set of interactiveelements with a common goal. The new concept of finality is key to verify how a distributeduser interface does or does not support the user’s system goal. The paper concludes withan algorithm that allows us to verify this concept. The integration of this new model in amodel-based framework to generate final user interfaces with this DUI perspective is partof the future work.

References

Abrams, M., Phanouriou, C., Batongbacal, A., Williams, S., & Shuster, J. (1999). UIML: AnAppliance-Independent XML User Interface LanguageUiml: An appliance-independent xmluser interface language. Computer Networks311695-1708.

Bowen, J., & Reeves, S. (2007). Using formal models to design user interfaces: a case studyUs-ing formal models to design user interfaces: a case study. In Proceedings of the BCS-HCI07Proceedings of the bcs-hci 07 (p. 159-166). Swinton, UK, UK.

A PROPOSAL TO VALIDATE THE USER’S GOAL IN DISTRIBUTED USER INTERFACES 14

Calvary, G., Coutaz, G., Thevenin, D., Limbourg, Q., Bouillon, L., & Vanderdonckt, J. (2003). Aunifying reference framework for multi-target user interfacesA unifying reference frameworkfor multi-target user interfaces. Interacting with computers153289-308.

Chi, U. (1985). Formal Specification of User Interfaces: A Comparison and Evaluation of FourAxiomatic ApproachesFormal specification of user interfaces: A comparison and evaluation offour axiomatic approaches. IEEE Transactions on Software Engineering11671-685.

Demeure, A., Calvary, G., Sottet, S., & Vanderdonckt, J. (2005). A reference model for distributeduser interfacesA reference model for distributed user interfaces. Task models and diagramsfor user interface design79-86.

Demeure, A., Sottet, S., G., C., Coutaz, G., Ganneau, J., & Vanderdonckt, J. (2008). The 4Creference model for distributed user interfacesThe 4c reference model for distributed userinterfaces. In Proc. of 4th Int. Conf. on Aut. and Aut. Systems ICAS 2008Proc. of 4th int.conf. on aut. and aut. systems icas 2008 (p. 61-69).

Eisenstein, J., Vanderdonckt, J., & Puerta, A. (2001). Model-Based User-Interface DevelopmentTechniques for Mobile ComputingModel-based user-interface development techniques for mo-bile computing. In J. Lester (Ed.), Proceedings of ACM International Conference on IntelligentUser Interfaces IUI 2001, Santa FeJ. lester (ed.), proceedings of acm international conferenceon intelligent user interfaces iui 2001, santa fe (pp. 69–76). ACM Press, New York.

Faure, D., & Vanderdonckt, J. 2010. Proc. of 1st Int. Workshop on User Interface ExtensibleMarkup Language UsiXML2010 (Berlin june 2010)Proc. of 1st int. workshop on user interfaceextensible markup language usixml2010 (berlin june 2010). Thales Research and Technology.

Gallud, J. A., Villanueva, P. G., Tesoriero, R., Sebastian, G., Molina, S., & Navarrete, A. (2010).Gesture-based Interaction: Concept Map and Application ScenariosGesture-based interaction:Concept map and application scenarios. In Proceedings of The 3rd International Conferenceon Advances in Human-Oriented and Personalized Mechanisms, Technologies and Services.CENTRIC 2010Proceedings of the 3rd international conference on advances in human-orientedand personalized mechanisms, technologies and services. centric 2010 (pp. 28–33). IEEE.

Guerrero, J., Gonzalez, J., Vanderdonckt, J., & Munoz, J. A. (2009). Theoretical Survey of UserInterface Description Languages: Prelimi-nary ResultsTheoretical survey of user interface de-scription languages: Prelimi-nary results. In LA-Web/CLIHC’2009La-web/clihc’2009 (p. 36-43). IEEE Computer Society Press, Los Alamitos.

Helms, J., Schaefer, R., Luyten, K., Vermeulen, J., Abrams, M., Coyette, A., et al. (2009). Human-Centered Engineering with the User Interface Markup LanguageHuman-centered engineer-ing with the user interface markup language. In Seffah, A., Vanderdonckt, J., Desmarais,M. (eds.), Human-Centered Software EngineeringSeffah, a., vanderdonckt, j., desmarais, m.(eds.), human-centered software engineering (p. 141-173). Springer.

Limbourg, Q., Vanderdonckt, J., Michotte, B., Bouillon, L., & Lopez-Jaquero, V. (2004). UsiXML:a Language Supporting Multi-Path Development of User InterfacesUsixml: a language sup-porting multi-path development of user interfaces. In (pp. 11–13). Springer-Verlag.

Lopez-Espın, J., Lazcorreta, E., Gallud, J., Penalver, A., & Botella, F. (2011). Formal Specificationof Distributed User InterfacesFormal specification of distributed user interfaces. In In Proc.of DUI 2011 Workshop.In proc. of dui 2011 workshop. University of Castilla-La Mancha.

Luyten, K., Abrams, M., Vanderdonckt, J., & Limbourg, Q. (2004). Developing User Interfaceswith XML: Advances on User Interface Description Languages.Developing user interfaces withxml: Advances on user interface description languages. Galipoli.

Luyten, K., & Coninx, K. (2004). UIML.NET: An open UIML renderer for the .NET frame-work.Uiml.net: An open uiml renderer for the .net framework. Technical report, LimburgsUniversitair Centrum

Paterno, F., Santoro, C., & Spano, L. (2009). MARIA: A universal, declarative, multiple abstraction-level language for service-oriented applications in ubiquitous environmentsMaria: A universal,declarative, multiple abstraction-level language for service-oriented applications in ubiquitous

A PROPOSAL TO VALIDATE THE USER’S GOAL IN DISTRIBUTED USER INTERFACES 15

environments. ACM Trans. Computer-Hum. Interaction164.Reichart, D. (2004). A.: Task Models as Basis for Requirements Engineering and Software Execu-

tionA.: Task models as basis for requirements engineering and software execution. In In Proc.of TAMODIA 2003In proc. of tamodia 2003 (pp. 51–58). ACM Press.

Shaer, O., Green, M., Jacob, R., & Luyten, K. (2008). User Interface Description Languages forNext Generation User InterfacesUser interface description languages for next generation userinterfaces. In Proc. of Extended Abstracts of CHI’08Proc. of extended abstracts of chi’08(p. 3949-3952). ACM Press, New York.

Souchon, N., & Vanderdonckt, J. 2003. A Review of XML-Compliant User Interface DescriptionLanguagesA review of xml-compliant user interface description languages. Joaquim A. Jorge,Nuno Jardim Nunes, and Joao Falcao e Cunha, editors, DSV-IS, volume 2844. Springer.

Vanderdonckt, J. (2010). Distributed User Interfaces: How to Distribute User Interface Elementsacross Users, Platforms, and EnvironmentsDistributed user interfaces: How to distribute userinterface elements across users, platforms, and environments. In International ConferenceInteraccion.International conference interaccion.

Vanderhulst, G. (2005). Dynamic Distributed User Interfaces: Supporting Mobile InteractionSpaces.Dynamic distributed user interfaces: Supporting mobile interaction spaces. Phd. The-sis

Villanueva, P. G., Tesoriero, R., & Gallud, J. A. (2010). Multi-pointer and collaborative sys-tem for mobile devicesMulti-pointer and collaborative system for mobile devices. In Pro-ceedings of the 12th international conference on Human computer interaction with mobiledevices and servicesProceedings of the 12th international conference on human computerinteraction with mobile devices and services (pp. 435–438). New York, NY, USAACM.http://doi.acm.org/10.1145/1851600.1851699