Lately I have been thinking alot about .LRN and learning management systems in general and I came to the conclusion that .LRN in its core is primarily not a "learning management system". What makes it an LMS I will explain later on. But in fact it is more a portal, than a groupware solution and finally a framework.

Portal

What makes .LRN so special is the portal functionality. I strongly believe that this will be future more many web based systems. The reasons are:

• Single Point of Entry
• Personalisation & Customisation
• Content Aggregation
• Integration & Extensibility

From the users perspective the biggest challenge is to provide users with latest information at the lowest cost.

A good example is the news package. Here the user can see the latest news items.

Unfortunately there are many bad examples: forums, calendar, faq. Too many clicks to view the latest information. The worst is most probably file-storage. Here you need to navigate several levels depending on the folder structures to figure out what has changed and to download it.

A user would expect to see the latest changes on each package at one glance.

Framework

Now what do I mean with framework? Basically that .LRN more OpenACS than it is .LRN. It's just a little bit more. One aspect is portals I just mentioned above.

The most important features of web application frameworks (WAF) like OpenACS are:

1. Level

• Installer
• Kernel
• Package/Plugin Management (Upgrades, Versions)
• Sitemap
• API Browser
• System Monitoring
• Integrated Testing and Debugging
• Callbacks/Service Contracts
• Templating System, MVC-Paradigm
• Hot Deployment
• Integration with an IDE
• Scheduling/Cronjobs
• Message/Progress Bar
• Wizards
• Caching & Clustering
• ...

OpenACS has support for most of the features here. What is lacking mostly is the integration with an IDE.

2. Level

• Objects, Categories, Taggin (Meta-data)
• Content Repository, Directories, Versioning
• Roles, Rights and Group Management
• Workflow
• Help System
• Internationalisation
• Search
• Portals
• Notification
• Clipboard
• Annotation
• Organisational structure
• ...

Some of the feature are available in OpenACS, others in .LRN. What is needed most is a smoother way to provide these features right from OpenACS.

Best example is:

• Internationalisation
• Portals (provided in .LRN/OpenACS)

Room for improvement:

• Objects API
• Search Integration
• Workflow Integraion
• Clip board

What is missing?

• Roles Managment (provided in .LRN)
• Help System
• Annotations (as part of .Folio)
• Object tagging
• Organisational Structure (partially in .LRN)

From the users perspective it would be nice to allow a users to annotated an to clip everything on the portal and to structure the objects by his own categories under his/her portfolio. Maybe integration of .Folio to .LRN will close this gap.

From an administrators perspecitve it would be nice to have a package that allows the define or import the organisational structure of the given institution.

One important thought:
I believe that right now we are mixing two metaphors in .LRN due to the fact that we try to bring two worlds together OpenACS (solved by master templates) and .LRN (solved by portal pages). Toolbars (DS, .LRN) should be made available as portal pages in .LRN. I know that most of the stuff is either a link list or toggles but why confuse the navigation. One could display the portal pages depending on the user and also add more portal pages like one for .LRN administrators, one for system monitoring, one for developers...each page could be made of a reusable set of feature specific portlets.

Domain Specific Solution

The last two points have solution specific elements since roles and organisational structures are taken from the context of the learning domain. What makes .LRN a real solution is the learning domain specific terminology used.

Though I don't know whether this effort will ever be made but if one would cleaned up .LRN to use a domain neutral terminology dotLRN would be infact nothing but a groupware solution based on features provided by an extensible web application framework. The domain specific parts could be outsourced in so called domain catalogs.

Depending on the used domain catalogs it would be in one case:

• .LRN
• .WRK
• Finance Portal
• ...

The key feature here is the fact that portals is used, which is also available in OpenACS. This allows the integration of any application build on top of the web application framework. Adding remote web services would even allow the integration of external applications.

Now what makes .LRN a learning management system are basically the learning domain specific applications integrated into the platform like

• Grade book
• Learning Design
• Learning Object Repository
• Homework
• ...

Again: What is .LRN? (status quo)

So here is my answer to what .LRN is:
.LRN is a Portal based on an extensible WAF with

• learning domain specific terminology (presently tighly bound to)
• groupware functionality (file-storage, forums, faq, surveys ...)
• several learning domain applications (grade book, homework, learning object repository...)

Where should we go from here? (quo vadis)

I believe that the leaner we make .LRN and bring back stuff to OpenACS the better. Outsourcing the domain specific terminology would allow reuse of .LRN for other scenarios.

Here is my vision. That one day