Abstract
Mobile communication technology offers a potential platform for new types of communication applications. Here, we describe the development and experiences with a mobile group communication application, mCell, that runs on a mobile phone. We present the underlying design implications, the application implementation, and a user study, where three groups used the application for one month. The findings of the user study reveal general user experiences with the application and show different patterns of usage depending on the social setting of the group and how the preferred features vary accordingly.
1. Introduction
The evolution of Internet and cellular technology has given rise to various forms of computer-mediated communication (CMC). Particularly, email, instant messaging (IM), mobile telephony, and SMS have become widely adopted communication means. These breakthroughs are recent, with the main advances taking place primarily in the course of the 1990s.
Rise of mobile Internet could be seen as a factor contributing to yet further changes in the way people use communication technologies. As more and more mobile devices are able to connect to the Internet, various forms of IP-based CMC, such as IM and voice over IP (VoIP), will make their way to the mobile domain. Overall, this development implies that individuals will have a multitude of ways to be in touch with their social networks, through an increasing number of platforms and modalities. As Barlow et al. [1] state, “with the development of the Internet, and with the increasing pervasiveness of communication between networked computers, we are in the middle of the most transforming technological event since the capture of fire.”
The trend for increased communication possibilities has led to several interesting social implications, such as the elevation of the status of social networks. Most contemporary Western Communities do not resemble preindustrial villages for they are socially diverse, sparsely knitted, and well connected to the outside world [2]. Wellman argues that, at least partly due to fact that computer networks are social networks spanning large distances, there has been a conceptual revolution moving from defining community in terms of space, neighborhoods, to define it in terms of social networks [3].
Communication technology has evolved rapidly in the recent years contributing to the networked nature of today’s world. With increases in the number of interconnected computing platforms and in the extent to which social networks are present in people’s everyday life, it is more than likely that also the near future will witness emergence of novel forms of CMC. It is impossible to predict the exact nature of this evolution and consequently, determining the design space of new communication technologies can be challenging. However, trialing with new group communication concepts may give important information for the designers of the future communication applications.
We have examined mobile users’ communication with their social network with a novel mobile phone application, mCell, which supports different types of group communication styles and which implements a novel technical solution as it is based on communication server running on an S60 mobile phone. In this paper, we present the concept of mCell and the design implications behind it, describe the technical implementation and the design process, and report the findings of a user study involving three different social groups.
2. Related Work
CMC has several roles in terms of supporting an individual’s social network. On one hand, it enables a pervasive connection to one’s strong ties [4]. On the other hand, Internet services, such as IM and social networking tools (see, e.g., https://www.orkut.com/), are suitable for branching new connections and expanding beyond one’s core group. Mobile communication technology has enabled people to be connected to their social networks independently of their current context and has affected, for example, the communication patterns of mobile workers [5], as it offers new ways to support both synchronous and asynchronous communications between users.
Text messaging has become an everyday phenomenon and has a big role in mobile communication practices. Teenagers’ reasons for the use of SMS are strongly grounded in their social context [4]. For instance, a densely knitted group of friends can utilize SMS for communication coordination, activity planning, and general chat [4]. Text messaging supports flexible way to manage social network and to facilitate social identity. It offers the sender better means to express themselves, for instance in order to overcome shyness and control the self-presentation [6]. Camera phones and multimedia messaging service (MMS) have enabled sharing of the pictorial information via mobile communication technology and added to the existing text messaging culture. In a study on cameraphone use, Kindberg et al. [7] describe users’ behavior with capturing and sharing the images and report, for example, on how sharing of mutual social experience is one of the key motivators for taking and sharing photos.
In a long term study on Blackberry users, Peters and ben Allouch [8] report on findings how mobile communication technology affects on boundaries between work and personal life by fading the distinction between the two contexts, as the technology is used simultaneously for personal and business purposes. Also managing social networks with mobile communication technology becomes intrinsic over time [8]. The ability for asynchronous communication in mobile context may have an effect on the practices in computer supported collaboration, as demonstrated in the study by Pinelle and Gutwin. In [9], they have studied mobile groups and collaboration in settings of home healthcare work, where the users have adopted a loosely coupled collaboration style.
Whereas mobile messaging culture supports maintaining the social network by facilitating typically the communication between two users at a time, currently the PC domain hosts better tools for group communication, providing, for example, multiuser chats and online discussion forums. Instant messaging happening in PC domain is a practice that has been commonly adopted by large user groups in both work and leisure settings. For teenagers, IM allows conversing outside the traditional places and times, and conversation windows are often kept open even if the conversation is added only now and then [10]. Isaacs et al. [11] have studied the use of IM in workplaces and report on two main styles of use, working together and coordinating. IM is also used for initiating the use of other communication media, such as calling [11]. The use of IM in public displays at a workplace has also been trialed, and balancing the public and personal aspects in social interaction is shown in the use of IM, for example, with public announcements versus private messages [12].
Most of the research concerned with computer-supported communication and management of social networks has so far concentrated on reporting the findings on usage culture with existing technology, which often concentrates on one medium, for example, SMS or PC chat. Moreover, the communication means for mobile context have not been designed to support group but to support person-to-person communication. Our research diverges from the existing research into two matters. Firstly, it introduces a novel mobile application that has been designed to support group communication in mobile context. Secondly, it concentrates on charting phenomena which this new type of communication means brings up in order to better facilitate the further design of such applications.
3. mCell Design Space
Upon starting the project, two layers contributed to defining the scope of the concept to be designed. On one hand, user layer was associated with stipulating the potential user group as well as generic motivations of use. On the other hand, technical layer articulated the technical enablers on top of which the concept was to be incorporated.
3.1. User Layer
The section above was concerned with conceptualizing communication from the perspective of social networks. In line with this, we decided to aim our communication concept at the central part of the network, namely, the highly interconnected core. Examples of such core groups, or cliques, could include, for example, local peer groups, hobby groups, or colleagues working in the same team. To be able to focus on an even narrower segment of users, we further restricted our scope to cover young, mobile savvy adults. Several reasons justified this approach: (i)young people in cities around the globe spend increasing amount of time with their friends, forming networks that Ethan Watters has coined “urban tribes” [13];(ii)young adults have a relatively large social network and are disposed to utilize various forms of CMC to manage them;(iii)younger technology users are inclined to try out new technologies and try to differentiate from the mainstream through their selection of communication means;(iv)technology adoption correlates strongly with young age—for example, percentage of Internet users decreases when progressing to older age groups. On the basis of the above assumptions, we reasoned that focusing on young adults would enable us to learn about the behavior of a segment of users that appropriates, from a relatively large selection of tools, the relevant ones for the purposes of the given group. We thus assumed that insight gained from this particular category of users may apply to the more general user population in the future.
3.2. Technical Layer
As for the enabling technology, earlier work has been done in porting Apache web server to S60 Symbian mobiles devices and an HTTP access solution from the Internet to the server has been developed [14]. This platform made it possible to develop a web forum which was to be hosted on a mobile device and accessed from anywhere in the Internet with a usual web browser. Our assumption was that such a mobile web forum would serve a relatively small core group of, for example, ten people.
This technical choice was encouraged by the fact that the content of the communications would remain private to the group since nothing was to be stored to network server out of the group’s control. It also made it possible to integrate the web forum with a user’s contact book information seamlessly in order to define the members of the group.
The choice also introduced challenges to the user experience such as the unequal share of cost of use among the group members, battery consumption, and service availability if the server device is turned off sometimes.
4. mCell Design Process
The mCell design process started with a user research stage to produce a set of user-centric requirements. In line with the user layer considerations of the previous section, we recruited two sets of users, five people in each. One set consisted of mobile IM users and the other one consisted of IRC users, both in Finland.
First the users were interviewed about their communication habits and the nature of tools used. Then they were asked to maintain diaries to record the group-based communication during ca. 20 days. Finally the users were interviewed again, elaborating on the communication topics and motivations, using the diaries as a basis.
It was observed that real-time IP-based communication tools, such as IM and IRC, eat up the time and money invested in mobile phone calls, SMS, and email. Factors contributing to this change are based both on technological (broadband access and flat fee IP-based communication, surging uptake of IM technologies) and lifestyle issues (constant access to computer while at home and being constantly online). Real-time communication was characterized by multimodality (seamless coexistence of various channels) and pervasiveness (real-time channels constantly at least in a peripheral role, mobile use). All interviewees were able to use an ensemble of CMC tools in a seamless way, for example, discussing the same cognitive thread over multiple channels.
Several themes in communication that were linked to group-level needs were observed as follows: (i)facilitating the existence of a group that used to be local (e.g., high school mates wanting to keep in touch when moving apart after graduation);(ii)coordinating mutual activities and maintaining situational awareness of group members’ short-term plans;(iii)discussing mutual activities retrospectively (e.g., discussing the game after an online game session or talking about what happened at a party previous night);(iv)group cohesion through humour and competition.
Table 1 summarizes the main user research findings, the design drivers, and features conducted from them.
The user research stage was followed by a consolidation stage where the technical layer of the mCell design space was consolidated with the user-centric requirements, and the final concept was selected.
5. mCell Concept
mCell is a group communication portal hosted in a mobile phone of one group member. Members of the group can access the portal by using any Internet connected terminal, mobile or PC, equipped with a web browser. One phone can host several mCell portals typically targeted for different groups, for example, one for family, one for friends, and so forth. The mobile phone hosting mCells has an application to manage them, called mCell Manager.
5.1. mCell Manager Features
The mCell Manager application can be used to create, modify, and delete mCell portals. When mCell portal is created, it is given a name and its members are specified. mCell Manager enables selecting the members from the already existing contact items in the mobile phone. Once a new mCell portal is activated, mCell Manager sends invitations to its members. If the contact item related to a member includes a mobile phone number, an SMS invitation is sent to his/her phone. In addition, if the contact item includes an email address, an invitation is also sent to that address. The invitations contain the name and the URL of mCell, member’s personal username, and password to access it.
5.2. mCell Portal Features
The mCell portal has the following main features: (i)mFocus,(ii)mLine,(iii)mBoard,(iv)mTivity,(v)Members. Figure 1 illustrates the mCell user interface main view with the key application elements.
mFocus ia a banner displaying a short message to all members in a visible place on the mCell main page. The message can be modified by all members. The postulated user benefit is effective information dissemination within the group.
mLine is a channel for real-time text-based chat. Upon entering mLine, ten latest messages or actions (entries or exits of users) are shown to a user so as to acquire a situational awareness of the status of the chat. It is also possible to see which members are on-line, and if they are accessing the service through a mobile or a PC. Members not currently logged on can be invited via SMS messages generated by mLine. The postulated uses are planning of events taking place in the near future, and general chitchat.
mBoard is a channel for non-real time, threaded discussion. The mCell members can create topics, post, and read messages in them. It is also possible to attach files, for example, pictures taken with a camera phone, to the messages. An mBoard RSS feed is provided to ease detecting of new messages. Obsolete topics can be deleted or archived to mTivity (see below). The postulated uses of mBoard are planning of mutual events when there is still ample time left, and reflecting on personal issues.
mTivity is an mCell activity tracker. It displays activity figures on a group and on a member level, and statistics about the longest and the most visited mBoard threads. Friendly competition is encouraged by displaying the most active members concerning, for example, mLine, mBoard, and overall mCell usage. Viewing of “golden oldies” content saved from mBoard is also provided. The postulated effect of mTivity is to facilitate channel sustainability and group cohesion.
Members is a list of the group members’ names on the main page of mCell. Online/offline status and currently used terminal type (a mobile or a PC) of each member are indicated by different icons. The postulated benefit is the potential to see which members are most likely able to participate in the mLine chat.
6. mCell Prototype
The Apache web server ported to Series 60 Platform on Symbian OS was primarily tested with the Nokia 6630 phone model, so it was also the choice for the mCell prototype. The main software components which were needed to be implemented for the prototype were the mCell Manager application and the scripts to generate dynamically the group communication portal web pages. The portal pages were designed and tested to be used with the browser of the Nokia 6630 mobile phone which supports XHTML MP 1.1, and, although this model was chosen for prototyping purposes, any browser with at least the same capabilities could be used to access them as well.
6.1. mCell Manager
mCell Manager, as described by the mCell concept, is a phone application with a UI to create, modify, and delete mCell group communication portals. In practice, mCell Manager writes mCell information (name, members, status) to an mCell database in the phone. That database is then accessed by the scripts to generate mCell portal web pages. The mCell database does not duplicate members' contact data but only refers to the data in the Contacts database of the phone.
mCell Manager was implemented as a native Symbian C++ application to be able to access all the necessary Symbian and Series 60 APIs. For example, using C++ made it possible to utilize a service provided by the Contacts application of the phone for displaying a list of its contact items (view switching). That was helpful to enable picking up mCell members from the already existing contact items in the phone. All the native UI classes are also available in the C++ implementation, like double item listboxes needed in mCell Manager. In addition, mCell Manager required access to the Symbian messaging interfaces (SMS and MMS) to be able to send mCell invitations both to mobile phone numbers and email addresses. That was also best supported by C++ APIs.
A side effect of comprehensive functionality of Symbian C++ APIs is that development is also more complex, and thus slower. In order to meet the tight schedule requirements for the mCell prototype, the Application Wizard, example applications of the Series 60 SDK, and Forum Nokia were fully utilized. That proved to be important to speed up the development.
6.2. mCell Portal Scripts
The Apache web server ported to Series 60 also contains mod_python, an Apache module that closely integrates Python with Apache [15]. The porting of that module was, for its part, enabled by Python for S60 [16], which provides a scripting solution for a subset of the Symbian C++ and Series 60 APIs. As Python is an effective programming language, suitable for prototyping, and also because Python for S60 functionality was found to be sufficient for mCell portal needs, we decided to implement the portal scripts in Python.
A publisher handler of mod_python allows access to functions within a Python module via URLs. It is a good way to avoid writing your own handlers and focus on rapid application development, so the publisher handler was very useful for the mCell prototype development. In addition, mod_python allows to tell Apache to call an authentication handler implemented as a Python module instead of using the Apache password and configuration file-based authentication and authorization. By means of this feature it is possible to utilize the information in the mCell database for authentication and authorization directly, and avoid the manual or programmatic modification of Apache password and configuration files.
7. User Study Setup
7.1. Method
To evaluate the mCell application and to chart the practices users developed with it, a user study was arranged. We selected three groups of four, five, and six people to use the application for one month. The aim was to find out how well mCell supported group communication and what kind of groups could benefit from it the most. We were also interested in clarifying if mCell truly suited to mobile devices: was it feasible to keep the server on a phone and what problems and possibilities did users find in it? In addition to the generic results, we aimed to analyze the problems and possibilities in the feature level.
The study was conducted in February 2006 in Finland, and the groups used the devices with mCell for a month uninterrupted. The trial period started by giving all groups individual briefings, where the group members were explained some of the basic features of mCell. The participants were also encouraged to use the application in a way that they discovered to fit best their own habits and purposes. A short midway questionnaire was sent to all the participants in the middle of the trial to remind them about mCell and the features it has, and after a month of using mCell all groups were interviewed about their experiences. Each device also automatically collected logs of the mCell use during the one-month use period.
7.2. Participants
For the user study, we wanted to find groups of approximately five people having constant need for sharing information between each other. The groups were chosen so that the group members were able to stay within 3G network coverage area at least for the most parts of the study. The participants had also to commit on using the given devices as their only mobile phones for the time of the study.
When selecting the groups, attention was paid not only to the group but also to the suitability of the individual group members: they all had to be active SMS users and have no problems using standard phone keypad for text entry. In addition they needed to have PCs in use and have the willingness to operate the mCell application on both devices. One criterion was also the familiarity with S60 mobile phones, so the study results would not get affected by the different level of skills in using the devices.
The trial was conducted with three teams—referred here as Family, DollHouse, and Business teams—which differed from each other in a number of aspects (different ages, gender divisions, etc.), Table 2. The first team was a family of six people, two parents and four children between the ages of 10 to 16. The second team consisted of women with small children. The connecting factor in their case was a hobby of building dollhouses and accessories and living in the same region. The third team was a small IT company employing only men. They shared their work tasks but were located in different offices and even in different cities.
The teams were quite scattered based on their location in Finland. The Family team lived in Tampere, DollHouse team members in Jyväskylä area. The Business team’s IT company was located in Helsinki, although the team members lived all across Southern Finland.
8. User Study Results
8.1. Context and Content of the Use
The places where mCell was used varied a lot between the teams. The business team members all used mCell only when working from their home offices. This was due to the fact that they would be interacting with their colleagues and therefore perceived that mCell usage felt more like work to them. The group described their mCell use as “business orientated chitchat,” meaning that they did not really talk about ongoing work activities. The discussion was more on a general level, but still somehow linked to the company affairs. The messages relating to work topics were about issues that were not quite urgent, since no one knew how actively the others were checking the messages. The work-orientated usage can also be noticed from the application logs, which show that only little conversation took place in the evening and none at night, Figure 2.
The members of the DollHouse team used mCell mainly during day time, which was due to their lifestyle: “We are all married with children and need to sleep at night, might be different for a group of teenagers who stay up late at night.” One of the DollHouse team members said that she used mCell a lot in the toilet where she could have a break from her kids and concentrate on the messages.
Content-wise, the DollHouse team’s manner of using mCell differed from the other teams. Contrary to the other teams, the discussions between the DollHouse team members were mostly factual. This was also a major difference between the male and female dominated groups, that is, Business and DollHouse groups, respectively. The DollHouse group exchanged only some chat like messages, as most of their discussions were based on actual topics, such as setting up an exhibition, agreeing on meetings times, sharing tips on how to build new items for the doll houses, and so forth. The Business group only used mCell to say hello to each other in a more testing type of setting. In addition, the conversations of these two groups varied not only in the aspect of chatting versus sharing factual information, but in sensitivity level also, as explained further in Section 8.3.
Whereas the DollHouse team members used mCell mostly from their homes, this was not a beneficial use domain for the Family team because “they all were at home anyway.” Thus, the Family team’s use was then strictly limited to schools and workplaces. The Family team claimed that since they mainly used mCell at school and work, the only time mCell was ever used was the day. Interestingly, this subjective perception the team had of themselves is not supported by the data gathered from the application logs; see Figure 2. The team members said their communication through mCell was generally only chatting. They used SMS for informative messages whereas mCell was used merely for keeping in touch and killing time.
The average number of mCell entries per person recorded in the application log is illustrated in Figure 2. The figure shows also how the use times were distributed in each group.
The mobility of mCell usage was considered more important in the DollHouse than in any other team. Other teams thought they might not need the mobility too much since they had frequent access to the Internet. In the DollHouse group, the participants appreciated the mobility, as for them an Internet access without constant disturbances was not so easy to arrange because all of them had small children. One of the participants even mentioned that she really liked mCell for the fact that it allowed her to get a private moment for herself and her hobby as she could use the application in the bathroom with the door locked, and her children would not get there to disturb her.
8.2. Used Features
Both the DollHouse team and the Business team used mainly mBoard in their communication, whereas the Family team found no use for it and concentrated on using mLine only. DollHouse team members as well as the Business team members said that they would not use mLine as they were always there alone. Moreover, they did not want to disturb others by inviting them to a chat, when they could just leave a message on mBoard waiting for the others to login. The family members were not so shy about disturbing each other and invited each other frequently to the mLine chat. They also kept themselves logged in most of the time so they could join active chats any time.
In the following, the experiences the users had with different mCell features are described.
mBoard was generally considered a very good tool for small groups, and the concept itself seemed to work well in the context of small group communication. When trying to estimate potential future concerns, it was pointed out that with larger user groups, mBoard could feel too crowded and the user could have difficulties in perceiving the message hierarchies and navigating in them. An example of a conversation thread taking place in mBoard is illustrated in Figure 3.
mLine was seen as something made for much larger groups than the ones in this trial. The fact that there hardly ever was anyone else logged in made them feel like it would require more users. Only the Family team members invited each other frequently to join the chats, whereas other teams felt like they would be disturbing others with their not-so-important chats. This might be due to the family members being more familiar with each other and therefore not as worried of disturbing each other as the other teams and their members. But also the size of the Family team being the largest in this trial played an important role in how useful the chat feature was considered. However, the participants who used mLine said that it was too difficult to follow the chat with many people participating in it. The finding highlights the limitations set by the small screen size, and on the other hand also implies the difficulties larger user groups might have with the application. Interestingly, once the family members had learned to use mLine they were reluctant to learn other parts of the application even though the most technology experienced member of the family once suggested changing to mBoard. Figure 4 shows an example chat in mLine.
mFocus, mTivity, and Member features had a significantlylesser role in the use of the mCell application, and they were mostly perceived as indifferent. None of the participants used mFocus—only the server owners had sent a couple of messages with it. With mTivity, all participants reported that they had had a look at what the feature was, but none of them had developed any habit of checking it, and for their use purposes the feature was seen as insignificant. The situation was the same with Members, although here it was commented that the feature would have been used more if it had shown online status of the team members (as this had not been implemented into the application).
8.3. Privacy and Trust
The questions related to privacy and trust brought up interesting observations. As the study was run as a research trial with noncommercial software, participants from every group had concerns about the research team accessing to their discussions (although they had been explained this was not the case). The Family team participants argued that they would not have been worried if they had bought the application themselves. However, the privacy element was also something that changed very quickly during the study period, and despite the concerns in the beginning, after few days of use the Family team did not care if their messages were read or not.
The DollHouse team did not care about privacy issues at all. All of the members had participated also in larger web-based discussions about dollhouses and two of them even wrote a public blog about similar issues. Thus they were not worried about other people reading their conversations in mCell either. Although much of their conversation was factual and about practical things, the DollHouse team members also shared some very private things about themselves in their conversations (e.g., about pregnancy). Still they claimed that they would not mind if others would have read the conversations.
The Business team on the other hand was the opposite to the DollHouse team in privacy issues: they felt they had to protect their business sensitive information and therefore used mCell only for general chitchat to minimize the risk of outsiders getting their information.
The server being on one phone created more trust on privacy. The participants perceived that as there was only one person in control of the server, and this person was known to all, it was relatively easy to trust that there would be no outsider online. In addition, the Family team stated that they would have enhanced the trust on the privacy if the mCell group had been created and maintained by someone they know.
8.4. Experiences with the Server in the Phone
As the research implemented also a new technical solution having server in a phone, it was important to gather user experiences related to this phenomenon as well. However, unfortunately the benefits of having the server on the phone were not clearly demonstrated, as in the study the users did not have the possibility to create their own mCells freely.
The server related problems could be divided into two groups: issues due to current technology and the ones related to the concept. Power and stability are crucial factors in the use of the application, as server being down affects to the communication of the whole group. Now, for example, running out of phone battery was perceived as a major problem in the use. In addition, the phone’s limited processing power in comparison to PC caused the server to function somewhat slowly. After the study, all the three groups agreed that it would be better to have the server on a PC as the current solution brought too many technical problems—in addition to power consumption and processing power, running the server on a PC would eliminate the influence of the existence of the 3G network coverage. Another major issue was the cost of using the server, which was feared to be too high for the server owner with the current data transfer costs. The participants also assumed that PC use would make it easier to share the maintenance responsibility.
The average data transfer per server during the study was MB and included barely any images or other files. None of the trial participants were ready to estimate the monetary cost of their mCell usage, and they frequently estimated it to be too high. The server owners had more realistic ideas about the cost of their subscriptions. In the DollHouse team all but one of the participants had been checking the cost of the mCell use, although in the study setting they did not have to pay for it themselves. In the Business group only the server admin had been interested in the cost, and he had done this not in the sense of actually wanting to know the cost, but for being curious of the amounts of data transferred.
9. Discussion
The problems appearing in mCell were twofold: problems caused by the technical implementation and problems caused by the concept itself. From the research point of view, the technical problems do not have the same level of significance when the technology develops. However, the design itself can benefit from the concept level findings.
The problems reported with the use of mBoard were mostly technical, and although larger user groups might affect negatively to the information presentation and navigation, no significant problems were detected for the participating groups. With the online chat function mLine, one problem with the concept was the barrier of inviting others to join the chat, and the threshold for inviting others seemed to be greater than expected. The findings suggest that in order this concept to be successful, the group members should either know each others very well, or the groups should be larger to maximize the possibility to have someone logged into chat at all times. One can speculate that this may have had an effect even in this study, as the biggest group having the most members (Family team, 6 members) was the one using mLine. The reason may also lie in a family type of communication, where only fast real-time communication is needed, when all other discussions can be handled once the whole family is at home. In a family, people are also more familiar with each other and do not worry so much about disturbing with their chat requests. One aspect to the different behavior of Family group in comparison to other groups can also be the fact that it was the only one involving minors; teenage members probably have different communication needs and patterns than adults in their thirties and forties.
The results varied a lot between the groups and therefore it is also interesting to look at the differences in the group attributes. The Family group was the most differentiating from the other two as the majority of its members were minors. But the DollHouse group and the Business group were quite similar in age and education level, and it was interesting to see that the results were still quite different, may be partly because of the gender difference.
The most eye-catching differences between the male and the female groups were the attitude toward privacy issues and the type of communication mCell was used for. DollHouse group was not worried about the possibility of other people seeing their conversations, whereas the Business team was constantly bringing it up in the interviews. This can be explained partially with the information sensitivity, as the DollHouse issues are not business sensitive like the communication inside a small business. The DollHouse participants shared some very private things in the conversations, whereas the business team only used mCell to kill time and chat about nonbusiness issues, sharing jokes and such. Still, the Business team was the one that was more worried about the possibility for others accessing their discussions.
One reason affecting the types of conversation could be also the background of the participants. In the DollHouse group all the women had been using several message boards in the Internet before and were still very active in using them. The men of the business group worked in an IT company and were of course very well accustomed to all kinds of Internet services but were not as active in any discussion forums in the Internet. It was probably more natural for the DollHouse team to take a new kind of discussion tool in use as they were so accustomed to having discussions with such before. This can also be seen in the amount of use of mCell, Figure 2.
The technical problems with mCell were mostly related to the occasional events of the server being down, which caused also majority of the negative feedback in the user study. This problem can be estimated to become less frequent as the mobile devices will be equipped with more memory and processing power and the batteries will get better. For the problems caused by the situations where the server owner was not able to keep the server on, it would be recommended, for example, to provide a way to change the server admin inside the team. The maintenance account could be switched from one phone to another. One design solution could also be that mCell changed the server in use by itself whenever needed.
10. Conclusions
In this paper, we have described mobile communication application for small groups, mCell, which is based on having a server running on an S60 mobile phone. The application fosters several different kinds of communication styles, that is, online chat, messaging board, list of group members and their activity tracker, and short, one-line, onscreen messaging. After implementing the application, we run a one-month user study that involved three groups having 4–6 members in order to evaluate the application and find out the practices people developed with such a mobile group communication tool.
The user study results indicate that the concept was received well, and group communication applications are an intuitive and natural way to extend the communication characteristics of mobile phones. The study also shows that the practices of how the group communication application is used will vary between different user groups based on the nature of the group (professional, family, hobby, etc.), closeness and trust between the group members, members’ earlier experiences with using group communication application, for example, in the Internet, and their general lifestyle. The results of the study also revealed that each group found its preferred way of communicating rather quickly and concentrated its usage on it while leaving the other features of the application quite untouched. As a future work, the authors would find it interesting to develop the concept further and look at the dynamics of group communication in more depth with a larger user study.
Acknowledgment
The authors would like to thank the coresearchers in the project and the study participants.