Having outlined the features of the existing SynergyNet framework which was possible to adapt to facilitate synchronous remote collaborative learning activities, this section addresses those features which presented a barrier to doing so and how these barriers were overcome. Initially, SynergyNet was designed for co-located collaboration, incorporating architecture which was not able to support remote working. This section outlines the challenges faced in terms of the framework, the school setting and mobile connectivity.
Co-location to non-co-location
The SynergyNet framework was developed to be as adaptable and extensible as possible. However, this had previously not included functioning across multiple environments in separate locations. The main priority of early development had been use in a single lab-classroom. Consequently, several issues in the design of both the framework and the apps became apparent when meeting the challenge of working between multiple sites in the current project.
The majority of SynergyNet features were developed on the assumption that users would be located in the same physical environment and thus be able to see each other’s screen directly. This informed the design of visual elements, such as the menus. For example, the menu used by teachers to load and transfer content in previous studies assumed that the teacher was able to see pupil’s interfaces, so that they could choose which group’s work to display to the class. As this was not the case for this study, the in-app menu system was removed to avoid potential disruptions through its use. A second issue was the inbuilt assumption of the network flick gesture about its use: users will know where their target interface is in relation to them. However, this knowledge can also be made available to users even when their target interface is in a remote location. The implications of not directly seeing the target interface when performing a network flick gesture are the key foci of this new strand of work and will be discussed in terms of the networking challenges and content transfer behaviour.
Network challenges
Overview
The use of single environments in the past has meant that the framework was always deployed across a single local area network (LAN) in all studies. Many of the features are not immediately capable of functioning across the wider internet.
Despite the original intention of using SynergyNet solely across LAN, a large amount of the framework’s networking capability was built in such a way that it could easily function across the internet. The use of third-party libraries such as OpenFireFootnote 3 (a real-time collaboration (RTC) server that uses XMPP/Jabber (the widely adopted open protocol for instant messaging) and HazelcastFootnote 4 (an open source in-memory data grid for simplified distributed computing, written in Java) means that the framework can use several different protocols across wider networks for communicating messages to each other.
However, the transfer of media content between instances of the framework was an original feature which was solely limited to use in a LAN. The framework uses a shared network location as a form of cache, which was beneficial in the past as it was simple to implement and gave teachers a single location to collect the files used in a lesson for use in future lessons. The Mysteries app only sends data when first discovering other instances of the app and when a content transfer occurs. The first time any content is sent it is moved to the shared area on the network. Afterwards, all subsequent transfers point back to the same item in the shared area, treating it like a cache.
The secure use of a shared network location across a wider network, such as the internet, is inadvisable without precautions due to data security and latency of such a technique. Development work took place prior to the trial taking place to allow the framework, to function over the internet as the two locations used would not be able to share a typical LAN.
Virtual private networking
Many of the networking features (including the network flick gesture) are dependent on the devices being on the same local network. When working with different locations and networks there are a number of technical issues to overcome. Some of these issues are general; others are specific to working in educational environments. It became apparent that the most effective approach would be to emulate a LAN across a wider network (i.e., the internet). This solution was decided upon as it was more practical given the available time and resources compared to supporting direct communication across the internet. The latter would have required several of the framework’s key networking features to be completely re-engineered.
The most effective way to emulate a LAN in this type of environment was to utilise a virtual private network (VPN). A VPN provides many of the features of a local network that SynergyNet requires, such as shared folders, whilst still supporting communication across the internet. Though various VPN solutions are available, both free and paid-for services, Zero-TierFootnote 5 was selected to provide network virtualisation services. This low-cost VPN solution was able to support the necessary networking features over the internet. Two table-top machines were required to be connected to the same network in the trial (i.e., one touchscreen table-top interface for each site). It was not necessary to use a more feature-rich VPN. The tablets used in the trial for the Skype did not need to be on the same network as the table-top interfaces and could function over the internet. Given the sensitivity associated with conducting research in a school—in particular the fact that the participants are vulnerable persons—security of the connection was a major consideration. The trial did not transmit any private data between the two sites. Therefore, the level of security afforded by the Zero-Tier VPN was considered to be adequate both technically and in the ethical permissions granted for the project to be conducted.
School security
An unexpected problem was encountered with the use of Zero-Tier on the school networks. It was originally intended that all devices would connect to the internet via the schools’ own network infrastructure. However, during preparation for the trial it was discovered that the firewalls at both of the schools were explicitly blocking outbound VPN traffic relating to Zero-Tier. When tested in other environments which have strict firewall policies (e.g., university networks), the Zero-Tier VPN had operated as expected. However, the school firewalls were locked down much more than anticipated. Both school’s networks limited the permitted outbound connections allowed through the firewall to a great degree.
Such stringent measures, prompted by e-safety concerns and wider protection issues in a school environment, have been a feature technical infrastructure for some time. However, there has been a concerted effort for local education authorities not to indiscriminately “block and lock” networks without justification (Welsh Government 2015). Despite this policy of more focused and strategic security, the SynergyNet framework could not operate when connected to the Zero-Tier VPN through the schools’ networks. Adding exceptions to the firewalls would have allowed the VPN connections to function correctly. However, this was not feasible due to administrative issues with approval via the school and local education authority in any short-to-medium timeframes. Therefore, an alternative method of connecting to the internet was required.
Mobile networking and connectivity
An alternative method of connecting to the internet allowing the table-top interfaces to function was identified using pay-as-you go 4G mobile dongles. These were connected via USB to the two table-tops to allow them to connect to the internet through a relatively fast mobile connection. Due to the geographical locations of each school it proved difficult to find acceptable coverage using a single mobile network so the interfaces at both sites were connected to the internet via two different 4G providers. This had no noticeable impact or latency on the connection and allowed the instances of SynergyNet on both table-tops to interact quickly and with minimal data loss. For example, there were no noticeable instances of failed transmissions of messages between the instances resulting in flicked items not arriving on their target device.
Although 4G mobile connections may not be as secure as using the wired school network, data to and from the VPN were end-to-end encrypted ensuring they were secure. Furthermore, task design ensured no sensitive or personal data were transmitted between the tables.
Multi-casting
Prior to the current project, SynergyNet had used multicast service discovery as a method of automatically finding other running instances of the framework on a network. However, many VPNs do not support the User Datagram Protocol (UDP) that SynergyNet employs. To accommodate this constraint, the framework was modified to work entirely through Transmission Control Protocol (TCP). However, this change meant that SynergyNet could no longer automatically detect other instances using multicast service discovery. Therefore, at least one instance would need to be informed of the IP address of the other instance. To support this new functionality, a user interface was developed which allowed for the user to specify participating device’s IPs on the network. This update was initially a change at the app level but has since been integrated into the framework so that all apps on the latest version of SynergyNet can work over VPNs more easily.
Content transfer behaviour
The tablet computer showing each group of participants the other group via Skype was placed on the long table edge opposite to them. The tables were configured so that flicking items towards the tablet (and therefore the other group ‘facing’ them) would transfer these items to the remote table. This was achieved by configuring the tables so that they were virtually positioned opposite each other, with the sides on which the tablets were placed being parallel to each other. This meant each table operated virtually as if the other was co-located with it. With students passing items towards their ‘window’ to the other team, the metaphor of physically pushing items towards another interface was maintained. Virtually positioning the tables opposite each other also meant that the entire edge of the tables with the tablet on could be used as the target for network flicks. If the two tables were configured to use their real-life locations in relation to each other, the size of the boundary where a network flick could be trigged (i.e., that points to the remote table) would be less than a pixel at the distance between the two locations.
Another benefit to this configuration of the tables being placed virtually opposite relates to behaviour of the transfer. Normally a realistic effect is employed with time taken for items to transfer and is calculated by the time it would take to travel from the gap between the interfaces at the speed of the item before it leaves its source interface (ignoring deceleration). This is useful for co-located interfaces as it reinforces the metaphor of real objects being pushed around the environment. Clearly this behaviour would not be suitable with the interfaces using their real-world locations in the trial as it would take a long time even with the fastest flick gesture the interfaces are capable of identifying. Therefore, the virtual distance between the tables was set to be as small as possible. This meant the flick behaviour had the effect of items travelling the shorter virtual distance from one interface to the other when flicked in a direction with a trajectory that would eventually intercept the nearby virtual representation of the remote table.
Limitation: data collection
Screen recording software was installed on both tablets allowing both sides of the video conferencing software used for communication between the groups to be recorded. In addition to this, stand-alone cameras were used at both locations to record in high-definition the interactions in and around the table-top interfaces.
Previous SynergyNet studies have been informed by detailed data collection of touch frequency and location during activities. These data were collected on separate lab-based infrastructure which was not possible to replicate in the current study. SynergyNet uses OpenGL (a cross-language, cross-platform API for rendering 2D and 3D vector graphics) for its visual output. Video capture from the table-top screens was problematic because, using a secondary device that mirrored the output of the table would have affected the visual output configuration and impacted on the performance of the device. This in turn would adversely affect the intuitive operation of the tables. This was considered an unnecessary risk to the study for the potential data collected. Future research will explore data capture solutions which do not risk inhibiting the performance of the tables.