Different cultures have different needs; an evolving approach should be taken in groupware development. Rather than developing different versions of groupware specific to different culture, an expert system that helps in defining which features or functionalities of groupware that would be best suited for its users would be more effective. With the use of an expert system, the functionalities of groupware will slightly matched to the behavior of a group from a specific culture. To even more facilitate its user, the expert system will display only the suitable tools on the screen to support the different needs of different cultures. Developers who understand the work environment well enough to design successfully will be in a good position to help design strategies for supporting adoption as well [131].
Passenger 2, an innovative synchronous groupware application that is currently developed in the Institute of Computer Engineering, UDE would need to incorporate the following facilities which use is introduce as a culture-centered design approach in order to provide a real ‘added-value’ from both the social and engineering viewpoint, as shown in Figure 8.13:
Culture‐ centered groupware design Tailorabili ty Negotiabil ity Anonimity Hierarchic al support Visibility Controlabil ity Figure 8.13 Culture-centered design approach for groupware
a. Tailorability
Groupware should be flexible in a way that it can be setup to display information for users of that system.The most promising groupware development methodology is participative design [13], [259]. The technological features of groupware systems should not be designed static, it need to be tailored according to the different preference of users. Groupware should be designed flexible according to the
users need. Using tailorable system is a good step to provide flexibility, but in order to do so, to tailor effectively would be a great challenge since people are not conscious of detailed functioning of the system and how the changes will affect the other users.
b. Controlability
User should be able to control the features provided in the groupware. The user’s control-ability implies that user has the choice of different options. Control-ability, in this case should focused which require specific reactions by other users who do not choose between different options but are affected by the choice of an active user. User, therefore, should be able to choose between various media and should be able to make a choice of various functions within one type of this media. For example, if one user decided to activate the usage of the telephone, other users that may not wish to have this media to be activated, should be given the option to select the functions that is included in that media, such as call waiting, automatic callback, etc. The interest of one user (user A) finding access to another one (user B) may be in conflict with the interest of User B that might prefer to be undisturbed. Therefore such functions that provide the possibility for making access more flexible are worthy. Another example, if user A wants to have unlimited access to user B’s file, and if user B only permits this for a limited period of time, there should be the possibility for user B to do so by entering directly into the list of parameters of the command or the menu field used to specify this certain access. Control-ability is referred to the ability of groupware systems that enable each user to specifically select the appropriate number of functions during the configuration process.
Groupware should enable the group of users to specifically select the appropriate number of functions and their functional alternatives during a process of participative configuration [155]. A configuration of groupware should also consider that an activation of a function affects users in different roles. The effect of the design requirements will also be influenced by the organization that will use the groupware itself, and by its hierarchical structure. One technical solution is to allow users to group the potential information together into roles. For examples, if user wishes to hide their information details from the other users, then they can categories the users that may view his information into a special group.
User has the control to select only features or icons to be put to the screen depending on the interest of the users. Another feature in control-ability is the capability that would allow user to block incoming messages (in private chat) when they wanted to concentrate on the tasks.
c. Negotiability
The mechanism of negotiability should also be applied in the design requirement. As groupware has more than one user, the multitude of individuals implies the existence of diverging and even conflicting interest [155], [260], [261]. Potential conflict may arise; this should be anticipated on the level of design requirement. Negotiations among users should be possible and facilitated. Therefore to allow this facilitation, the system has to offer options to its function, in which user may choose. Negotiability would ask in the system as asking for a mechanism to support these processes at the moments a function’s activation.
Members of organizations sometime have different/multiple goals and conflict may be as important as cooperation in obtaining issue resolutions (Kling 1991). Groups and organizations may not have shared goals, knowledge, meaning, and histories (Heath & Luff 1996; Ackerman 2000). Without
shared meanings or histories, meanings will have to be negotiated (Boland et al. 1994). The norms for using groupware system are often actively negotiated among users. Therefore groupware should have some kind of mechanism that would allow users to negotiate its use in order to make the system more flexible.
Audio conferencing give benefit for users that cannot type fluently, but it can also be a disadvantage for multicultural users. User who are not fluent in communicating with certain language (such English) will then feel burden and not confident with his/her fluency in communicating and will prefer to use text medium (such as chat).
Negotiability in the technical area itself are insufficient in conflict solving, conflicts of interest between different users should be discussed in group meetings and solved by less structured communication among users. Therefore, functions that provide such support should be taken care. If functions are activated, their complexity and effort of use should be in a reasonable relationship. The relationship between effort involved in use and the effect caused by use is strongly influenced by the qualification levels of the users [155].
The negotiability tools should be able to be adapted to the necessities of certain workgroups. The possibility to include or exclude this functions that are not considered to be suitable for a special groups of users should also be provided.
d. Anonymity
Group process refers to the way the group works. Examples of measures of group process include time to reach a decision, efficiency of communication and equality of participation [262]. When the group perform brainstorming tasks, equal participation of the group members is important. But this can also become a cultural barrier, anonymity should be considered for this case.
Anonymity is where users’ contribution can be anonymous. Anonymity can be provided as an option in the groupware user’s profile setting, since it may be effective in reducing the power distance during the meeting (Chung & Adams 1997; Robichaux & Cooper 1998). With user’s status as anonymous, the issue with who has the power to decide can be reduced and will no longer be relevant since the group ideas are anonymous, which may encourage more equal participation from all participants. This can help the users concentrate on what is being put forward rather than who said it.
In a brainstorming session, user has the ability to enter as many ideas as they want anonymously. For example, high power distance members may be reluctant to speak up during discussions, especially when the identity of the other speakers is not known [263]. For a groupware to be effective, it is important for each group member to have equal opportunity, regardless of status differentials, to express an opinion in a group decision.
e. Visibility
Communication and cooperation between users can be supported by the visibility of user in the groupware. A groupware system is visible if the functionality offered by the system and its state of use can be displayed to the users [155]. Visibility means that there should be an option provided in the groupware of generating the data records that can be displayed.
As visibility makes users aware of certain aspects of a system it is conflicting to the requirement for transparency as it is understood in the distributed systems community, which demands for a masking
out of certain aspects from the users [264]. Visibility of user can either be restricted to functions active at the same time.
Another form of visibility is providing user the possibility to have different user interface layout, whereas user have different preference in working. As Western has the tendency to be low context and Asian to be high-context. Groupware therefore, should have the possibility to offer different working styles and different user interface layout. Although awareness to common objects can be shared via a common view of the work, or also known as WYSIWIS (What You See Is What I See). Strict WYSIWIS was found to be limiting and relaxed versions were proposed to accommodate personalized screen layouts [265]. One example of different version of the same workstation is shown in Figure 8.14, where two collaborative users share the same mission-planning workspace but with different version of the area map application. The left user uses two-dimensional and right users uses three- dimensional rendering of the mission-planning document, but they both use the same chat JavaBean [266].
Figure 8.14 Two collaborative users sharing the same workspace but with different version of application view (source: [266])
Infrequently used groupware features should also have the possibility to be “invisible” from the user’s screen, yet when needed it is accessible to the users.
f. Other supports - Hierarchical support
Asensio et al (1998) performed research on how to support hierarchical relationships and competitive/cooperative interactions in CSCW applications by grouping of individuals from different hierarchical levels in different subgroups enables hierarchical relationships and restriction of information dissemination among different subgroups, gives support to different levels of competitive/cooperative interactions [150]. Hierarchy in implementation of CSCW application had already been researched in other works [267].