Adapting to the groupware aspect

Conference systems are conceived to support the process of exchanging personal ideas, mainly between geographically distant conferees, and especially when more than one communication medium has to be exploited to convey a message. As a requirement for this exchanging of ideas, the system has to emulate and distribute, or to coordinate replicas of the discussion content and any other medium that contributes to mutual understanding. Recalling the cognitive seams mentioned before, the system will be certainly rejected if it disturbs the social process or if it gives rise to doubts as to whether the message is being accurately delivered.

Regarding the operational case, where technical asymmetries between the users’ platforms exist, an intervention between the extremes is paramount. In this case, the server of the conference system has to handle a sort of repository of the profiles of the accessing system clients, and then, adapt media contents and services accordingly–but above all–steadfastedly preserving the equivalence of the shared message. Adaptation procedures shall consider and comply with the following issues:

Interface for a multi-user application

For this research, the main issue related to interface design is that users might access the conference system under distinct operating conditions, and, therefore, the system should offer interface alternatives (for each specific usage model and client profile) applying the three principles mentioned in the previous sub-section. An additional challenge is to allow individuality in each interface (i.e., adaptations for a single client), but to keep functional correspondences among them.

Content filtering

A conference system may offer several conferencing functionalities, as well as handling diverse media forms, but, if in an operational case, one conferee has to use a low-resource mobile platform, he should not be confronted with receiving a media content that is inadequate for his platform. An example would be receiving a video file when there is no tool locally installed to deal with its encoding. In such a case, each partner (and the system server) has to be informed beforehand of another’s deficiency and a substitute medium might have to be employed.

Some existing information systems, especially related to Web services, already offer this kind of filtering as a way to reduce the communication costs and as service customisation.

Media “distillation”

The limitations of a ‘thin’ mobile terminal accessing a groupware should not necessarily imply a general decrease in the features or performance of the service. Instead, the quality of a shared media-content (and thus the resource requirements) could be carefully reduced only for this constrained terminal. This situation might occur, for example, when an imminent delivery of a huge image file or video stream is confronted with low memory availability or low bandwidth network conditions.

A proposed procedure is that, before they are sent to the mobile host, the image or video stream shall have the respective resolution and colour-depth, or frame-rate, decreased–a process called “Distillation” by Brewer et al. [Brewer98], and Fox and Brewer [Fox96]–

Application Systems – Design Implications according to the resource conditions. For preserving a common understanding and a certain level of consistency, each conference partner ought to be informed of another’s deficiency and the changes in content fidelity.

Nevertheless, for such a functionality, an adaptation strategy has to be carefully established, since media have different QoS requirements, depending on the nature of the message. For example, playback video does not have the strict timing requirement of real-time video for interactive use. Additionally, in this strategy, there are aspects related to media synchronization that have to be considered. This concern emerges, for example, when two streams are supposed to be synchronized, such as voice and motion of a tele-pointer, and the latter has its pacing distilled (reduced) to save bandwidth.

From the groupware user’s perspective, such effort is particularly important, because certain adaptations might lead to the misinterpretation of a message and errors; further, when evidences are uncertain, fast perceptual tasks might change into exhausting cognitive tasks (e.g., mentally guessing the real state).

Above all, the constrained user should be able to interrupt this distillation in the event that accurate outcomes for the share content are paramount for the discussion and application domain, and he is willing to bare the costs of obtaining this content.

Duties allotment

Depending on the resources available in a user terminal, certain system functionality might be too demanding for its local processing engine. Therefore, being aware of the participation of this terminal in the network, a conference server could take this functionality in hand or assign it to another terminal that is able to cope with it. Nevertheless, thinning out and assuming functionality from a system client depends highly on the network availability, possible modes of work (i.e., with temporary and voluntary disconnection during particular actions) and, if employed, middleware features.

From another point of view, the system could offer the possibility that a partner could remotely undertake interactions in his partner’s domain (as mentioned in section 5.2) to help alleviate operation and cognitive demands placed upon him.

5.4 Partial Conclusions

In this chapter, some relevant aspects of the technical and social components of a CSCW have been revised. Likewise, concerns have been presented in respect to the interference that the technological mediation might cause to the social process, especially when the human communication process is already in jeopardy due to social, contextual, and technological distances.

Essential features for an application system to run over different platforms, especially when a mobile one is included, have been revised and formulated. These features concern the ability to continuously observe and adapt functionalities according to the available processing and communications resources, and general conditions of usage. In the case of conference systems, the requisites are even more complex, because, besides the heterogeneous platforms, users under different conditions might be interacting with the systems and within the network of conferees. In the end, harmony in every sense has to exist.

The proposals for realisations result from the method advocated all along this research, which is, to pay meticulous attention to the user and task to be supported rather than hailing the latest cutting-edge trends in functional features and forcing their usage in applications (and

Application Systems – Design Implications later, compelling user acceptance). Taking this user-oriented focus, the author has revised and proposed ways to adapt functionality and attend to individual requirements, so that each conference partner would be able to fulfil his computer-supported duties efficiently.

Details of a prototype realisation of a conference system for remote assistance are presented in the next chapter.