Bundle-PBib
view release on metacpan or search on metacpan
t/expected-sample-pbib.html view on Meta::CPAN
relationship to the previously identified requirements. Concrete
examples of how these models have been applied are given afterwards.</P>
<H3 CLASS="western"><A NAME="_Ref517456041"></A><A NAME="sDataModelConcept"></A>
Data Model: Information Objects</H3>
<P CLASS="western" STYLE="margin-bottom: 0.11cm">It is a very common
approach in application modeling to separate the application model
from the data or domain model [[VisualWorks-UsersGuide],
[HUMANOID-Model]]. The data model relates to the <I>information
dimension</I> identified by Jacobson et al. (1992), while the
application model represents the <I>behavior dimension</I>. This way,
both data and application models can be reused independently.</P>
<P CLASS="western" STYLE="margin-bottom: 0.11cm">Different
applications can be specified and implemented for one kind of data.
This can save much time if the current application domain has complex
data structures or algorithms. On the other hand, application models
can be reused for different kinds of data, if the interface between
the application and the data has been defined very carefully at an
appropriate level of abstraction.</P>
<P CLASS="western" STYLE="margin-bottom: 0.11cm">The data model
defines the classes and functionality of all objects that can be part
of a document. According to an object-oriented view, data objects
combine document state with methods to change the state. In the
context of cooperative work (req. ), it makes sense to choose a
fine-grained model to gain more flexibility in defining different
aspects of collaboration, like the degree of coupling (req. ). In
(Anderson et al., 2000) the model facet represents the data model.</P>
<P CLASS="western" STYLE="margin-bottom: 0.11cm">Following an
object-oriented approach, the data model will usually consist of a
network of multiple connected objects. For hypertext-like documents,
e.g., it is popular to define one main containment hierarchy with
additional connections defined by hyperlinks.</P>
<P CLASS="western" STYLE="margin-bottom: 0.11cm">Depending on the
actual application, data objects are not restricted to represent what
is classically seen as a “document”. In
(Edwards and LaMarca, 1999) a much broader view on
documents is described. If, for instance, physical devices, people,
or tasks are also treated as special kinds of “documents”,
a uniform interface can be used. The term “domain model”,
which is sometimes also used for the concept of a data model
(ParcPlace-Digitalk, Inc., 1995; Schuckmann et al., 1999), stresses that it models
the artifacts of a given domain, which may not be necessarily
documents. Although this term can be used interchangeably with “data
model”, this paper uses the latter term in order to provide a
clearer contrast with the application model.</P>
<P CLASS="western" STYLE="margin-bottom: 0.11cm">Looking at the
example of the Passage system, the data model covers all objects that
should be attached to and carried with a passenger object. The
implementation described below (see section ) supports the generic
document elements provided by the BEACH framework, but also new
document elements defined by other BEACH modules.</P>
<H3 CLASS="western"><A NAME="sApplicationModelConcept"></A>Application
Model: Application Behavior</H3>
<P CLASS="western" STYLE="margin-bottom: 0.11cm">Application models
are used to describe all application aspects such as manipulation of
data objects. As application models define the <I>behavior</I> of the
application, they specify control objects as defined in
(Jacobson et al., 1992).</P>
<P CLASS="western" STYLE="margin-bottom: 0.11cm">For a “text”
object, the data model includes the string describing the text and
text attributes like font or size. The application model adds the
editing state for text, for instance, cursor position or selection.</P>
<P CLASS="western" STYLE="margin-bottom: 0.11cm">Further, it can
specify the degree of coupling between different users, i.e. it
controls which parts of the editing state are shared by which users,
and where private values are allowed. The workspace application
model, e.g., allows specifying different rotations of the workspace
for two users working at an interactive table (see req. ), while all
other properties are tightly coupled.</P>
<P CLASS="western" STYLE="margin-bottom: 0.11cm">To be able to use
different application models for the same data model, the data model
has to be unaware of any application model and represent document
state only.</P>
<P CLASS="western" STYLE="margin-bottom: 0.11cm">It has proven
helpful to choose a rather fine granularity for some application
models. This way, low-level application models with a well-defined
functionality (e.g. to edit a simple text) can be aggregated to form
more complex models at a higher level of abstraction (e.g. an editor
that can manage complete workspaces). Usually, a whole hierarchy of
application models composed of generic, reusable parts and custom
parts constitute an application (Schuckmann et al., 1999). This way, the
application model often forms a hierarchy that is isomorphic to the
containment hierarchy of its associated data model
(ParcPlace-Digitalk, Inc., 1995).</P>
<P CLASS="western" STYLE="margin-bottom: 0.11cm">Using small
application models turns out to foster a new conception of what is
regarded as an application. The application model is seen as a
description of <I>additional</I> semantics for a data model, instead
of the conventional approach of seeing data as a “supplement”
to be edited by applications. It therefore leads to an
<I>information-centric</I> perspective on application models
(Winograd and Guimbretière, 1999).</P>
<P CLASS="western" STYLE="margin-bottom: 0.11cm">The Passage system,
e.g., defines no new application model. Instead, it reuses the
application models that are available for the data objects being
attached to passengers. In fact, it associates the application model
with a passenger object (in contrast to creating an association
between passenger and data object) as shown in figure below. This
way, the current editing state (e.g. selections, cursor position
etc.) can be transferred using Passage; this allows users to go to
another roomware component and continue working there at exactly the
same state.</P>
<H3 CLASS="western"><A NAME="sUIModelConcept"></A>User-Interface
Model: Interface Elements</H3>
<P CLASS="western" STYLE="margin-bottom: 0.11cm">As traditional
operating and window management systems have been designed for use
with a traditional desktop PC, the interface they offer has drawbacks
when used with devices not having a mouse and keyboard or having
different forms and sizes. For instance, if a menu bar is always at
the top of the screen, it might be hard to reach at a wall-size
display (Pier and Landay, 1992). Toolbars can take up a lot
of precious screen space on a PDA-like device.</P>
<P CLASS="western" STYLE="margin-bottom: 0.11cm">Therefore, the user
interface aspects have to be separated from information and behavior
of applications. This is related to the <I>interface dimension</I>
identified by Jacobson et al. (1992). However, the BEACH
conceptual model further distinguishes the <I>user interface</I> from
the <I>interaction</I>, to allow accessing a shared user interface
with different modalities and different devices. The user interface
model defines the components that are available in the user
interface, while the interaction model specifies how they are
presented and modified.</P>
<P CLASS="western" STYLE="margin-bottom: 0.11cm">In the case of the
Passage system, the user interface is rather simple; it consists of
the virtual part of the bridge. The <I>virtual</I> part of the bridge
is displayed on a roomware component whenever a passenger is detected
on the <I>physical</I> part of the bridge (see figure ).</P>
<P CLASS="western" STYLE="margin-bottom: 0.11cm">The user-interface
model allows one to define alternative user-interface concepts
suitable for different interaction devices (req. ). Multiple-computer
devices (req. ) and multi-device interaction (req. ) make it
necessary to have user interface elements that can be distributed and
shared among different devices (see below).</P>
<P CLASS="western" STYLE="margin-bottom: 0.11cm">By explicitly
modeling an appropriate user-interface, all issues related to the
hardware and physical environment can be addressed at one point,
allowing applications and documents to be device-independent.</P>
<H3 CLASS="western"><A NAME="sPhysicalModelConcept"></A>Environment
Model: Context Awareness</H3>
<P CLASS="western" STYLE="margin-bottom: 0.11cm">One major property
of ubiquitous computing environments is the heterogeneity of the
available devices. In order to provide a coherent user experience
(Prante, 2001), the “system must have a
deeper understanding of the physical space”
(Brummit et al., 2000). This raises the need for an adequate
model of the application’s physical environment.</P>
<P CLASS="western" STYLE="margin-bottom: 0.11cm">Therefore, the
environment model is the representation of <I>relevant</I> parts of
the “real” world. On one hand, this includes a
description of which devices are used, how they are configured, and
which capabilities they have. This is the direct <I>hardware
environment</I>, which can be employed by the user-interface model to
adapt to different devices (req. ). This part corresponds to the
platform model defined by the Plasticity framework
(Thevenin and Coutaz, 1999), or Aura’s notion of
environment (Sousa and Garlan, 2002).</P>
<P CLASS="western" STYLE="margin-bottom: 0.11cm">In addition, other
aspects can be included if they can influence the behavior of the
software. Necessarily, it has to be possible to measure their
t/expected-sample-pbib.html view on Meta::CPAN
<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 “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
(Marsic, 2001) or Pocket Dream Team
(Roth, 2002)). 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 (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
“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 (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 &
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” (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 – without affecting
with the performance of the roomware component. Another extension we
implemented uses Palm Pilot PDAs to “beam” data to the
bridge of a roomware component (Prante et al., 2002). Here,
again, the shared user interface can be controlled remotely by the
Palm.</P>
<H3 CLASS="western">Sharing the Environment Model: Environmental
Awareness</H3>
<P CLASS="western" STYLE="margin-bottom: 0.11cm">When several people
and devices physically share a common environment, it is obvious that
applications that are used in such situations can benefit from a
shared model of how their environment looks.</P>
<P CLASS="western" STYLE="margin-bottom: 0.11cm">In ubiquitous
computing environments, many different devices have attached sensors
that allow detection of some aspects of the physical environment. By
combining all available information and making it accessible to other
applications, it is possible for each application to draw on a lot of
( run in 1.241 second using v1.01-cache-2.11-cpan-39bf76dae61 )