This is an echo from some other posts I have made in the past, but in a more concrete way using a fictional API, Learning App Connect. It feeds in the same territory as the Learning Tools Interoperability LTI specifications, and could be seen as an extension of it, but differs in a few key elements:
- It puts the end user (student/instructor) in the forefront by using a strict 3-legged OAuth 2 flow
- It is not LMS centric. The interaction does not initiate from the LMS nor does it require the user to ever go to it. The LMS is more a central nerve or a way to get extra data about the user to enrich her experience. App first!
- By using standardized services and authorization scopes, a Learning App should be able to connect to any institution Learning Hub/LMS
For now the API only exposes the ability for an app to discover a student’s enrollment, and a way to push engagement data back to the institution. Note that the API does not intend to be used as an Identity provider. The student may connect to the App using, for example, a Google Open Id flow, and then grant access to his institution’s data (and possibly even multiple institutions!).
The engagement data format is open for discussion: Closed vocabulary or open-ended? Caliper and metrics profile, or XAPI to let the app open to express any interaction (as no one can know what kind of app can be used in a learning context, for example if it is a complex simulation or a game like Kerbal Space Program ‘User successfully launched a satellite in orbit’)?
When an app becomes a key aspect of the course and is selected by the instructor rather than the student, then the instructor should also be able to set up a more closely integrated experience, including grade reporting, possibly adding activities to the course calendar, and so on. Those operations are limited to instructor like roles, and would be covered by a set of OAuth scopes that can only be granted in a context where the user has a non-learner role. Those services could ideally be the LTI services (Outcome, ContentItemService, Membership, ….).
A important aspect from the LTI specifications is that little knowledge of the services end point needs to be known in advance (outside of where to do the LTI launch) as those are injected as launch parameters. To keep that spirit, the Learning App Connect api will use an Hypermedia like API by embedding the services end point the user may access in the result of the initial connect response.
One barrier of entry here is for an app to have to register to all institutions. Possibly the LTI Registration Service could ease the deployment by including it as part of the Tool Proxy (i.e. the deployment contract between the app and the LMS). In that scenario, the LMS Admin would start a registration process, and the Tool Provider would indicate it requires the Learning App Connect flow and the services for which it may ask the user to grant access to. However this still needs an explicit consent from the Institution. Possibly an ad-hoc app mode could allow any app to connect and retrieve a very limited subset of data (i.e. user enrollment) since, in any case, disclosure of that data is explicitly granted by the end user himself.
Another usability issue is for the App to know where to send the Connection request, i.e. which institution the current user should connect to. There could be hundreds of institutions registered (ideally, there would be). One way would be to let the user indicates it by entering the institution name, that might be enough. Also, sometimes, you just want to connect to a given course as quick as possible. What about then a universal course locator that would encode the provider and the course within the provider space?
You can view the mock draft of the API in swagger: https://app.swaggerhub.com/api/claudevervoort-perso/LearningAppConnect/1.0.0
All of this is fictional, and is aimed to serving as an illustration and bring some ideas to discuss whether or not such an integration model would indeed by useful in the ed-tech ecosystem. In a fragmented space, I think it might make sense for the LMS to sometimes let the apps take the front row, and mostly focus on being the glue joining those various experiences…