Information Systems Services, Computer Centre. 1. ,. The Learning Technology ... University 24/7 365 days of the year and furthermore, to act as a research ...
Unified and Personalised Messaging to Support E-Learning Keith Mitchell1, Nicholas J. P. Race1, Duncan McCaffery1, Mark Bryson2, Zhen Cai2 Information Systems Services, Computer Centre1, The Learning Technology Group2 Lancaster University, Lancaster, U.K., LA1 4YW {k.mitchell, n.race, d.mccaffery, m.bryson, z.cai}@lancaster.ac.uk
Abstract The University of Lancaster is a campus based educational institution with over 10,000 members of staff and students on campus during a typical day. The University is currently investigating the use of mobile and smart devices as a platform for delivering mobile learning services and administrative information on a personalised basis. This paper describes two current active areas of development. First, we present an SMS text messaging extension to our Virtual Learning environment (VLE) and describe how this is used to provide personalised messaging. Second, we present our work on a Bluetooth based communications service, named BlueZone, which we use to complement SMS text messaging to offer an alternative communications platform to students. The combination of these technologies provides a unified and cost effective delivery mechanism for communicating with University undergraduates on a large scale.
1. Introduction and Motivation The University of Lancaster’s Learning Technology Group (LTG) has developed the institution web based VLE to support staff and students. The LUVLE (Lancaster University Virtual Learning Environment) consists of sites for many individual departments as well as a central module database called “My Modules”. All of these sites are hosted on two main servers running a Domino database. The “My Modules” site currently contains information for 2078 different course modules and is in active use by over 10,000 students at present. An independent initiative at Lancaster, called eCampus [4], is currently in the process of creating a campus-wide pervasive communications infrastructure which is also designed to support staff and students on a daily basis. This initiative is currently focussing on the deployment of a range of display technologies (such as plasma, LCD and projectors), communications technologies (wi-fi and Bluetooth) and sensor networks (cameras, PIR, etc) within a number of public spaces (indoor and outdoor) across campus. The aim is to use this pervasive infrastructure to offer novel information services and applications in public
and social spaces across campus. Perhaps uniquely to eCampus, the infrastructure must satisfy some high level goals, namely to be available to all members of the University 24/7 365 days of the year and furthermore, to act as a research resource for all faculties of the University. To date, the eCampus infrastructure is being used to present digital signage (i.e. public information), new media and artistic performances [5] and for supporting research prototype developments [6], [7]. The remainder of this paper details a new communications system at Lancaster which supports timely and personalised communications between staff and students. The overall system exploits technical developments in both the Learning Technology Group’s VLE with the ubiquitous computing researchers work on Bluetooth and sensor based communication using eCampus.
2.
Facilitating SMS Communications
2.1 Overview The LTG group have recently been investigating the use of SMS text messaging as a new channel of communications between staff and students. In this context, a number of alternative methods are available to institutions and organisations whom wish to exploit the use of (bulk) SMS text messaging services [8]. In essence, one is either able to: • Use an existing service, such as one operated by a mobile operator (e.g. Orange) • Purchase hardware and develop a customised software solution There are clear advantages and disadvantages to each approach. The use of existing services offers a simple and effective mechanism for the dispatching of text messages; however, this generally incurs minimum monthly fees and often higher charges. In addition, one is limited to the services offered by the service provider themselves. The alternative is to exploit lower cost hardware and develop customised or in house systems. This offers the significant advantages such as being able to integrate
more easily with existing software systems in production at the University, lower operational costs and more crucially, flexibility and control over the services being offered. One of the motivations for implementing an SMS text messaging service for LUVLE was that traditional email based communication is not always appropriate for certain types of communication. For example, time sensitive messages which need to be delivered urgently are not necessarily appropriate for dissemination via email since it is a pull based service. Consequently messages relating to topics such as the cancellation of lectures, room changes, or other emergency information could not necessarily be guaranteed to be delivered in a timely manner. By exploiting communications to mobile handsets, we potentially increase the chance of being able to delivery messages in a more timely fashion.
2.2 Text Messaging Infrastructure The current SMS text messaging service is provided by connecting a GSM/GPRS data modem to a serial port of our GSM Communications server. Server software written in Java directly communicates with the data modem via AT commands in order to send SMS text messages, as shown in figure 1. This approach was chosen because it offers a low cost solution when compared to using a SMS gateway service. The disadvantage of this solution is that the time taken to send or receive SMS messages is relatively high due to bulk delivery restrictions on the GSM network. The message sending interface is closely integrated into the “My Modules” pages retrieved from the VLE. Lecturers can send text messages to all the students in a certain module/group or chose individual students to send messages to. When a lecturer presses the submit button from the VLE web page, the SMS message and recipient list is posted into a database. A separate Java process running on the GSM Communications server connects to this database periodically (every 5 mins) and carries out the batch sending process to ensure the messages are still been sent within a reasonable time frame. At present the system is very easy to use for University lecturers. Figure 1 highlights the web interface presented to lecturers for modules they are involved in teaching. From this page, they are able to select who they wish to send a message too, a specific user, a group of users or all users in the year group. The mobile phone numbers are hidden for privacy reasons and the overall system operates on a credit based system, in which each department is allocated a monthly quota.
Mobile Phone
GSM Network 1) Form submission 3) AT Command
4) SMS Message
Serial Connection
VLE 2) Message Object
RS232
GSM Modem
GSM Communication Server
Figure 1: General Architecture of SMS Service in VLE At present, the main drawback to the SMS based system is cost. Each SMS message costs approximately 5 pence when bought in bulk. This cost can become prohibitive as the volume of messages sent is considerable when all the students registered with the system are taken into account. Another important factor to consider is in determining what constitutes ‘proper usage’ of the technology. Improper usage or overuse of the system may mean the effectiveness of important messages may be lost if endusers receive too many messages or start thinking of them as SPAM. These two factors helped motivate some work on an alternative approach, which could exploit the existing eCampus communications infrastructure at the University to offer a free transport mechanism for communications.
2.3 Communications Usage An initial trial of the text messaging service with 40 Biological Science students revealed some valuable results both from the sender and receiver perspective. Firstly, lecturers and more generally the department were keen to avoid over use of the system. Moreover, the text messaging service interface is similar in appearance to the VLE’s email communications interface and so it is potentially tempting to use the service to communicate more directly with students. However, it was considered that by sending too many messages via SMS would not only incur a charge for the department but may also reduce the effectiveness of important messages. It was important not to overuse the technology for annoyance reasons and reduce the chance of creating many unwanted SPAM messages which could be delivered by email. As a result, a need for more personalised or flexible message may be required. By this we mean a system which supports the classification of messages which may
be used to help decide when to deliver a message. For example, should a message relating to a change of lecture for the following week be delivered immediately or nearer the time? We return to this specific scenario in section 4.
3.
The BlueZone Service
The aim of the BlueZone service is to facilitate the delivery of localised and personalised messages to students by exploiting the campus infrastructure and thus offer a free delivery platform for large scale communications. The infrastructure consists of a number of BlueZone communications servers spread across the University campus which are able to deliver messages to handsets without charge. In essence, each BlueZone communications server continuously searches for devices in range before determining whether or not to dispatch a message to the device. To achieve this, each server communicates with a central database and performs some logic prior to dispatching any messages. At present, the BlueZone service consists of two distinct phases, an initial registration or authentication phase followed by the communication phase, which are described below:
3.1 BlueZone Registration Servers In order to facilitate personalised message dissemination and offer tailored services, it is crucial that we are able to associate a learners’ mobile phone’s Bluetooth hardware address (i.e. MAC Address) with their VLE learner profile. This may be achieved in two ways. Firstly, users may log into their personal MyModules area of the University VLE and enter their address into the text field provided online. However, since retrieving the MAC address is a non-trivial process and something which differs greatly between manufacturers and devices, we provide an automated approach which involves BlueZone servers to run a registration service. The BlueZone registration service runs on dedicated servers, for example servers located within the student registry building or departmental offices. Each registration server is a standard windows desktop PC with a Belkin USB Bluetooth adapter attached. Every server utilises a combination of C# .NET to provide Bluetooth services and the Ruby on Rails web development framework to provide a user interface to the service while data storage is provisioned through the use of a MySQL 5.1 database. Our current implementation utilises the 32feet.NET [1] personal area networking API which provides a managed .NET wrapper for Microsoft’s built-in Bluetooth stack. This library provides functionality for Bluetooth device
discovery, along with network layer support and basic provisioning for services defined in the Bluetooth standard. Additionally message transfers are performed utilising the OBEX protocol which is a standard commonly used by Mobile Telephone manufacturers as a means to enable the transfer of contact details among mobile telephones. We therefore developed minimal OBEX protocol support and layered it on top of the services provided by the Bluetooth library to provide common data transfer capabilities. During normal operation the BlueZone registration service attempts to discover Bluetooth devices in range and once detected, records the Bluetooth hardware address in the MySQL database. This hardware address is then hashed to create a unique PIN which the registration server will then attempt to transfer to the device using the OBEX protocol. Along with the PIN, instructions are included which appear in the message sent to the device. The instructions in the message direct users to the VLE’s WAP page where they are able to login to the site using their normal user credentials (i.e. username, password) along with the PIN sent to them. By submitting these details, the service is able to confirm the identity of the recipient and associate the Bluetooth hardware address with the end-user by hashing the PIN to reveal the MAC address. If the end user is not satisfied with this mobile over-the-air (OTA) method of authentication then they are alternatively able to enter their PIN by logging into the campus domain and VLE from any public or personal computer before navigating to their MyModules page within the VLE.
3.2 BlueZone Communication Servers Once a personal device has been registered it is then able to receive announcements from the VLE via the Bluetooth communications infrastructure on campus. The BlueZone communication service is similar in architecture to the registration service again making use of Bluetooth support libraries along with Ruby on Rails to provide a management interface to message delivery services and the user registration database. Each BlueZone Communication Server continuously searches for new Bluetooth devices in range using the standard Bluetooth device discovery mechanism. If a device is detected, the server communicates with the BlueZone registration database in order to establish whether there are any pending messages for this end-user. If there are pending messages, BlueZone attempts to transfer them via OBEX, as shown in figure 2.
Mobile Phone
GSM Network
3a) AT Command
4) SMS Message
Serial Connection RS232
GSM Modem 1) Form submission
GSM Communication Server 3b) OBEX Transfer
VLE 2) Message Object BlueZone
Mobile Phone Central Communication Server BlueZone Server
Figure 2: BlueZone Communications Infrastructure The BlueZone services logs all sightings of Bluetooth devices across the network and we are currently using this to help make the service more intelligent. This is discussed in more detail in section 4.
3.3 BlueZone Client Software To gain maximum benefit from the BlueZone service users are requested to download a small client application which resides on their mobile handset. This software, when executed on a mobile device, simply listens for incoming Bluetooth connections from our servers and handles the delivery of messages from any server across campus. If a handset is detected which does not have the BlueZone software installed then the server communicates with the device using the standard OBEX file transfer protocol. This means that any mobile device with Bluetooth enabled is also able to receive the basic level of functionality, although in order to view a message delivered using OBEX a user will be required to navigate to the location at which OBEX file transfers are stored (e.g. \My Documents on Windows Mobile 5 devices). For devices with the client software installed, we decided to make use of the existing communications interfaces on the device to facilitate a more intuitive user experience. More specifically, the client software is used to transparently handle communications from the BlueZone servers and to translate all OBEX BlueZone messages into standard SMS or MMS messages and write these to the folders on the mobile device, as shown in figure 3. By doing this, end-users are able to use the features and functionalities of their personal devices (such as folder management) without having to learn how to use a new application. Our initial implementation has targeted the Microsoft Windows Mobile 5 class of Smartphones. These devices offer programmer support for Microsoft’s Bluetooth stack via both managed .NET and unmanaged WIN32 APIs.
Figure 3: Summary of Communications Process Access to the MMS/SMS folders on the device is supported and managed through the use of the Windows Mobile 5 version of the Messaging API (MAPI). MAPI provides a series of C++ COM interfaces that offer access to message store (including all SMS, MMS and email folders). Through the use of MAPI it is possible to create a new message in any of the formats supported by the device and to place it in the appropriate inbox folder. Furthermore, we are able to notify the user that a new message has arrived using the existing messaging user interface (i.e. audible alerts and/or phone vibrate). The advantage of this approach is that as user’s roam around the University campus they are presented with a consistent interface to communications received either by our GMS/GPRS SMS gateway or the BlueZone Bluetooth communications servers. Figure 4 shows a screenshot of a device which has received an OBEX file transfer containing the data presented as the message body.
Figure 4: The BlueZone Client Interfaces
4.
Initial Evaluation and Results
At present the BlueZone service has been trialled with a small number of Computing MSC Students (approximately 30) all using Windows Mobile 5 devices. Before we release this service to a wider audience and conduct more widespread trials on a larger scale there are some crucial factors which must first be addressed which are the focus of our present experiments, namely
predicting the best channel for communications and how best to avoid SPAM [3]. At present the BlueZone communication servers maintain a log of all sightings of Bluetooth hardware devices discovered across campus. We maintain timestamp and location information for each device stored and use this during the decision making process when determining whether or not to dispatch a message over SMS or Bluetooth. Consider the example presented in section 2, where a University lecturer wishes to send a message from the VLE to her students notifying them of a change in venue relating to a lecture the following week. When using SMS text messaging alone and the system described in section 2, this kind of message would be dispatched immediately. However, by exploiting the BlueZone service, it is possible to use the history information in order to inform or predict the likely hood that any of the users in the group will be on campus during the days preceding the lecture change. At present we are working on an algorithm which we feel can be used to represent the probability of user being on campus on any particular day. We are using the discovery logs only at the moment in order to represent a percentage (probability) of an individual being on campus on a specified day. The second area of evaluation relates to maximising the use of the technology available without creating large amounts of unwanted and potentially intrusive text messages to user’s personal devices. Here we are considering trialling a new lecturer VLE web interface to posting messages which includes basic classification or prioritisation options. Additionally this includes checkboxes to explicitly allow the lecturer to choose the method of delivery (email, SMS or BlueZone) if they do not wish to allow the system itself to decide.
5.
Future Work
At present, the BlueZone service is being used in conjunction with the Lancaster University VLE (LUVLE) in order to facilitate unified text message communications between course leaders and their students within a single department. As well as increasing its use across the University, there is interest by other groups wishing to take up the service, such as the Students Union. Here, they are interested in using the Bluetooth infrastructure as a new avenue for communications specifically for news, events as well as promotional offers and discounted service. For example, they would like to investigate the use of the PIN creation and communications service to offer 2 for 1 promotions to students within the student’s union shop.
6.
Summary and Conclusion
In this paper we have presented our initial work on a unified solution for large scale communications between University lecturers and the student population. This approach is based on the delivery of Bluetooth or SMS based text messages and uses basic heuristics in order to determine the most appropriate avenue for dispatching messages. We believe this has the potential to offer several advantages to the Institution and the end user. Firstly, tailored or personalised communications direct to a learner’s handset are possible. Secondly, this approach offers a more timely solution to communication than relying purely on email between staff and students. Finally, the use of an existing infrastructure and the ubiquitous nature of Bluetooth devices mean this offers a cost effective solution for HE institutions. However, as our initial trials have revealed, one must be careful not to overuse the system since the potential for creating unwanted messages (or SPAM) will have a detrimental effect on the system’s overall success and acceptability.
5.
References
[1] 32feet.NET project website: http://32feet.net/ [2] Alsop, G., Briggs, J., Stone, A. and Tompsett, C., “Mlearning as a Means of Supporting Learners: Tomorrow’s Technologies Are Already Here, How Can We Most Effectively Use Them in The E-learning Age?” Networked Learning 2002, Proceedings of the Third International Conference on e-Learning in Higher Education and Lifelong Learning, Sheffield, March, 2002 [3] Garner, I, Francis, J. and Wales, K., “An Evaluation of a Short Message Service (SMS) to Support Undergraduate Student Learning”, Mlearn 2002, Proceedings of the European Workshop on Mobile and Contextual Learning, Birmingham, June 2002 [4] Lancaster eCampus Initiative website http://ecampus.lancs.ac.uk/ [5] Metamorphosis, Interactive Art http://domino.lancs.ac.uk/info/lunews.nsf/I/97F2B7D7B37 636BA8025703C00559183 [6] Mitchell, K Race, N. J. P. Suggitt, M., “iCapture: Facilitating Spontaneous User-Interaction with Pervasive Displays using Smart Devices,” in Proceedings of Workshop on Pervasive Mobile Interaction Devices (PERMID), a Workshop at Pervasive 2006, Dublin, Ireland. [7] Mitchell, K., and Race, N. J. P., “Oi: Capturing User Attention Within Pervasive Display Environments,”in Proceedings of Workshop on pervasive display infrastructures, interfaces and applications, a Workshop at Pervasive 2006, Dublin, Ireland. [8] Riordan, B., Traxler, J, "The Use of Targeted Bulk SMS Texting to Enhance Student Support, Inclusion and Retention" WMTE 2005 , pp. 257-260, 2005.
