Nearly 2 years ago, Rustici began supporting the LTI standard across our products. The Learning Tools Interoperability (LTI) sets a standard for the communication between LMSs and content libraries or learning applications. Our customers quickly began utilizing the functionality, an encouraging sign of LTI’s adoption within the eLearning community.
The growing adoption of LTI wasn’t without its pain points. For those LMS administrators that needed to set up and configure many courses, each one with many content modules, the standard LTI integration process felt a bit tedious. In addition, the process to integrate multiple pieces of content from third-party libraries could also be laborious.
To help address these bottlenecks, IMS developed a way to streamline multiple integrations and integrations with external content libraries and added it to the LTI 1.3 spec under the name “Deep Linking”. The Deep Linking addition enables a platform to easily integrate content from an external tool. Users can launch an external tool, select specific content (any number of content items), and return the specific content to the LTI Platform in one singular workflow without leaving the LMS or requiring secondary logins or packages to import. At the end of the Deep Linking process, the LTI links for the integrated content pieces are fully configured and ready to be launched.
Our customers were feeling the pain points of LTI. Once LTI 1.3 Deep Linking was introduced, we needed to bring that enhanced functionality to our products.
Design and development
My first task in bringing LTI Deep Linking support was to accurately wrap my brain around the Deep Linking process from start to finish. This involved writing internal tech spec documents and individually analyzing each step in the process. This wasn’t a project I wanted to dive into without fully understanding the process; I didn’t want to be overwhelmed with information while also writing code. As a remote developer, not having the ability to just pull people into a meeting room and draw on a whiteboard was tough at times, but we made it work over Slack and video calls. After taking time to gameplan and clarify my understanding around the whole Deep Linking process, I began writing the code that would support it in our products.
In Rustici Engine, I updated our existing LTI processing methods to recognize the new ‘DeepLinkingRequest’ LTI message type that is sent from an LTI Platform. Engine now prepares the required information and redirects the user to the specified tool where the user will be able to select available courses to integrate into the platform. I also added methods to Engine that receive information on the user’s content selections. Engine packages and formats that data into the new ‘DeepLinkingResponse’ message type, and finally redirects the user back to the LTI Platform. Engine’s support for these two new message types fulfilled its support for LTI Deep Linking.
Content Controller’s role in the Deep Linking process is more visible for end users, which necessitated a few more changes. I updated our Content Controller product so that it recognizes the information that is now being sent from Engine. Content Controller uses that information to authenticate and redirect a user to what we’re calling a Content Selector app. This Content Selector app provides a window into the Content Controller library that lets users see accessible content that is available to be integrated into the LTI Platform. Users can search for and navigate through folders for content items. After a user makes their content selections, the Content Selector app will send the user’s selections back to Content Controller, which will gather and format the necessary information to then send it back to Engine. Engine will ultimately redirect all the information back to the LTI Platform.
…. and quite a bit of testing
Not only did I have to fully test each step of the process individually, I spent quite a bit of time testing the whole Deep Linking process from start to finish. To do this, I worked with a few unfamiliar external systems, which came with its own hurdles. When I encountered an error, I would always start by questioning if there was a bug in my code (which was nearly always the case), a bug in someone else’s code, or if I wasn’t using the external software correctly. I relied on Moodle LMS, an open-source LMS with which our team had previous experience. I also tested our Deep Linking implementation with Canvas LMS, as many of our customers work with Canvas. I had very little experience with each of these products, and each required some learning as I went along. To ensure that I didn’t miss anything, I also validated the Deep Linking implementation in Content Controller by running through the IMS Test Suite for LTI Deep Linking. Passing this test suite sets Content Controller up to be certified for LTI Deep Linking 2.0 and LTI 1.3. Trying to debug an error when using new software is hard, but thorough testing helps ensure we’re providing a quality solution for our customers.
Extra thoughts
This was a big project, and it’s one of which I’m very proud. I was able to walk this feature from its planning stages through its release. Working with various spec documents and the IMS Test Suite was challenging, but it helped me reach a deep understanding of a feature that can really improve our customer’s LTI experience. I got to dust off the ‘Engine Development’ part of my brain by adding this feature to our Engine product (I used to be a dev on the Engine team but have been with Content Controller for almost 2 years). I got my first real experience with the Vue framework writing the Content Selector App in CC. I got experience working with Moodle and Canvas, both of which are used by many of our customers. Adding LTI 1.3 Deep Linking support in our products was a challenging and rewarding project. On to the next one…
If you have any questions about Deep Linking or LTI, reach out. We’re here to help.
