To leave a comment you must sign in.
Please login or create a Web Account.Forgot your username or password?
Create a Web Account:
In the physical world, it goes without saying that not all classrooms look the same. A room that is appropriate for teaching physics is in no way set up for teaching art history. A large lecture hall with stadium seating is not well-suited to a small graduate seminar. And even within a particular class space, most rooms are substantially configurable. You can move the chairs into rows, small groups, or one big circle. You can choose to have a projection screen or a whiteboard at the front of the room. You can bring equipment in and out. Most of the time, we take these affordances for granted; yet they are critical factors for teaching and learning. When faculty members don't have what they need in their rooms, they tend to complain loudly.
The situation is starkly different in most virtual classrooms. In the typical Learning Management System (LMS), the virtual rooms are fairly generic. Almost all have discussion forums, calendars, test engines, group work spaces, and gradebooks. (The Edutools Web site lists 26 LMSs that have all of these features.) Many have chat capabilities and some ability to move the chairs around the room using instructional templates. (Edutools lists 12 products with these additional capabilities.) Beyond these common features, LMSs tend to differentiate themselves with fine-grained features. Does the chat feature have a searchable archive? Can I download the discussion posts for offline reading? These features may be very useful but they are also fairly generic in the sense that they are merely enhancements of general-purpose accoutrements that already exist. Our virtual classrooms may be getting smarter, but they are still pretty much one-size-fits-all. They aren't especially tailored to teach particular subjects to particular students in a particular way.
This is not as it should be. Virtual classrooms should be more flexible than their physical counterparts rather than less so. Do you teach art history? Then you need an image annotation tool. But probably a different one than the image annotation tool needed to teach histology. Foreign language teachers may want voice discussion boards to check student accents. Writing teachers should have peer editing tools. History teachers should have interactive maps. And so on.
Granted, some of these applications exist today and can be included in an LMS. But there are not nearly as many of them as there can and should be. We contend that the current technical design philosophy of today's Learning Management Systems is substantially retarding progress toward the kind of flexible virtual classrooms that teachers need to provide quality education. In order to have substantial development of specialized teaching tools at an acceptable rate, LMSs need to be designed from the ground up to make development and integration of new tools as easy as possible. In the remainder of this article, we will make the case that specialized teaching tool development is, in fact, radically slower than it ought to be. We will propose reasons for this evolutionary logjam, suggest LMS design qualities that would break it, and provide guidelines that technical and non-technical stakeholders within an organization can use together to help select an LMS that is designed for a future in which the virtual chairs are unbolted and teachers have control over their teaching environments again.
Opening the Floodgates
There are several different ways that software can be designed for extensibility. One of the most common is for developers to provide a set of application programming interfaces, or APIs, which other developers can use to hook into their own software. For example, Blackboard provides a set of APIs for building extensions that they call "Building Blocks." The company lists about 70 such blocks that have been developed for Blackboard 6 over the several years that the product version has been in existence. That sounds like a lot, doesn't it? On the other hand, in the first five months after Google made the APIs available for Google Maps, at least ten times that many extensions have been created for the new tool. Google doesn't formally track the number of extensions that people create using their APIs, but Mike Pegg, author of the Google Maps Mania weblog, estimates that 800-900 English-language extensions, or "mash-ups," with a "usable, polished Google Maps implementation" have been developed during that time—with a growth rate continuing at about 1,000 new applications being developed every six months. According to Pegg, "There are about five sites out there that facilitate users to create a map by taking out an account. These sites include wayfaring.com, communitywalk.com, mapbuilder.net—each of these sites probably has hundreds of maps for which just one key has been registered at Google." (Google requires people who are extending their application to register for free software "keys." Perhaps for this reason, Chris DiBona, Google's own Open Source Program Manager, has heard estimates that are much higher. "I've seen speculation that there are hundreds or thousands," says DiBona, noting that estimates can vary widely depending on how you count.
Nevertheless, even the most conservative estimate of Google Maps mash-ups is higher than the total number of extensions that exist for any mainstream LMS by an order of magnitude. Here are just a few examples of Google Maps mash-ups that could be useful for teaching various subjects:
History, Geography, and Demographics
Even this cursory list shows that something different is happening here regarding the pace of extension development and the variety of projects. And Google Maps isn't the only example of a product that has experienced such an explosion. eBay, for example, has constructed an entire directory of tools—both free and for-pay—that use their APIs. And the Quick Online Tips weblog lists over 130 tools that use the Flickr APIs, which are less than two years old.
What is going on here? Why can't we see the same pace of development for extensions to our virtual classrooms?
Learning Affordance Management
Viewed from a traditional perspective of the nature of learning environments, there is something odd about the list above. Some of these mash-ups fall into the category of what we would traditionally consider to be learning objects. For example, map-based displays of historical hurricane or earthquake data are pretty standard fare. Other mash-ups, however, look more like learning applications than learning objects. Frappr, a service that lets participants map their own locations (or anything else they please), provides no content at all; it is purely a mapping tool. Still others fall somewhere in the middle. Is a highly interactive game a learning object or a learning application? How about a tool that dynamically maps the locations of events from a news feed? And what happens when you take a largely content-focused Web page, such as a map of locations hit by an earthquake, and allow other people to update it with personal pictures and reports?
This definitional problem is not just limited to Google Maps, either. This Merode Altarpiece page created in Flickr by FIT History of Art professor Beth Harris and her students is a good example of the same conundrum in a different domain. What is the learning object here? Or, to put it another way, what is the locus of educational value? Is it the picture itself? Is it the picture plus the comments of the students? Or is it both of these plus the action potential for students to continue to exchange ideas through the commenting system? A learning object-centric view of the world would place the emphasis on the content, ignoring the value of the ongoing educational dialog as something extraneous. But that view clearly doesn't allow us to encapsulate the locus of educational value in this case. Sometimes people will try to fudge the difference by tacking the word "interactive" in front of "learning object." This obscures the problem rather than solving it. "Object" is just a longer word for "thing." It inherently focuses on artifacts rather than activities. It emphasizes content to be learned rather than the actions on the part of students that lead to learning.
To take a more familiar example, consider the spreadsheet. What is it that you share when you email a spreadsheet to a colleague? Is it the content, the interaction potential, or both? Are you simply sharing a "tabular data object," or is the potential for the recipient to plug in new data and get new results an inextricable part of the thing we're calling a "spreadsheet?" There is no one right answer to this question; it is entirely context-dependent. Sometimes what we mean by "spreadsheet" is a set of completed calculations and how they were derived. In this case, content is king. However, at other times a "spreadsheet" means a tool for plugging in new numbers to make calculations and run "what-if" scenarios. Sometimes its locus of value is as a "tabular data object," sometimes it is as a "tabular data-processing application," and sometimes it is as an inextricable fusion of the two.
So what is the distinction between a learning object and a learning application? What is the difference between the domain of content (and therefore content experts) and the domain of functionality (and therefore programming experts)? We contend that there is no clean separation of concerns. The world does not divide neatly between functionality packages that can be integrated as Blackboard Building Blocks or WebCT Powerlinks on the one hand, and self-contained content packages that can be tied up in a bow and listed in MERLOT on the other hand. The division between learning objects and learning environments is a false dichotomy. Students need both the functionality and the content—the verbs and the nouns—in order to have a coherent learning experience. They learn when they do things with information. They discuss paintings. They correlate news with its location in the world. They run financial scenarios in a business case study. Consequently, managing the learning content or managing the learning environment in isolation doesn't get the job done. We need to manage learning affordances. We need to focus on providing faculty and students with a rich array of content-focused learning activities that they can organize to maximum benefit for each student's learning needs.
This is consistent with an instructional design worldview that Stephen Downes and others have been calling "e-Learning 2.0." As Downes recently wrote in eLearn:
What happens when online learning ceases to be like a medium, and becomes more like a platform? What happens when online learning software ceases to be a type of content-consumption tool, where learning is "delivered," and becomes more like a content-authoring tool, where learning is created? The model of e-learning as being a type of content, produced by publishers, organized and structured into courses, and consumed by students, is turned on its head. Insofar as there is content, it is used rather than read.
The notion of learning objects doesn't disappear entirely; but it becomes a lot less important because learning objects play a very different role. The emphasis shifts from learning objects to learning actions.
The e-learning application…becomes, not an institutional or corporate application, but a personal learning center, where content is reused and remixed according to the student's own needs and interests. It becomes, indeed, not a single application, but a collection of interoperating applications—an environment rather than a system.
Viewed from this perspective, any Learning Management System with only 50 or 100 extensions (which is all of them, at the moment) is severely impoverished. It's possible that we need as many different extensions to the learning environment as there are learning activities. We need hundreds or thousands or even hundreds of thousands of them (depending on how you define them). In order to achieve this ambitious goal, we need to think differently about how we design and evaluate our LMSs.
The challenge of evolving a software application from a fairly static system that is only extensible by developers to one that is highly extensible by users is by no means unique to Learning Management Systems. In fact, as internet entrepreneur Joe Kraus points out, it is exactly the evolutionary path that spreadsheets took:
Before Excel existed, if you wanted to build a financial app, it was just like Web-based programming today: You had to find an expert. Obviously, spreadsheets existed before VisiCalc, but they were on chalkboards or whiteboards, and it was a bitch. You erased and penciled in, and if you wanted to make an electronic version, you had to get a Cobol programmer, wait six months, and then get back something that usually wasn't quite right.
As a result, you didn't do many electronic spreadsheets: They were silver bullets that you fired infrequently. But when Excel came along, it enabled end-users to do what had previously been the realm of high priests. And it enabled another class of programmer—a less technically skilled programmer—to do even more interesting things. End-users could do basic stuff—put things in rows and columns or cells and maybe do some formulas—while another level of programmer (for example, a financial analyst) could do macros and crazy stuff. When this happened, a thousand million billion spreadsheets bloomed. So Excel lowered the barriers to creating financial applications.
We need an Excel-like makeover of the LMS in order to similarly lower the barriers to creating educational applications.
The traditional objection to this vision by IT departments is that Excel is desktop personal application whereas an LMS is a server-based enterprise application. Providing end users with the ability to customize a mission-critical application that tens of thousands of people could be using every day is not practical, the argument goes. A system can be either optimized for scalability and availability or for easy customization by teachers, but not both. We contend that this is another false dichotomy.
So does Joe Kraus. He and his business partner Graham Spencer, both co-founders of the Excite search engine, have based their new company, JotSpot, on the proposition that they can provide a hosted internet application to the masses that is optimized for end-user customization. They call it an "application wiki." Says Kraus:
I want to do for collaborative Web-based applications what Excel has done for financial applications…. When you look at the Web today, you'll see that Web-based applications are still kind of hard: You don't do many of them, and you certainly don't do them casually. But when you take an Excel spreadsheet and make a database out of it—putting things in cells that aren't formulas such as vendor lists and partner lists—and then e-mail that spreadsheet to people, you're doing DIY application publishing and you don't even know it. You've built an app (the Excel spreadsheet); you've published it (in this case over e-mail)—and you're doing something that you could do much more efficiently if you had the right tools.
I really believe that JotSpot's mission over time is to transform Web-based applications the way that Excel has transformed financial apps. We want to enable end-users to build these ad hoc, one-time-if-necessary Web-based apps. And we want to enable a lighter-weight class of programmers to do a lot more than they ever could before.
As one example, we'd like an HTML person to be able to build a relatively complicated recruiting application—fully featured—that he or she could then resell on top of JotSpot. And this is just one of the many applications that could be built on top of JotSpot in a prepackaged way.
Kraus' description of his vision for JotSpot is uncannily close to the way that we think Learning Management Systems should work. He clearly believes it is possible to provide end users (or teachers and learners, in our case) with a huge amount of flexibility to build new learning affordances—which he calls "tinkerability"—on top of a stable application base designed to support many simultaneous users. And Jotspot is hardly the only company that is thinking this way. In addition to the Maps API, Google provides tinkerable programming interfaces to its chat application, its personalized home page, its desktop search program, its advertising tools, and of course, the search engine itself. Yahoo! provides similar APIs and has recently been on a buying spree, snatching up tinkerable internet sites such as Flickr and del.icio.us. This trend, sometimes called "Web 2.0," is manifest in just about every hot new Web site on the internet. JotSpot's vision merely represents the distillation of this trend.
We need a Web 2.0 LMS. A tinkerable LMS. An LMS for a mash-up world. The technological capabilities exist to create one. But in order to get it, we have to ask for it. LMS developers, whether Open Source or proprietary, will not prioritize tinkerability as a core design value unless they know that institutions will be evaluating candidate systems on that value. And institutions can't do that unless they have some concrete tinkerability evaluation criteria.
Unfortunately, evaluating tinkerability isn't easy. To begin with, we don't yet have many good models of radically tinkerable LMSs to use as benchmarks. (Of the current crop on the market, Moodle probably comes the closest.) The number of extensions currently in existence for a given platform is not necessarily a good benchmark because many of them may have been created by vendors using professional programmers. So all you learn is the degree to which vendors believe there are enough potential customers to justify their development expenses. And finally, there are different ways to achieve tinkerability, with success often the result of a number of factors together rather than just one or two.
That said, there are ways to assess the degree to which an LMS is well-suited for grassroots extension by teachers. All of them require actual teachers and learners to be involved in the evaluation process in one way or another. IT staff, CIOs, and CFOs cannot make these evaluations in isolation. Tinkerability is in the eye of the tinkerer, and in this case the tinkerers who matter are the faculty, instructional support staff, and students.
Here are a few measures that your organization can use:
These measures aren't perfect, but they should give you a clearer sense of how likely it is that the LMS will grow at Google Maps-like speeds. Right now, most LMS vendors and Open Source projects are not prioritizing tinkerability, so expect scores to be low.
We started this article by contending that the chairs in our virtual classroom are bolted to the virtual floors. This metaphor radically understates the case, partly because it reinforces false distinctions between learning environments, learning objects, and learning activities. It is this last category—the vastly rich variety of critical learning interactions between students, their teacher, each other, and the world—that we should care about when we choose our online learning platforms. Every class can be seen as a series of genre moments. There is the moment in the Art History class when the students discuss some detail of a painting. There is the moment in the business school class when a student must report the best and worst case financial scenarios for a given course of action. There is the moment in the creative writing class when students are asked to write about a particular place. The ideal online learning platform enables us to reproduce these genre moments and create new ones. But that will only happen when the platform is designed such that teachers and learners can shape it to their own needs. And that, in turn, will only come to pass if organizations demand it.
To leave a comment you must sign in.
Please login or create a Web Account.Forgot your username or password?
Create a Web Account: