Users wanting to integrate their own applications into the ILP user interface have several options; choosing one means determining what kind of experience you’re trying to afford users, and what level of context you need passed back and forth between your application and the ILP (from a simple URL launch point to in-depth Learning Tools Interoperability®, abbreviated as LTI®).
|Minimal context passing||Complex context passing|
|Loose UI integration||
A simple link can act as a launch point from the
Learning Service's UI to your own application's
separate user interface, embedded in the navigation bar.
You can use replacement strings to pass simple context information through the invoked URL.
An external learning tool quicklink can act
as an LTI launch point to your application's
separate user interface, embedded in the navigation bar.
You can customize the LTI context data passed to your application, and also use replacement strings if needed.
|Tight UI integration||
A simple custom widget can provide LMS
course and site designers with a bounded region
within a Learning Service's homepage in which they
can place their own HTML for rendering. This can
include links off to your application or service.
Simple URLs placed in the widget can use replacement strings to provide you with a minimal level of context.
Custom widgets can also include quicklinks and
stuff-style objects, and these can act as an
LTI launch point to your application.
You can customize the LTI context data passed to your application, and also use replacement strings if needed. When your application responds to the launch point, you can send back data to render within the widget's bounded region.
D2L’s ILP can support connections to your application with various depths of context (letting you know who’s connecting to your application, from where, and why). The simplest connections you can build to your application provide the thinnest amount of context.
Each org unit can have a collection of links defined as resources it can draw upon. Simple links consist of an URL (which can include query parameters) paired with a descriptive title.
Referrer header. Your application can use the referrer HTTP header to intuit that the request comes from a D2L ILP service, and your application can then proceed to make Brightspace API calls to gather more data before sending back a response to the URL request. However, since all Brightspace API calls need to be made within the context of a particular user, unless your application already knows the right user context, you’ll probably need more contextual information.
Replacement strings. When you define a simple link, you can inline replacement strings in the URL text. These replacement strings get expanded by the Learning Service when the user clicks on the link, allowing your application to receive some contextual information directly encoded in the full URL of the request (for example, a user name, or organization name).
Because this substitution happens directly in the text of the URL being directed to, the site handling the link cannot really be guaranteed of the integrity or authenticity of this contextual data unless the communication path between the LMS server and the site handling the link are secured by some external means (for example, if the LMS server and the handling site were both within the LMS organization’s firewall).
An org unit’s custom link can be, instead of just a simple URL link, a QuickLink (an ILP-specific connection to a well-defined type of system tool) pointing to an External Learning Tool (a custom-defined interface to an externally hosted tool, taking advantage of Learning Tools Interoperability® (LTI) to provide context).
You can define a custom link using LTI and then place that link in the D2L Learning Environment’s navigation bar, on a homepage, or within a course offering’s course content (via the Course Builder tool). These LTI links can pass your service a limited amount of pre-defined contextual information along with the HTTP request when an LMS user clicks the link.
In this case, the work flow uses these steps:
A LTI launch passes your application the context defined when the custom link was created. Some of the contextual information your application receives is defined within the LTI standard; D2L’s implementation supports several additional custom properties that it can provide to your application.
(Optional) You can decide to use LTI’s facility for posting result data back to the back-end Learning Service.
(Optional) You can decide to use the Brightspace APIs to fetch more context around the request (more detail about a user’s profile, for example), and to post result data back into the Learning Service.
Data exchange. When performing an LTI launch, tool consumers (the back-end learning service in this case) provide their context data to the tool provider (your service in this case) in POST form data.
Given sufficient context from replacement strings (in a trusted fashion) or LTI, your application can of course use API calls to the Brightspace API to gather even more information about the context of the request and can then use these calls to take action.
D2L’s ILP provides several general launch points, or places where you can integrate with the standard LMS user interface.
By default, organization and course homepages get constructed out of a set of widgets. For example a student’s view of the organization homepage might be built from several system widgets: My Settings, My Courses, Events, News, and so forth. Custom widgets let you expand this visual experience by adding custom HTML into a defined frame that can later be placed on a homepage. Custom widgets can point to content resources in LE, or act as an IFrame to other systems (but without inherent single sign-on).
Custom widgets can be placed on the org page where they’re created, and shared to all (and only) its descendants. (So, a custom widget can be created once at a department level, and then shared to all course offerings within that department; however, if you create a custom widget in one department, you can’t share it to another department: you’d have to re-create it.)
Permissions. For each role type, over each org unit type, a set of Homepage role permissions control this technique:
Manage Widgets lets a user role place an existing widget available to the current org unit onto that org unit’s home page.
Create/Edit Widgets lets a user role create a custom widget so that the current org unit can use it.
Share Widgets and Delete Shared Widgets lets a user role share a custom widget to org units that are descendants from the org unit where they’re created.
When using system-provided widgets, the permissions governing the system tool pertain to the content shown (or not shown) inside the widget. (So, when a user has the News widget embedded on a homepage, that user’s role in that context determines the News permissions that will affect the content the user sees.)