Forum .LRN Q&A: .LRN Roadmap (Request for Comments)

I uploaded a modified version of the .LRN roadmap I presented in Copenhagen to the file storage.

I will be adding short descriptive texts with links to specifications, documentation, and any existing project pages.

This is a call for comments and/or corrections.

Posted by Rocael Hernández Rizzardini on
a few comments / questions:
Course evaluations or grade book is something like a grading system (for keeping all the grades that a student is having through the course)? and what about a online testing tool? is covered by one of the previously mentioned or by the complex survey?

new-portal means that an openacs installation will be able to handle multiple dotLRN instances?

Also I would like to see extension that defines an standard for creating a syncronization between university administrative system and dotLRN (class, users, user-class assigment, etc) creation.

Will be nice to have another package to have all the messages being sent to mobile phones (SMS), probably to make it wide useful by creating something to comunicate to provider sites that offer to send SMS to their subscribers.

I've been working on this and more stuff that I would like to see on dotLRN 2.0, when I have more info I could post it here.

Posted by Carl Robert Blesius on

Yes, the grade book will be a place to store a users grades.

Complex Survey should cover most online testing needs.

New-portal in the diagram represents moving infrastructure out of .LRN that should be in OpenACS. We want to share as much infrastructure as possible with other projects forming around OpenACS. Another example would be getting .LRN to use a  new and improved acs-subsites (check out the mockup link in the first post)

Synchronization with back-end systems is something Heidelberg needs. We hope to cover do this with the cooperative funding of the AuthN work.

A SMS broker exists (just search the boards).

Please post anything you would like to see in .LRN 2.0 here.

Posted by Lars Pind on

I'd like to see this diagram up on the subsite. :)


Posted by Samir Joshi on
One critical functionality we need is ability to tranfer content across dotLRN instances ( and still better, across competing platforms). Work on OCW or on IMS by Ernie/Sydney Uni. may be reused for this purpose. Here are more details :
Posted by Rocael Hernández Rizzardini on
Yes, Samir is right, we need that.
I named it as a reference in a document that I'm working on:
Inter Xchange Package (ability to communicate between different dotLRN instances/sites and share data). Remember what Malte said about "generell content aggregation service" here:

Also, I've been writting about: Archive classes & content recycling based on use (a combination of the Learning Objects Repository that you have & the rating system), this is really important to have a sucessful adoption of an e-learning system with the most of the professors, because makes their work easier, so they will love more dotLRN.

7: Priority Items for v2.0 (response to 1)
Posted by Alfred Essa on
We need to determine right away which of the items listed in the roadmap for v2.0 are a priority. And for those items how much work has been completed.  This will give us a better sense of where to focus our energies and resources.
Posted by Rocael Hernández Rizzardini on
I'm completely agree with you Al.
A real time-frame should be set, but that is mostly based on the requirements.
Posted by Oscar Bonilla on
I'd say the most important thing for .LRN would be to bring back the "killer features" that the original education package (the one from Randy's Thesis) had. Those are:

1. Web interfaces for managing tasks (assignments, handouts, exams, lecture notes, etc). From my experience using a system derived from ACES 2.0 beta I've found that the file storage is not a good abstraction for most people.

2. Groups of students working on projects together.

3. A grading system that supports the aforementioned groups.

4. Randy's education package had some pages in which professors could see at-a-glance all the grades given to a particular student. This page would display the student's photo, a small blurb written by the student, and a list of all grades received in that class. There was also a page for TA's in which professors could see a photo of the TA, the blurb, and a list of all grades *given* by the TA. This allowed professors to see in one page wether the TA was a high grader or a low grader.

We had also a page in the education module (that we copied and modified from the intranet module) which would display in a portlet information about a random student (the photo, blurb, and courses in which he was enrolled). This was actually the one feature that allowed me to convince professors to use the system. They said the hardest thing about teaching a class was memorizing student's names!

These might be trivial procs or small enhancements, but no matter how robust or sophisticated .LRN is, these small details make all the difference when convincing professors (and the institution) to actually use the system.



Posted by Malte Sussdorff on
I think a grading system is necessary, as well as minor bells and whistles that make dotLRN look nice (e.g. the photo solution Oscar mentioned).
I'd assume a compley survey is fairly high on the list of priorities, though I have no clue what people would like to see there.
Stability and performance is important to a certain degree (if you manage to run it with 40k users, that should be sufficient for most educational institutions).
Internationalization for sure (as we are heavily marketing it, we should adhere to our promises there).
Posted by Staffan Hansson on
Priority or not, Curriculum phase 1 (curriculum bar) is funded by Heidelberg and will be delivered within a couple of months - we'll start shortly. Further, as part of the Curriculum project, File Storage/Content Repository will be upgraded to handle relative linking (resolution of items via virtual URLs).
Posted by Carl Robert Blesius on

sounds good. Let's see how we can add these points to the roadmap.

1. After a couple of days of watching people use file-storage it seems it needs some major UI work. I would be very interested in seeing the web interface you mention.

2. Wimpy point is is going to be the first "group project tool" we are going to have. What else was in there?

3. This would be excellent. A grading system is a puzzle piece we are all looking for right now. Support for groups would be excellent.

4. Do you have a demo we could look at? The "help remember random students" function sounds really cool. The MIT profiles package seems to be making progress (it has shown up on SloanSpace recently) and I hope it will be part of the solution. In addition, the "What other users see about me" page is one of the most important community promoting tools in OpenACS/.LRN and it needs some major work to get it back up to the 3.x level (the page is more than lame at the moment). In the process we have to think about who gets to see what (e.g. only people in class X should be able to see my postings in that class, TAs and Professors should have a link to my grades in that class, dean's office might have access to all grades, etc.). I hope the  profiles package is  part of the solution.

Posted by Carl Robert Blesius on
as you know the document is up on the subsite.

I added "Support for Content Exchange" to the roadmap (will upload a new version soon).

as soon as the tar in the roadmap hardens a bit we can start a simple star based system on the page that reflecs priorities. Then we can think about adding a timeline diagram.

testing and grading is key and complex survey is way up at the top of the list for us. Sadley I missed the demo of your imporvements to the survey package you posted here:  Do you have one up somewhere else?

Stability and performance: goes without saying.

i18n: .LRN 2.0 will be fully internationalized unless hell freezes over. I am sure Bergen's tight schedule, Oscar's interest in .LRN, the possiblity of Greenpeace syncing with OpenACS 5.0, and some additional large "foreign" .LRN adoptors (I can not yet mention yet) will help push this effort forward.

Curriculum is up on the roadmap and will be in .LRN 2.0.  😊

Posted by Oscar Bonilla on
--- Carl Wrote ---
Synchronization with back-end systems is something Heidelberg needs. We hope to cover do this with the cooperative funding of the AuthN work.

Synchronization is only part of the problem. For .LRN there should also be an API (or a standard way at least) for mapping users to courses, professors to courses, importing course catalogs, etc. Usually universities already have databases with all this info and .LRN needs to be able to communicate with this database.

One of the hardest jobs was integrating GES with the universities database.