Academia.eduAcademia.edu

Figure 43 – uploaded by Niklas Elmqvist

See full PDFdownloadDownload figure
Fig. 15.5 Sequence diagram to illustrate the scenario 2 (partial duplication of functionality on VP)

Figure 15 5 Sequence diagram to illustrate the scenario 2 (partial duplication of functionality on VP)

Related Figures (64)

The domain is distributed across users, computing platforms, or environments. This case is relevant to the domain of Distributed Databases, where mechanisms have been defined for users to manage persistent data using different platforms (that include perhaps different database management systems) that span over different physical locations (e.g., for security, optimization, replication, continuous work). When a task and/or a domain are distributed across different users, platforms, environments, the UI of the resulting computer-based system becomes a DUI. This DUI could be studied at different levels of abstraction ranging from the abstract to concrete to final. This therefore induces many potentially different configurations in which the distribution may occur. | en ke, hs ee ec Co nn ee Ce 2 Cec i.e
The domain is distributed across users, computing platforms, or environments. This case is relevant to the domain of Distributed Databases, where mechanisms have been defined for users to manage persistent data using different platforms (that include perhaps different database management systems) that span over different physical locations (e.g., for security, optimization, replication, continuous work). When a task and/or a domain are distributed across different users, platforms, environments, the UI of the resulting computer-based system becomes a DUI. This DUI could be studied at different levels of abstraction ranging from the abstract to concrete to final. This therefore induces many potentially different configurations in which the distribution may occur. | en ke, hs ee ec Co nn ee Ce 2 Cec i.e
listribution is operated. In order to address this issue, we now provide a catalogue f distribution primitives that will operate on CUI models of the cluster. We first lefine these distribution primitives in natural language, then in an Extended Backus- Naur Form (EBNF) format. In this notation, brackets indicate an optional section, vhile parentheses denote a simple choice in a set of possible values. In the follow- ng definitions, we use only one widget at a time for facilitating understanding. n the EBNF, we will use the four selector mechanism standard from W3C for CSS or generalization to all widgets. Fig. 3.1 Command line interface provided by the toolkit
listribution is operated. In order to address this issue, we now provide a catalogue f distribution primitives that will operate on CUI models of the cluster. We first lefine these distribution primitives in natural language, then in an Extended Backus- Naur Form (EBNF) format. In this notation, brackets indicate an optional section, vhile parentheses denote a simple choice in a set of possible values. In the follow- ng definitions, we use only one widget at a time for facilitating understanding. n the EBNF, we will use the four selector mechanism standard from W3C for CSS or generalization to all widgets. Fig. 3.1 Command line interface provided by the toolkit
Fig. 3.3. EBNF grammar for distribution primitives (excerpt) ““&? means that something can be repeated any number of times, and “+” means that something can appear one or more times. EBNF has been selected because it is widely used to formally define programming languages and markup languages (e.g. XML and SGML), the syntax of the language is precisely defined, thus leaving nc ambiguity on its interpretation, and it is easier to develop a parser for such < language, because the parser can be generated automatically with a compiler (e.g. YACC). Instances of distribution primitives are called by statements. The definition: of an operation, a source, a target, a selector and some other ones are defined ir Figs. 3.3 and 3.4 (excerpt only). The definitions could be extended later to suppor more operations or features.
Fig. 3.3. EBNF grammar for distribution primitives (excerpt) ““&? means that something can be repeated any number of times, and “+” means that something can appear one or more times. EBNF has been selected because it is widely used to formally define programming languages and markup languages (e.g. XML and SGML), the syntax of the language is precisely defined, thus leaving nc ambiguity on its interpretation, and it is easier to develop a parser for such < language, because the parser can be generated automatically with a compiler (e.g. YACC). Instances of distribution primitives are called by statements. The definition: of an operation, a source, a target, a selector and some other ones are defined ir Figs. 3.3 and 3.4 (excerpt only). The definitions could be extended later to suppor more operations or features.
Fig. 4.4 The updated CARE attributes References
Fig. 4.4 The updated CARE attributes References
The main task for the target application is the ability to plan and execute flight route plans. The main gui components of the application are: Map tool, flight planner, video player, land tool and a report tool, in Fig.5.1 you can see the entire application running on a single device. As a new device is connected the application either then adapt itself by place components on the new device, either through Atomic, Mirrored or Cloned representation or operators can manually transport components between devices. Figure 5.2 shows the application distributed over two devices and one component is mirrored on both devices wheres one component is moved to the new devices.
The main task for the target application is the ability to plan and execute flight route plans. The main gui components of the application are: Map tool, flight planner, video player, land tool and a report tool, in Fig.5.1 you can see the entire application running on a single device. As a new device is connected the application either then adapt itself by place components on the new device, either through Atomic, Mirrored or Cloned representation or operators can manually transport components between devices. Figure 5.2 shows the application distributed over two devices and one component is mirrored on both devices wheres one component is moved to the new devices.
Fig. 5.2. The application distributed over two devices, where the map tool is mirrored on both devices where as the flight planner is transferred atomically to the second device The boolean argument indicates if Component representation should be used, if false a Image representation will be used. The framework provides means for the developer to control the callback functionality tied to ui-components. Using the standard Listeners provided with Java will allow for Client call-back coupling, where the code is transferred with the component, whereas using the Listeners supplied with the Marve framework will enable Server call-back coupling. The Listeners in the Marve framework extends the Listeners in the Java toolkit and have Server attached to the name.
Fig. 5.2. The application distributed over two devices, where the map tool is mirrored on both devices where as the flight planner is transferred atomically to the second device The boolean argument indicates if Component representation should be used, if false a Image representation will be used. The framework provides means for the developer to control the callback functionality tied to ui-components. Using the standard Listeners provided with Java will allow for Client call-back coupling, where the code is transferred with the component, whereas using the Listeners supplied with the Marve framework will enable Server call-back coupling. The Listeners in the Marve framework extends the Listeners in the Java toolkit and have Server attached to the name.
Fig. 6.1 Overview of the adaptation process in collaborative scenarios under the DVP subsequent adaptauion are considerably enriched and resulting interlaces provide the benefits from plasticity and awareness jointly. Next, in this section, the process to be carried out to provide awareness during execution, without neglecting plasticity is presented. Then, the system architecture operating in the server is described. The first step to put in practice this approach is embedding a specific Implicit Plasticity Engine (IPE henceforth) on a given DUI on the client side. IPE is a runtime adaptive engine to provide runtime adaptations, and specific awareness mechanisms focused on promoting collaboration that enrich the default operative in the client side. Details on the software structure for the IPE, specially detailed for components aimed at supporting work in group can be consulted in [11]. However, we would like to mention the most important component of these kinds of compo- nents, the so-called particular group-awareness —pGA in Fig. 6.1, which represents the individual perceptions and particular understanding about the group from each working group member. It includes all the information generated during the perfor- mance of the combined tasks that could affect to whole group state. Additionally, it registers interactions of the user at hand with the other group members and also any data related to communication events and coordination actions.
Fig. 6.1 Overview of the adaptation process in collaborative scenarios under the DVP subsequent adaptauion are considerably enriched and resulting interlaces provide the benefits from plasticity and awareness jointly. Next, in this section, the process to be carried out to provide awareness during execution, without neglecting plasticity is presented. Then, the system architecture operating in the server is described. The first step to put in practice this approach is embedding a specific Implicit Plasticity Engine (IPE henceforth) on a given DUI on the client side. IPE is a runtime adaptive engine to provide runtime adaptations, and specific awareness mechanisms focused on promoting collaboration that enrich the default operative in the client side. Details on the software structure for the IPE, specially detailed for components aimed at supporting work in group can be consulted in [11]. However, we would like to mention the most important component of these kinds of compo- nents, the so-called particular group-awareness —pGA in Fig. 6.1, which represents the individual perceptions and particular understanding about the group from each working group member. It includes all the information generated during the perfor- mance of the combined tasks that could affect to whole group state. Additionally, it registers interactions of the user at hand with the other group members and also any data related to communication events and coordination actions.
performed in the same or different places and finally, the task can be synchronous or asynchronous. The original CD has been modified including awareness in the group task definition. The main reason is that awareness is obtaining a remarkable importance in the studied environments. The new version allows indicating that a task needs awareness (Request Awareness, RAw) or provides awareness (Provide Awareness, PAw).
performed in the same or different places and finally, the task can be synchronous or asynchronous. The original CD has been modified including awareness in the group task definition. The main reason is that awareness is obtaining a remarkable importance in the studied environments. The new version allows indicating that a task needs awareness (Request Awareness, RAw) or provides awareness (Provide Awareness, PAw).
Fig. 8.1 A distributed multi-display environment (dMDE) is a multi-display environment (MDE) distributed at the scale of a building, e.g., a hospital
Fig. 8.1 A distributed multi-display environment (dMDE) is a multi-display environment (MDE) distributed at the scale of a building, e.g., a hospital
Fig. 8.2 In the activity view, activities are represented by floating panels including graphic and text description. Related actions are represented by icons on that panel
Fig. 8.2 In the activity view, activities are represented by floating panels including graphic and text description. Related actions are represented by icons on that panel
Fig. 8.3. On the eft, Action view presents the resources in panels encapsulating different type of interactive remote content, e.g., web pages, tables or graphs, etc. On the right, Action view collaborative windows include list of participants, chat window and video-conference window
Fig. 8.3. On the eft, Action view presents the resources in panels encapsulating different type of interactive remote content, e.g., web pages, tables or graphs, etc. On the right, Action view collaborative windows include list of participants, chat window and video-conference window
Fig. 9.1 General view of MPrinceTool
Fig. 9.1 General view of MPrinceTool
Fig. 9.2 Functionality of MPrinceTool system
Fig. 9.2 Functionality of MPrinceTool system
between the students is usually done by through a vocal dialogue, but the teacher can apply also the use of other non-oral forms of dialogue, such as a chat. Once the student/s makes the choice; the teacher has the feedback from the system to discover if the selected answer of the student/s is correct or not. a -s
between the students is usually done by through a vocal dialogue, but the teacher can apply also the use of other non-oral forms of dialogue, such as a chat. Once the student/s makes the choice; the teacher has the feedback from the system to discover if the selected answer of the student/s is correct or not. a -s
As future work we aim to develop new methods and learning techniques that can encompass a greater number of goals in a collaborative task and that the user is responsible for scheduling, in our case the teacher, the task he chooses and how these objectives will be evaluated. And also propose a new form of assessment indi- cators to be chosen by the teacher.
As future work we aim to develop new methods and learning techniques that can encompass a greater number of goals in a collaborative task and that the user is responsible for scheduling, in our case the teacher, the task he chooses and how these objectives will be evaluated. And also propose a new form of assessment indi- cators to be chosen by the teacher.
Fig. 10.1 A ZOIL-based multi-user, multi-surface, and multi-device interactive space (left). The right section shows the architecture and user interface of a ZOIL client application in detail
Fig. 10.1 A ZOIL-based multi-user, multi-surface, and multi-device interactive space (left). The right section shows the architecture and user interface of a ZOIL client application in detail
Fig. 10.2, Overview of ZOIL’s distribution capabilities overall network load of a ZOIL setup is relatively small, since only small changes of the data model are transmitted (Fig. 10.2). To achieve this, the ZOIL software frame- work uses the object database db4o [4] with its Transparent Persistence (TP) mecha- nism. The aim of TP is to enable programmers to access or change persistent data in their application with the same ease as non-persistent data models in main memory. This means that with TP and db4o, ZOIL developers are not concerned with persis- tence at all since persistence simply becomes a natural property of all ZOIL objects. Using TP, programmers can simply change the states and locations of objects on the client-side using standard C# code. Invisible to the programmer, all changes are then observed by db4o’s TP implementation. It collects all changes and transmits them via TCP/IP to the database server in regular intervals (typically 100 ms). The server per- sists the new state of the landscape and informs all other clients about the changes which are then automatically retrieved and executed on the remote clients within 100- 300 ms (in typical setups). Thereby the use of the object database db4o instead of traditional Object-Relational Mapping libraries (e.g. Hibernate) also facilitates itera- tive design, since changes in the objects’ class definitions in C# are directly recog- nized by db4o0 without the need to update external XML mappings.
Fig. 10.2, Overview of ZOIL’s distribution capabilities overall network load of a ZOIL setup is relatively small, since only small changes of the data model are transmitted (Fig. 10.2). To achieve this, the ZOIL software frame- work uses the object database db4o [4] with its Transparent Persistence (TP) mecha- nism. The aim of TP is to enable programmers to access or change persistent data in their application with the same ease as non-persistent data models in main memory. This means that with TP and db4o, ZOIL developers are not concerned with persis- tence at all since persistence simply becomes a natural property of all ZOIL objects. Using TP, programmers can simply change the states and locations of objects on the client-side using standard C# code. Invisible to the programmer, all changes are then observed by db4o’s TP implementation. It collects all changes and transmits them via TCP/IP to the database server in regular intervals (typically 100 ms). The server per- sists the new state of the landscape and informs all other clients about the changes which are then automatically retrieved and executed on the remote clients within 100- 300 ms (in typical setups). Thereby the use of the object database db4o instead of traditional Object-Relational Mapping libraries (e.g. Hibernate) also facilitates itera- tive design, since changes in the objects’ class definitions in C# are directly recog- nized by db4o0 without the need to update external XML mappings.
Code Sample 10.2, XAML for making ZPhoto a draggable, resizable, and rotatable zoom target
Code Sample 10.2, XAML for making ZPhoto a draggable, resizable, and rotatable zoom target
ind devices act as one distributed UI for co-located collaboration (Fig. 11.1). In thes« spaces we try to achieve a “natural” interaction, i.e. the UI is perceived as somethin: inobtrusive or even invisible that does not require the users’ continuous attention or « zreat deal of cognitive resources. A well-proven approach to achieve this is the visua nodel-world interface for “direct manipulation’, in which a tight coupling of input anc yutput languages narrows the gulfs of execution and evaluation [6]. While direc nanipulation originates from 1980s desktop computing, its principles are also the oundation of novel post-WIMP (post-“Windows Icons Menu Pointing’) or reality yased UIs [7]: Their interaction styles (e.g. tangible, multi-touch or paper-based UIs ‘draw strength by building on users’ pre-existing knowledge of the everyday, non ligital world to a much greater extent than before.” Users can apply the full breadth o heir natural, non-digital skills, e.g. the bimanual manipulation of objects, handwritins yr their awareness of objects or persons in their physical and social environment. Our two research groups have designed and implemented a great variety of suct
ind devices act as one distributed UI for co-located collaboration (Fig. 11.1). In thes« spaces we try to achieve a “natural” interaction, i.e. the UI is perceived as somethin: inobtrusive or even invisible that does not require the users’ continuous attention or « zreat deal of cognitive resources. A well-proven approach to achieve this is the visua nodel-world interface for “direct manipulation’, in which a tight coupling of input anc yutput languages narrows the gulfs of execution and evaluation [6]. While direc nanipulation originates from 1980s desktop computing, its principles are also the oundation of novel post-WIMP (post-“Windows Icons Menu Pointing’) or reality yased UIs [7]: Their interaction styles (e.g. tangible, multi-touch or paper-based UIs ‘draw strength by building on users’ pre-existing knowledge of the everyday, non ligital world to a much greater extent than before.” Users can apply the full breadth o heir natural, non-digital skills, e.g. the bimanual manipulation of objects, handwritins yr their awareness of objects or persons in their physical and social environment. Our two research groups have designed and implemented a great variety of suct
patterns and still requires much know-how about the technical background. For example, a DUI developer needs to know how to distribute the UI onto other machines. But network synchronization with all its issues is a very complex topic and a UI developer should not need to worry much about it. and a UI developer should not need to worry much about it. The concept of a Distributed ViewModel tries to address those problems by providing a network-synchronized model of a view to ease development of a shared UI. It provides an additional abstraction layer that contains the content of a view as well as view-dependent properties. The distributed view model is based on the Model-View-View-Model (MVVM) design pattern [15]. In the MVVM pattern the data model of an application is separated from its view, similar to the Model- View-Controller (MVC) pattern. In contrast to MVC, MVVM provides an addi- tional abstraction layer, the so-called “ViewModel” which is an abstract description of the view. The “ViewModel” can also be seen as a “Model of the View” containing only view-related information and logic. This allows an UI designer to mainly focus on UI design and it provides a clean interface to the non-UI parts of the application. The Distributed ViewModel pattern, as depicted in Fig. 11.2, facilitates this clean interface to provide a transparent distribution of view-related properties which are defined in the ViewModel. The Distributed ViewModel is much like the ViewModel as it contains the same information, but in contrast its contents and structure are already prepared for network synchronization. All information stored in a Distributed ViewModel is automatically serialized and synchronized with all other connected instances of the application or UI. In practice, the ViewModel can often be completely replaced by a Distributed ViewModel, if data types used in the view are compatible with network synchronization.
patterns and still requires much know-how about the technical background. For example, a DUI developer needs to know how to distribute the UI onto other machines. But network synchronization with all its issues is a very complex topic and a UI developer should not need to worry much about it. and a UI developer should not need to worry much about it. The concept of a Distributed ViewModel tries to address those problems by providing a network-synchronized model of a view to ease development of a shared UI. It provides an additional abstraction layer that contains the content of a view as well as view-dependent properties. The distributed view model is based on the Model-View-View-Model (MVVM) design pattern [15]. In the MVVM pattern the data model of an application is separated from its view, similar to the Model- View-Controller (MVC) pattern. In contrast to MVC, MVVM provides an addi- tional abstraction layer, the so-called “ViewModel” which is an abstract description of the view. The “ViewModel” can also be seen as a “Model of the View” containing only view-related information and logic. This allows an UI designer to mainly focus on UI design and it provides a clean interface to the non-UI parts of the application. The Distributed ViewModel pattern, as depicted in Fig. 11.2, facilitates this clean interface to provide a transparent distribution of view-related properties which are defined in the ViewModel. The Distributed ViewModel is much like the ViewModel as it contains the same information, but in contrast its contents and structure are already prepared for network synchronization. All information stored in a Distributed ViewModel is automatically serialized and synchronized with all other connected instances of the application or UI. In practice, the ViewModel can often be completely replaced by a Distributed ViewModel, if data types used in the view are compatible with network synchronization.
Fig. 12.1 Placement complexity of paired text and button widgets across a large display (LD) and small device (SD) This model allows us to separately explore the input and the output of a (distributed 1ser interface and how users respond to it during the execution and evaluation stages According to Norman, different mental activities are associated with the input anc yutput and so widgets allowing users to enter input might exhibit different design con traints compared to output widgets. Hence, we denote widgets associated with systen nput as interactive-widgets and those associated with system output as non-interactiv vidgets. Non-interactive widgets are in general used to present system states to users towever, interactive widgets accept user input to initiate system state changes. There is considerable complexity concernins the placement of non-interactiv
Fig. 12.1 Placement complexity of paired text and button widgets across a large display (LD) and small device (SD) This model allows us to separately explore the input and the output of a (distributed 1ser interface and how users respond to it during the execution and evaluation stages According to Norman, different mental activities are associated with the input anc yutput and so widgets allowing users to enter input might exhibit different design con traints compared to output widgets. Hence, we denote widgets associated with systen nput as interactive-widgets and those associated with system output as non-interactiv vidgets. Non-interactive widgets are in general used to present system states to users towever, interactive widgets accept user input to initiate system state changes. There is considerable complexity concernins the placement of non-interactiv
to enter their input. Considering multi-step interactions that involve more than one interactive widget, we can come up with four basic design strategies: (1) LD mode: With this design strategy, users use their smart phone to directly interact with widgets placed on the large public display. Although simple, in a multi-user scenario; problems can arise where more than one user want to access the same interactive widget. Furthermore, a sequence of actions might require a user to interact with several widgets over a longer time period which demands for space or ‘real estate’ on the LD; (11) SD mode: Moving interactive widgets down to the SD will free up real estate on the LD. Placing the interactive widgets on the display of a smart phone will also help ameliorate the multi- user access problem. Conversely this approach has the added complexity of using both the primary LD and the secondary SD where the smaller display imposes limita- tions in widgets placement compared to available real estate on the LD. (iii) LD-SD mode: Here some interactive widgets are placed on the LD and some on the SD. For example, a menu bar widget placed on the LD with associated menu widgets placed on the SD when activated by the users on the LD. The advantage here is that every user interaction has a defined entry point, which is in this case the LD. On the other hand, an interactive widget arrangement that is partly across LD and SD may cause user confusion; Mirrored mode: This design strategy introduces redundancy into the distributed user interface by placing the same widgets on both LD and SD. Hence, the audience can clearly see what the user enters. Of course, we neither solve real estate nor multi-user access problems, but users can make their own choice of select- ing the display they want to interact with, without the risk of getting confused.
to enter their input. Considering multi-step interactions that involve more than one interactive widget, we can come up with four basic design strategies: (1) LD mode: With this design strategy, users use their smart phone to directly interact with widgets placed on the large public display. Although simple, in a multi-user scenario; problems can arise where more than one user want to access the same interactive widget. Furthermore, a sequence of actions might require a user to interact with several widgets over a longer time period which demands for space or ‘real estate’ on the LD; (11) SD mode: Moving interactive widgets down to the SD will free up real estate on the LD. Placing the interactive widgets on the display of a smart phone will also help ameliorate the multi- user access problem. Conversely this approach has the added complexity of using both the primary LD and the secondary SD where the smaller display imposes limita- tions in widgets placement compared to available real estate on the LD. (iii) LD-SD mode: Here some interactive widgets are placed on the LD and some on the SD. For example, a menu bar widget placed on the LD with associated menu widgets placed on the SD when activated by the users on the LD. The advantage here is that every user interaction has a defined entry point, which is in this case the LD. On the other hand, an interactive widget arrangement that is partly across LD and SD may cause user confusion; Mirrored mode: This design strategy introduces redundancy into the distributed user interface by placing the same widgets on both LD and SD. Hence, the audience can clearly see what the user enters. Of course, we neither solve real estate nor multi-user access problems, but users can make their own choice of select- ing the display they want to interact with, without the risk of getting confused.
present a new system state as a result of user interactions Fig. 12.3. Since non-interactive widgets are meant to present content while interactive wid- gets are mainly to receive user inputs, the placement decision a designer has to make in case of non-interactive content would be based on the gains and the loss in each design decision as described below: (i) LD mode: This is the classic design strategy used by the majority of today’s interactive large public display installations. From the design point of view the LD mode is a challenging task. A designer has to find the right balance between available real estate on the LD and the quantity and the quality of content presented on the LD to properly serve the audience; (11) SD mode: Forcing users to rely solely on a SD defeats the purpose of large public display installations, which are designed to be enjoyable for an entire audience. However, in some circumstances, e.g. content that requires privacy or security considerations, utilizing this mode may be useful for implementing certain aspects of a large dis- play application; (iii) LD-SD mode: This mode combines the advantages of LD and SD. Content that might be interesting to the entire audience can be presented using non-interactive widgets on the LD. On the other hand, content specific to a request- ing user, and of less interest and importance for the rest of the audience, can be placed on the SD; (iv) Mirrored Mode: In this mode the very same content is pre- sented through same non-interactive widgets placed on the LD and SD. Here users can make their own choice of which display they use to view content. As listed above, the overall design strategies for non-interactive widgets compared to interac- tive-widgets differ in the way they serve and apply to distributed user interface concepts/issues.
present a new system state as a result of user interactions Fig. 12.3. Since non-interactive widgets are meant to present content while interactive wid- gets are mainly to receive user inputs, the placement decision a designer has to make in case of non-interactive content would be based on the gains and the loss in each design decision as described below: (i) LD mode: This is the classic design strategy used by the majority of today’s interactive large public display installations. From the design point of view the LD mode is a challenging task. A designer has to find the right balance between available real estate on the LD and the quantity and the quality of content presented on the LD to properly serve the audience; (11) SD mode: Forcing users to rely solely on a SD defeats the purpose of large public display installations, which are designed to be enjoyable for an entire audience. However, in some circumstances, e.g. content that requires privacy or security considerations, utilizing this mode may be useful for implementing certain aspects of a large dis- play application; (iii) LD-SD mode: This mode combines the advantages of LD and SD. Content that might be interesting to the entire audience can be presented using non-interactive widgets on the LD. On the other hand, content specific to a request- ing user, and of less interest and importance for the rest of the audience, can be placed on the SD; (iv) Mirrored Mode: In this mode the very same content is pre- sented through same non-interactive widgets placed on the LD and SD. Here users can make their own choice of which display they use to view content. As listed above, the overall design strategies for non-interactive widgets compared to interac- tive-widgets differ in the way they serve and apply to distributed user interface concepts/issues.
Fig. 12.4 The polar defense game (/eft) and the interactive directory (right) For our user studies we developed three applications whose interfaces were capable of utilizing just the LD or distributing itself across both the LD and SD. Polar Defense is a game where users begin by placing six defense towers on a 9x9 grid. Once the towers have been placed, enemies begin to cross the grid. Depending on the strategic placement of the towers, a number of enemies will be prevented from crossing the field as the towers attack nearby enemies. Users score based on how many enemies they prevented from crossing the field. Figures 12.4 and 12.1-left shows the Polar Defense game. OO TT HY cs Di i ee ee kh ee ec el ee i ec kl Bes Eb cc Becca ;
Fig. 12.4 The polar defense game (/eft) and the interactive directory (right) For our user studies we developed three applications whose interfaces were capable of utilizing just the LD or distributing itself across both the LD and SD. Polar Defense is a game where users begin by placing six defense towers on a 9x9 grid. Once the towers have been placed, enemies begin to cross the grid. Depending on the strategic placement of the towers, a number of enemies will be prevented from crossing the field as the towers attack nearby enemies. Users score based on how many enemies they prevented from crossing the field. Figures 12.4 and 12.1-left shows the Polar Defense game. OO TT HY cs Di i ee ee kh ee ec el ee i ec kl Bes Eb cc Becca ;
Fig. 13.1 Design of a dynamic peephole interface for projector phones. Only a part of the information space is visible (in this figure the opaque part). Notifications on different parts of the information space are indicated using the Halo technique [1]
Fig. 13.1 Design of a dynamic peephole interface for projector phones. Only a part of the information space is visible (in this figure the opaque part). Notifications on different parts of the information space are indicated using the Halo technique [1]
Fig. 13.2 This image was created by blending two images of the prototype taken from the same viewpoint. The accuracy is very high even though a small can be seen in the blending which is due to position inaccuracy To explore the whole map the user simply changes the orientation of the device. By this, the application than reveals the whole map part by part using the peephole metaphor (compare Fig. 13.2). In line with a normal map application, the map can be enhanced with different layers containing Points of Interest (POD) like georefer- enced Wikipedia articles, Hotels or the Google Latitude position of friends. The user can explore the detailed content of the POIs by moving the crosshair on the projection over the points and click on the select button. The information
Fig. 13.2 This image was created by blending two images of the prototype taken from the same viewpoint. The accuracy is very high even though a small can be seen in the blending which is due to position inaccuracy To explore the whole map the user simply changes the orientation of the device. By this, the application than reveals the whole map part by part using the peephole metaphor (compare Fig. 13.2). In line with a normal map application, the map can be enhanced with different layers containing Points of Interest (POD) like georefer- enced Wikipedia articles, Hotels or the Google Latitude position of friends. The user can explore the detailed content of the POIs by moving the crosshair on the projection over the points and click on the select button. The information
Fig. 13.3. The prototype consists of an 4th generation iPod touch and a microvision showWX laser projector
Fig. 13.3. The prototype consists of an 4th generation iPod touch and a microvision showWX laser projector
Fig. 14.1 Shared workspace with multi-pointer system On a similar way, software applications are expected to be used on different platforms. Users look for user interfaces which are familiar, intuitive, and easy to use. Designers should develop for the user (user-center design) looking for increasing the user experience and the usability of the system.
Fig. 14.1 Shared workspace with multi-pointer system On a similar way, software applications are expected to be used on different platforms. Users look for user interfaces which are familiar, intuitive, and easy to use. Designers should develop for the user (user-center design) looking for increasing the user experience and the usability of the system.
Fig. 14.2 Distributed interfaces. Two different views 14.4 Implementing Distributed User Interfaces in Drag&Share
Fig. 14.2 Distributed interfaces. Two different views 14.4 Implementing Distributed User Interfaces in Drag&Share
WT UINIY ALY auy Va Sew Vil Ul ay Olelil. The client is the internet browser. It displays the page containing the shared workspace, and communicates with the web server and the websockets server. The system architecture allows multiple users to interact concurrently in the system, delete documents or use the chat system. The interface always shows a consistent view with the state of the system.
WT UINIY ALY auy Va Sew Vil Ul ay Olelil. The client is the internet browser. It displays the page containing the shared workspace, and communicates with the web server and the websockets server. The system architecture allows multiple users to interact concurrently in the system, delete documents or use the chat system. The interface always shows a consistent view with the state of the system.
Fig. 15.1 The TangiSense interactive table with the recognition and learning of colors application ee oe ae Interactive tables have existed for a few years now. They are similar to the touchscreen tablet, but larger, being more the size of a coffee table for example around | m square. These tables are mainly based on tactile or vision technology} and allow the same uses as the tablets; they thus handle mainly virtual objects. It this chapter, we propose another type of interactive table which uses Radic Frequency Identification (RFID) technology in order to interact, not only with the fingers on virtual objects but directly with tangible objects RFID tagged. Thi: table, called TangiSense, detects objects equipped with RFID tags when they are placed on it [3]. The use of RFID makes it possible firstly to detect objects presen on the surface of the table, secondly to identify them thanks to one or more tag:
Fig. 15.1 The TangiSense interactive table with the recognition and learning of colors application ee oe ae Interactive tables have existed for a few years now. They are similar to the touchscreen tablet, but larger, being more the size of a coffee table for example around | m square. These tables are mainly based on tactile or vision technology} and allow the same uses as the tablets; they thus handle mainly virtual objects. It this chapter, we propose another type of interactive table which uses Radic Frequency Identification (RFID) technology in order to interact, not only with the fingers on virtual objects but directly with tangible objects RFID tagged. Thi: table, called TangiSense, detects objects equipped with RFID tags when they are placed on it [3]. The use of RFID makes it possible firstly to detect objects presen on the surface of the table, secondly to identify them thanks to one or more tag:
Fig. 15.2 (a) Centralized distribution of UI (b) Network of distributed UI
Fig. 15.2 (a) Centralized distribution of UI (b) Network of distributed UI
Fig. 15.3. Problem space and positioning of four representative scenarios
Fig. 15.3. Problem space and positioning of four representative scenarios
Fig. 15.4 Sequence diagram illustrating the scenario 1 .2.2 Scenarios of Interaction Initiated by Tangible Objects on Tabletop
Fig. 15.4 Sequence diagram illustrating the scenario 1 .2.2 Scenarios of Interaction Initiated by Tangible Objects on Tabletop
3 Case Study: Crisis Management Unit
3 Case Study: Crisis Management Unit
Fig. 15.7 Crisis unit using TangiSense and other platforms
Fig. 15.7 Crisis unit using TangiSense and other platforms
Fig. 15.9 Sequence diagram to illustrate an example of exchange in the case study (Multiple collaboration) Fig. 15.8 Examples of DUI
Fig. 15.9 Sequence diagram to illustrate an example of exchange in the case study (Multiple collaboration) Fig. 15.8 Examples of DUI
Fig. 16.1 The collaborative mobile service creation editor architecture
Fig. 16.1 The collaborative mobile service creation editor architecture
Fig. 16.2 The shared and local views of the system functionality
Fig. 16.2 The shared and local views of the system functionality
Fig. 16.3. The sport tracker scenario
Fig. 16.3. The sport tracker scenario
Fig. 17.1 (a) Meeting room that incorporates the “Co-Interactive Table system”. (b) Natural gesture performed to execute a task by means of the interactive panel. This interaction style has been called “approach&remove” point to the server that stores the important data, files and methods ne-cessary for the operation of the system. In addition, the room has a projector con-nected to a PC that shows the users connected in each moment and the post-it notes that they have sent during the meeting through their panels. It can also sup-port remote meetings where users are distributed in different geographical loca-tions connected to the same server.
Fig. 17.1 (a) Meeting room that incorporates the “Co-Interactive Table system”. (b) Natural gesture performed to execute a task by means of the interactive panel. This interaction style has been called “approach&remove” point to the server that stores the important data, files and methods ne-cessary for the operation of the system. In addition, the room has a projector con-nected to a PC that shows the users connected in each moment and the post-it notes that they have sent during the meeting through their panels. It can also sup-port remote meetings where users are distributed in different geographical loca-tions connected to the same server.
Fig. 17.2 Interactive panel user interface showing the functions offered by the intelligent objects
Fig. 17.2 Interactive panel user interface showing the functions offered by the intelligent objects
Fig. 17.3. (a) Co-Interactive table implementation of distributed user interfaces. (b) The user in (/) has a presentation open in his/her mobile device. The user brings near the device to the metaphor called “Send to project’’. Instantly the projector shows the same presentation that the user has in his/ her mobile devices. In this way the interface mobile device is distributed in the projector (2)
Fig. 17.3. (a) Co-Interactive table implementation of distributed user interfaces. (b) The user in (/) has a presentation open in his/her mobile device. The user brings near the device to the metaphor called “Send to project’’. Instantly the projector shows the same presentation that the user has in his/ her mobile devices. In this way the interface mobile device is distributed in the projector (2)
The system is a client-server system (see Fig. 17.4). The client system runs on the user mobile device. It is connected to the server application through a wireless network and it is communicated with the interactive table via RFID. When the RFID reader in the mobile device is approached to the chosen metaphor, the RFID tag is excited by electromagnetic waves sent by the RFID reader, then, the component controller, explained below, sends the identifier to the server. The server maps this information in the database and executes the steps necessary to return the information to the mobile device. The applications running in the server are shown in the projector. In addition, the system includes a webcam to communicate via conference with other users and share files and information remotely.
The system is a client-server system (see Fig. 17.4). The client system runs on the user mobile device. It is connected to the server application through a wireless network and it is communicated with the interactive table via RFID. When the RFID reader in the mobile device is approached to the chosen metaphor, the RFID tag is excited by electromagnetic waves sent by the RFID reader, then, the component controller, explained below, sends the identifier to the server. The server maps this information in the database and executes the steps necessary to return the information to the mobile device. The applications running in the server are shown in the projector. In addition, the system includes a webcam to communicate via conference with other users and share files and information remotely.
Fig. 18.1 Distributed photo frames with light auras indicating high level changes in the elderly’s wellbeing, and intelligent photo frame jewelry to exchange affective messages, forming part of the Aurama awareness system
Fig. 18.1 Distributed photo frames with light auras indicating high level changes in the elderly’s wellbeing, and intelligent photo frame jewelry to exchange affective messages, forming part of the Aurama awareness system
Fig. 18.2 Overview of the Aurama awareness system with tailored distributed user interfaces for each party. The sensors in the elderly’s home capture contextual information to assess their wellbeing and inform family and care providers
Fig. 18.2 Overview of the Aurama awareness system with tailored distributed user interfaces for each party. The sensors in the elderly’s home capture contextual information to assess their wellbeing and inform family and care providers
have a contact with whom they have a caring and affective relation at a distant locatio. and also be familiar with voice over IP (VOIP) communication systems. Thus, the walk around performing some tasks while having a phone conversation. In this initia study, participants commented very positively on ambient telephony considering 1 more comfortable and convenient than cordless, especially regarding its hands-fre and location-free use. Some participants commented about feeling their contac closer, as if they were in the same room. Participants noticed the sound source (speakers on the ceiling) and in many cases showed intimacy behaviors (like noddin: and staring at the sound sources). On the other hand, there were negative remark about “talking to the ceiling”, the “unnatural” position of the sound, not havin: anything to look at, and the low quality of the sound. These could be annoying especially when multitasking. a a i: a a a a) a a,
have a contact with whom they have a caring and affective relation at a distant locatio. and also be familiar with voice over IP (VOIP) communication systems. Thus, the walk around performing some tasks while having a phone conversation. In this initia study, participants commented very positively on ambient telephony considering 1 more comfortable and convenient than cordless, especially regarding its hands-fre and location-free use. Some participants commented about feeling their contac closer, as if they were in the same room. Participants noticed the sound source (speakers on the ceiling) and in many cases showed intimacy behaviors (like noddin: and staring at the sound sources). On the other hand, there were negative remark about “talking to the ceiling”, the “unnatural” position of the sound, not havin: anything to look at, and the low quality of the sound. These could be annoying especially when multitasking. a a i: a a a a) a a,
Fig. 18.4 User test of the ambient telephony system: (/eft) a user laying back during the call and (right) a user addressing the rendering unit while performing a task
Fig. 18.4 User test of the ambient telephony system: (/eft) a user laying back during the call and (right) a user addressing the rendering unit while performing a task
Fig. 18.5 An example of the SoPresenT devices distributed remotely conveying presence and motion information of the remote party the user triggers the remote device to glow indicating the person is thinking about the remote party. By tapping the device the user requests information of the remote party regarding how active they have been around their device and this is shown via patterns of light. Furthermore, when one taps their device requesting information of the remote party, the remote party’s device can glow indicating that their informa- tion has been requested.
Fig. 18.5 An example of the SoPresenT devices distributed remotely conveying presence and motion information of the remote party the user triggers the remote device to glow indicating the person is thinking about the remote party. By tapping the device the user requests information of the remote party regarding how active they have been around their device and this is shown via patterns of light. Furthermore, when one taps their device requesting information of the remote party, the remote party’s device can glow indicating that their informa- tion has been requested.
Fig. 19.1 In this scenario, two visitors use their mobile devices to search for a restaurant or a hotel. Their productivity would benefit from knowledge of what the other person is looking at, for example, in the same shared virtual workspace. However, common interfaces for mobile devices lack such awareness cues
Fig. 19.1 In this scenario, two visitors use their mobile devices to search for a restaurant or a hotel. Their productivity would benefit from knowledge of what the other person is looking at, for example, in the same shared virtual workspace. However, common interfaces for mobile devices lack such awareness cues
Table 19.1 A summary of awareness features and their corresponding visual augmentation cues
Table 19.1 A summary of awareness features and their corresponding visual augmentation cues
Fig. 19.2. The mobile display view and conceptual shared workspace. The second user’s navigation region is shown by a bounding box and is indicated by a red wedge. Other wedges reveal the locations of a POI and a visit wear
Fig. 19.2. The mobile display view and conceptual shared workspace. The second user’s navigation region is shown by a bounding box and is indicated by a red wedge. Other wedges reveal the locations of a POI and a visit wear
Fig. 19.3. A shared projected display shows the location and scale of each user’s view. Clouds provide information about their respective navigation histories
Fig. 19.3. A shared projected display shows the location and scale of each user’s view. Clouds provide information about their respective navigation histories
Fig. 20.1 Controlling the shared surface
Fig. 20.1 Controlling the shared surface
Fig. 20.2 Conceptual design for a system supporting secure distributed user interfaces
Fig. 20.2 Conceptual design for a system supporting secure distributed user interfaces
580 California St., Suite 400
San Francisco, CA, 94104
© 2025 Academia. All rights reserved