e-Literate

Present is Prologue

Tag: IMS Global

  • Pedagogical Intent and Designing for Inquiry

    I’ve been asked by several folks to write up some version of the talk I gave at the recent IMS learning analytics summit. The focus was on how, going forward, interoperability standards will need to capture pedagogical intent if we are going to develop meaningful learning analytics.

    This isn’t a word-for-word transcription of that talk, but it does capture the gist. The subtitles and literary quotes are mostly from the original presentation. Many thanks to Rob Abel and Cary Brown for inviting me and giving me the opportunity to speak to the IMS community about this important inflection point.

    Interoperability is communication

    We are not here to curse the darkness, but to light the candle that can guide us through that darkness to a safe and sane future.

    John F. Kennedy

    Ten or fifteen years ago, when we talked about what we wanted from EdTech software interoperability, most of the time the things we wanted seemed like they ought to be simple. Mostly, we just wanted to transfer student roster and grade information from one system to another. When we got a little more ambitious, we asked for single sign-on and the ability to put a little window of one application into another one. This was foundational interoperability. It wasn’t “disruptive” or “revolutionary” or otherwise life-altering, but it was important.

    My first close encounter with an IMS interoperability effort was when I worked at Oracle in on Peoplesoft Campus Solutions team. We just wanted to be able to send a course roster to the LMS and have the LMS send a final grade for each student back. Going in, I couldn’t understand why that was hard or why it hadn’t already been done. All I knew was that (a) it was a problem that IMS had tried and failed to solve at least once before, since we were working on the revision of an existing standard, and (b) a consequence of that failure was that IT professionals on campuses everywhere had to cook up their own, often time-intensive, duct-tape-and-chewing-gum solutions to getting roster data into the LMS. As for grades, it made no sense to me that faculty had to copy grades from their electronic LMS grade book and manually re-enter them into their electronic SIS grade book. It seemed weird that this was a thing.

    It turned out that there was a translation problem. Registrars think about classes very differently than instructors and students do. For a registrar, if a student is taking a “statistics for psychology majors” course, and that course can be taken for credit in either the psychology or the math department, then “statistics for psychology” is actually two completely separate courses. And the decision of which of the two courses a student registers for may make the difference between that student meeting the requirements for graduation or not. On the other hand, the students and instructor experience “statistics for psychology” as one course meeting in one place on one schedule with one syllabus and one group of people.

    Good software reflects and supports the needs and expectations of its users. Accordingly, SIS software represented “statistics for psychology” as two courses, while LMS software wanted to create one course space for it. In order to have roster information show up as instructors and students expect it in the LMS and then return final grades as the registrar expects them in the SIS, the standards committee had to recognize that there was a translation problem and design a specification that could function as a two-way translator.

    This was an important lesson for me. Even seemingly simple interoperability challenges can be complicated because they often aren’t about the software so much as they are about the people who use the software. Interoperability design is at least partly a liberal art.

    Now, today, we would have a different possible way of solving that particular interoperability problem than the one we came up with over a decade ago. We could take a large data set of roster information exported from the SIS, both before and after the IT professionals massaged it for import into the LMS, and aim a machine learning algorithm at it. We then could use that algorithm as a translator. Could we solve such an interoperability problem this way? I think that we probably could. I would have been a weaker product manager had we done it that way, because I wouldn’t have gone through the learning experience that resulted from the conversations we had to develop the specification. As a general principle, I think we need to be wary of machine learning applications in which the machines are the only ones doing the learning. That said, we could have probably solved such a problem this way and might have been able to do it in a lot less time than it took for the humans to work it out.

    I will argue that today’s EdTech interoperability challenges are different. That if we want to design interoperability for the purposes of insight into the teaching and learning process, then we cannot simply use clever algorithms to magically draw insights from the data, like a dehumidifier extracting water from thin air. Because the water isn’t there to be extracted. The insights we seek will not be anywhere in the data unless we make a conscious effort to put them there through design of our applications. In order to get real teaching and learning insights, we need to understand the intent of the students. And in order to understand that, we need insight into the learning design. We need to understand pedagogical intent.

    That new need, in turn, will require new approaches in interoperability standards-making. As hard as the challenges of the last decade have been, the challenges of the next one are much harder. They will require different people at the table having different conversations.

    Data and communication are not the same

    O wonder!
    How many goodly creatures are there here!
    How beauteous mankind is! O brave new world
    That has such people in’t!

    William Shakespeare

    The quote above is from The Tempest. Here’s the scene: Miranda, the speaker, is a young woman who has lived her entire life on an island with nobody but her father and a strange creature who she may think of as a brother, a friend, or a pet. One day, a ship becomes grounded on the shore of the island. And out of it comes, literally, a handsome prince, followed by a collection of strange (and presumably virile) sailors. It is this sight that prompts Miranda’s exclamation.

    As with much of Shakespeare, there are multiple possible interpretations of her words, at least one of which is off-color. Miranda could be commenting on the hunka hunka manhood walking toward her.

    “How beauteous mankind is!”

    Or. She could be commenting on how her entire world has just shifted on its axis. Until that moment, she knew of only two other people in all of existence, each of who she had known her entire life and with each of whom she had a relationship that she understood so well that she took it for granted. Suddenly, there was literally a whole world of possible people and possible relationships that she had never considered before that moment.

    “O brave new world / That has such people in’t”

    So what is on Miranda’s mind when she speaks these lines? Is it lust? Wonder? Some combination of the two? Something else?

    The text alone cannot tell us. The meaning is underdetermined by the data. Only with the metadata supplied by the actor (or the reader) can we arrive at a useful interpretation. That generative ambiguity is one of the aspects of Shakespeare’s work that makes it art.

    But Miranda is a fictional character. There is no fact of the matter about what she is thinking. When we are trying to understand the mental state of a real-life human learner, then making up our own answer because the data are not dispositive is not OK. As educators, we have a moral responsibility to understand a real-life Miranda having a real-life learning experience so that we can support her on her journey.

    Intention matters in education

    With regard to moral rules, the child submits more or less completely in intention to the rules laid down for him, but these, remaining, as it were, external to the subject’s conscience, do not really transform his conduct.

    Jean Piaget

    The challenge that we face as educators is that learning, which happens completely inside the heads of the learners, is invisible. We can not observe it directly. Accordingly, there are no direct constructs that represent it in the data. This isn’t a data science problem. It’s an education problem. The learning that is or isn’t happening in the students’ heads is invisible even in a face-to-face classroom. And the indirect traces we see of it are often highly ambiguous. Did the student correctly solve the physics problem because she understands the forces involved? Because she memorized a formula and recognized a situation in which it should be applied? Because she guessed right? The instructor can’t know the answer to this question unless she has designed a series of assessments that can disambiguate the student’s internal mental state.

    In turn, if we want to find traces of the student’s learning (or lack thereof) in the data, we must understand the instructor’s pedagogical intent that motivates her learning design. What competency is the assessment question that the student answered incorrectly intended to assess? Is the question intended to be a formative assessment? Or summative? If it’s formative, is it a pre-test, where the instructor is trying to discover what the student knows before the lesson begins? Is it a check for understanding? A learn-by-doing exercise? Or maybe something that’s a little more complex to define because it’s embedded in a simulation? The answers to these questions can radically change the meaning we assign to a student’s incorrect answer to the assessment question. We can’t fully and confidently interpret what her answer means in terms of her learning progress without understanding the pedagogical intent of the assessment design.

    But it’s very easy to pretend that we understand what the students’ answers mean. I could have chosen any one of many Shakespeare quotes to open this section, but the one I picked happens to be the very one from which Aldous Huxley derived the title of his dystopian novel Brave New World. In that story, intent was flattened through drugs, peer pressure, and conditioning. It was reduced to a small set of possible reactions that were useful in running the machine of society. Miranda’s words appear in the book in a bitterly ironic fashion from the mouth of the character John, a “savage” who has grown up outside of societal conditioning.

    We can easily develop “analytics” that tell us whether students consistently answer assessment questions correctly. And we can pretend that “correct answer analytics” are equivalent to “learning analytics.” But they are not. If our educational technology is going to enable rich and authentic vision of learning rather than a dystopian reductivist parody of it, then our learning analytics must capture the nuances of pedagogical intent rather than flattening it.

    This is hard.

    Some more examples

    The lesson assessment example is easy enough to understand. (My post series on content as infrastructure explores it in more detail.) But the more one looks around at the full range of analytics that are truly aimed at supporting student success, the clearer the lesson about capturing intent becomes.

    Take, for example, summer melt. I recently just hosted an entire hour-long Standard of Proof webinar on this topic. (You should watch it. It’s good.) Here’s a slide from that webinar which illustrates the obstacles that first-generation students face in getting from their college acceptance letter to the first day of class:

    The Summer Melt Maze

    Credit: Lindsay Page

    Each of the text labels represents an obstacle that first-generation students in particular may struggle to overcome, because their circumstances are complex (e.g., no parent to provide a parental signature), because they don’t have parents or guardians who have the training and knowledge to help them, and/or because they’re seventeen-year-old kids. I don’t know about you, but I don’t think I had to navigate a single one of these obstacles without parental help, and I don’t know if I could or would have done so without it.

    Now think about developing a software solution to identify the specific barrier a student is struggling with and provide appropriate help. Could you solve the problem simply by sucking in enough data and running a machine learning algorithm? I very much doubt it. And even if you could, think about how invasive you would have to be to do so. Think about the privacy implications. The cure would be worse than the disease.

    Georgia State University took a different approach. They have invited students to share their intent. They use a chatbot. A chatbot is a conversational interface. Students can ask directly about the problems they were encountering. Once students specify their intent, then machine learning can be used to further disambiguate it. For example, the software can figure out that a student who writes “I have no money” may be asking for help obtaining financial aid. But only because there is a conversational interface, and because the software behind that interface has been programmed to anticipate and respond to a certain range of questions that a student might come to the chatbot for answers. Through a combination of the interface layer, the data layer, and the usage context, the educational intent was encoded into the system.

    Here’s another example that postdates my talk. ACT recently released a paper on detecting non-cognitive education-relevant factors like grit and curiosity through LMS activity data logs. This is a really interesting study that I hope to write more about in a separate post in the near future, but for now, I want to focus on how labor-intensive it was to conduct. First author John Whitmer, formerly of Blackboard, is one of the people in the learning analytics community who I turn to first when I need an expert to help me understand the nuances. He’s top-drawer, and he’s particularly good at squeezing blood from a stone in terms of drawing credible and useful insights from LMS data.

    Here’s what he and his colleagues had to do in order to draw blood from this particular stone:

    The online interaction features were generated from the LMS clickstream data. After manual inspection, we determined that the action field alone (e.g., “opened”) was insufficient to address our research questions and needed to be joined with the label of the item that the action was taken in reference to, which was a complex pairing. For example, course item values in the LMS data include “Week 12: Electrochemistry” or “CHEM 102 Practice Exam 4B,” which were easily interpretable from the course syllabus, while others (e.g., “2/27 CL” or “18.7 RQ”) required confirmation from the instructor. Hence, we created broader activity categories for these activity events in the LMS data using the course syllabus with confirmation from the instructor which resulted in 110 unique activity events in the LMS data that were recoded to a total of 21 activity categories as described in Table 4.

    First, they had to look at the syllabi. With human eyeballs. Then they had to interview the instructors. You know, humans having conversations with other humans. Then the humans—who had interviewed the other humans in order to annotate the syllabi that they looked at with their human eyeballs—labeled the items being accessed in the LMS with metadata that encoded the pedagogical intent of the instructors. Only after they did all that human work of understanding and encoding pedagogical intent could they usefully apply machine learning algorithms to identify patterns of intent-relevant behavior by the students.

    LMSs are often promoted as being “pedagogically neutral.” (And no, I don’t believe that Moodle is any different.) Another way of putting this is that they do not encode pedagogical intent. This means it is devilishly hard to get pedagogically meaningful learning analytics data out of them without additional encoding work of one kind or another.

    Interoperability without intent creates chaos

    If Jorge Luis Borges’ Library of Babel could have existed in reality, it would have been something like the Long Room of Trinity College.

    Christopher de Hamel

    I want to underscore the point that simply collecting more data and writing more clever algorithms will not help us find a way out of the problem of that last example. It is a problem of epistemic closure. Data and knowledge are not the same, and more data do not necessarily unlock more knowledge.

    “The Library of Babel” is a short story by the great Jorge Luis Borges. (It’s only nine pages long. You should read it.) The story describes a world that perfectly captures the nature of the problem we face:

    The universe (which others call the Library) is composed of an indefinite and perhaps infinite number of hexagonal galleries, with vast air shafts between, surrounded by very low railings. From any of the hexagons one can see, interminably, the upper and lower floors. The distribution of the galleries is invariable. Twenty shelves, five long shelves per side, cover all the sides except two; their height, which is the distance from floor to ceiling, scarcely exceeds that of a normal bookcase. One of the free sides leads to a narrow hallway which opens onto another gallery, identical to the first and to all the rest. To the left and right of the hallway there are two very small closets. In the first, one may sleep standing up; in the other, satisfy one’s fecal necessities. Also through here passes a spiral stairway, which sinks abysmally and soars upwards to remote distances….

    There are five shelves for each of the hexagon’s walls; each shelf contains thirty-five books of uniform format; each book is of four hundred and ten pages; each page, of forty lines, each line, of some eighty letters which are black in color. There are also letters on the spine of each book; these letters do not indicate or prefigure what the pages will say….

    The orthographical symbols are twenty-five in number. This finding made it possible, three hundred years ago, to formulate a general theory of the Library and solve satisfactorily the problem which no conjecture had deciphered: the formless and chaotic nature of almost all the books. One which my father saw in a hexagon on circuit fifteen ninety-four was made up of the letters MCV, perversely repeated from the first line to the last. Another (very much consulted in this area) is a mere labyrinth of letters, but the next-to-last page says Oh time thy pyramids. This much is already known: for every sensible line of straightforward statement, there are leagues of senseless cacophonies, verbal jumbles and incoherences….

    Five hundred years ago, the chief of an upper hexagon came upon a book as confusing as the others, but which had nearly two pages of homogeneous ines. He showed his find to a wandering decoder who told him the lines were written in Portuguese; others said they were Yiddish. Within a century, the language was established: a Samoyedic Lithuanian dialect of Guarani, with classical Arabian inflections. The content was also deciphered: some notions of combinative analysis, illustrated with examples of variations with unlimited repetition. These examples made it possible for a librarian of genius to discover the fundamental law of the Library. This thinker observed that all the books, no matter how diverse they might be, are made up of the same elements: the space, the period, the comma, the twenty-two letters of the alphabet. He also alleged a fact which travelers have confirmed: In the vast Library there are no two identical books. From these two incontrovertible premises he deduced that the Library is total and that its shelves register all the possible combinations of the twenty-odd orthographical symbols (a number which, though extremely vast, is not infinite): Everything: the minutely detailed history of the future, the archangels’ autobiographies, the faithful catalogues of the Library, thousands and thousands of false catalogues, the demonstration of the fallacy of those catalogues, the demonstration of the fallacy of the true catalogue, the Gnostic gospel of Basilides, the commentary on that gospel, the commentary on the commentary on that gospel, the true story of your death, the translation of every book in all languages, the interpolations of every book in all books.

    Jorge Luis Borges

    The rest of the story is a rumination on how humans might make sense of this infinite series of rooms—this “data lake,” in modern parlance—in absence of any information about the intent of its creator.

    Since the Library contains every possible book with that number of pages, lines and characters, somewhere in all these rooms must exist a book that explains exactly what it all means. So it’s a data search problem, right?

    Wrong. Because there also exist books that are extremely similar but differ in minor but critical details. And books that argue why the book with the Truth is actually false. For that matter, there are books that contain many of the exact same words in the exact same order but are written in languages in which the words mean different things. How can one tell which account is the Truth?

    One can’t.

    If we are going to make progress toward educationally useful analytics, then we must ruthlessly expunge all traces of magical thinking about data. There are fundamental limits to what the data can tell us. Even systems that are designed for pedagogical intent do not necessarily encode it in a way that is useful for interoperable analytics. In some cases, it may be encoded at the user interface layer. A courseware authoring platform may never label an assessment as “formative” or “summative” in the data because the intended distinction is obvious to the users. In other cases, the data may be encoded in an idiosyncratic manner that does not map well to other systems (either of software or of thought). In still other cases, it may be designed badly and incorrectly or misleadingly reflect the pedagogical intent. It would be relatively easy to create a data lake of Babel which we could explore infinitely in a fruitless search for meaning.

    That way lies madness.

    If we want useful educational analytics, then we cannot simply worship the data and the algorithms. The humans must do some of the learning.

    The “semantic web” is all about intent

    I love you. You are the object of my affection and the object of my sentence.

    Mignon Fogarty

    One of the triggers for my being invited to speak at IMS about learning analytics in the first place was a previous post I wrote which was (partly) on how the structure of Caliper, which is borrowed from the structure of the semantic web, supports new sorts of interoperability conversations. Since you can read that blog post, I won’t repeat the argument in detail here. But the gist is that we both have to and can boil down chains of inference that combine pedagogical intent into simple human language that educators can understand and articulate for themselves. The triple structure of the semantic web—a simple three-word sentence with a subject, a verb, and a direct object—is designed to enable non-technical humans to string thoughts and inferences together in ways that enable more technical humans to translate those inference patterns into data structures and interoperability requirements.

    Right now, IMS Caliper adopters are largely using this vernacular as just one more IT tool for largely old-school data centralization. So now they use a “lake” instead of a “warehouse.” It’s still a centralized and IT-specialized mindset which is not suited for thinking about making meaning from multiple applications, never mind talking with other humans about interpreting the intent of users working across multiple applications.

    This is the problem that must be solved over the next decade to make real progress on educational analytics. It is at least partly a liberal arts problem. And it will be at least a decade’s worth of work, though we don’t have to wait that long to see early results.

    You get to choose the world we live in

    O wonder!
    How many goodly creatures are there here!
    How beauteous mankind is! O brave new world
    That has such people in’t!

    Shakespeare or Huxley?

    So which will it be? A brave new world in which we experience continuous wonder at how beauteous mankind is, or one in which “learning” is defined by the ability to correctly answer a series of questions and earn some digital badges? The difference between these possible futures is not one in which we embrace or reject technology, or data. It’s one in which we either embrace or ignore the complexity of human learning and the reality that we must make a conscious effort to ensure that some of this complexity is encoded into the data if we are going to design analytics systems that are educationally useful. We need to elicit specific reactions from our students as expert educators and encode the pedagogical intent for eliciting those reactions along with the reactions themselves.

    .The play’s the thing!

    William Shakespeare
  • How and Why the IMS Failed with LTI 2.0

    How and Why the IMS Failed with LTI 2.0

    While at EDUCAUSE last week, we heard from several sources that the IMS is walking away from LTI 2.0. I’m not sure what term the organization is using to characterize what they’re doing; there’s nothing on the public web site that I can find at the moment. But the reality is that they are no longer encouraging the adoption of LTI 2.0 and are actively investing their energy in developing the 1.x branch, starting with something that they’re calling “LTI Advantage.” (More on that in a bit.)

    To be clear, I believe this is a good decision, and I also believe the fact that they felt the need to do so is not particularly scandalous. Everybody makes mistakes. The important thing is to learn from them. So, with that in mind, and with the IMS quarterly meeting coming up this week, I thought it might be useful to write a post-mortem that could potentially be of use going forward.

    Interoperability Standards as Multilateral Trade Deals

    One of the biggest problems the IMS faces is that a lot of the participants on the specification committees don’t fully understand the big picture of how standards adoption works in the real world. They are mostly technologists with a sprinkling of product managers. They usually have the best of intentions. But they do not have the right roles to see the business ramifications of spec development clearly, and they very often do not get adequate guidance from the stakeholders in their respective organizations that do have the right roles.

    First and foremost, interoperability specifications are a lot like multilateral trade agreements. They are agreements that everybody will operate according to certain rules under certain circumstances. The fact that these agreements are written in engineering language and implemented in software code doesn’t change the fact that they are multi-party treaties. One of the major implications that falls out of this circumstance is that organizations will not adopt the standard—or “sign the treaty”—unless they believe the benefits will outweigh the costs. If a specification is going to be broadly adopted, then it needs to be designed so that all the adopting parties will see direct benefit. Remember, every minute of developer time spent implementing a standard could have been spent developing a feature or fixing a bug instead. If their customers don’t care about the benefits of the standard and developers don’t see internal benefits (like reducing the time they have to spend on one-off integrations), then the rational decision for product or project owners is to not implement the standard.

    Such a decision does not mean that all progress grinds to a halt. In the trade world, there are many more bilateral trade agreements than there are multilateral trade agreements. In the software world, the equivalent to a bilateral agreement would be a proprietary integration. Many companies today that want to provide richer integration with another platform—especially with an LMS—will use the multilateral agreement that is LTI 1.x as a baseline and extend it with the bilateral agreements of proprietary integrations. This is as it should be. Not every integration needs to be standards-based. In fact, a lot of innnovation happens beyond the edge of the standard as software developers come up with new ideas about how their products can work together. They hammer out a bilateral trade agreement to get that new idea implemented and to gain a competitive edge for a while. Eventually, enough products may choose to implement the same pattern that it makes sense for everybody to adopt the same way of integrating so that developers don’t have to build slightly different versions of the same integration over and over.

    Interoperability standards, being multilateral trade agreements, are rarely innovative or sexy if they are done right. Once in a while, a working group may come up with a new spin that is generative. But this is always a risky proposition. The technologists and product designers on these working groups, being creative people, want to come up with cool stuff. But “cool” isn’t what drives their employers to adopt. There always needs to be a cost/benefit analysis for each potential adopter. If that analysis doesn’t look good, then no amount of coolness will matter.

    As far as I can tell from the outside, this is precisely what went wrong with LTI 2.0.

    Please Pass (on) the SOAP

    Back in the early days of service-oriented architecture (SOA) in software engineering, everybody was using a complex XML-based protocol called SOAP. The idea was that everybody had data to pass around, and if there were discrete services that could be called for that data, then we could have a lot more interoperability. SOAP was considered secure (or securable, anyway), so it could be used for sensitive data. SOA advocates envisioned a world in which all software provided lots of services for other software to use, creating rich opportunities for interoperability. In fact, they thought there would be so many services that it would be impractical to connect them all up by hand. So they invented something called a service bus that helped each piece of software automagically discover the services available to it from other software in the system and also to offer up its own services to any other software that needed them.

    As you might imagine, this all turned out to be horribly complex and expensive. I happened to work at Oracle at the time that all this peaked, so I had a ring-side seat. The company was selling hugely expensive service management software that was often implemented by hugely expensive consultants. Some of that stuff took off and is in use in some places—usually big IT shops like moneycenter banks. But it never got the ubiquitous adoption that the enthusiasts expected because it was too much work for not enough payoff. There just weren’t that many services to justify the management costs.

    That was roughly ten years ago. Fast forward seven years from then. What is the essence of LTI 2.0? It was essentially an attempt to implement the same idea using the more modern REST style of web programming. It was going to have a strong security model and service discovery. Predictably, it was really hard to implement. A senior development manager from a major LMS vendor—somebody who has been in the industry and involved with the standards process for a very long time—said that LTI 2.0 was by far the most complex standard he’s ever had to implement. If the major LMS providers struggled to implement it, then what are the chances that lots of small LTI-compatible tool makers will implement it? To answer that question, start from zero and subtract a significant number.

    But I don’t think LTI would have had a high chance of success even had it been less complicated, because it wasn’t designed to be a multilateral trade agreement. What problem would a secure service bus with discoverability solve for each of the treaty signatories? The LMS companies do get a clear benefit. For them, many of the customers have LMS systems administrators who spend their days hooking up tools for individual instructors. The LMS gets most of the blame for this situation, not because it’s primarily their fault but because their customers perceive it as a pattern of weakness when they use the product. Automagic integrations would make some of their key stakeholders very happy.

    On the other hand, if you’re a tool vendor, you usually only get blamed for the challenges of one integration: your tool into the customer’s LMS. And even then, the LMS vendor gets most of the heat. At the same time, hardly anybody is passing data to you, and it can be a struggle to even get the LMS vendors to accept the data that you want to give them. So LTI 2.0 offered most tool makers a lot of pain for no obvious benefit.

    The people at the negotiating table for LTI 2.0 were apparently not the right people to negotiate a trade agreement. They were the right people to think of something really cool. For a standard to work, you need the former and want the latter, but only if the people thinking of cool stuff are in close communication with their colleagues who are making the cost/benefit decisions.

    Now, I believe there is an opportunity to get to the cool world that the LTI 2.0 working group envisioned. But to get there, you need to flip the script.

    Services First

    Let’s try another analogy for a moment. In the early days of the telephone, human operators connected every call manually. There was interoperability in the sense that all telephones operated the same way over the network of wires and switchboards, but each individual connection between callers had to be hand-configured. In the early days, that was fine. It made sense. There were few enough callers that it was worth the cost of the operators. But eventually, the number of phone connections grew to the point where hiring humans to manually wire connections was no longer viable for anybody. Call connection times grew, as did service provider costs. At that point it made economic sense to create an automated switchboard.

    LTI 2.0 was an attempt to invent a very fancy automated switchboard at a time when there are still hardly any callers. Once we reach the point where many tool providers are offering multiple data services and, in some cases, also receiving them, then they will see direct benefits from a secure and automated service discovery mechanism. At that point, the negotiations can begin regarding feature richness versus cost of implementation.

    To get there, the IMS needs to flip the script and start by creating a world that is rich enough in services that people need to care more about managing them all. The IMS has made a good (re)start with LTI Advantage, which just adds roster provisioning, grade return, and deep linking to LTI. These are basic hygiene needs. Basically, this means any tool can find out from the LMS who is in the class and what their roles are, which a lot of tools need and is a step up from the way LTI passes user information along now. LTI Advantage can also enable the tool provider to give the LMS links that support single sign-on to specific places within the tool, and it can enable tools to return multiple grades to the LMS. Lots of apps would find these capabilities handy.

    I’ve heard through the grapevine that the next challenge is improving security. Obviously, securing student data is critical. There are a lot of data sharing services that shouldn’t be offered until that security can be guaranteed. (I won’t comment on the security of rostering and grade information in LTI Advantage because I don’t know anything about it, but obviously that is one very sensitive area where schools should be asking questions about security.)

    Once security is in place, the next step beyond that should be to focus on generating enough call connections to keep the switchboard operator busy. I have been arguing for some time that Caliper should be used as a data interoperability exchange standard between apps that operates through the LTI window. This could work for bilateral agreements. For example, let’s say that you want to integrate a blog with an LMS so that posts with a certain tag could be automagically submitted upon publication for a particular assignment. Let’s further suppose that the IMS has not yet developed a standard, a multilateral trade agreement, for that kind of integration. If LTI and Caliper provide tools that make developing that integration easy enough, then the two integrating parties could do the work in the style of an official integration, saving time by drawing on the LTI and Caliper infrastructure that’s already in place. If enough other tool makers become interested in the integration, then it could be submitted for ratification as an official extension of the standard. This only works if designing and implementing a new Caliper profile is easy. But if it’s done right, then we should see the number of services explode.

    At some point, it will become obvious to all parties that they need autodiscovery to manage all these integrations. Then and only then will it make sense to come up with a hopefully simpler implementation of service discovery for the next run at LTI 2.x.

    Open It Up

    To reiterate, the path to getting to the next era of interoperability is to make it easy for many developers to build bilateral integrations that draw on the building blocks of the standards and are easy to incorporate as extensions to the standards. Some of this involves prioritizing the work on LTI and Caliper to make this easy. But it also likely will require the IMS to consider changing its policies in ways that will make some stakeholders uncomfortable.

    A little history is in order here. A bit more than a decade ago, the IMS nearly died. It wasn’t generating enough revenue to sustain the work. While IMS Global is a non-profit, it still has salaries to pay, rent to cover, and so on. Operating it is not free. One of the steps that the organization made to save it from potential insolvency was to put a lot of the work behind a paywall. I don’t like it, but I get it. And it worked. The IMS appears to be much healthier now and has produced some of its best work in a very long time. Life is about trade-offs.

    It may be time to consider a new trade-off. Just like getting the telephone to take off required a network effect—the value of the network increases exponentially with the number of people on it—the value of a world of standards-based services increases exponentially with the number of services on it. To get there, it’s time to at least consider lowering the pay wall. The IMS needs to create an environment with very low barriers to creating standards-compatible integrations. A membership fee, however reasonable it may seem to the membership organization, is a barrier. The IMS leadership should think creatively about how to lower this barrier while maintaining the financial stability of the larger organization.

    The Nub of It

    To sum up, here’s what I think the IMS should do to recover from the LTI 2.0 misstep and foster a step-function change in interoperability:

    1. Promote LTI Advantage and build from there.
    2. Focus next on creating a simple security model that is trustworthy for common use cases.
    3. Focus Caliper efforts on turning it into a quick and easy to use method for creating data interoperability extensions that take advantage of the existing LTI infrastructure.
    4. Make a giant push to get developers to build their bilateral integrations using the LTI and Caliper infrastructure, whether or not they submit those integrations as extensions to the standard. This should explicitly include re-examining policies about giving non-members early access to the work being done inside the IMS in cases where such access will increase the velocity of new Caliper-compatible service generation.
    5. Wait for demand to build on both provider and consumer side before attempting another run at discoverability.
  • The Case for Learning Platform Grade Book

    The Case for Learning Platform Grade Book

    A little while back, I wrote a post reflecting on how close we are to getting a next-generation, modular learning platform and how the next steps in the IMS standards-making process can influence whether and when we might actually see this elusive beast in the wild. Today, I’d like to zero in on what I believe is the next logical step, given the current state of the ecosystem: namely, making LMS grade books fully interoperable with courseware and other ed tech tools.

    No, it isn’t sexy. No, it won’t revolutionize education. But I believe that it will benefit vendors and educators alike in a way that will shift relationships among ed tech tools, reduce wasted effort reinventing the wheel, and open up new design possibilities.

    (more…)

  • Opening Up the LMS Walled Garden

    In yesterday’s post I described where I (and many others) see the LMS market heading in terms of interoperability.

    At the same time, the LMS does a very poor job at providing a lot of the learning technologies desired by faculty and students. There is no way that a monolithic LMS can keep up with the market – it cannot match functionality of open internet tools especially without adding feature bloat.

    I would add that part of the cause of the “false binary position” that D’Arcy points out is that much of the public commentary focuses on where the LMS has been rather than where it is going. There is a significant movement based on interoperability that is leading, perhaps painfully and slowly, to a world where the LMS can coexist with open educational tools, with even end users (faculty and students) eventually having the ability to select their tools that can share rosters and data with the institutional LMS.

    Coexistence and interoperability, however, should not imply merely having links from the LMS to external tools as is too often the case.

    The Walled Garden

    The LMS (which George Station rightly points out was really called the Course Management System in the early years) started out as a walled garden with basic functionality of syllabus sharing, announcements, gradebook, email, and a few other tools.

    walledgarden

    (more…)

  • The IMS Is More Important Than You Think It Is

    I have long argued that the development of technical interoperability standards for education are absolutely critical for enabling innovation and personalized learning environments. Note that I usually avoid those sorts of buzzwords—“innovation” and “personalized learning”—so when I use them here, I really mean them. If there are two fundamental lessons we have learned in the last several decades of educational technology development, they are these:

    1. Building monolithic learning environments generally results in building impoverished learning environments. Innovation and personalization happen at the edges of the system.
    2. There are tensions between enabling innovation at the edges and creating a holistic view of student learning and a usable learning environment. Integration does matter.

    To these two education-specific principles, I would add a general principle about software:

    • All software eventually grows old and dies. If you can’t get your data out easily, then everything you have done in the software will die with it (and quite possibly kill you in the process).

    Together, these lessons make the case for strong interoperability standards. But arriving at those standards often feels like what Max Weber referred to as “the strong and slow boring of hard boards.” It is painful, frustratingly slow, and often lacking a feeling of accomplishment. It’s easy to give up on the process.

    Having recently returned from the IMS Learning Impact Leadership Institute, I must say that the feeling was different this time. Some of this is undoubtedly because I no longer serve on any technical standards committees, so I am free to look at the big picture without getting caught up in the horrifying spectacle of the sausage making (to mix Germanic political metaphors). But it’s also because the IMS is just knocking the cover off the ball in terms of its current and near-term prospective impact. This is not your father’s standards body.

    (more…)

  • The IMS’s New “Caliper” Learning Analytics Interoperability Framework Is Deeply Interesting

    The IMS has announced the initial public release of something they call Caliper, which they characterize as a learning analytics interoperability framework. But it’s actually much, much more than that. In fact, it represents the functional core of something that my SUNY colleagues and I used to refer to as a Learning Management Operating System (LMOS), and is something that I have been hoping to see for eight years, because it promises to resolve the tension between the flexibility of lots of  separately developed, specialized learning tools and the value and convenience of an integrated system.

    Let’s take a peek at the framework to see why I’m so hopeful about this framework. But before we do that, you should fasten your seat belts and strap on your aviator goggles. It’s going to get geeky in here.

    (more…)

  • OER and Standards

    Speaking of that $2 billion initiative by the U.S. Departments of Labor and Education that everybody is buzzing about, it turns out that, not only does it mandate a license for the educational resources it funds (CC-BY), it also mandates an interchange format. Namely SCORM. Rob Abel, CEO of IMS, has posted a long rant about why he thinks this is a bad idea. I don’t endorse all of Rob’s criticisms of SCORM, but I strongly agree with the point that SCORM and IMS Common Cartridge (the other main contender for a standard educational content interchange format) have substantially different affordances that are appropriate for substantially different use cases.

    I understand why the Federal government wants to mandate a particular standard for content reuse, but I think it’s a mistake in this case. Educational content re-use is highly context-dependent, which means that no one standard is going to support all or even most of the relevant use cases. There will be times when SCORM is the best, times when IMS Common Cartridge is the best, times when RSS/Atom is the best, and times when just plain old HTML is really all that you need. Imposing a SCORM requirement for all resources will substantially increase the labor involved in producing them without necessarily bringing a payoff. The likely result will be fewer grantees will produce OERs and fewer of the OERs produced will be re-used.

    The better thing to do would be to require that grantees include in their proposal a plan for promoting re-use, which would include the selection of appropriate format standards.