Supporting Social Learning Around Collections of Open Educational Content: Open Learning Support

David Wiley and Brent Lanbert presented this overview of the Open learning Support system at the ITI conference in Logan, Utah. Essentially, the system is a mechanism for attaching discussions lists to learning resources, and in particular (to this point) the resources offered by the Open Courseware initiative. What's interesting is the degree to which they have focused on developing a simple and modular discussion system.

David: Learning should be social. But in learning, especially online learning, there are forces pushing against this. For example, teachers and tutors are expensive. How do you scale? People say, if we could just get more data down the pipeline. But the real bandwidth is teaching. How do we address this? We pull the teacher out. We create automatic quizzes. Teacher functions are automated. This is a broad movement - this is where all the learning object, SCORM and standrds people are going, to automate learning.

But have you ever had a problem with tech support? If you get an automated system - how many people choose the automated response over a live support person? If you'd rather talk to a human rather than an automated system, why would you assume that other people wouldn't?

Another focus or push we see is on repositories or collections of learning materials. OpenCourseWare. It's a huge task, licensing issues, it. But by definition, for a repository, social interaction is out of scope. We looked at OCW, said it's a fabulous project, but it's really missing something. We need something more than a library. We have lots of libraries, but nobody goes to them. You just don't get anywhere by yourself, you get to page two.

Professor Stang, best lecturer they have, every lecture is videoed. But no matter how good he is, you will have a question - you will wish there was some person you could ask the question of. OCW is really good work, our project piggybacks on it, but a collection isn't enough. You want to be able to tuen to that person and say, "Did you undertsand what that person said?"

OLS is social software that integrates with existing collections, designed to facilitate effective learning and support interactions without the presence of an a priori authoritative voice. In this case, teacher bandwidth is actually zero. Instead of replacing the teacher with an automated system, can we replace the teadcher with several thousand actual people. People learn pretty effectively that way. That's the criteria - lots of people, but no teacher, no tutor, just peers.

Now just having a room with tables and donouts does not make a group work effectively, it just creates the possibility. What can we do tocreate the right nvironment with the best possibilities.

Brent: how to grow a community? Haven't you even been in a web forum where you said, "If they just did such and such, it would be so much better. Exceptional features. Another thing we want to think about is advanced moderation. Thirs, we want a cutting edge recommender system. If we think about who is coming to an OLS system, we want to support them. But what happens when we put all this together is we have a disaster.

If you put too many features up front, it's too feature-heavy. We have to say, we're not growing communities, it's communities that are growing communities. So we went with an extensible qarchitecture that has a modular design. It grows as the community grows. It allows us to put off advanced features until they are needed. Dave, for example, had a community using Slash code. But the moderation system is so extensive, it killed the community. It is important, though, that it is flexible enough to support rapid development. Finally, it needs to be adaptable to change.

Feature support, therefore - should be minimalistic in design. What is the minimum set of features that will do th job users want to do. It needs to be simple, basic and intuitive. It should not include complicatd architecture that limits expansion. And it must fit the needs of the community. It's easy in an engineering group to say this feature would be really cool. But you have to be focused on the community.

It's really important that moderation not overburden the community. At first, modertaion is not necessary. As it grows, it may need some, but it should be light and in the background. It has to related to the specific needs of the community. It must be acceptable to community members - some communities might find a post offensive, while another community would call the removal of the post a form of censorshop.

The recommender system needs to provide adequate guidance. The community needs to communicate what it needs to know. It needs to suit the size and extent of the community. It's easy to get starry-eyed about features. It has to be appropriate to the social level - if we were in a small room holding drinks in groups of three and four, I would not stand in a corner and try to have a conversation with everybody in the room, but that's much more appropriate here. Of course, those needs are going to change over time.

So - what is the minimum amount of features that we can build that will support our community. Then, we allow the community to say what the next feature should be, and then try to support that.

David: think about the technologies that have been successful - blogs and instant messaging. Blogs are so much better than everthing else because they are simple. Your Mom can run a blog. Same with Instant messaging. They are massively, massively popular, not because they're fature rich, but because they are simple. Torvalds - don't think that you can design anything better than what could be producd by a massively parallel community.

We looked at OLS, we had a whole set of features - but we looked at things blowing up, and we realized we had to write something very small. We had to write something very small and wait for the research team to look and say, 'the community is screaming for this feature'. It's a really different approach, it's not a Microsoft Word sort of approach.

Features:

  • Forums - to facilitate educational discourse
  • Logins - to provide stable identity
  • Kudos - to facilitate community recognition and reputation development
  • Fire alarm - to facilitate community policing
.

Growing the community:

  • Feedback - email, etc., provides guidance for new feature sets. That's hy there's not just an engineering team.
  • Forums
  • Fire alarm

You ask yourself, why do people participate and provide answers. And the answer is - I don't know. I have some idea. It's a multifaceted things. Usenets, web boards, etc. - we can say, this behaviour is stable. So it doesn't matter why it happens - we can count on it.

For having launched in May, and running over the summer - there are 600 users registere, 173 posts (in linear algebra). The design was so simple, and it was implemented really well by the engineering team.

Next version of OLS - on the very front page we'll actually aggreggate all the feeds from the conversations on the site. So we'll have a list of all the message threads or topics.

So far we only have one partner that we've integrated with so far, which os OCW. There are others coming - the connextions project down at Rice. When they roll that out, all their learning objects will be enabled. May to August - 600 users. For being young and being summer, I think we're doing pretty well.

The platform on which OLS is built is Zope, with code in Python. It's all open source. We want to port it all to Plone. If you have a platform like us is you can have a tight integration. Or you can put a link on your site that links to OLS - it's not a tight integration. Any collection of open matrials, you can integrate to them. We need to get a release on SourceForge. But the majority of the future direction is whatever the community says what it needs.

Comment - connection to resource base. We've tried to make the distinction between landmarks and port towns. Think about Mt Rushmore - how many times do you go? How do you build a community around it. I put a book online - they came, they saw, they left. As opposed to the port town, where there's new stuff constantly coming in. Slashdot - there's little tiny bits of content. The strategies are different - the content is stable versus the people are stable. The only kind of community development I understand is the port town, but MIT is the landmark.

Slashdot deals with content that is constantly changing. Butg linear algebra will be the same in five years. The set of possible questions and answers in a stable domain is finite. Because most of the questions have been answered. But if the content doesn't change, then the community can die. Absolutely. It's the port-town landmark metaphor changing. All the content that people will ask questions about are things that Stang has just talked about. The fact that people have just talked about doesn't mean there aren't any questions any more.

Side groups, provate spaces. Won't work if the commu nity is too small. We decided to implement only if the group gets large enough. We're about to the point where e see sub-groups happening.

SD - my comments - communities - as defined by the artifacts as opposed to being defined by the tool or environment. Also: support tools - there is no single instant messaging app, conferencing app. Finally, are threads larning objects?


Share |
Views Today: 6 Total: 174.