Now we begin to get into some of the meatier topics when it comes to evolving from the world of today to next generation digital learning environments.
One of the challenges of even envisioning, much less implementing, a configurable constellation of educational apps (see previous post in this series on metaphors) is the notion that potentially “everything is connected to everything else.” How does that scale? I will consider the scale issues in a later post. But, for now, let’s just consider the interoperability needed to enable next generation digital learning.
It is very tempting here to elucidate the various types of products, functions and services that must come together in the delivery of an institutional education experience. Indeed I have often gone down that road for the sake of making the discussion very tangible. Shown here is a figure from the precursor paper to the NGDLE, A New Architecture for Learning, along those lines.
Another, more detailed treatment along these lines, has been published by IMS member SURF of the Netherlands. The paper, entitled, “A Flexible and Personal Learning Environment,” is a really great survey of ideas and realities from a functional (“components”) perspective.
For this post I am going to take a different perspective, namely looking at the anatomy of the interoperable educational or learning app. If you’re into legos than this is akin to thinking about how the legos connect to enable personalized learning environments.
For this “app-centric” view I offer the following figure depicting the potential anatomy of an interoperable educational or learning app:
The view shown here is informed by numerous insights from many years of IMS members working on many, if not all, aspects of this challenge. However, it is also flavored by the “dimensions” enumerated in the Next Generation Digital Learning Environment research paper, namely:
- Analytics, Advising, and Learning Assessment
- Accessibility and Universal Design
Ignoring the detailed information on inputs and outputs for a moment, the following overview statements apply to the figure:
- An “app” is different than “content” in that content does not process inputs or outputs, while an “app” does
- While not required, an app can “mash-up” other educational apps and content using the same structures shown (note the reference to mash-up per the NGDLE research paper: “If the paradigm for the NGDLE is a digital confederation of components, the model for the NGDLE architecture may be the mash-up. The confederation-based NGDLE will be mashed up at both the individual and the institutional levels, as opposed to consortia forming to create open enterprise applications.”)
- An app may also produce content or app launch links that can be mashed-up into other apps
- An app does not necessarily support all of the inputs, outputs or management interfaces shown – only those required for what it supports
- An app typically has a web back-end as well as a web or mobile client, however, some apps may be mobile only
What can be mashed up? Again, mash-up support is not required but if supported enables an app to leverage the ecosystem of interoperable apps and content. Based on IMS experience we see three categories of mash-up:
- App interoperability: For example an app launched and integrated using LTI.
- Assessment interoperability: For example assessment items using QTI. Assessment items and tests are a very important and specialized category of content in education and learning that merits a specialized language for interoperability.
- Content & app manifest interoperability: For example common cartridge or thin common cartridge. A “manifest” is a list of the assets, some of which may be available locally and some of which are web accessible. Note that both varieties of common cartridge support LTI app launch links.
It is also worth noting the reference in the figure to “IMS App SDK and APIs.” While it is not the official or even necessarily majority view of IMS members that IMS will ever have a production-worthy developers kit, it is my own personal view that this is the direction that makes most sense for enabling high levels of interoperability and cost reduction. It is also an extrapolation of what is occurring in most IMS spec areas, namely development of APIs, code libraries, sample code, etc.
Again, the above is my attempt an interoperable app definition that we are building towards to enable the NGDLE. We have seen over and over again that the evolution will take time and respond to market needs.
Next up in the series I will explore more explicitly how the interoperability features shown in the Interoperable App Anatomy support the NGDLE dimensions, including some potential ramifications on the enterprise apps required.