The Aquapons project had as it’s initial goal to create a “robust badging ecosystem where traditional and 21st century skills and achievements are inspired, recognized, translated across contexts, and displayed and managed across the web” using Mozilla’s Open Badge Infrastructure (Bowen 2012, p. 258). Here is a short video explaining the Open Badges project by Mozilla:
What interests me about this badging project is how well they seem to be engaging students in hands-on learning while at the same time integrating assessment, mentorship and the idea of progress through a series of levels and achievements. They do this by using an online open resources such as Open Badges. From a student perspective, I can imagine myself have a clear view of the extent of progress I need to make in any given field of study, which would be outlined visually by a series of digital badges I need to earn. Then I could also imagine that it would be quite a proud moment to be able to display on my website, LinkedIn profile or share via social media the badge I would earn.
When UBC transitioned from WebCT/Vista to Blackboard Learn in 2012-2013, many instructors noticed usability issues with the new platform including a non-intuitive interface and high click-rates to access features and settings. In addition, because of FIPPA restrictions, UBC had to self-host its on instance of Blackboard Learn. Performance issues and frequent crashes in the first few months of full deployment, along with the UI issues, led some instructors to consider other ways of creating and publishing course content online.
Hence the idea of integrating WordPress blogs with the LMS via a BasicLTI tool integration. UBC already had its own self-hosted WordPress instance for student and instructor blogs at blogs.ubc.ca. So all that was left was to create a means for the Tool Provider (Blogs.ubc.ca) to communicate with the Tool Consumer (UBC Connect LMS) and vice versa, via a customized BasicLTI tool. The result is that an instructor can have a private, subscriber only WordPress blog that only students from a particular course in UBC Connect can have access to (see diagram below).
In this way, an instructor is able to update all her content using the WordPress CMS which then seamlessly integrates with her Connect course which houses all the assignments, asessments and Grade center tools. Here is a breakdown of how each platform would manage the specific educational technology pieces:
WordPress CMS (Blogs.ubc.ca)
Blackboard LMS (UBC Connect)
Assignment Submission areas
General course content (WP pages)
Informal Assessments (Quizzes, Surveys, etc.)
Slides (.ppt, .pdf)
Groups and group-related tools
Documents (.docx, .pdf)
Formal assessments, including midterm and final exams
Learning Ecosystems has become a bit of a buzzword in the Ed Tech corporate eLearning and Higher Ed spheres, with whole conferences now being dedicated to the topic. Marc J. Rosenberg and Steve Foreman, in Learning and Performance Ecosystems: Strategy, Technology, Impact, and Challenges(2014), suggest that “we must move away from individual, siloed, ‘one-off’ solutions to an ecosystem comprised of multi-faceted learning and performance options that enhance the environments in which we work and learn.”
Often the one-off, siloed solution is the Learning Management System (LMS) such as Blackboard Learn, Canvas, Desire2Learn or Moodle, among others. These systems try to offer everything in a one-stop shop but fail to do everything well and are often a victim of “feature-creep”, continually adding new features that don’t necessarily integrate very well into the whole and often slow down the system.
What’s nice about an ecosystem approach is that the entire online learning environment of the student is considered: everything from discussion forums to blogging sites, social media to mobile apps — basically everything that the instructor expects the students to digitally ‘touch’ in addition to the sites, apps and tools students themselves use and promote amongst themselves.
The key with good Learning Ecosystems management is to be able to link all these desperate platforms (especially the ones supported by the service unit) in an integrated fashion. Learning Tools Interoperability (LTI) is one way to do this, allowing a tool provider (such as a 3rd party survey tool) to interact with a tool consumer (such as an LMS). Here we use BasicLTI tool integration with a variety of platforms linking into our core LMS, Blackboard Learn: Piazza, WebWork, WordPress blogs, various Publisher applications, etc. Here is a diagram to illustrate those integrations:
This semester (January – April 2015) my colleagues and I at Learning Services in the Sauder School of Business have helped professors create and deploy over six thousand online exams for students bringing to the classroom their own devices connected to UBC’s secure wi-fi and logged into “Connect” – UBC’s instance of Blackboard Learn‘s LMS. We have developed very specific guidelines in collaboration with professors in order to ensure students are technically ready for the exam, including an online technical pretest and instructions displayed in their Connect LMS course, as well as online exam instructions shown on digital projector screens during the exam.
Midterm Performance Blues: Lag time, saving, image display issues
For the midterm we noticed many students experiencing lag times with when initially accessing the exam, some with more than 30 seconds of lag time. This was most likely the result of 1. limited staggered start time (only 15 second intervals between launching largest rooms) and 2. the fact that the LMS database was having to process 1200+ instances of the entire online exam displaying all questions at once. Several students lost some of their responses due to saving issues, while others had issues seeing displayed images properly.
Final Success: Logistics and Exam Build Improvements
Thanks in large part to the eagerness and technical savviness of COMM291 Prof. Greg Werker, we were able to work collaboratively with UBC IT Learning Applications to optimize certain parameters of the online exam deployment to attain much better performance results:
Increased staggered release time to 1 minute (60 second) intervals of approximately 100-200 students at a time going into the exam
Placed several on standby mode in the event lagging occurred in other rooms, so as to provide a sufficient buffer for database load issues
Reduced picture sizes displayed during the exam to less than 100 kilobytes
Placed mandatory questions in the exam prompting students to ensure their questions are saving.
Performance Comparisons of Midterm and Final Exams
UBC IT supported us on the database side and took performance measurements and comparisons for both the midterm and the final exams. Here are the launch statistics (performance during the first 25 minutes):
With the staggered release, we were seeing more “green”, i.e. quicker access times for students logging into the assessment tool (the online exam link). For “Save Attempt” performance, i.e. when answers were automatically saved or when students attempted to save their own answers, we noticed marked improvements on launch and submission times, with only very slight latency issues that were hardly noticeable by students:
Finally with submission performance we also saw significant improvements:
Because the launch was staggered by a minute per chunk of rooms, submission times were also staggered for those students who chose to use the full allotted time (the majority of students). Therefore the LMS database did much better, with reduced latency issues. Jeff Longland from UBC IT Learning Applications mentioned that “Looking at this data, I think the staggered start helped to mitigate some of the issues that were experienced with the midterm. There doesn’t appear to be as much congestion around launch and submission events for the final exam.”
A big thanks goes out to the UBC IT Learning Applications team, Infrastructure support, Networking and a host of other IT departments all working collaboratively with the goal of improving LMS performance on our campus.
Tin Can API or xAPI is “a brand new specification for learning technology that makes it possible to collect data about the wide range of experiences a person has (online and offline)” (http://tincanapi.com/overview/). API, in case some readers are confused, stands for Application Programming Interface and is simply a way to obtain information from a source location and pass on that information to trusted partnering applications.
The Tin Can API is able to consistently capture data about a student’s learning activities from a variety of technologies. Because of Tin Can’s simple vocabulary inherent in the coding, diverse systems are able to communuicate with each other in a secure manure by interacting with Tin Can API’s stream of user activity data.
A Learning Record Store (LRS) on the other hand, works with the Tin Can API and is a new system that stores learning records. According to their website:
“As Tin Can-enabled activities generate statements, they’re sent to an LRS. The LRS is simply a repository for learning records that can be accessed by an LMS or a reporting tool. An LRS can live inside an LMS, or it can stand on its own.” – http://tincanapi.com/learning-record-store/
I see the Tin Can API and LRS working together to create a complex set of data about student learning not primarily for the institution but for the ownership of the students themselves. Students will increasingly need data on their learning to prove that they did in fact engage with various digital learning tools as they were instructed. The LRS will potentially record all their activity in a course down to how much time they spent reading a particular article or doing an online quiz. The flexibility of the Tin Can API to record almost any activity on these platforms is what is most appealing for a Learning Ecosystems architecture approach to Higher Ed learning technology.
Here is a slide show presented by one of my colleagues regarding xAPI or Tin Can API integration with WordPress: