MSG Instant Messenger: Social Presence and Location for the "Ad Hoc Learning Experience"

Alex Little ¹, Chris Denham ², and Marc Eisenstadt ³

Abstract: "Elearning2.0" promises to harness the power of three of today's most disruptive technologies: social software, elearning, and Web2.0. Our own work in this disruptive space takes as a starting premise that social networking is critical for learning: finding the right person can be more important than 'scouring the web for an answer', particularly when hand-holding or other explanatory services are required. Moreover, it 'feels good' to know that others are around! With this in mind, we have taken our older BuddySpace tool, and created a new tool we call MSG, which is simpler, available as Open Source, and integrates cleanly with a number of other services, including Moodle and Google Maps.

Keywords: Social presence, location, elearning, social networking, presence, enhanced presence, presence discovery, Openlearn, BuddySpace, MSG

1 Introduction: disruptive technologies for the learner

"Elearning2.0" promises to harness the power of three of today's most disruptive technologies: social software, elearning, and Web2.0. Our own work in this disruptive space takes as a starting premise that social networking is critical for learning: finding the right person can be more important than 'scouring the web for an answer', particularly when hand-holding or other explanatory services are required. We know from Whitelock et. al. (2000) that presence awareness increases emotional well-being, and from Nardi et. al. (2002) that users benefit from knowing who else is around via presence and messaging tools; so generally it 'feels good' to know that others are around!

The notion of peer-group interactions is critical to many learning interactions. Johnson and Johnson (1986) and numerous others have described the benefits that accrue from activities such as joint problem solving and related peer interactions that take place in the presence of other students. But in an e-learning situation, what exactly does it mean to be ‘in the presence of other students'? The notion of 'presence' must therefore be extended, because the other students, and indeed the teacher or tutor, may not be physically present: instead they are only virtually present. Our belief is that simply being able to see the other person, although obviously useful, is neither necessary nor sufficient to impart a sense of presence: more critical is the mental state that depends on knowing the other person is available, even at a distance, and this can be de-coupled from 'visibility'. This mental state is crucial for what we called 'enhanced presence'. We argued in Eisenstadt et al (2004) that enhanced presence could be of direct benefit to learners in informal settings by facilitating their conversations, especially at a distance.

With this in mind, we have taken our older BuddySpace tool (Vogiazou et. al. 2005), which provided instant messaging and maps, but was found by testers to be 'over-geek-ish' to use, and created a new tool we call MSG, which is simpler, available as Open Source, and integrates cleanly with a number of other services, including Moodle and Google Maps. Below we describe our initial design principles for BuddySpace and how we extended them to MSG, and illustrate the nature of the MSG environment.

2 From BuddySpace to MSG

BuddySpace was our original geographically-enhanced instant messaging environment, based upon the same Jabber/XMPP messaging protocol now made popular by GTalk and Meebo. The essence of BuddySpace was to provide the user with a personal 'dashboard' or 'radar screen' so that he or she could observe the availability and 'interaction state' of colleagues, fellow students and friends worldwide in a manner that was based on the following design principles:

. XML-literate: for intelligent applications, communication transport needs to be about more than just string-transmission; another reason we adopted Jabber is that it is based entirely on a generic XML transport architecture, ideally suited for enhancing it with semantics in the future

.

Table 1: key differences between BuddySpace and MSG

The development of MSG also allowed us to learn from our experiences with BuddySpace in a number of distinct areas. Firstly, we had learned from BuddySpace that adding many features does not necessarily help the user, because it becomes difficult to design a clean and simple user interface. Also, the study of Vogiazou et. al (2005) showed that many of these features were rarely used. From the data about the usage of features of BuddySpace, MSG was able to take the feature set known to be actually used. An example of this is "group chat", although an often requested feature, evidence shows that it is rarely used and so was omitted from MSG..

Secondly, using a distributed, service-based architecture makes it much easier for us to embed third party applications, of which embedded maps are a good example. In BuddySpace, the presence maps used maps which had been designed specifically for that purpose, making it difficult and time consuming to update. Whereas in MSG, we have used the Google Maps API to embed presence mapping facilities.

The interface to MSG has been kept deliberately clean and simple - as figure 1 shows - users simply click on the name of the user, or their presence icon if they are online, to instantiate a chat session.

Figure 1: interface to MSG, showing the users contact groups

In addition to being able to find users based on group membership, MSG users can also find their contacts based on geolocation. Through the analysis of an Open University course discussion forum, we found that nearly 20% of the first 1000 postings were related to finding out whether or not there were other students in the same geographical area, so the ability to identify and locate fellow learners "in one's region or close by in order to form a self support group is invaluable" (Vogiazou et. al. 2005).

Unlike the custom maps of BuddySpace, we wanted to foster interoperability via mashups with other existing technologies, the most obvious one being Google Maps. With the MSG Presence Map (see figure 2).,users can pan and zoom around the map to see where their contacts are currently located. We have made it easy for users to update their location, using another 3rd party service, Geonames (http://www.geonames.org), to geocode the textual location entered by the user. This is another example of how the distributed architecture of MSG has enabled us to easily make use of external web-services.

Figure 2: Google Maps integration

Other facilities in the MSG presence map include the ability to search for users, based on their name or contact group and being able to filter the markers displayed on the map; the markers can be filtered by contact group or by search results.

A common problem with many Google Maps applications is that when there are many markers to display, they can end up being displayed on top (or very close) to each other, making it hard to identify individual markers, and from a performance perspective, too many markers on a map (over approximately 100) can slow Google Maps down significantly, having a negative impact on the user experience. In order to address this problem, MSG presence maps uses a clustering algorithm, to avoid markers being overlaid on top of each other. As the users zooms the map in, the markers break apart and on zooming out the markers recombine. So a marker on the map can represent a group of users, with the size of the marker indicating the number of users at a particular location. If at least one user at a location is online then the marker is green, otherwise gray.

When a marker is clicked, a listing of all the users at the location is displayed, along with their presence status and an option to launch a chat conversation if the user is currently online. All the presence state information is live, negating the need for the user to refresh the page.

The MSG Presence Map can be used as an alternative to, or in conjunction with the MSG contacts page (as shown in figure 1), giving the user a variety of ways to keep track of the presence state of their contacts.

2.1 Integration with OpenLearn

One of the key aims of OpenLearn is to "explore how best to make [high quality learning materials] freely accessible in an international web-based open content environment" (OpenLearn project proposal) and in doing so "encourage the creation of non-formal collaborative learning communities". With Instant messaging (IM) being one of the most widely used social networking tools, integrating instant messaging into OpenLearn, with its potential for community building, peer-to-peer and collaborative learning, seemed natural. There is a huge range of instant messaging tools available (e.g. AIM, MSN and GTalk). However they do not fit the bill for messaging in an educational context, where our background research on BuddySpace suggested that educational users liked the power of IM tools, but preferred the security, familiarity and 'feel-good' factor of an IM tool associated with an educational resource provider. MSG offers the openness and interoperability required to embed IM into OpenLearn, other IM systems can be fairly closed and would be difficult to integrate into a third party websites.

Figure 3: MSG Instant Messenger embedded in LabSpace. [A] The persistent OpenLearn 'Block' that shows personal status, personal contacts, and all users currently logged in. [B] The MSG messenger itself runs in any browser, with standard browser tools hidden, and allows setting of 'status' via the three lights at the top, listing of group members and 1-1 chat after clicking on a user name, as shown in [C]. Geographical location (using Google Maps API) of users' contacts is the latest new feature [D].

The ability for integration into OpenLearn was one of the key factors in the decision to further develop MSG rather than using an existing IM system. MSG enables us to deeply embed and integrate users presence within the OpenLearn site. Whenever a user is logged in to the OpenLearn site, they are also automatically logged in to MSG, removing the need for the user to separately launch and log in to MSG. The MSG 'block' (as show in figure 4), which appears on most of the webpages in OpenLearn (the exception being the course content pages), displays the users current presence state, the number of their contacts currently online and the total number of users online. A small MSG presence map is also displayed, showing the locations of all the users currently online in OpenLearn.

Figure 4: MSG 'block'

MSG uses information from the user's OpenLearn profile to populate contact groups, this is necessary as users can only chat to each other if they share a group. Currently, the MSG contact groups are generated from a user's course enrolments, so two users who have both enrolled on 'S103 - Earthquakes' for example will each be added to the 'S103 - Earthquakes' group. However we are looking at making the automatic contact group creation slightly more flexible (see the 'Future' section). MSG also uses the location entered on the users OpenLearn profile (on registering all users are required to provide a town or city and country) to populate the MSG Presence Map.

MSG presence status is embedded throughout the OpenLearn site, wherever a user's name appears, if the users are in the same groups, we also display their presence status. This is most noticeable in the forums (as shown in Figure 5) where we can easily see who is currently online. The presence icons are clickable, giving the MSG standard single click to chat. This gives learners the opportunity to engage in spontaneous discussions with other users who share a common interest.

Figure 5: Showing presence status embedded in the OpenLearn website

New message notifications are given in the page header as well as a small pop up window in the bottom right of the page (in a similar style to how GTalk displays new message notifications), giving the user instant notification that they've received a new message and the opportunity to engage a in chat conversation. The alerting of new messages needs to be a balance between being intrusive enough that the user will notice the alerts, but not so intrusive as to irritate the user.

Privacy and security, on a number of levels, was an important factor we needed to take into consideration when planning and implementing the integration of MSG into OpenLearn, especially with the inclusion of the users location on the presence map. By editing their OpenLearn profile (or when they first register), users are given the option to opt out of MSG altogether - in which case the data in the OpenLearn profile will not be replicated over to MSG. On registering with OpenLearn, users are required to provide a town or city and country, this is the data MSG uses to mark the users location on a map. The apparent lack of granularity in the location is actually a benefit for MSG, as using just the town is good enough for the purpose of displaying users on the presence map and for other users to find who is in their locality. It also avoids potential privacy and security concerns that would be raised if MSG were to mark users exact addresses on the map. The final privacy consideration was the storage of the chat conversations since the MSG server allows the option of storing all conversations. For the purposes of research and to be able to monitor the usage levels of MSG, we took the decision to record all chat conversations with users identities obfuscated. This obfuscation, rather than totally anonymisation, allows us to offer extra facilities to users such as the option to retrieve their chat history - which wouldn't be possible with total anonymised recording. This is in line with the facilities and options provided by almost all mainstream IM systems (e.g. MSN).

2.2 MSG: just another Instant Messaging system?

Although there are a large number of instant messaging systems and tools in use and readily available, there are a number of attributes that, in combination, make MSG distinctive:

. Experiences

Initially, MSG was only integrated with the LabSpace part of OpenLearn (LabSpace is the experimental area of OpenLearn to allow researchers and educators to 'try things out'), and did not include presence maps. During this initial phase (from Oct 2006 to mid-May 2007) approximately 4000 users registered with MSG (by registering on LabSpace and enrolling on a course) and participated in several hundred chat conversations. In May 2007 MSG was integrated into the mainstream OpenLearn site (LearningSpace), which receives approximately 10 times the number of page hits to LabSpace, so the number of registered users significantly increased and now (November 2007) stands at just over 17500 with several hundred more chat conversations having taken place. The MSG presence map was launched in May 2007 across both LabSpace and LearningSpace.

3.1 Usage

Analysis of the chat conversation logs shows that the vast majority of MSG chat to be conversations about the MSG tool itself, what we would term 'meta-level-chat', rather than discussion concerning the OpenLearn materials and content ('object-level-chat'). Table 2 shows sample chat messages to demonstrate typical conversation messages:

Table 2: sample chat messages

This is entirely as we would expect since there are two central problems which preclude object-level-chat.

Firstly, motivation: there is neither overarching guidance nor any self-evident motive that inherently embeds MSG interactions into any of the educational resources (e.g. "now do activity X which involves synchronous chat"). This is due to the nature of most of the materials in OpenLearn, which has been taken directly from standard Open University courses, so is very focused on individual as a lone learner, rather than group, collaborative or peer-to-peer learning. Hence the majority of OpenLearn content does not contain activities encouraging the use of collaborative tools. So the collaborative tools (including MSG), although freely available, may be seen as entirely optional.

Another factor related to motivation is the fact that users have very little information about the other learners in their groups, for most learners the information available is limited to their name and an approximate location. Users may feel they don't have enough information about other learners in their groups to simply strike up chat conversations, for example, about other learners interests or how much of the course they have already completed. This is why we felt it important to deeply embed the MSG presence icons into the OpenLearn site, especially in the forums, where the forum posting content would give a reason and subject matter for learners to chat to each other. It all adds up to suggest that chat interactions can only occur spontaneously and for no obvious mutual end, with limited motivation for the learner to use the chat.

Secondly, critical mass: At any random moment, there is no one else 'around' in MSG, because there is not a sufficient number of users right now. Thus, even if there were anything of direct educational relevance to discuss, there is no one to discuss it with. Typically there are between 20 and 40 registered users logged in to MSG (via OpenLearn) at any given time, but, given there are over 600 courses in OpenLearn, a typical visitor may only have a maximum of 5 or 6 contacts online at any time. Also, these contacts may not be on the same course the learner is currently studying. This problem may be exacerbated by the fact that users can access all the OpenLearn material without registering, therefore these users will never receive an MSG account, so nor appear to other MSG users. We're not suggesting that OpenLearn material should only be available to registered users, but perhaps we're not making the benefits of registration compelling or obvious enough for users to take the time to register.

3.2 Peer Presence Discovery

The presence map (item [A] in figure 3) is designed to foster peer presence discovery. This in turn is intended to facilitate an ad hoc learning experience: not unlike what happens throughout our lives! From our server logs we know that the Presence Map (figure 2) is now the primary launchpad for MSG and has a higher hit rate than the standard contacts page (figure 1).

3.2.1 Tyranny of the Browser

A web-centric approach for an instant messaging client, with the limitations of users' browsers, brings it's own advantages and complications over a standard desktop application. The key advantages are common to those for any web application, for example, the ability to access anywhere, no download or installation necessary and new features or bug fixes are instantly available to all users.

However, complications arise from the fact that the web browser is sandboxed from the rest of the user's desktop:

. Notifications and focus: alerting users to new messages when they may be viewing another web browser window can be problematic. Although MSG will attempt to switch focus to alert the user, most browsers will simply make the browser window blink in the system bar, to notify users that the window requires their attention.

MSG also overcame an additional challenge not usually faced by other web-based instant messaging providers, namely that there are a number of routes into MSG, via the standard MSG web client, MSG Alert system tray tool or by being logged in to OpenLearn website. To achieve this flexibility, MSG provides an open API, allowing any third party website to embed MSG.

4 Future

People don't come to the OU or OpenLearn just for fun: they are heavily time-constrained and need a good payoff for any tool that is added to the learning mix. Therefore, for the future development of MSG we need to specifically address the tighter coupling of social tools with learning activities in order to overcome the motivation and critical mass problems raised above. Some of the methods we intend to use in addressing these issues include:

. Study buddy finder. To specifically address the fact that users know little about each other and to help users find the right person to speak to, we could use the interests and homepage URL from the users profile to automatically populate BuddyFinder keywords and URLs. We are already experimenting with this type of integration by leveraging the OU Course Profile Facebook App (Hirst 2007), which aims to create a 'study buddy' capability by linking Facebook users who share Open University and OpenLearn course profiles.

. Encourage development of learning materials. Create sample learning materials which include the use of group and collaborative activities which the social tools (MSG, FlashMeeting and Compendium) can be used to support.

.