OLAT 4.0.0 has many new features like support for SCORM, a portal style homepage and an upgraded shibboleth 1.3 interface. Much more, to much to list here. If you are interrested, check out the detailed release notes on

http://www.olat.org/public/download/releasenotes/4-0-x.html

or download the double-click easy installer version to get a quick hands on impression:

http://www.olat.org/public/download.html

Cheers
Florian

Along similar lines, Figure 13 from the LAMS/Moodle integration walkthrough (see my previous post) shows a LAMS sequence linking to a Moodle forum via URL as the third step in a LAMS sequence.

So the question is, what else might you want from the interaction between LD system and Forum? (NB: I’ll use Forum here as a proxy for any activity tool)

One basic requirement might be a shared security context and provisioning of user information from LD system to Forum. This way, when users who are logged into the LD system move to the Forum, this requires no extra login. It also doesn’t require the teacher/sysadmin to set up users in the Forum separate from setting up users in the LD system prior to getting started.

Following on from this, you’d also probably want to be able to instantiate the Forum from the LD system automatically, rather than set it up by hand each time it is needed.

All of the above would hopefully be possible with IMS TI, and is pretty typical of LMS-tool integration (eg, Blackboard Building Blocks). So what does LAMS do that goes beyond this?

(1) LAMS provides a central authoring environment where you can configure the Forum and populate its starting threads, etc. So the Forum needs to provide an authoring interface to LAMS authoring to make this possible. This includes an agreed XML format for capturing the Forum configuration information that is stored in the Learning Design, and is later used to setup the Forum at run-time.

(2) The LAMS Forum has an option called “Lock when finished”. This allows the LAMS workflow engine to “lock” an activity once it is completed. After that point, a student can return to the activity and view it, but can’t change/add to it. In many cases in higher education, you would probably leave a Forum “unlocked” to allow for further discussion; but there may be contexts where you want to have several separate discussion forums at particular points in a sequence, and lock each one as that step is completed (rather than mix all the threads together, and end up with ongoing debate on an earlier topic). Whether you allow locking of a Forum is a pedagogical decision that depends on your context - the point here is, with LAMS, locking is *possible*. (The locking feature becomes more relevant for other LAMS tools, such as Q&A, where you might want to elicit an initial response from students, then build on this response for further discussion/debate, without students being able to go back and change their original answer - as this might remove the basis of a later debate).

(3) Some LAMS activity tools (but not Forum at the moment) have a feature called “Define in Monitor” - this allows an author to define the text for an activity (such as voting categories) while the sequence is live - rather than only beforehand at the design (authoring) stage. This means the Forum needs to provide an interface for “intervention” by the teacher while it is running live. A related feature is the ability of teachers to post directly to the Forum while it is running live (another form of “intervention”). Another type of intervention is “force complete” - that is, move a student on to the next activity.

(4) All LAMS tools can be run in “small group” or whole class mode. First, a teacher sets up a grouping task earlier in the sequence (say, randomly allocate all students in a class to 4 subgroups), then the teacher “applies” this grouping to the Forum. In this case, the Forum then needs to know to create 4 parallel versions of itself (rather than just one) with only the specified students in each relevant area (rather than the whole class).

(5) In LAMS Monitoring, there is a screen that shows the whole sequence, with a green dot for the current position of each student. So a Forum needs to be able to report on which students are currently “in” this activity.

(6) In LAMS Monitoring, another screen allows the teacher to click on any activity for any student, and see “what the student saw” when they were in that activity - that is, the student’s own contributions and any other contributions they are entitled to see (eg, for their subgroup only).

(7) In the next version of LAMS (V1.1), students will be able to export a record of all their activities for a sequence (together with all those of other students they interacted with) as a single file - we call this “portfolio export” - in the sense that you could store this LAMS activity record in an e-portfolio. The implication of this feature is that the Forum needs to know how to generate this report, and provide it to the LAMS core to have it aggregated with other records to produce the portfolio export file. In certain contexts, it may also be necessary for portfolio export to be able to present an “anonymised” version of records from other students (eg, Forum postings from student 2, student 3, etc, rather than Bob, Jane, etc.

(8) In the next version of LAMS (V1.1), any activity in authoring can be run online or “offline”. So you may want students to debate a topic at a certain point in a sequence, but whether they debate this f2f in class or online in a Forum will depend on your context, pedagogy, etc. If you run this activity “offline” in LAMS, the online sequence will just present a text “placeholder” informing students that this task takes place offline. In addition, you can print out information for the teacher (such as the debate topic, instructions on how to run the debate, etc) and potentially information for students as well (advice on debating practice, etc). So the Forum needs to be able to run in either online or offline mode, present the appropriate online interface, and be capable of printing off instructions instead of running an online Forum.

(9) In LAMS V1.2, tools will be able to recieve input data, and generate output data for other tools. V1.2 will alos include more complex branching and conditionality. Taken together, this means a Forum could, potentially, have two streams - one for students who scored 8+ on a prior test, and another for those who scored 7 and below. You could also have a subsequent task (maybe another Forum), where students were again divided into 2 streams, but this time according to whether they had posted 5+ contributions to the previous Forum (or not). While the details of this area are complex and far from finalised, the point is the Forum may need to know how to accept certain input data from other tools, and provide certain output data for others.

Quite a bit of work for a simple Forum! And that’s without any discussion of actual Forum functionality, or anything on lower level deployment/management/security issues….

From a different perspective, Scott Wilson has describe four things that tools need to offer in their services interface:
- activation
- closedown
- monitoring
- intervention
(see standards.edna.edu.au/idea/ summer2005/ppt/OTF20050209_scottwilson.ppt - slide 37). This is one way of categorising the issues raised above.

Related to this, Scott has a new paper on workflow in education - see http://members.imsglobal.org/forum/ims/dispatch.cgi/f.altilabwork/showFile/100041/d20050615182617/No/SOAandWorkflow2.pdf
I think this is an excellent paper for those interest in LD and workflow issues.

Hope this helps!

James Dalziel

Babi (and others), I’d be interested to here what you all think that SEPP partners could do (with support from the Sakai community) to use the Sakai development project as a tool in their diversity-promotion strategy.

James, your comments about the challenges of LD are really important and interesting. Can you give us a little more concrete detail in terms of, say, what has to be done to make a discussion board work with an LD workflow framework?

Chuck (Kearns), your description of the Sakai team’s goals and current thinking is fantastic. It clarifies a lot about why 2.0 looks the way it does as well as the priorities of the project.

Ray, your points are all well taken regarding the practical realities of the development team’s needs, especially in the short run. That said, I still believe that Sakai would benefit from the developers striving to eat more of their own dog food over time.

I really shouldn’t have brought the theoretical argument up first, since it encourages the Is-It-a-Future-or-Is-It-a-Now? fog which surrounds so much Sakai talk. I did, though, so — into the fog! That theoretical side has much more to do with community and financial support than “purely technical” (as if there ever is such a thing) restrictions. A distributed open source project would benefit from integration with a bug tracking system, ability to link tasks to milestones and schedules, easy publishing to the outside world, and (most of all) the much greater community of skilled open source developers who aren’t employed by higher ed institutions — none of which are top business priorities for a team whose primary targets are course sites and online learning.

But it’s absolutely true that a really useful and flexible online collaboration suite can support online learning, course sites, and software development pretty well, and all those missing elements could plug into our theorized collaboration suite one by one — once it exists! When we get to that point, it may turn out to be a fairly trivial matter to integrate non-Sakai-centric development tools.

Until then, though, I owe it to our end users to do my work efficiently by any means necessary, whether it makes good propaganda or not.

(Think of the way that savvy instructors and students who feel constrained by Blackboard’s functionality and UI will seek out an external weblogging host so that they can get what they need. Obviously, it’s not always ideal for them to be taking university-based roles out of the university system. But is the proper response to ban the use of external weblogging hosts, slap the wrists of the savvy instructors and students, and send them back to Blackboard? I’d say a better response is to figure out what they need, get better-than-adequate support for it within the university, count on carrots working better than sticks, and in the meantime not interrupt their work.)

Back to the real world. I don’t take any of your questions as rhetorical. We ask them inside the project, too — probably more heatedly. I agree with Ben’s summary. Since first cuts at core framework services and a new presentation layer weren’t available until Sakai 2.0, since they’re still not fully proven, and since Sakai 1-through-2 has been more about the core than about best-of-breed functionality, schools have wisely been cautious about sinking a great deal of development into new integrated applications. It’s being done, but the best approach is probably to design defensively, with loose coupling between the application and the framework, and that’s a skill which doesn’t always come naturally to developers or funders. Given such constraints, I’ve been amazed and delighted by the amount of labor being volunteered worldwide.

Beth, I understand that this is a good news and bad news response, but the gender skew was more pronounced on stage and in the audience than it is day-by-day in the project. Not only are there typically smaller numbers of women in back-end architectural development (which the conference heavily slanted toward), but in that group there are typically smaller numbers of women who feel an impulse to publicly hold forth. I agree that the end result was telling.

* “Sakai feels very “Blackboardish”. One of the goals of the Sakai project is to create a replacement CMS for the core schools (Michigan, Indiana, MIT, Stanford and later UCBerkeley and Foothill). While none of these schools used Blackboard alone, their CMSes evolved in the same environment as Blackboard. In fact, most of the tools can be traced to their unix-webpage heritage (newsgroups, chat, home page, etc). but with an integrated look and interaction design, single signon, common data store, etc) So one key intention was to replace what was there-hence a basic CMS look, feel, action, organization. We are keeping our clients(instructors and students) happy by not changing too much too fast in a critical system for their courses.

Another Sakai goal is to provide a platform for innovation to develop teaching and learning tools-but at Stanford that cannot happen until we move our faculty and students to a comparable CMS (in terms of user experience) to our existing CourseWork CMS (home grown and open-sourced, but suffering scaling problems that require a new architecture).

We see this as an 80/20 problem: 80% of the faculty want to continue teaching much as they have (the early and late majority in “diffusion of innovation” terms); 20% are pedagogical innovators who want to try new tools and change learning activities (project-based courses, studio science, problem-based activity integration, collaborative knowledge building courses). We must support both groups. But the 80% has to come first to a campus academic computing support group such as ours.

Innovators will not stop innovating if the CMS does not initially support them (it does not now), but we want to work with them and especially to support transfer of their innovations out of their original sites.(The big failure of most innovations in learning technology). Inclusion of their tools in the CMS is the best way for us to support transfer.

* “the four big institutions at the core of the Sakai project aren’t giving a whole lot of thought to using Sakai beyond basic web-enhancement of F2F classes.” This is true for Stanford and, I believe, several of the other core schools.. We look to our partners in SEPP to add the enhancement/changes for distance learning needs.

* “I was very disapointed about the fact that there is absolutely no group functionaliy” Because Sakai’s starting point was CHEF (UMichigan’s CMS) that had a flat structure, the architecture needed to be redone for use even in the other core schools. As has been pointed out, this is the BIG change coming up next. It must be or we at Stanford cannot implement.

“I noticed that Sakai conference participants were primarily men” and “. . .it’s hard to think of ways in which the Sakai project itself could make a meaningful dent in the much bigger gender gap problem in software development ” Because Sakai started architecture-out, a preponderance of the people participating have been from computer architecture and programming groups on the different campuses. These groups are often WMDs: white male-dominated (note that this is not true at Stanford’s Academic Computing). Sakai is not alone in this regard as Michael notes. Where does the dent start–in K-12 and university CS education, in hiring practices ?

I am working with the Sakai interface and interaction design team and with the user support groups. we are approaching gender parity in these fields. These groups will be more evident (and more influential) as Sakai is adopted. This is not to ignore your observation, but to place it again in the larger domain of software development, which has a lot of old (or maybe young) boyism required to play.

” I’d also like to see a commitment to LD.” There is a “pedagogy/teaching-learning” discussion group in Sakai. Malcolm Brown of Dartmouth and Phil Long of MIT head the group and I have been active in its discussions. Also, see (and contribute to) the pedagogy section in the Sakaipedia. (http://bugs.sakaiproject.org/confluence/display/ENC/Pedagogy+Information)

In the dg we have talked about the “silo-ization” of learning activities in traditional CMS tools and the need for finer granularity and modularity within these tools so that activities can be combined into sequences (exactly as in LAMS and the LD spec). But with the need to fill the 80% side of the solution, we have stuck with the basic tool paradigm and not chunked their actions (Samigo has started with its QTI web services interface). I have been assured by Joseph Hardin that next year is the year of pedagogy in Sakai.

Probably half of the discussion in this on-line group during the past several months has been about functionality needed for assync discussion - what’s needed to facilitate learning (and teaching) rather than just having superficial grade-driven studentposting.

We look forward to a fully inclusive community with the teaching and learning support/research/practitioners more involved in Sakai development and design activities after it expands from its rushed architecture-out effort.

* “Where are the community members who are working on the teaching tools?” Most schools like Stanford have a group of programmers working on their own CMS or gluing a proprietary CMS to their other enterprise systems. The pitch was made at SEPP in Baltimore for these schools to have their programmers work on tools etc for Sakai. Rather than an army of individual programmers, I expect institutional members to play the biggest role in Sakai development. We at Stanford will continue to work of different components of Sakai and for inclusion in the general release. Others are developing or getting started: we talked to Columbia and others about enhancements to Samigo, and to Simon Frasier about using their Sakai event sign up tool.

I must admit that our current focus is on replacing the existing campus CMS.
But we are looking forward to getting innovative tools included in the Sakai toolset, initially for our early adopters.

My major concern for Sakai is the assumption that LD will be relatively easy now that most of the software infrastructure is in place. From our experience of building LAMS - this is unlikely to be the case.

LAMS is, in effect, a multi-actor workflow system incorporating both a “core” workflow system and a suite of workflow-enabled activity tools. LAMS allows recording, monitoring and intervention for its workflows, and visualisation of workflows for both authoring and monitoring.

This functionality is quite different to traditional LMSs. One of the byproducts of this difference is that when we built LAMS, we had to completely rebuild every LMS tool (forum, chat, quiz, etc) to make them “workflow enabled”. This lesson remains the most painful one we learned. From speaking with many technical (and pedagogical) colleagues, it is also the least understood. Many people still assume you can just drop existing LMS activity tools into a sophisticated worflow framework, and expect them to work.

NB: If by “work” you mean “presents a URL pointing to the activity tool at the relevant step in the workflow”, then this hopefully shouldn’t be too hard (we’ve just done this with Moodle - see http://lamsfoundation.org/integration/moodle/walkthru.html - especially figures 12/13/14).

But if you want to do things like retain single-sign-on, implement sub-groups, allow teachers to monitor/intervene, allow an authoring environment to create a set of instructions to configure and populate the activity tool, and allow the core workflow system to create a full record of each student’s activities (so this can be exported and stored in an e-portfolio system), then your activity tools all need to richly communicate with the workflow core about these things.

The best quick illustration of the problem is a series of graphics I presented at a Cambridge MIT Initiative conference in April 2004, where I compared the architectures of OKI, Sakai and LAMS. The final two slides illustrate the problem between hopes and reality for LD tools from our experience of building LAMS - see
http://www.lamsinternational.com/CD/html/resources/presentations/LearningDesign.CambridgeExtra.ppt

For a paper reviewing the development of LAMS, and the challenges we faced with the IMS LD spec, and some reflections on a “LD activity tools API”, see
http://www.lamsinternational.com/CD/html/resources/whitepapers/Dalziel.LAMS.doc

For a detailed discussion of LAMS, IMS LD and activity tools interoperability from the UK CETIS EC-SIG discussion list, see http://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind0505&L=cetis-ecsig&T=0&F=&S=&P=1014

Hope this helps. I think Sakai has great potential. I also realise some people don’t see the value of an approach like LAMS. But for those who are interested in how to combine them, the lessons we learned along the way may be useful.

James Dalziel

It is unfortunate that most of the tools shown in Sakai are primarily administrative as opposed to collaborative. But in order to support collaborative tools you need to get some of the basics in place and working. For example, as you mentioned, Sakai doesn’t support groups or sectioning, so we’re pushing forward on a tool to create groups and sections. Pretty dull in some ways, but it will make it possible to do much more interesting work later on.

There is some development going on beyond Melete. There are a few discussion tool projects - the one out of Cambridge University looked especially cool - and some tools using image repositories. I saw a very cool plugin to the rich text editor called Twin Peaks that lets people insert links to library resources from anywhere in Sakai. There was a lot to see at the conference.

But there is still a lot of hard work to be done on the framework, and on the administrative tools. I think many schools are quite rationally waiting for the platform to stabilize before they start developing on it. I’m not worried about the money running out - many schools have been paying their developers to work on Sakai and will continue to so.