I began to blog about our “New Vision for Learning Management Systems” over a year ago. Since then, we have come across many new ideas, causing the New Vision to morph, change, and grow. Hopefully it will continue to change and grow. But I thought it would be a good idea to take a step back and summarize where the idea stands now.
The bigger idea is still to turn the LMS inside out. In order to do that, a new name was needed. While our current idea is not set in stone, the new term we are currently calling this new vision is a Social Learning Environment (SLE). The term “social” is becoming an over-used buzz term, so it may need to change at some point. There are some other good ideas for terms out there. I have been following the concept of the Open Learning Environment (OLE) as described by Jon Mott of Brigham Young University. The OLE is very similar to what we are calling the SLE, but with a few key differences as described later.
Our goal with the SLE is two fold: to aggregate student Personal Learning Networks (PLN) and make the teacher’s administrative task easier in the process. In the back of our minds is also FERPA, reporting, and accessibility. There really is not one good place to start, so I will begin with the students.
Overall, the SLE is connected to university enrollment databases. Students log in to the SLE with the same password that they use for other services such as university email. The SLE authenticates each student through this system. This system also indicates what courses the students have enrolled in. When students first log in to the system (before going to a class page), they will create connections to all of their content creation services (blogs, Twitter, YouTube, etc). This will connect their profile in the SLE with all of the accounts they use. Nothing else really happens at this point.
Teachers will create a class in the SLE. This class will be assigned a unique tag, such as “eng1301sp10.” This tag will be connected with the class on the SLE server. Students will use this tag to label all work they do for this class in their various connected services. Since each class would have a unique tag, students could use the same services for all classes while keeping work for different classes separate (but also retaining ownership of their work).
The SLE will then troll through all of the RSS feeds for each connected service the student has added, looking for unique course tags. When the tag is found, that content is sent to the appropriate course. This content can then be accessed as a continuous stream by the student in either a web-based interface or on a mobile device. RSS feeds of this aggregated content can also be created. This could look something like this:
This may lead to a confusing jumble of content for several different assignments. The solution for this is to create a second tag for each assignment, such as “week1” for discussions or “assignment1” for the first class assignment. This will allow students to sort the data stream, as well as help instructors connect content with a secure grade book.
This grade book would use tags to populate the grade book easily for instructors. Teachers would see a split screen when they begin to grade. On one side of the screen, the SLE would pull up the content from the student’s PLN that matches the class tag and the assignment tag. The SLE can also be set to look for either the first occurrence of all tags, the last occurrence of all tags, or an aggregation of all tags. This would allow instructors to allow for collections of different media (such as photo collages), journaling over time, or rough drafts with feedbacks. The SLE could also be set to scrape out the first instance of a set of tags if a tool (such as WordPress) allows students to go back and edit content. The other side of the screen would show a rubric (created by the instructor) that allows instructors to give feedback either based on grades, letters, or just pure instructor feedback. This feedback would only be visible to students. A grade book could potential look like this:
Discussions could also be taken to the student PLNs instead of being hidden inside of the SLE. When instructors create a discussion, they would also assign it a tag. The SLE would aggregate all student responses together from around the web. This would theoretically allow students to use any media and many different sites to contribute to a discussion. The same interfaces mentioned above (web, mobile, RSS) would be used to organize these discussions into manageable streams, which students can read on the device or service of their choice. To reply to a post, a reply button would be built in to the SLE interface that allows students to respond to discussion posts in the service that they like (no matter where the post originated at). This response would be posted on the service that the post originated on as well as somewhere in the responder’s PLN. This response would also be tagged in the SLE as a response so that it would show up in the discussion stream as a nested response.
Grading discussions would also need to be facilitated through an easy-to-use interface. When setting up the discussion, instructors would designate how much each discussion post would be worth, how many responses are required by each student, how much responses are worth, and what each point value means (ie – what would earn higher or lower points). When the instructor logs in to the SLE interface, they would see a drop-down next to each discussion post. They would be able to grade each post as they read it, and the SLE would add all of these grades up automatically in the grade book. For example, if an instructor said that each discussion response will be worth 5 points, they would see a drop down next to each post that allows them to score each post on a scale of 0 – 5 as they are reading. If they are only grading one post per student, then once they grade a post for a student, the drop-downs would disappear from all other student posts on that subject.
Instructor course content would also be handled much in the same way as student assignments. Instructors would add their connection sites to their profile. As they blog, create videos, or take pictures, they would simply need to tag the appropriate content each week with the course tag, and it would get sent to the SLE as content. This would be especially powerful if coupled with a browser plug-in that allows teachers to tag sites as they read them (in the same way that social bookmarking sites like Delicious operate). This would allow students to “follow” teachers as they research, read articles, and visit websites that relate to the course content. These social bookmarks would also make excellent discussion question starters for weekly discussion topics instead of stale, canned questions that stay the same every semester.
In many ways, this would also create a Personal Teaching Environment. We don’t necessarily see the SLE as one product that looks the same for everyone. We could potentially see it as a concept that has many different flavors and companies. The idea could even be that the only part of the SLE that is installed on a school’s servers is the database (that stores grades and information) and an authentication module with interface. Much in the same way that services like OpenID and FaceBook Connect allow users of those services to log in to other sites, the SLE server would allow students to securely log in to a course SLE no matter where it resides. Or, to avoid confusion, the SLE server could serve as a login hub that lets students have one login location that links out to the SLEs containing the courses they are enrolled in. Teachers would choose to use whatever SLE they want, which could include anything from free online services to paid areas with different companies to even an open-source version that they install on their own web site. Schools would give a unique security code to each instructor for each class. Teachers would enter this code into their SLE instance, and then authenticate their class with the SLE server installed on at the school. The two systems would then talk with each other to securely pass student authentication back and forth. This kind of system would have several distinct advantages. Instructors could take classes with them where ever they go. Schools could invite instructors from other schools to be guest teachers as they see fit (or they could even share instructors over alternating semesters). Instructors would find it easier to invite guests in to their classes. Also, institutions could save time and money if they only have to maintain a simple server area instead of a complex LMS solution. Not to mention they could focus resources on instructional designers that could help teachers design quality classes rather than on the massive tech support teams that keep LMS servers running. The good news for students is that no matter where the class is hosted or who teaches (tenure to adjunct to guest), they would still use the same password and user name to sign in.
All of this PLN aggregation will be possible by the using RSS feeds and tags. Most Cloud-based web services have both RSS feeds and tags. Those that don’t have official separate tags (such as Twitter) have found ways to still integrate them in to the service. For those services that lack both, the SLE will users to submit links or embed codes to the SLE and tag them as needed for specific class assignments.
One major topic that is gaining attention in educational circles recently is the concept of ePortfolios. Unfortunately, many ePortfolio solutions still seem to be more about showing off the company that created them more than the students using them. The field of ePortfolios is in need of some radical change, because the idea behind them is sound (even if many of the current solutions aren’t perfect). I don’t want to spoil anyone’s thunder here, but I have spoken to people that have great ideas in this area and I think there will be some great new ideas coming to ePortfolios in the future. All of that being said, the SLE would easily integrate with an innovative ePortfolio system. Any object that students want to add to a portfolio can easily have a third tag of “portfolio” added to them. The SLE would see this and send that object to the portfolio. In fact, new tags to categorize the portfolio entries could also be added, such as “portfolio-education” or “portfolio-experience”. The ePortfolio software would then be used to present the objects added as desired.
Learning goals and outcomes are often relegated to an after-thought in many online courses. The SLE would be designed to bring these up front. Teachers would be required to enter course goals or objectives when they start a class, as well as connect relevant local and national learning standards to their course. These would be displayed to the students. As teachers create activities for students to complete, they will also be connecting these activities to course objectives. This would also all be stored on a school’s SLE server for accountability purposes.
A word about the underlying architecture of the SLE. Since web tools change all the time, with new ones also being created quite frequently, the basic design of a SLE would need to be modular. As new tools are created, new modules can be quickly built that are designed to troll through the RSS feeds from these services and read the tags that are there. As existing services change, the modules for these services can also be updated quickly. This architecture would allow for new and updated tools to quickly be integrated in to the SLE as the web evolves.
The following diagram gives a basic overview of how this system would work.