view release on metacpan or  search on metacpan

t/expected-sample-pbib.html  view on Meta::CPAN

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 (Dewan and Choudhary, 1995).</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
(Gutwin et al., 1996; Nomura et al., 1998). This
can easily be realized if the application model including all editing
state is shared (Schuckmann et al., 1999). 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 &ldquo;sharing&rdquo;
can be implemented in many different ways. In the case of
collaborating devices with quite varying properties &ndash;
especially in terms of memory, performance, or network connection &ndash;
a shared object does not necessarily have to have the same
implementation for different platforms (see e.g. Manifold
(Marsic, 2001) or Pocket Dream Team
(Roth, 2002)). For example, a shared &ldquo;image&rdquo;
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 (Patterson, 1991), the document
is necessarily shared. Replicated (or semi-replicated
(Phillips, 1999)) systems create a shared-object space by
synchronizing the replicated objects [[Clock-Architecture],
[Dragonfly-Architecture], [COAST-ooSyncGroupware]]. In later versions
of GroupKit (Roseman and Greenberg, 1992; Roseman and Greenberg, 1996) shared
&ldquo;environments&rdquo; 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 &amp; 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 (Schuckmann et al., 1999). 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 (Schuckmann et al., 1999). 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 &amp;
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 &ldquo;join&rdquo; operation of
&ldquo;join and capture&rdquo; (Olsen et al., 2001).</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  (Tandler et al., 2001). 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
passenger objects, it is quite likely that the video camera is
attached to a different computer. This computer can provide the
performance for processing the video signal &ndash; without affecting
with the performance of the roomware component. Another extension we