Please Don't Bash the Aggregator
The Internet is made up of a bunch of disaggregated units that we call web sites or apps. Every unit can provide its own diversity of opinion, tone, arguments, activities, etc. Each unit has its own strategy for styling and interaction, its own bugs and awesomeness, its own security policy and often its own terms of use. Each unit can be physically situated anywhere in the network (the idea that we need everything in "the cloud" is really just based on corporate convenience). We typically use one of four popular rendering engines to access the loosely-connected units, and it's all kicked off by typing an obscure code into an empty text box. It's actually kind of a miracle that anything meaningful ever happens there.
Nobody exclusively uses the disaggregated Internet. If you're using browser bookmarks or a feed reader or an LMS or email or a search engine or social network then you're using at least one of what I'm calling an aggregator. Aggregators collect items either automatically, or based on user input, and group them in a way that makes it easier for the user to handle.
A completely disaggregated Internet would have every person with their own web site for which you would punch in their unique address to check in with or communicate with them. There is nothing inherently wrong with strong disaggregation, I'm actually a big fan of it. In my mind I envision everyone's home router having a built-in web server with their own Dropbox, Calendar, etc. (I think that'll be the next great evolution of the Internet, but now I'm getting off-topic).
The problem with a completely disaggregated Internet is that, by itself, the motivation to access any one unit is relatively low. I like Bob, but I really don't need to see what's going on in his life or check if he's messaged me all that often, so I'll probably only visit his disaggregated unit of the Internet when he tells me there's something waiting for me there. Now if I lump Bob, Fran and my other coworkers together, the motivation to check for communication with them *as a group* becomes more valuable. So we figure out a way to aggregate all of our interactions into one web site. Many web sites work as internal repositories, collecting items crafted or imported by site users and presenting them for other users to see. These internal aggregators are what I'm calling silos. Silos act primarily on the assumption that what you want is on the current web site, you don't need to go somewhere else to find it (they also typically underserve some percentage of their users by catering to the massive majority).
The LMS is traditionally seen as a silo. Instructors build learning resources, start discussions, distribute assessments, etc. inside a single web site. Learners use the web site because they have no choice if they want to graduate, and spend hours learning to navigate an interface that they'll never use again once they're done with school. The inherent bias of "everything important in a single place" discourages discovery outside the LMS and prevents the learner from getting comfortable with the disaggregated power of the Internet. It also discourages experimentation by instructors because they are stuck with whatever features their particular LMS deems valuable. One strong argument for this silo model is its convenience for the institution.
And hey, if you want to bash the LMS as a silo I'm all for it, I'll stand next to you and join in. But we do a disservice if we pretend that the LMS story stops there. We need to look at the alternatives to the LMS as a silo. Some teachers say just ditch the LMS and use your own disaggregated web site with a couple other modern web tools linked up. I ask them about cognitive load for the learner, having to jump around to all those different web sites and logins. Some tell me it hasn't been a problem for their web-native learners. That's cool for them, but the learners I talk to hate -- like really HATE -- jumping around the web trying to remember where their homework or lecture slides are. And maybe if you had only one instructor doing the disaggregate thing it could work, but with a full courseload of web-hopping I'd get stabby too. Learners pine for an aggregator. So do administrators, for very different but justifiable reasons. Instructors do too, it turns out. Learners submitting homework on their personal blogs is great until you have to start pasting URLs and switching tabs to get it all graded with feedback. So we circle back to the LMS silo, as if silo is the only way to get aggregation.
http://www.educause.edu/visuals/shared/er/extras/2014/ReclaimingInnovation/default.html
Un-siloed aggregation isn't impossible, of course. We need to do a better job of teasing apart the aggregator and the silo, because they don't have to be the same thing even though sometimes they are. Silos are self-referencing, internal aggregators (Facebook, AOL, LMS, etc.) but there are also great external aggregators (feed readers, search engines, etc.) that collect without lock-in. Email is probably the best example of external aggregation. I can host my email on any number of services or run my own, and there's a well-defined protocol for notifying other units of a new item that may be of interest to them (email is slightly different in that the actual item gets passed around, not a link or snippet). An external aggregator is a jumping-off point that gives a higher-level view without trying to force lock-in, and the LMS, it turns out, can be a powerful external aggregator.
When we started Instructure almost seven years ago we'd been thoroughly indoctrinated by David Wiley, Jared Stein and company on the merits of disaggregation. We started our LMS by drawing everything up completely user-centric and disaggregated (e.g. Google Spreadsheets or equivalent for the gradebook, SurveyMonkey or equivalent for the quizzes, etc.), then looking at what made the most sense to pull back in for the sake of user experience. Everything that got folded back in was done in a way that it could be swapped for an alternative if desired. We splattered the site with RSS feeds (and RSS aggregators), notification policies, URL submissions and user-defined connections. We made it easy to pull in or link to other web sites, and when we discovered LTI we kind of went crazy implementing the heck out of it. We built a whole bunch of integration points that, while they weren't showing up on RFPs, were still the right thing to do.
We were trying to build an LMS as an aggregator. A jumping-off point for the rest of the web. A learning platform -- not "platform" the "open"-like buzzword that at this point just means "thing on the Internet", but "platform" the jumping-off point and a place to get an idea of what's going on in at a higher level. I'd say we've had mixed degrees of success making Canvas a learning platform. Some parts of Canvas are still too locked-in for my liking (and I'm excited for the potential of xAPI and Caliper), but in general it's the best example I've come across for learning aggregation.
Incidentally that's also why we've pushed so hard for LTI. LTI is an integration standard, and while the UX of launching third-party apps from a consistent wrapper is nice, the real value is in not having to log in to or paste the URL for another web site as a disruption of the learning flow, and in being able to pass useful information back to the aggregator. Two-way communication, just like the Canvas APIs.
Nobody exclusively uses the disaggregated Internet. If you're using browser bookmarks or a feed reader or an LMS or email or a search engine or social network then you're using at least one of what I'm calling an aggregator. Aggregators collect items either automatically, or based on user input, and group them in a way that makes it easier for the user to handle.
Disaggregation Pros and Cons
 |
| Disaggregation is an unsung hero of the web. |
The problem with a completely disaggregated Internet is that, by itself, the motivation to access any one unit is relatively low. I like Bob, but I really don't need to see what's going on in his life or check if he's messaged me all that often, so I'll probably only visit his disaggregated unit of the Internet when he tells me there's something waiting for me there. Now if I lump Bob, Fran and my other coworkers together, the motivation to check for communication with them *as a group* becomes more valuable. So we figure out a way to aggregate all of our interactions into one web site. Many web sites work as internal repositories, collecting items crafted or imported by site users and presenting them for other users to see. These internal aggregators are what I'm calling silos. Silos act primarily on the assumption that what you want is on the current web site, you don't need to go somewhere else to find it (they also typically underserve some percentage of their users by catering to the massive majority).
The LMS vs. Disaggregation
 |
| Walled gardens are no fun. |
And hey, if you want to bash the LMS as a silo I'm all for it, I'll stand next to you and join in. But we do a disservice if we pretend that the LMS story stops there. We need to look at the alternatives to the LMS as a silo. Some teachers say just ditch the LMS and use your own disaggregated web site with a couple other modern web tools linked up. I ask them about cognitive load for the learner, having to jump around to all those different web sites and logins. Some tell me it hasn't been a problem for their web-native learners. That's cool for them, but the learners I talk to hate -- like really HATE -- jumping around the web trying to remember where their homework or lecture slides are. And maybe if you had only one instructor doing the disaggregate thing it could work, but with a full courseload of web-hopping I'd get stabby too. Learners pine for an aggregator. So do administrators, for very different but justifiable reasons. Instructors do too, it turns out. Learners submitting homework on their personal blogs is great until you have to start pasting URLs and switching tabs to get it all graded with feedback. So we circle back to the LMS silo, as if silo is the only way to get aggregation.
http://www.educause.edu/visuals/shared/er/extras/2014/ReclaimingInnovation/default.html
Learning Aggregation
 |
| My favorite aggregator, RIP :-( |
When we started Instructure almost seven years ago we'd been thoroughly indoctrinated by David Wiley, Jared Stein and company on the merits of disaggregation. We started our LMS by drawing everything up completely user-centric and disaggregated (e.g. Google Spreadsheets or equivalent for the gradebook, SurveyMonkey or equivalent for the quizzes, etc.), then looking at what made the most sense to pull back in for the sake of user experience. Everything that got folded back in was done in a way that it could be swapped for an alternative if desired. We splattered the site with RSS feeds (and RSS aggregators), notification policies, URL submissions and user-defined connections. We made it easy to pull in or link to other web sites, and when we discovered LTI we kind of went crazy implementing the heck out of it. We built a whole bunch of integration points that, while they weren't showing up on RFPs, were still the right thing to do.
We were trying to build an LMS as an aggregator. A jumping-off point for the rest of the web. A learning platform -- not "platform" the "open"-like buzzword that at this point just means "thing on the Internet", but "platform" the jumping-off point and a place to get an idea of what's going on in at a higher level. I'd say we've had mixed degrees of success making Canvas a learning platform. Some parts of Canvas are still too locked-in for my liking (and I'm excited for the potential of xAPI and Caliper), but in general it's the best example I've come across for learning aggregation.
Incidentally that's also why we've pushed so hard for LTI. LTI is an integration standard, and while the UX of launching third-party apps from a consistent wrapper is nice, the real value is in not having to log in to or paste the URL for another web site as a disruption of the learning flow, and in being able to pass useful information back to the aggregator. Two-way communication, just like the Canvas APIs.
Comments