IMS QTI Trial
© Copyright 2010 University of Southern Queensland
(458 KB)Introduction
The IMS QTI trial builds on previous investigations for the TS-DER project investigating 21st century learning environments. The project explores how we can integrate Web 2.0 tools into learning environments such as Learning Management Systems (LMS).
Web 2.0 offers an enormous number of tools and services that offer great potential in the classroom. New tools are released with increasing frequency - far beyond the capacity of LMS vendors and other education platform software vendors to keep up with. A number of vendors recognise this and are working with IMS on how they can integrate other web tools and content into their learning platforms.
While many of these tools and content have great application in teaching and learning environments, there are challenges in ensuring their appropriate use. For example, on the web, safety and identity are crucial for students. We want to ensure that students use appropriate tools and content in a safe manner. IMS Learning Tools Interoperability (LTI) is a specification that allows users in environments such as an LMS to 'launch' Web 2.0 tools and content from within the LMS. In this way, teachers and educators can control which of these tools and content can be accessed by students from within their learning platforms.
Our investigation tests the utility of this approach using two services that are available to the Australian education community.
IMS Learning Tools Interoperability (LTI)
IMS Learning Tools Interoperability (LTI) is one of three Core specifications for IMS Digital Learning services. These core specifications are:
- Common Cartridge. The Common Cartridge specification enables platform-independent learning content and assessments supporting collaborative learning.
- Learning Tools Interoperability. LTI enables a wide variety of web-based learning applications to integrate into learning environments such as LMSs.
- Learning Information Services. LIS supports provisioning of learning/learner information from administrative systems into learning platforms.
The following diagram (courtesy of IMS GLC) shows how these three core specifications fit together to support digital learning services:
The full IMS LTI specification is yet to be released. A 'lite' version (Basic LTI V1.0) was released early in 2010. This project worked with Basic LTI and wherever the term LTI is used in this report, it is in the context of Basic LTI V1.0.
Basic LTI allows a platform such as an LMS to launch an external Web tool. There are two main components to LTI. These are:
- Tool Consumer. The tool consumer is (generally) the LMS. It 'launches' external tools or content.
- Tool Provider. The tool provider is the 'external tool'. This may be a Web 2.0 tool or some external content. The tool consumer (TC) will consume the tool provider (TP).
Scenario
In our investigation we used www.me.edu.au, a personal and professional-development social-networking platform available to all Australian educators, as the LTI tool consumer. Me.edu.au provides Australian education and training professionals with an online networking and profile space. They can use me.edu.au to:
- create an online professional profile
- connect with educators who have similar interests
- share links, news, photos, ideas, opinions
- blog about work and professional learning
- aggregate online activity to show what you are doing online
- create communities of interest.
We created a community that would launch tools from a Web 2.0 service. The service that we chose was Scootle. It provides access to a wide range of digital-curriculum resources from The Learning Federation. You can find interactive learning objects, images, audio files and movie clips via browse, search and filter technology. Scootle allows you to create personal favourite lists of resources for quick access.
Scootle stores both learning objects and learning paths. A learning path is a simplified lesson plan - it may contain content and activities for students to complete. Access to Scootle objects is controlled. Typically, this is done via the use of a shared secret key. A teacher will identify a Scootle resource to be used in a class and will share a secret key for that resource with the class's students. The use of the shared secret aligns very well with the OAuth approach used in Basic LTI.
Using Scootle alone, the teacher must let the students know the secret key to the resource. Using LTI, the teacher simply needs to share the key with the LMS, or whatever context they are using to deliver their lesson. This eliminates manual processes and also increases security. By registering the shared secret with the LMS students do not need to know it (which eliminates the potential for errors and unauthorised access). They can also launch the service without having to leave their learning environment.
Approach
Basic LTI simply allows a tool to be launched within an iframe and performs authorisation using OAuth. The basic process that this project demonstrated was launching an external service (TP) from an LMS (TC). Me.edu.au acted as the TC and Scootle acted as the TP.
In order to support this process a number of other functions were required in our TC. These are:
- TP List Tools
- TP Create New Tool
- TC List Tools (Administrator)
- TC Add New Tool
- TC Launch Tool
These functions were required so that the TC knows about the TPs and how to launch them. An administrator (or, in LTI terms, an instructor) can add new tools into the TC for use by students. Once these admin functions are in place, it becomes very easy for instructors to add new tools into their environment for use by students etc.
Students simply go to their 'class' (in this case, a community space on me.edu.au) and see a list of activities (tools) that they need to launch and complete.
Creating both a TC and a TP gave us the opportunity to assess the specification both as a tool consumer and as a tool provider.
As mentioned above, Basic LTI uses OAuth to provide security so that only authorised users can access the TP. In OAuth, a shared secret is used to authorize access to a tool or service. In this case, both the TC and the TP must know the secret. Basic LTI does not provide a mechanism for sharing the secret, i.e. the TP must provide the secret to the TP through some external mechanism. When the instructor is defining the TP in the TC, they must also setup the secret key so that when students launch the TP, it is able to check the secret key supplied in the launch request is valid.
Scootle works in a similar fashion. When a teacher wishes to have students in a class use a resource, they must let the students know what the key is to that resource. In the case of Scootle, this key must be known by the students and supplied to Scootle by them. Using OAuth however, the students do not need to know what the secret key is. The teacher (instructor) provides that to the LMS (TC) when they add the TP into the system. The secret key is then passed automatically and securely when the student launches the TP from the TC.
'Appendix A: UML Diagrams' contains the UML diagrams describing the processes that were required to support the implementation of both TC and TP functionality.
The purpose of the project was to assess and demonstrate the utility of the LTI specification, rather than create a production-quality solution. As a consequence, the user-interface changes that were implemented concentrated purely on functionality rather than elegance of the user interface. No graphical design expertise was employed to create a high-quality user interface. The following screen capture depicts a resource from Scootle launched from within me.edu.au:
TP (Scootle learning object) launched from TC (me.edu.au)
In the above screenshot, the learning resource (Heroes of the Air) is launched directly from within the me.edu.au personal learning environment. Any LTI compliant tool consumer (TC) would be able to launch the resource, potentially making this and other resources from this TP available to a very large number of authorised teachers and educators.
Summary
The LTI trial allowed us to consider the LTI specification from four different aspects. These are:
- as a Tool Consumer (TC)
- as a Tool Provider (TP)
- as an instructor
- as a student.
Tool Consumers (TCs) will typically be an LMS. LMS vendors that wish to take advantage of LTI should apply for conformance to the specification. Through implementing LTI, a vendor can allow their customers to potentially integrate with many different web tools and content, which can ultimately allow their customers access to a very rich and large number of teaching and learning scenarios. Although not a vendor of LMSs, we found it quite simple to implement Basic LTI in our personal learning environment (me.edu.au). Setting up administration forms to add and maintain tools (TPs) was a once-off task that the tool TC needs to do.
Tool Providers (TPs) will typically be providers of either content or Web 2.0 tools and services that would like the opportunity to be integrated into teaching and learning environments (such as an LMS). Without LTI, TPs need to do integration work with each of the LMS vendors that their (potential customers) use. Using LTI, they only need to setup their tool once and have it certified as LTI compliant. Once this is done, their tool/content should be interoperable with any TC-compliant solution. This is a one-off task and to setup as a TP was a trivial task for the project team.
Instructors will typically be teachers that use LMSs and add activities/content into their courses and lesson plans for their classes. Registering a TP into the TC was a very simple task and opens up a range of teaching and learning opportunities for them and their students. In our example, we provided access to a tool that required some form of authentication (the use of the shared secret). In our case, security and usability were both improved through the use of LTI.
As a student, the opportunity to potentially use a very wide range of external tools and content from within the learning environment (LMS) was obvious. Rich tools and content provide a more compelling and rewarding environment to learn from. Safety and security is improved as these tools are vetted and registered by teachers or course developers.
Basic LTI only provides the opportunity to launch (secure) external tools and content from within the LMS. Information is not sent back to the LMS from the TP. However, full LTI addresses this so in the future it will be possible to launch an external tool that may have some form of assessment in it which is returned back to the LMS on completion of the tasks set by the TP. IMS are currently running trials with an internal version of LTI known as LTI Simple Outcomes. In this version, it is possible for the TP to return an assessment result back to the LMS for population into the gradebook (for example).
In conclusion, the Basic LTI specification allows for a very simple and fast integration of external web services and content into the LMS. This does open up a potentially very large range of new teaching and learning opportunities for students and teachers in a relatively safe and secure manner. We found the specification easy to work with and will be recommending to the service owners of the services that we trialled, to consider the benefits of getting those services certified as LTI compliant.
Appendix A: UML Diagrams
