One of the thrilling features of the Iron Man movies is the idea that Tony Stark can step into a mechanized robot suit and control it as if he were just moving his body naturally. The suit is expertly designed to understand his movements in real time and seamlessly amplify them to give him superhuman powers. The promise at the heart of the Iron Man suit is one of harnessing the immense power of technology without having to “speak the language of” the technology– the expectation that machines should just know what we want to do and support us effortlessly in doing it.
We expect learning and collaboration software to perform like the Iron Man suit– to support the many different ways we could choose to use our bodies (or our minds and hearts!) and to facilitate those activities. Taking an offline task like teaching and trying to perform the same actions through a learning management system often feels clunky, frustrating– like dancing in a medieval suit of armor.
In the real world, it’s easy to look around a room and see everyone’s faces, look them in the eye, and talk to them naturally. In online ed that same action requires a dedicated video chat system, a webcam, a microphone, a fast connection, a license for more than 10 people, blah blah blah.
In the real world, getting everyone to look at the same document at the same time is simple– when you’re online, you have to evaluate which collaborative document platform can integrate with your LMS, support annotation, allow file uploads, work on all platforms, blah blah blah.
“Sorry, sir. That Maneuver is Not Supported”
Often, software tools are developed to solve a specific problem under a specific set of conditions called a “use case”. These use cases are always tightly focused and seldom match the full range of actions we could take in the real world outside of the software. Instead of the “do it all” Iron Man suit, we end up with a suit for walking with an attachment to make it a flying suit, another to add shooting capabilities, a “turning your head” plugin, and so on. The result, much to the frustration of the average faculty or student, is that we have a huge collection of tools to choose from that all do mostly the same thing with slight variations, and it’s hard to tell which to use when. Each additional feature comes with its own additional cost, terms of service, interoperability issues, etc.
Users grow frustrated because actions that should be simple, like share a document with a group of friends and highlight relevant passages, are not always easy to do in whichever tools they’re given to use. This problem is especially limiting in top-down technology environments where end users are not free to install, purchase, or integrate the tools they need in response to new challenges.
This limitation of users’ abilities can take on political significance when they are not free to express their full range of thoughts or emotions within your software ecosystem. The classic example is Facebook, which famously lets you “like” things but does not give you an equivalent button to “dislike” it or express other emotions. What activities are your users not free to engage in because they don’t have the appropriate tools?
The practice of “app smashing” arose as a way of stringing together several limited-use iPad apps into one long workflow that allows you to accomplish the task you’re trying to achieve. This can get expensive if the apps you need to accomplish your workflow each come with additional costs. App Smashing is a new name for an old practice– desktop platforms like Mac, Windows, and Linux have long supported free and cheap single-use applications to accomplish mundane tasks like cropping photos, converting files, or recording audio, and they’re designed to let different apps share files between them (fairly) seamlessly. Open source platforms like Firefox, WordPress, Chrome, and Moodle offer a basic platform that can be extended to meet any use case through a standard format of interoperable plugins. In so doing, it frees users to add features as their individual needs change.
Small Parts, Loosely Joined
This fundamental disconnect– between human beings who can adapt to novel situations and software that can’t– is a great argument for choosing cheap, open, and interoperable tools over big systems that claim to “do it all”. As much as many IT staff and university administrators might like to just buy one integrated system that does everything everybody wants all the time (like an Iron Man suit), I’ve never seen such a technological marvel in the real world. More often, I see creaky, EXPENSIVE, medieval suits of armor that don’t move the way people move.
The enduring geek principle of “small pieces loosely joined” is central to the most effective edtech tools I know of. FromWordPress and its dizzying ecosystem of plugins to Google’s suite of interoperable collaboration tools, to the web itself– you want to make it cheap and relatively easy to add any feature you need to your software “suit”, recreating your inherent, natural abilities offline, online.
When you’re looking for new education/collaboration technology, you may get hung up on asking “what features does it have?” Instead, ask “what integrations are possible?” “What is the app ecosystem that works with this technology?” Does this software play nice with open interoperability standards like IMS Common Cartridge, Tin Can API, SCORM, LTI?
The dream of an edtech ecosystem that can nimbly amplify our every action to the maximum effect may remain an ideal (for now), but I’m excited after reading Michael Feldstein’s description of the IMS’ Caliper system, a “Learning Management Operating System” that allows unrelated tools to share data seamlessly around a central brain, like the various motors and servos in Tony Stark’s suit. My hope is that we’ll be able to invest less money in a central LMS that supposedly “does it all”, and instead spread investments over a broader range of cheap, interoperable, single-use tools that fit more of us like a glove.
Liked this post? Follow this blog to get more.