MSG Instant Messenger: Social Presence and Location for the "Ad Hoc Learning Experience"
Alex Little 1, Chris Denham 2, and Marc Eisenstadt 3
1 Knowledge Media Institute, The Open University Walton Hall Milton Keynes MK7 6AA UK |
2 Knowledge Media Institute, The Open University Walton Hall Milton Keynes MK7 6AA UK
|
3 Knowledge Media Institute, The Open University Walton Hall Milton Keynes MK7 6AA UK |
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
.
BuddySpace |
MSG |
Java application |
Web based - JavaScript (AJAX) |
Self-contained (monolithic) |
Distributed (web-services) |
Download & install |
Browser based (no installation) |
Custom maps |
Google Maps |
100's of features |
Functionality kept to the basics |
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:
"Hello, I'm just trying to learn about Open Learn. It's my first day. How are you getting on?" |
"Hi, just messenging you to test the system. it's my first visit!" |
"hello..? hellooo-ooooo..??! is this thing on?" |
"testing.. (hi... sorry to interrupt... just testing a few features.. let me know if you receive this ok)" |
"Hi there- are you doing dd100 too?" |
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.
.