Bundle-PBib
view release on metacpan or search on metacpan
t/sample.html view on Meta::CPAN
<META NAME="AUTHOR" CONTENT="Peter Tandler">
<META NAME="CREATED" CONTENT="20041130;13260000">
<META NAME="CHANGEDBY" CONTENT="Peter Tandler">
<META NAME="CHANGED" CONTENT="20041130;17282428">
<META NAME="CLASSIFICATION" CONTENT="JSS special issue on UbiTools">
<STYLE>
<!--
@page { size: 21cm 29.7cm; margin-right: 3.18cm; margin-top: 2.54cm; margin-bottom: 1.27cm }
P { margin-bottom: 0.21cm; direction: ltr; color: #000000; text-align: justify; widows: 2; orphans: 2 }
P.western { font-family: "Times New Roman", serif; font-size: 10pt; so-language: en-US }
P.cjk { font-family: "Times New Roman", serif; font-size: 10pt }
P.ctl { font-family: "Times New Roman", serif; font-size: 10pt; so-language: ar-SA }
H1 { margin-bottom: 0.42cm; direction: ltr; color: #000000; text-align: left; page-break-inside: avoid; widows: 2; orphans: 2 }
H1.western { font-family: "Arial", sans-serif; font-size: 14pt; so-language: en-US; font-weight: medium }
H1.cjk { font-family: "Times New Roman", serif; font-size: 14pt; font-weight: medium }
H1.ctl { font-family: "Times New Roman", serif; font-size: 10pt; so-language: ar-SA; font-weight: medium }
H2 { margin-top: 0.21cm; margin-bottom: 0.11cm; direction: ltr; color: #000000; text-align: left; page-break-inside: avoid; widows: 2; orphans: 2 }
H2.western { font-family: "Arial", sans-serif; font-size: 11pt; so-language: en-US; font-weight: medium }
H2.cjk { font-family: "Times New Roman", serif; font-size: 11pt; font-weight: medium }
H2.ctl { font-family: "Times New Roman", serif; font-size: 10pt; so-language: ar-SA; font-weight: medium }
H3 { margin-top: 0.21cm; margin-bottom: 0.11cm; direction: ltr; color: #000000; text-align: left; widows: 2; orphans: 2 }
H3.western { font-family: "Arial", sans-serif; font-size: 11pt; so-language: en-US; font-weight: medium }
H3.cjk { font-family: "Times New Roman", serif; font-size: 11pt; font-weight: medium }
H3.ctl { font-family: "Times New Roman", serif; font-size: 10pt; so-language: ar-SA; font-weight: medium }
P.sdfootnote-western { margin-left: 0.25cm; text-indent: -0.25cm; margin-bottom: 0.14cm; font-family: "Times New Roman", serif; font-size: 10pt; so-language: en-US }
P.sdfootnote-cjk { margin-left: 0.25cm; text-indent: -0.25cm; margin-bottom: 0.14cm; font-family: "Times New Roman", serif; font-size: 10pt }
P.sdfootnote-ctl { margin-left: 0.25cm; text-indent: -0.25cm; margin-bottom: 0.14cm; font-family: "Times New Roman", serif; font-size: 10pt; so-language: ar-SA }
H1.heading-1*-western { font-family: "Arial", sans-serif; font-size: 14pt; so-language: en-US; font-weight: medium }
H1.heading-1*-cjk { font-family: "Times New Roman", serif; font-size: 14pt; font-weight: medium }
H1.heading-1*-ctl { font-family: "Times New Roman", serif; font-size: 10pt; so-language: ar-SA; font-weight: medium }
H2.heading-2*-western { margin-left: 1.02cm; text-indent: -1.02cm; font-family: "Arial", sans-serif; font-size: 11pt; so-language: en-US; font-weight: medium }
H2.heading-2*-cjk { margin-left: 1.02cm; text-indent: -1.02cm; font-family: "Times New Roman", serif; font-size: 11pt; font-weight: medium }
H2.heading-2*-ctl { margin-left: 1.02cm; text-indent: -1.02cm; font-family: "Times New Roman", serif; font-size: 10pt; so-language: ar-SA; font-weight: medium }
A:link { color: #000000; text-decoration: none }
A.western:link { font-style: italic }
A.cjk:link { font-style: italic }
A:visited { color: #800080 }
A.sdfootnoteanc { font-size: 57% }
-->
</STYLE>
</HEAD>
<BODY LANG="en-US" TEXT="#000000" LINK="#000000" VLINK="#800080" DIR="LTR">
<P ALIGN=LEFT STYLE="margin-top: 0.42cm; margin-bottom: 0.42cm; page-break-inside: avoid; page-break-before: always; page-break-after: avoid">
<FONT FACE="Arial, sans-serif"><FONT SIZE=4 STYLE="font-size: 16pt"><B>The
BEACH Application Model and Software Framework for Synchronous
Collaboration in Ubiquitous Computing Environments</B></FONT></FONT></P>
<P STYLE="margin-top: 0.21cm; page-break-inside: avoid; page-break-after: avoid">
<FONT FACE="Arial, sans-serif"><FONT SIZE=3>Peter Tandler</FONT></FONT></P>
<P LANG="" ALIGN=LEFT STYLE="margin-bottom: 0.64cm; page-break-inside: avoid; widows: 0; orphans: 0; page-break-after: avoid">
<FONT FACE="Times, serif">FhG – Fraunhofer Gesellschaft
e.V.<BR>IPSI – Integrated Publication and Information Systems
Institute<BR>AMBIENTE – Workspaces of the
Future<BR><FONT COLOR="#000000"><I><SPAN STYLE="text-decoration: none"><A CLASS="western" HREF="http://ipsi.fraunhofer.de/ambiente/">http://ipsi.fraunhofer.de/ambiente/</A></SPAN></I></FONT><I>
</I></FONT>
</P>
<H1 CLASS="heading-1*-western">Abstract</H1>
<P CLASS="western" STYLE="margin-bottom: 0.11cm">The devices
available in ubiquitous computing environments offer new
possibilities for interaction. In the context of meetings and
teamwork situations, it is desirable to take advantage of their
properties for synchronous collaboration. Besides offering an adapted
user interface, this requires that the software infrastructure is
designed for <I>synchronous access</I> to shared information objects
using <I>heterogeneous devices</I> with <I>different interaction</I>
characteristics. As this field is still emerging and no mature
standards are at hand, it is necessary to provide guidance for
UbiComp developers how to model their applications to ensure both
extensibility for future developments and reusability in new
contexts.</P>
<P CLASS="western" STYLE="margin-bottom: 0.11cm">In this paper, a
conceptual model for synchronous applications in ubiquitous computing
environments is proposed. To test its applicability, it was used to
structure the architecture of the BEACH software framework that is
the basis for the software infrastructure of <SPAN LANG="">i-LAND</SPAN>
(the ubiquitous computing environment at FhG-IPSI). The BEACH
framework provides the functionality for synchronous cooperation and
interaction with roomware components, i.e. room elements with
integrated information technology. To show how the BEACH model and
framework can be applied, the design of a sample application is
explained. Also, the BEACH model is positioned against related work.
In conclusion, we provide our experiences with the current
implementation.</P>
<H2 CLASS="heading-2*-western">Keywords</H2>
<P CLASS="western" STYLE="margin-bottom: 0.11cm">Synchronous
collaboration, heterogeneous devices, software architecture,
conceptual model, BEACH application model and framework, <SPAN LANG="">i-LAND</SPAN>,
roomware components</P>
<H1 CLASS="western">1Introduction</H1>
<P CLASS="western" STYLE="margin-bottom: 0.11cm">Ubiquitous computing
environments offer a wide range of devices coming in many different
sizes and shapes [[UbiComp-Issues]]. Being often occupied by multiple
users simultaneously, ubiquitous computing environments must support
synchronous work with information that is shared among all present
devices. Due to the heterogeneous nature of ubiquitous computing
devices, their software infrastructure must enable user interfaces
taking advantage of their different properties. In addition, it must
enable tight collaboration of users working with different devices or
sharing the same device.</P>
<P CLASS="western" STYLE="margin-bottom: 0.11cm">Current operation
systems provide no support for handling this heterogeneity.
Synchronous collaboration can be handled by several
computer-supported cooperative work frameworks, groupware systems, or
middleware infrastructures, but these systems have no support for
heterogeneous devices. There are research prototypes aimed at
managing devices with different interaction capabilities, but these
projects mainly deal with interfaces for and discovery of simple
services and lack support for tight collaboration. There is a need
for a software infrastructure designed for handling heterogeneous
environments, providing adequate interaction styles and user
interface concepts, as well as offering capabilities for synchronous
collaboration. As this kind of infrastructure is built on top of
current operating systems, which handle the interaction with the
specific hardware, it can be referred to as “meta-operating
system” [[Gaia-GaiaOS]].</P>
<P CLASS="western" STYLE="margin-bottom: 0.11cm">Over the last five
years, we have been working at IPSI, the Fraunhofer Integrated
Publication and Information Systems Institute in Darmstadt (Germany),
in the context of the <SPAN LANG="">i-LAND</SPAN> project on support
for synchronous collaboration with roomware components
[[Roomware-Matters], [Roomware-i-LAND], [Roomware-NextGeneration],
[Roomware-SecondGeneration]]. “Roomware” is a term we
coined to refer to room elements with integrated information
technology such as interactive tables, walls, or chairs.</P>
<P CLASS="western" STYLE="margin-bottom: 0.11cm">The work presented
here was originally triggered by the need to create a software
infrastructure for this roomware environment. This led to the
development of a software prototype called “BEACH”, the
<U>B</U>asic <U>E</U>nvironment for <U>A</U>ctive <U>C</U>ollaboration
with <U>H</U>ypermedia. BEACH provides the software infrastructure
for environments supporting synchronous collaboration with many
different devices. It offers a user interface that also fits to the
needs of devices that have no mouse or keyboard, and which require
new forms of human-computer and team-computer interaction. To allow
synchronous collaboration BEACH builds on shared documents accessible
via multiple interaction devices concurrently.</P>
<P CLASS="western" STYLE="margin-bottom: 0.11cm">During the
development, BEACH was restructured and refactored
[[Refactory-Smalltalk], [Jacobsen-SoftwareModelling]] several times.
It became obvious that a <I>conceptual model</I> was needed to guide
developers of ubiquitous computing applications. This led us to the
work presented here. Parts of BEACH emerged into a software framework
with an architecture that is structured according to the conceptual
model for synchronous ubiquitous computing applications proposed in
this paper. The model aims at offering both flexibility and
extensibility for different devices that are part of ubiquitous
computing environments.</P>
<H2 CLASS="western"><A NAME="sContributingAreas"></A>1.1Involved
Research Areas</H2>
<P CLASS="western" STYLE="margin-bottom: 0.11cm">Due to the nature of
collaborative ubiquitous computing environments, the results of
several related research areas have to be combined to gain an
integrated application model that covers all aspects of interaction
and collaboration (fig. 1-1.1):<SUP><A CLASS="sdfootnoteanc" NAME="sdfootnote1anc" HREF="#sdfootnote1sym"><SUP>1</SUP></A></SUP></P>
<UL>
<LI><P STYLE="margin-bottom: 0cm"><FONT FACE="Times, serif">Human-Computer
Interaction (HCI) deals with user interfaces and interaction
techniques.</FONT></P>
<LI><P STYLE="margin-bottom: 0cm"><FONT FACE="Times, serif">Ubiquitous
computing (UbiComp) explores dynamic environments with heterogeneous
devices.</FONT></P>
<LI><P STYLE="margin-bottom: 0cm"><FONT FACE="Times, serif">Computer-Supported
Cooperative Work (CSCW) offers techniques to handle synchronous
interaction with distributed computers.</FONT></P>
<LI><P><FONT FACE="Times, serif">Software development techniques are
needed to ensure extensibility and reusability.</FONT></P>
</UL>
<P LANG="de-DE" ALIGN=CENTER STYLE="margin-top: 0.39cm; margin-bottom: 0.39cm; widows: 0; orphans: 0; page-break-after: avoid">
<IMG SRC="sample_html_49014637.gif" NAME="Graphic1" ALIGN=BOTTOM WIDTH=342 HEIGHT=172 BORDER=0></P>
<P STYLE="margin-left: 0.49cm; margin-right: 0.66cm; margin-bottom: 0.35cm"><A NAME="fContributingAreas"></A>
<FONT FACE="Helvetica, sans-serif"><FONT SIZE=2 STYLE="font-size: 9pt">Figure
<SPAN LANG="">1</SPAN> 1.1.<SPAN LANG=""> Conttibuting research
areas for the design of collaborative ubiquitous computing
applications.</SPAN></FONT></FONT></P>
<P CLASS="western" STYLE="margin-bottom: 0.11cm">A successful model
for collaborative ubiquitous computing applications must combine the
results of all involved research areas.</P>
<H2 CLASS="western">1.2Outline of the Paper</H2>
<P CLASS="western" STYLE="margin-bottom: 0.11cm">In the following
section, requirements for the software infrastructure of a ubiquitous
computing environment to support synchronous collaboration are
discussed. A sample application, the Passage system, is introduced,
which is used in the following to illustrate the application of the
BEACH model and framework. Based on the identified requirements, the
proposed conceptual application model has been designed, which is
presented next. The succeeding section presents the architecture of
the BEACH software framework, which has been developed according to
the structure suggested by the conceptual model. The software design
of the Passage system is explained as a sample application of the
BEACH model and framework. To position the BEACH model against other
approaches, the next section compares the proposed model with related
work. The paper closes with a discussion of the conceptual model and
ideas for future work.</P>
<P CLASS="western" STYLE="margin-bottom: 0.11cm">[# …. Bla bla
bla … some stuff removed … #]</P>
<H1 CLASS="western"><A NAME="cConceptualModel"></A>2A Conceptual
Model for Ubiquitous Computing Applications</H1>
<P CLASS="western" STYLE="margin-bottom: 0.11cm">A conceptual model
defines the very high-level structure of an application
[[Groupware-Architectures], [PAC-UI-Architecture]]. By using this
structure for applications, basic components are identified that have
a clear separation of concerns, thus supporting their independence
and increasing their flexibility and adaptability. According to the
definition by [ :inline | [Nowack-Structures+Interactions]] a
“conceptual model describes a conceptual understanding of
something, and it is based on concept formation in terms of
classification, generalization and aggregation. Hence, conceptual
modeling implies abstraction”. Abstraction is a key technique
to overcome software complexity by allowing the developer to focus on
one specific aspect at a time. By using this structure for
applications, basic components are identified that have a clear
separation of concerns, thus supporting their independence and
increasing their flexibility and adaptability
[[BuildAppFWs-Viewpoints]].</P>
<P CLASS="western" STYLE="margin-bottom: 0.11cm">In this section, a
conceptual model for ubiquitous computing applications is presented.
Organized by three major design dimensions, which are identified
first, its properties are discussed.</P>
<H2 CLASS="western">2.1Design Dimensions</H2>
<P CLASS="western" STYLE="margin-bottom: 0.11cm">In order to identify
the design dimensions for a conceptual model, results of all
contributing research areas (identified in section 1.1) have to be
considered. Looking at these four areas, contributions for a
conceptual model can be identified (fig. 4-2.1):</P>
<UL>
<LI><P STYLE="margin-bottom: 0cm"><FONT FACE="Times, serif">Human-Computer
Interaction (HCI) is concerned with <I>user interface &
interaction</I>.</FONT></P>
<LI><P STYLE="margin-bottom: 0cm"><FONT FACE="Times, serif">CSCW has
identified different degrees of <I>coupling</I> and different
mechanisms for <I>sharing</I>.</FONT></P>
<LI><P STYLE="margin-bottom: 0cm"><FONT FACE="Times, serif">Ubiquitous
computing (UbiComp) has to deal with <I>device</I> heterogeneity and
their relation to the <I>environment</I> in which they are used.</FONT></P>
<LI><P><FONT FACE="Times, serif">And, finally, <I>separating
specific concerns</I> and defining <I>levels of abstraction</I> are
very important software modeling techniques.</FONT></P>
</UL>
<P LANG="de-DE" ALIGN=CENTER STYLE="margin-top: 0.39cm; margin-bottom: 0.39cm; widows: 0; orphans: 0; page-break-after: avoid">
<IMG SRC="sample_html_m1d98ba7c.gif" NAME="Graphic2" ALIGN=BOTTOM WIDTH=308 HEIGHT=238 BORDER=0></P>
<P STYLE="margin-left: 0.49cm; margin-right: 0.66cm; margin-bottom: 0.35cm"><A NAME="fContributionsForRWApp"></A>
t/sample.html view on Meta::CPAN
[[Schmidt-ImplicitHCI]]. This can be accomplished by using changes in
the real world’s state to trigger software functionality.<SUP><A CLASS="sdfootnoteanc" NAME="sdfootnote2anc" HREF="#sdfootnote2sym"><SUP>2</SUP></A></SUP>
Therefore, the environment model must be capable of expressing
relevant information, such as spatial relationships between physical
objects.</P>
<H3 CLASS="western"><A NAME="sInteractionModelConcept"></A>Interaction
Model: Presentation and Interaction</H3>
<P CLASS="western" STYLE="margin-bottom: 0.11cm">To be able to
support different styles of interaction (req. , ), the interaction
model specifies how different interaction styles can be defined. The
term used here describes a part of the software architecture, and
should not be confused with the “interaction model”
describing the “look and feel” of a user interface at a
conceptual level as defined by [ :inline |
[BeaudouinLafon-PostWIMPModel]]. Instead, it is a generalized view of
the “interaction model” described by [ :inline |
[Suite-CouplingUIs]].</P>
<P CLASS="western" STYLE="margin-bottom: 0.11cm">As shown in figure
4-2.2, the interaction model defines a way to interact with all other
basic models. This is necessary, as all models can define aspects and
functions that can be represented for and accessed by the user. For
example, a data object like a “text” object often has a
directly attached view and controller, enabling direct interaction
with the text; then, interaction and data model communicate directly,
bypassing user interface and application models. Alternatively, a
“visual interaction area” being part of the user
interface model, provides functionality that has an immediate visual
representation rendered by the interaction model. In other cases, the
interaction model will not access the data model directly. Instead,
it is associated with an appropriate application model as a mediator
to the data model. This way, the interaction style can be adapted
depending on which application model is used to access a data model.</P>
<P CLASS="western" STYLE="margin-bottom: 0.11cm">As an appropriate
interaction style depends on the available interaction devices and
the associated user interface, a suitable interaction model can be
chosen depending on the environment and user-interface model. For
visual-based interaction, an adapted version of the
model-view-controller concept [[MVC-Cookbook],
[COAST-ooSyncGroupware]] has proven successful. However, the “model”
of the model-view-controller concept is not further structured. It
can refer to each of data, application, user interface, or
environment model.</P>
<P CLASS="western" STYLE="margin-bottom: 0.11cm">Passage defines an
interactive visual representation (for the virtual part of the
bridge) and physical actions as input (placing objects on the
physical part of the bridge). Consequently, its interaction model
uses both a visual interaction model (see section ) and a sensor
model providing the basis for detecting physical objects (see section
).</P>
<H2 CLASS="western"><A NAME="sConceptualSharing"></A>2.3Second
Dimension: Coupling and Sharing</H2>
<P CLASS="western" STYLE="margin-bottom: 0.11cm">Whenever multiple
devices are involved in a software system, the question arises, which
parts of the system should be local to a device or shared between
several. This has to be clarified for both the application code and
its state. While <I>distributing code</I> among devices is a
technical question unique to every application, <I>sharing state</I>
has conceptual implications, which this section addresses.</P>
<P CLASS="western" STYLE="margin-bottom: 0.11cm">Today, many
applications still run entirely local to a single computer, or access
only data that is distributed over a network. Aiming at synchronous
collaboration, crucial aspects of traditional CSCW systems are <I>access
to shared data</I> and <I>coupling the applications </I>of
collaborating users [[Suite-CouplingUIs]]. Therefore, coupling has to
be applied to both the data and the application model
[[COAST-Model]].</P>
<P CLASS="western" STYLE="margin-bottom: 0.11cm">In the context of
ubiquitous computing environments, this view has to be extended. In
addition to data and application, also information about the physical
environment, e.g., the presence of nearby users or other available
interaction devices, has to be exchanged by different devices and
applications.</P>
<P CLASS="western" STYLE="margin-bottom: 0.11cm">As discussed above,
in a ubiquitous computing environment elements of the user interface
can be distributed among several machines (req. ) or among different
devices (req. ). Based on the separation of concerns that has been
previously identified, Dewan’s definition of coupling
[[Dewan-FlexibleUICoupling]] can be refined. Coupling can now be
defined as <I>sharing the same interaction, user interface, or
editing (application) state</I> among several users or devices.
Coupling can thus simply be implemented as accessing the same user
interface or application model. This is an important benefit of using
shared user interface and application models.</P>
<P CLASS="western" STYLE="margin-bottom: 0.11cm">Depending on how
much state is shared, the <I>degree of coupling</I> can be
controlled. If all involved user interface and editing state is
shared, a tightly coupled collaboration mode is realized; if only the
same data model is shared, users work loosely coupled (req. ). This
is related to the coupling model described in [[Suite-CouplingUIs]].</P>
<P CLASS="western" STYLE="margin-bottom: 0.11cm">Even, if some models
are not coupled, one can profit from sharing environment, user
interface, and application models. As the information encapsulated in
the models is accessible to all clients, it is possible to provide
<I>awareness information</I> in the user interface. Typical for CSCW
applications is the provision of workspace or activity awareness
[[GroupKit-AwarenessWidgets], [Interlocus-ActivityAwareness]]. This
can easily be realized if the application model including all editing
state is shared [[COAST-Model]]. While tightly coupling the user
interface can be inconvenient [[GroupKit-AwarenessTradeoffs],
[Colab-WYSIWIS-Rev]], shared user interface information provides a
means of giving additional awareness hints to remote users.</P>
<P CLASS="western" STYLE="margin-bottom: 0.11cm">Beyond the provision
of awareness in CSCW systems, sharing the environment model allows a
new kind of awareness for ubiquitous computing environments. The
information embodied in the environment model can be used to give
environmental awareness.</P>
<P CLASS="western" STYLE="margin-bottom: 0.11cm">This section
discusses the aspects of sharing the basic models. Before starting a
detailed discussion, it has to be noted that “sharing”
can be implemented in many different ways. In the case of
collaborating devices with quite varying properties –
especially in terms of memory, performance, or network connection –
a shared object does not necessarily have to have the same
implementation for different platforms (see e.g. Manifold
[[Manifold-Architecture]] or Pocket Dream Team
[[QuickStep-Challenges]]). For example, a shared “image”
object is likely to have a different implementation on a high-end
desktop PC than on a PDA. At the conceptual level, however, both
implementations refer to the same shared object.</P>
<H3 CLASS="western">Sharing the Data Model: Collaborative Data Access</H3>
<P CLASS="western" STYLE="margin-bottom: 0.11cm">In order to access
and work collaboratively with shared data (req. ), it is widely
agreed that a shared model for documents reduces the complexity in
dealing with distributed applications. While there are
well-established models defining a shared data model providing
read-only access only (e.g. the world-wide-web), it is much more
complicated to allow simultaneous modifications at a fine
granularity.</P>
<P CLASS="western" STYLE="margin-bottom: 0.11cm">Most popular
toolkits and frameworks for computer-supported cooperative work
provide some mechanism to manage a shared-object space. In toolkits
with a centralized architecture [[Rendezvous-Demands]], the document
is necessarily shared. Replicated (or semi-replicated
[[Groupware-Architectures]]) systems create a shared-object space by
synchronizing the replicated objects [[Clock-Architecture],
[Dragonfly-Architecture], [COAST-ooSyncGroupware]]. In later versions
of GroupKit [[GroupKit-CSCW92], [GroupKit-RealTime]] shared
“environments” have been introduced as shared data
structures that can trigger callbacks upon changes.</P>
<P CLASS="western" STYLE="margin-bottom: 0.11cm">Application
designers thus have to decide to which degree or for which parts of
their application shared access to data is desirable or necessary.
For the Passage system, a shared data model enables a straightforward
access to data objects from different computers, which is necessary
when a passenger is transferred to another roomware component.</P>
<H3 CLASS="western"><A NAME="sApplicationModelSharing"></A>Sharing
the Application Model: Workspace Awareness & Degree of Coupling</H3>
<P CLASS="western" STYLE="margin-bottom: 0.11cm">To have an easy way
of getting information about the editing state of other users, it has
been proposed not only to share the data model, but also to share the
application model [[COAST-Model]]. Sharing the editing state gives
the ability to provide awareness about editing activities. Taking
again the example of a text-edit application model, sharing it opens
the opportunity to visualize, e.g., text cursors or selections of
remote users.</P>
<P CLASS="western" STYLE="margin-bottom: 0.11cm">By changing the
state of the application model, the degree of coupling or other
possible work modes can be controlled (req. ). Users working with the
same application model can work tightly coupled with rich awareness
information [[COAST-Model]]. Tightly coupled work could for instance
include a coupled scroll position, coupled selection, or coupled
navigation. If separate instances of the application model or
different application models are used, users can still work loosely
coupled when they modify the same data.</P>
<P CLASS="western" STYLE="margin-bottom: 0.11cm">Again, the
application designer has to decide whether or not a tightly coupled
work mode should be supported or how much awareness information is
advantageous. As already mentioned, the Passage system allows
transporting both data and current editing state. This is enabled by
a shared application model.</P>
<H3 CLASS="western">Sharing the User Interface Model: Distributed &
Coupled User Interfaces</H3>
<P CLASS="western" STYLE="margin-bottom: 0.11cm">If one user
interacts with different devices at the same time (req. ), it is
desirable that their user interfaces are coordinated. This is only
possible, if the information about the currently used user interface
elements is accessible to all involved devices. An example of how
user interfaces can be coupled is the “join” operation of
“join and capture” [[XWeb-JoinCapture]].</P>
<P CLASS="western" STYLE="margin-bottom: 0.11cm">In addition, some
devices actually have several embedded computers (req. ). When a
visual interaction area crosses the borders between displays that are
physically placed next to each other, but connected to different
machines, it is necessary that the user interface elements be freely
movable between the different displays [[BEACH-ConnecTables]]. In
this case, user interface elements must be shared between the
involved machines.</P>
<P CLASS="western" STYLE="margin-bottom: 0.11cm">However, for the
Passage system, a shared user interface model is not necessary. It is
sufficient that the virtual part of the bridge runs as an application
local to each computer equipped with a bridge. Nevertheless, if the
user interface is shared, it is possible to control the bridge
remotely, opening opportunities for extensions. Then, sensors
attached to different computers can be used to detect objects on the
bridge. If, for instance, video recognition is used to identify
( run in 1.170 second using v1.01-cache-2.11-cpan-39bf76dae61 )