[DG: Teaching & Learning] Fwd: SCORM in Sakai

Tue Aug 24 09:58:52 PDT 2010

>   I'm not really up on where IMS Common Cartridge is at the moment, but if we are looking for a solution that the Sakai community can commit to long term, maybe that would be the standard to aim at. What do people think?

CommonCartridge, as it current is defined, has no provisions for 
sequencing or data communication for results reporting.  It does, 
however, allow a SCORM package to be embedded in it.  Common Cartridge 
is deliberately neutral concerning how content is formatted and delivered.

- Mark Norton

On 8/24/2010 12:25 PM, Ricci, Margaret P wrote:
> I want to echo many of the points John Norman made. One of the biggest issues with SCORM seems to be the maintenance because SCORM isn't as "standard" as everyone might wish. Certainly in the past, maintenance of something like a SCORM player would not have been considered one of Sakai's strong points. It's possible that the situation is changing a bit now, but I'm still not sure the community is up for that challenge right now.
>
> There has been a bit of an explosion of content editors that produce SCORM output, and that is pretty attractive to faculty who are seeing some benefit from putting content and exercises online, even in courses that are mostly f2f. There are a lot of pedagogical reasons for having small assessments and exercises embedded right in the content and presentations that students may be viewing.
>
> No one can ignore the cost of moving to a vended solution. For a small institution, the cost may be prohibitive. At Indiana University, we may well use the Rustici enterprise version of the software eventually, but we have the resources to make a decision like that. I'm glad to see this issue getting some discussion. It had really been on a back burner for a while until we took it out and dusted it off in Denver. I'm not really up on where IMS Common Cartridge is at the moment, but if we are looking for a solution that the Sakai community can commit to long term, maybe that would be the standard to aim at. What do people think?
>
> Thanks
> Maggie
>
>
> Margaret P. Ricci
> Principal Instructional Technology Specialist
> Teaching and Learning Technology Centers
> 307 Ballantine Hall
> Indiana University
> 812-855-8355
> mricci at indiana.edu
>
>
>
> -----Original Message-----
> From: pedagogy-bounces at collab.sakaiproject.org [mailto:pedagogy-bounces at collab.sakaiproject.org] On Behalf Of John Norman
> Sent: Tuesday, August 24, 2010 11:10 AM
> To: Mathieu Plourde
> Cc: Charles Hedrick; Teaching&  Learning Sakai Group; Sakai Dev List
> Subject: Re: [DG: Teaching&  Learning] Fwd: SCORM in Sakai
>
> Warning: This is a personal impressionistic view of SCORM, but FWIW is the reason we are not investing in it:
> 1. For whatever reason, I believe there is a high frequency of SCORM content failure. Perhaps the standard is loose enough that different editors can produce different content that is not really compatible. SCORM vendors invest considerable time in troubleshooting nominally standard content that doesn't want to play nicely. So there is a significant maintenance burden to a SCORM player. Indeed our choice of Rustici is a reflection of the fact that you need a SCORM *content service* more than a SCORM player.
> 2. Admittedly, from our early experiences (Warwick Bailey of Icodeon used to work at CARET and built an early SCORM player here), the data it provides is not very useful and is generally hard to interpret. Many implementations just record student start and stop (or whatever the minimum requirement is). The amount of code for unused functionality and the content-fixing overhead are hard to justify for such simple functionality.
> 3. Finally, in our situation demand is very low. This means the Rustici service is very affordable for us ATM.
>
> So creating a SCORM player is not a 'build and move on' sort of project. It has a high maintenance burden and needs to be taken on by someone who cares enough to dedicate continuous effort to maintaining compatibility with what editors churn out. The good news is that things are probably slowly getting better due to the efforts of the good folks at Rustici and Icodeon and elsewhere. When debugging a content/player issue, they try to notify the editor creator of the issue so it can be fixed in editor updates and releases - but that is a long, slow haul.
>
> It is interesting to speculate whether such a content service could/should be part of a Sakai Foundation offering, or even a joint project with other open-source efforts. Certainly the integration to the remote SCORMCloud servers seems to work well. We may be misconceiving the problem that needs solving.
>
> John
>
> On 24 Aug 2010, at 15:41, Mathieu Plourde wrote:
>
>> Dear Sakaigers,
>>
>> This thread reflects what a lot of people think about SCORM in
>> Sakai... I'm not against vendors, in fact they are vital to the growth
>> of Sakai, but why do we have to rely on them to get it to work?
>>
>> Isn't there enough reasons or demand, especially when it comes to HR,
>> compliance, staff training, distance ed, to put the efforts to make it
>> work natively in Sakai? Or should we focus our energy on some other
>> testing/tracking/portable learning object standard (Dr. Chuck?)?
>>
>> Mathieu
>>
>> ---------- Forwarded message ----------
>> From: Charles Hedrick<hedrick at rutgers.edu>
>> Date: Tue, Jul 13, 2010 at 2:20 PM
>> Subject: Re: SCORM in Sakai
>> To: Mathieu Plourde<mathieu at udel.edu>
>> Cc: markjnorton at earthlink.net
>>
>>
>> The tool my student is doing will be able to do enough sequencing and
>> conditionals to serve our needs. I'm hoping to use something like
>> Captivate to prepare content, and then deploy it through this tool. It
>> will work, but won't be as flexible as SCORM. But, like everyone else,
>> I don't feel I can take on SCORM.
>> On Jul 13, 2010, at 2:16 PM, Mathieu Plourde wrote:
>>
>> Hi Charles,
>>
>> I totally agree. We're also just struggling with not having SCORM in
>> Sakai. It just seems like vendors have targeted the niche, and no one
>> wants to touch that one with a 10 foot pole anymore. SCORM is mostly a
>> corporate solution, and corporations don't mind paying a vendor to get
>> it done, so education is left behind.
>>
>> Mathieu
>>
>> On Tue, Jul 13, 2010 at 1:23 PM, Charles Hedrick<hedrick at rutgers.edu>  wrote:
>>> We have the same issue with HR wanting to do training. So do some of our continuous ed groups. I have a high school student writing a tool that will do the minimum that we need, but if I could, I'd probably prefer SCORM.
>>> On Jul 13, 2010, at 12:00 PM, Mathieu Plourde wrote:
>>>
>>> Hi Charles,
>>>
>>> Not using Softchalk, not using any SCORM content anywhere on campus, nothing that I know of. HR wanted to do it with Articulate but backed-off because of the flakiness of the Sakai SCORM engine...
>>>
>>> They are now building their content in Articulate, publishing on the web without tracking, and are expecting to build quizzes in Sakai project sites to assess and track workers. Sucky workaround, but better than nothing.
>>>
>>> It just seems that every time SCORM comes around, we always think it's a requirement. And yet, when we look at the other things on our list, it always falls to the bottom.
>>>
>>> I'd love this to be fixed once and for all, but I can only complain...
>>>
>>> Mathieu
>>>
>>> On Tue, Jul 13, 2010 at 11:53 AM, Charles Hedrick<hedrick at rutgers.edu>  wrote:
>>>> So how are you using softchalk? I thought it needed scorm as a back end?
>>>>
>>>> On Jul 13, 2010, at 11:19 AM, Mark Norton wrote:
>>>>
>>>>> Having worked with the UC Davis SCORM player, my opinion is that it isn't usable.  It sorta works, but that's not good enough.  I tried to provide support for this player for SoftChalk integration, but I had problems with manipulating packages in the Content Hosting Service.  It doesn't have gradebook integration, either. In the end, SoftChalk decided not to support this SCORM player.  We also looked at the other players:  Icodeon and Rustici.  In both cases, the per-student cost was prohibitive.
>>>>>
>>>>> Matthew recommended the Edia player, but Edia has only made some bug fixes to the David player.  The base code is the same.
>>>>>
>>>>> Sadly, unless you are willing to pay for a commercial player, there is no open source support for SCORM in Sakai.  Personally, I think it's fixable, but the time/money commitment to make it so is non-trivial.
>>>>>
>>>>> - Mark Norton
>>>>>
>>>>> Charles Hedrick wrote:
>>>>>> We're looking for something like SCORM. GIven who needs to use it, it could have a modest cost for a tool to prepare content, but we can't pay a per-student fee for delivery. Do either of you know what kind of shape the open-source Sakai SCORM code is in? The alternatives are confusing for an outsider. I'm looking for someone who can tell me that they actually use one of the implementations, and preferably tell me what editors they use it with -- unless compatibility is good enough that we can honestly say that it's safe to use any of them.
>> =================================
>>
>> Mathieu Plourde, MBA
>> Project Leader, LMS/Instructional Designer IT-Client Support&
>> Services mathieu at udel.edu
>> Office: 302-831-4060
>>
>> =================================
>>
>> TOP LINKS:
>>
>> Technology Troubleshooting: http://www.udel.edu/help Sakai at UD Support
>> and Training: http://www.udel.edu/sakai/training
>>
>> =================================
>> <smime.p7s>_______________________________________________
>> pedagogy mailing list
>> pedagogy at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/pedagogy
>>
>> TO UNSUBSCRIBE: send email to pedagogy-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
> _______________________________________________
> pedagogy mailing list
> pedagogy at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/pedagogy
>
> TO UNSUBSCRIBE: send email to pedagogy-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
> _______________________________________________
> pedagogy mailing list
> pedagogy at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/pedagogy
>
> TO UNSUBSCRIBE: send email to pedagogy-unsubscribe at collab.sakaiproject.org with a subject of "unsubscribe"
>
>
>
>
> =======
> Email scanned by PC Tools - No viruses or spyware found.
> (Email Guard: 7.0.0.18, Virus/Spyware Database: 6.15720)
> http://www.pctools.com/
> =======
>

=======
Email scanned by PC Tools - No viruses or spyware found.
(Email Guard: 7.0.0.18, Virus/Spyware Database: 6.15720)
http://www.pctools.com/
=======