Bundle-PBib

 view release on metacpan or  search on metacpan

InnoSetupTemplate.iss  view on Meta::CPAN

LicenseFile=%base_dir%\LICENSE
InfoBeforeFile=%base_dir%\INSTALL
InfoAfterFile=%base_dir%\README
AppReadmeFile=%base_dir%\README
Compression=lzma
SolidCompression=yes
OutputBaseFilename=%app_name%-%app_version%
OutputDir=.

[Tasks]
Name: desktopicon; Description: {cm:CreateDesktopIcon}; GroupDescription: {cm:AdditionalIcons}; Flags: unchecked
Name: quicklaunchicon; Description: {cm:CreateQuickLaunchIcon}; GroupDescription: {cm:AdditionalIcons}; Flags: unchecked
Name: perlmodules; Description: {cm:InstallPerlModules}; GroupDescription: {cm:Perl}; Flags: unchecked

[Files]
Source: %base_dir%\*; DestDir: {app}; Flags: ignoreversion recursesubdirs
; NOTE: Don't use "Flags: ignoreversion" on any shared system files

[INI]
Filename: {app}\%app_name%.url; Section: InternetShortcut; Key: URL; String: %support_url%

[Icons]
Name: {group}\%app_name%; Filename: {app}\%app_exe%; WorkingDir: {app}\bin
Name: {group}\{cm:ProgramOnTheWeb,%app_name%}; Filename: {app}\%app_name%.url
Name: {group}\{cm:InstallPerlModules}; Filename: {app}\install.bat; Parameters: {reg:HKLM\SOFTWARE\ActiveState\ActivePerl\{reg:HKLM\SOFTWARE\ActiveState\ActivePerl,CurrentVersion|00},|}; WorkingDir: {app}
Name: {group}\{cm:UninstallProgram,%app_name%}; Filename: {uninstallexe}
Name: {userdesktop}\%app_name%; Filename: {app}\%app_exe%; Tasks: desktopicon; WorkingDir: {app}\bin
Name: {userappdata}\Microsoft\Internet Explorer\Quick Launch\%app_name%; Filename: {app}\%app_exe%; Tasks: quicklaunchicon; WorkingDir: {app}\bin

[Run]
Filename: {app}\install.bat; Description: {cm:InstallPerlModules}; StatusMsg: {cm:InstallingPerlModules}; Flags: shellexec; Parameters: {reg:HKLM\SOFTWARE\ActiveState\ActivePerl\{reg:HKLM\SOFTWARE\ActiveState\ActivePerl,CurrentVersion|00},|}; Tasks: ...
Filename: {app}\%app_exe%; Description: {cm:LaunchProgram,%app_name%}; Flags: shellexec postinstall skipifsilent

[UninstallDelete]
Type: files; Name: {app}\%app_name%.url
Type: files; Name: {app}\Build
Type: files; Name: {app}\pod2htmli.x~~

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

 perspective on application models ({\field{\*\fldinst { HYPERLINK \\l iRoomVisualInstruments}}{\fldrslt {Winograd and Guimbretière, 1999}}}).
\par 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 o}{\insrsid12989836 b}{\insrsid12989836 ject) as shown in figure }{\field{\*\fldinst {\insrsid1298...
 REF fPassageClasses \\h }{\insrsid12989836 {\*\datafield 08d0c9ea79f9bace118c8200aa004ba90b0200000008000000100000006600500061007300730061006700650043006c00610073007300650073000000}}}{\fldrslt {\lang1024\langfe1024\noproof\insrsid12989836 6}{
\insrsid12989836 \_}{\lang1024\langfe1024\noproof\insrsid12989836 3}}}{\insrsid12989836  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 co}{\insrsid12989836 n}{\insrsid12989836 tinue working there at exactly the same state.
\par }\pard\plain \s3\ql \li0\ri0\sb120\sa60\keepn\widctlpar\aspalpha\aspnum\faauto\outlinelevel2\adjustright\rin0\lin0\itap0 \f1\fs22\lang1033\langfe1033\cgrid\langnp1033\langfenp1033 {\insrsid12989836 {\*\bkmkstart sUIModelConcept}{\*\bkmkstart _To...
{\*\bkmkstart _Toc19764439}User-Interface Model{\*\bkmkend sUIModelConcept}{\*\bkmkend _Toc2659659}{\*\bkmkend _Toc19764439}: Interface Elements
\par }\pard\plain \qj \li0\ri0\sa60\widctlpar\aspalpha\aspnum\faauto\adjustright\rin0\lin0\itap0 \fs20\lang1033\langfe1033\cgrid\langnp1033\langfenp1033 {\insrsid12989836 As traditional operating and window
 management systems have been designed for use with a trad}{\insrsid12989836 i}{\insrsid12989836 
tional 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 to
p of the screen, it might be hard to reach at a wall-size display ({\field{\*\fldinst { HYPERLINK \\l PierLocationIndepInterfaces}}{\fldrslt {Pier and Landay, 1992}}}). Toolbars can take up a lot of pr}{\insrsid12989836 e}{\insrsid12989836 cious scre...
\par Therefore, the user interface aspects have to be separated from information and behavior of applic}{\insrsid12989836 a}{\insrsid12989836 tions. This is related to the }{\i\insrsid12989836 interface dimension}{\insrsid12989836 
 identified by {\field{\*\fldinst { HYPERLINK \\l JacobsonOOSE}}{\fldrslt {Jacobson {\i et al.} (1992)}}}. However, the BEACH conceptual model further distinguishes the }{\i\insrsid12989836 user interface}{\insrsid12989836  from the }{\i\insrsid12989...
, to allow accessing a shared user interface wit
h 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.
\par In the case of the Passage system, the user interface is rather simple; it consists of the virtual part of the bridge. The }{\i\insrsid12989836 virtual}{\insrsid12989836 
 part of the bridge is displayed on a roomware component whenever a passenger is detected on the }{\i\insrsid12989836 physical}{\insrsid12989836  part of the bridge (see figure }{\field{\*\fldinst {\insrsid12989836  REF fPassagePicture \\h }{
\insrsid12989836 {\*\datafield 08d0c9ea79f9bace118c8200aa004ba90b0200000008000000100000006600500061007300730061006700650050006900630074007500720065000000}}}{\fldrslt {\lang1024\langfe1024\noproof\insrsid12989836 3}{\insrsid12989836 \_}{
\lang1024\langfe1024\noproof\insrsid12989836 1}}}{\insrsid12989836 ).
\par The user-interface model allows one to define alternative user-interface concepts suitable for different interaction devices (req. }{\field{\*\fldinst {\insrsid12989836  REF qDifferentFormsOfInteraction \\h  \\* MERGEFORMAT }{\insrsid12989836 

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

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

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

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>

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

 perspective on application models ({\field{\*\fldinst { HYPERLINK \\l iRoomVisualInstruments}}{\fldrslt {Winograd and Guimbretière, 1999}}}).
\par 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 o}{\insrsid12989836 b}{\insrsid12989836 ject) as shown in figure }{\field{\*\fldinst {\insrsid1298...
 REF fPassageClasses \\h }{\insrsid12989836 {\*\datafield 08d0c9ea79f9bace118c8200aa004ba90b0200000008000000100000006600500061007300730061006700650043006c00610073007300650073000000}}}{\fldrslt {\lang1024\langfe1024\noproof\insrsid12989836 6}{
\insrsid12989836 \_}{\lang1024\langfe1024\noproof\insrsid12989836 3}}}{\insrsid12989836  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 co}{\insrsid12989836 n}{\insrsid12989836 tinue working there at exactly the same state.
\par }\pard\plain \s3\ql \li0\ri0\sb120\sa60\keepn\widctlpar\aspalpha\aspnum\faauto\outlinelevel2\adjustright\rin0\lin0\itap0 \f1\fs22\lang1033\langfe1033\cgrid\langnp1033\langfenp1033 {\insrsid12989836 {\*\bkmkstart sUIModelConcept}{\*\bkmkstart _To...
{\*\bkmkstart _Toc19764439}User-Interface Model{\*\bkmkend sUIModelConcept}{\*\bkmkend _Toc2659659}{\*\bkmkend _Toc19764439}: Interface Elements
\par }\pard\plain \qj \li0\ri0\sa60\widctlpar\aspalpha\aspnum\faauto\adjustright\rin0\lin0\itap0 \fs20\lang1033\langfe1033\cgrid\langnp1033\langfenp1033 {\insrsid12989836 As traditional operating and window
 management systems have been designed for use with a trad}{\insrsid12989836 i}{\insrsid12989836 
tional 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 to
p of the screen, it might be hard to reach at a wall-size display ({\field{\*\fldinst { HYPERLINK \\l PierLocationIndepInterfaces}}{\fldrslt {Pier and Landay, 1992}}}). Toolbars can take up a lot of pr}{\insrsid12989836 e}{\insrsid12989836 cious scre...
\par Therefore, the user interface aspects have to be separated from information and behavior of applic}{\insrsid12989836 a}{\insrsid12989836 tions. This is related to the }{\i\insrsid12989836 interface dimension}{\insrsid12989836 
 identified by {\field{\*\fldinst { HYPERLINK \\l JacobsonOOSE}}{\fldrslt {Jacobson {\i et al.} (1992)}}}. However, the BEACH conceptual model further distinguishes the }{\i\insrsid12989836 user interface}{\insrsid12989836  from the }{\i\insrsid12989...
, to allow accessing a shared user interface wit
h 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.
\par In the case of the Passage system, the user interface is rather simple; it consists of the virtual part of the bridge. The }{\i\insrsid12989836 virtual}{\insrsid12989836 
 part of the bridge is displayed on a roomware component whenever a passenger is detected on the }{\i\insrsid12989836 physical}{\insrsid12989836  part of the bridge (see figure }{\field{\*\fldinst {\insrsid12989836  REF fPassagePicture \\h }{
\insrsid12989836 {\*\datafield 08d0c9ea79f9bace118c8200aa004ba90b0200000008000000100000006600500061007300730061006700650050006900630074007500720065000000}}}{\fldrslt {\lang1024\langfe1024\noproof\insrsid12989836 3}{\insrsid12989836 \_}{
\lang1024\langfe1024\noproof\insrsid12989836 1}}}{\insrsid12989836 ).
\par The user-interface model allows one to define alternative user-interface concepts suitable for different interaction devices (req. }{\field{\*\fldinst {\insrsid12989836  REF qDifferentFormsOfInteraction \\h  \\* MERGEFORMAT }{\insrsid12989836 

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

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 B...
Application Model: Application Behavior
Application models are used to describe all application aspects such as manipulation of data objects. As application models define the behavior of the application, they specify control objects as defined in (Jacobson et al., 1992).
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.
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 differ...
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.
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 lev...
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 additional semantics for a data model, instead of the conventional approach of seeing data as...
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 contr...
User-Interface Model: Interface Elements
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 in...
Therefore, the user interface aspects have to be separated from information and behavior of applications. This is related to the interface dimension identified by Jacobson et al. (1992). However, the BEACH conceptual model further distinguishes the u...
In the case of the Passage system, the user interface is rather simple; it consists of the virtual part of the bridge. The virtual part of the bridge is displayed on a roomware component whenever a passenger is detected on the physical part of the br...
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 elem...
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.
Environment Model: Context Awareness
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.,...
Therefore, the environment model is the representation of relevant 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 hardware e...
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 relevant properties with sensors. Depending on detected changes in the physical environment, further ac...
The Passage system is an example of how to react upon changes in the physical environment. As mentioned, the virtual part of the bridge is shown as soon as a physical object is detected on the physical part of the bridge. Thus, Passage needs to keep ...
Besides the physical environment, other contextual information – such as the current task, project, or presence of co-workers – could influence the behavior of the software, so long as this information is available to the application. This part refer...

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

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 ada...
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 (se...
2.3Second Dimension: Coupling and Sharing
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 distributin...
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 access to shared data and coupling th...
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...
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, De...
Depending on how much state is shared, the degree of coupling 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 c...
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 awareness information in the ...
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.
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 – e...
Sharing the Data Model: Collaborative Data Access
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 dat...
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 sem...
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 diffe...
Sharing the Application Model: Workspace Awareness & Degree of Coupling
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 t...
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., ...
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...
Sharing the User Interface Model: Distributed & Coupled User Interfaces
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 involve...

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

<para>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...
<para>Application Model: Application Behavior</para>
<para>Application models are used to describe all application aspects such as manipulation of data objects. As application models define the behavior of the application, they specify control objects as defined in (Jacobson et al., 1992).</para>
<para>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.</para>
<para>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 ...
<para>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.</para>
<para>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 high...
<para>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 additional semantics for a data model, instead of the conventional approach of seeing d...
<para>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...
<para>User-Interface Model: Interface Elements</para>
<para>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. ...
<para>Therefore, the user interface aspects have to be separated from information and behavior of applications. This is related to the interface dimension identified by Jacobson et al. (1992). However, the BEACH conceptual model further distinguishes...
<para>In the case of the Passage system, the user interface is rather simple; it consists of the virtual part of the bridge. The virtual part of the bridge is displayed on a roomware component whenever a passenger is detected on the physical part of ...
<para>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 interfac...
<para>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.</para>
<para>Environment Model: Context Awareness</para>
<para>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” (Brumm...
<para>Therefore, the environment model is the representation of relevant 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 ...
<para>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 relevant properties with sensors. Depending on detected changes in the physical environment, furt...
<para>The Passage system is an example of how to react upon changes in the physical environment. As mentioned, the virtual part of the bridge is shown as soon as a physical object is detected on the physical part of the bridge. Thus, Passage needs to...
<para>Besides the physical environment, other contextual information – such as the current task, project, or presence of co-workers – could influence the behavior of the software, so long as this information is available to the application. This ...

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

<para>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 o...
<para>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, ...
<para>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 mod...
<para>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 distr...
<para>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 access to shared data and coupl...
<para>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, ...
<para>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 identifi...
<para>Depending on how much state is shared, the degree of coupling 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 loo...
<para>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 awareness information i...
<para>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...
<para>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 prop...
<para>Sharing the Data Model: Collaborative Data Access</para>
<para>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 shar...
<para>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 (...
<para>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...
<para>Sharing the Application Model: Workspace Awareness & Degree of Coupling</para>
<para>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 abi...
<para>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...
<para>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 e...
<para>Sharing the User Interface Model: Distributed & Coupled User Interfaces</para>
<para>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 i...

t/sample.html  view on Meta::CPAN

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-LocationIndepInterfaces]]. 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 [ :inline | [Jacobson-OOSE]]. However, the BEACH
conceptual model further distinguishes the <I>user interface</I> from

t/sample.html  view on Meta::CPAN

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>

t/sample.rtf  view on Meta::CPAN

 perspective on application models [[iRoom-VisualInstruments]].
\par 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 o}{\insrsid12989836 b}{\insrsid12989836 ject) as shown in figure }{\field{\*\fldinst {\insrsid1298...
 REF fPassageClasses \\h }{\insrsid12989836 {\*\datafield 08d0c9ea79f9bace118c8200aa004ba90b0200000008000000100000006600500061007300730061006700650043006c00610073007300650073000000}}}{\fldrslt {\lang1024\langfe1024\noproof\insrsid12989836 6}{
\insrsid12989836 \_}{\lang1024\langfe1024\noproof\insrsid12989836 3}}}{\insrsid12989836  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 co}{\insrsid12989836 n}{\insrsid12989836 tinue working there at exactly the same state.
\par }\pard\plain \s3\ql \li0\ri0\sb120\sa60\keepn\widctlpar\aspalpha\aspnum\faauto\outlinelevel2\adjustright\rin0\lin0\itap0 \f1\fs22\lang1033\langfe1033\cgrid\langnp1033\langfenp1033 {\insrsid12989836 {\*\bkmkstart sUIModelConcept}{\*\bkmkstart _To...
{\*\bkmkstart _Toc19764439}User-Interface Model{\*\bkmkend sUIModelConcept}{\*\bkmkend _Toc2659659}{\*\bkmkend _Toc19764439}: Interface Elements
\par }\pard\plain \qj \li0\ri0\sa60\widctlpar\aspalpha\aspnum\faauto\adjustright\rin0\lin0\itap0 \fs20\lang1033\langfe1033\cgrid\langnp1033\langfenp1033 {\insrsid12989836 As traditional operating and window
 management systems have been designed for use with a trad}{\insrsid12989836 i}{\insrsid12989836 
tional 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 to
p of the screen, it might be hard to reach at a wall-size display [[Pier-LocationIndepInterfaces]]. Toolbars can take up a lot of pr}{\insrsid12989836 e}{\insrsid12989836 cious screen space on a PDA-like device.
\par Therefore, the user interface aspects have to be separated from information and behavior of applic}{\insrsid12989836 a}{\insrsid12989836 tions. This is related to the }{\i\insrsid12989836 interface dimension}{\insrsid12989836 
 identified by [ :inline | [Jacobson-OOSE]]. However, the BEACH conceptual model further distinguishes the }{\i\insrsid12989836 user interface}{\insrsid12989836  from the }{\i\insrsid12989836 interaction}{\insrsid12989836 
, to allow accessing a shared user interface wit
h 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.
\par In the case of the Passage system, the user interface is rather simple; it consists of the virtual part of the bridge. The }{\i\insrsid12989836 virtual}{\insrsid12989836 
 part of the bridge is displayed on a roomware component whenever a passenger is detected on the }{\i\insrsid12989836 physical}{\insrsid12989836  part of the bridge (see figure }{\field{\*\fldinst {\insrsid12989836  REF fPassagePicture \\h }{
\insrsid12989836 {\*\datafield 08d0c9ea79f9bace118c8200aa004ba90b0200000008000000100000006600500061007300730061006700650050006900630074007500720065000000}}}{\fldrslt {\lang1024\langfe1024\noproof\insrsid12989836 3}{\insrsid12989836 \_}{
\lang1024\langfe1024\noproof\insrsid12989836 1}}}{\insrsid12989836 ).
\par The user-interface model allows one to define alternative user-interface concepts suitable for different interaction devices (req. }{\field{\*\fldinst {\insrsid12989836  REF qDifferentFormsOfInteraction \\h  \\* MERGEFORMAT }{\insrsid12989836 

t/sample.txt  view on Meta::CPAN

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 B...
Application Model: Application Behavior
Application models are used to describe all application aspects such as manipulation of data objects. As application models define the behavior of the application, they specify control objects as defined in [[Jacobson-OOSE]].
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.
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 differ...
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.
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 lev...
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 additional semantics for a data model, instead of the conventional approach of seeing data as...
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 contr...
User-Interface Model: Interface Elements
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 in...
Therefore, the user interface aspects have to be separated from information and behavior of applications. This is related to the interface dimension identified by [ :inline | [Jacobson-OOSE]]. However, the BEACH conceptual model further distinguishes...
In the case of the Passage system, the user interface is rather simple; it consists of the virtual part of the bridge. The virtual part of the bridge is displayed on a roomware component whenever a passenger is detected on the physical part of the br...
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 elem...
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.
Environment Model: Context Awareness
One major property of ubiquitous computing environments is the heterogeneity of the available devices. In order to provide a coherent user experience [[DisappearingUI-CoherenceScope]], the "system must have a deeper understanding of the physical spac...
Therefore, the environment model is the representation of relevant 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 hardware e...
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 relevant properties with sensors. Depending on detected changes in the physical environment, further ac...
The Passage system is an example of how to react upon changes in the physical environment. As mentioned, the virtual part of the bridge is shown as soon as a physical object is detected on the physical part of the bridge. Thus, Passage needs to keep ...
Besides the physical environment, other contextual information – such as the current task, project, or presence of co-workers – could influence the behavior of the software, so long as this information is available to the application. This part refer...

t/sample.txt  view on Meta::CPAN

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 ada...
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 (se...
2.3Second Dimension: Coupling and Sharing
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 distributin...
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 access to shared data and coupling th...
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...
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, De...
Depending on how much state is shared, the degree of coupling 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 c...
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 awareness information in the ...
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.
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 – e...
Sharing the Data Model: Collaborative Data Access
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 dat...
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 (o...
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 diffe...
Sharing the Application Model: Workspace Awareness & Degree of Coupling
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 ...
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]]. Tig...
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...
Sharing the User Interface Model: Distributed & Coupled User Interfaces
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 involve...

t/sample.xml  view on Meta::CPAN

<para>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...
<para>Application Model: Application Behavior</para>
<para>Application models are used to describe all application aspects such as manipulation of data objects. As application models define the behavior of the application, they specify control objects as defined in [[Jacobson-OOSE]].</para>
<para>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.</para>
<para>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 ...
<para>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.</para>
<para>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 high...
<para>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 additional semantics for a data model, instead of the conventional approach of seeing d...
<para>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...
<para>User-Interface Model: Interface Elements</para>
<para>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. ...
<para>Therefore, the user interface aspects have to be separated from information and behavior of applications. This is related to the interface dimension identified by [ :inline | [Jacobson-OOSE]]. However, the BEACH conceptual model further disting...
<para>In the case of the Passage system, the user interface is rather simple; it consists of the virtual part of the bridge. The virtual part of the bridge is displayed on a roomware component whenever a passenger is detected on the physical part of ...
<para>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 interfac...
<para>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.</para>
<para>Environment Model: Context Awareness</para>
<para>One major property of ubiquitous computing environments is the heterogeneity of the available devices. In order to provide a coherent user experience [[DisappearingUI-CoherenceScope]], the “system must have a deeper understanding of the physi...
<para>Therefore, the environment model is the representation of relevant 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 ...
<para>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 relevant properties with sensors. Depending on detected changes in the physical environment, furt...
<para>The Passage system is an example of how to react upon changes in the physical environment. As mentioned, the virtual part of the bridge is shown as soon as a physical object is detected on the physical part of the bridge. Thus, Passage needs to...
<para>Besides the physical environment, other contextual information – such as the current task, project, or presence of co-workers – could influence the behavior of the software, so long as this information is available to the application. This ...

t/sample.xml  view on Meta::CPAN

<para>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 o...
<para>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, ...
<para>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 mod...
<para>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 distr...
<para>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 access to shared data and coupl...
<para>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, ...
<para>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 identifi...
<para>Depending on how much state is shared, the degree of coupling 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 loo...
<para>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 awareness information i...
<para>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...
<para>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 prop...
<para>Sharing the Data Model: Collaborative Data Access</para>
<para>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 shar...
<para>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. Replica...
<para>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...
<para>Sharing the Application Model: Workspace Awareness &amp; Degree of Coupling</para>
<para>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 pr...
<para>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]...
<para>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 e...
<para>Sharing the User Interface Model: Distributed &amp; Coupled User Interfaces</para>
<para>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 i...