Introduction
Developed by and for the learning community in collaboration with educational technology companies and shepherded by the 1EdTech Consortium, Learning Tools Interoperability® (LTI®) is a technology standard that defines "glue code" to launch courseware, services, or tools—henceforth "solutions" —from within a learning platform such as a learning management system (LMS). LTI is a growing set of mature and stable technologies that benefit countless stakeholders: students, instructors, staff, institutions, and providers.
When launched from a learning platform, LTI-enabled solutions leverage single sign-on (SSO) authorization, identify important user and course contexts, and securely pass content, assignment scores, grades books, etc., between your solution and the platform, resulting in richly interactive learning capabilities. LTI minimizes the burden of student access to your solution, eases classroom management for the instructor, and lessens the concerns of administrative and support staff—all with minimal effort.
About this Guide
1EdTech higher education members leading the Digital Learning Ecosystem Innovation Leadership Network designed this guide for edtech providers to consider how their solutions can leverage LTI technologies. It has been prepared by experienced higher education professionals collaborating with 1EdTech to promote this universal integration method. Solution providers new to higher education are often surprised by the complex social, regulatory, and technical realities they confront. As you consider how your solution will be used, remember that LTI can help ease some of these challenges. Below are some considerations to help you better understand the needs of many higher education institutions.
Becoming a 1EdTech member allows solution providers to help shape the LTI specification, access developer resources, and participate in the LTI Advantage Conformance Certification program.
Review the LTI Specifications Before Designing Your Solution
Solution Considerations
As you review this guide, consider what your solution offers the learner, instructor, institution, local school district, or state university system.
(Core vs. Advantage)
(Assignment & Grade Services)
Functional Considerations (Access)
The functionality of your solution should be flexible to accommodate the variety of needs across higher education. As noted above, institutions have surprisingly complex ecosystems.
For example, in terms of user roles, it is not unusual for an individual to have a variety of simultaneous roles in the learning environment, such as a person who is a student in one course and a teacher in another course.
In addition to considering how roles are assigned to people, it is valuable to know that institutions define roles like instructor or TA in ways that meet their local needs. Not only can roles and responsibilities vary between institutions, but the functional rights associated with the TA role in one part of a university can be very different from the functional rights of the TA role in another part of the same university. For example, a TA may be able to grade student papers in the School of Law, but in the Business School, the TA may be limited to providing coaching advice and commenting in the course discussion forums.
- Does your solution require more access than provided by LTI (such as a scoped token or API access)?
- Is API access appropriately scoped to the minimum data and permissions required?
- Limiting data access is essential for both the institution and the tool provider to minimize risk. In some cases, local policies or legal regulations may prevent the type of HE data access, so it behooves you to develop a solution that relies on ingesting the minimal amount of campus data.
- After the initial configuration phase, are additional connections required to complete the setup?
- For example, one provider built a tool to assist with LMS integration, so institutions would not need to devote extensive technical expertise to the setup. This tool required a high level of permissions during setup only, and ongoing use only required minimal access.
- Does your solution require custom fields and substitution variables?
- Is API access appropriately scoped to the minimum data and permissions required?
- Does your solution provide different experiences based on role (i.e., learner vs. instructor)?
- Does your solution support different roles based on course, section, or group?
- LTI allows for multiple roles per user in a context, but the vocabulary for the _types_ of roles is fixed in the specification.
Learner/Instructor Considerations
Learner and instructor experiences are of growing importance to institutions. When you are designing your tool, be sure to keep the user experience in mind.
Here are some areas of importance to institutions:
- Does your solution minimize the number of user clicks during the launch process?
- Does your solution provide a clean and modern user interface, such as avoiding double scroll bars when launched from the LMS?
- Does your solution offer a setting to launch in full screen or a new browser tab?
- What is the mobile experience? Can learners and instructors practically experience full functionality? Or is the mobile device experience tailored for quick activities?
- What is the expected interaction on different types of devices? For example, do users need to download a separate app?
- What are your solution's initial, one-time user setup requirements, such as account authorization, providing personal information, and opting in or out of marketing?
- Have you performed robust accessibility checks for disabled users?
In most cases, instructors should be able to:
- Activate the tool in their courses without IT support
- Access the tool from the LMS in a way that sends them to the type of activities, exercises, and assessments they want to create within the tool
- If your solution requires setting up activities, exercises, and assessments within it, then make it simple to bring those into the LMS with LTI Deep Linking
- Enable complete functionality in your solution without redirecting students and faculty into what amounts to a separate LMS.
In summary, when students use a well-designed and implemented LTI solution, they should not know it's an external tool.
Administrative Functionality Considerations
Companies developing LTI solutions will find that LMS administrators and others who support the environment are often key personnel. Easing the burden of the LMS administrators is one way to help ensure your tool or service will be received positively. A robust and thorough LTI integration process will go a long way toward earning the goodwill of these key ambassadors.
User Management
- Are you able to auto-provision users via LTI clicks? Have you built a mechanism to easily de-provision users?
- What is the primary user identifier key? Although an email address is commonly used elsewhere, the eduPersonPrincipalName (EPPN) is more commonly used in higher education. The other solution would be to design your system to allow an institution to define this in one of the LTI fields.
Data
- Is your tool or service able to provide usage/activity data? If so, is the data provided in a standard format, such as Caliper, or only available through a proprietary dashboard? Are institutions expected to pay to consume their data?
- Caliper and LTI Advantage Data (member login required)
- Does your tool minimize the data flow? What does the supplier plan to do with the data? Put more thought into what you need to limit data flow and understand data privacy. Avoid overreaching; this will diminish your security risk profile (not always malicious, just ease).
Content Management
- Is copying content from previous terms (or template courses) straightforward?
- Does your solution account for hierarchical course > course sections (i.e., one "parent" course and separate sections with separate TAs)?
- Does your solution avoid the pitfall of requiring content created in one location and then linked to a course?
Administrative Support
- How do you orchestrate support for end users of this tool?
- Can administrators access your solution? Can they impersonate users in order to provide support?
- Does your solution reduce dependency on the need to impersonate instructors to add the tool to a course?
- Does your solution account for LTI and naming conventions for long course names or white space in account names?
- What's the smallest unit this LTI can be installed on? (A single course, an area or sub-account, or the whole LMS instance?)
- And can the app be installed in more than one place (multiple courses, multiple sub-accounts, beta/test environments)
Company Considerations
The higher education community relies on providers to understand and honor their campuses' security, accessibility, and data use policies and practices. Indeed, failure to meet these needs may make or break the ability for your solution to be purchased. Adherence to the LTI standard can facilitate meeting these technical, cultural, and regulatory procedures.
- Do you maintain up-to-date documentation, such as the HECVAT and VPAT?
- Do you provide institutions with advance notice of changes and updates? A roadmap for new or deprecated features?
- Are these changes tracked over time so institutions can understand what has changed with your solution since the institution's last review?
- Do you work with customers on staging and scheduling proposed changes to your solution?