Rustici Software

Rustici Software - We Make SCORM Easy SCORM Consultants
     Home HOME     SCORM Engine LMS STANDARDIZATION      SCORM Driver CONTENT STANDARDIZATION      SCORM Test Track TEST TRACK      Offline Delivery OFFLINE DELIVERY      SCORM Resources RESOURCES

Holiday Gifts
12.19.2008 - Mike Rustici

This is a festive time of year. Whether you celebrate Christmas, Hanukkah, Kwanzaa, the New Year, or if you're just excited that it might snow soon, we wish you and your loved ones all the best.

The other day, I was talking with a few other entrepreneurs about how how we handle holiday gifts for employees. I'm proud of the answer I gave and figured I'd share it.

Tim and I select personal, meaningful gives for each of our employees. We try to give our employees something they will really enjoy and perhaps something they wouldn't normally treat themselves to. It's hard and it takes some work, but it's worth it.

So, what did we get this year:

Brian, the rabid Tennessee Titans fan, will be taking his family to the sold out final home game against the Steelers.

David, the disc golf pro, will get his own disc golf goal at the office for coffee break practice sessions. He's also getting a book on toilet paper origami since he has a reputation for never replacing the role.

Joe, the Xbox fanatic, is getting the complete Guitar Hero world tour set. He will also get a new fleece pullover to replace the one he constantly wears to work that bears the logo of his former employer.

John, the newly born do-it-yourselfer, will get a power tool shopping spree at Lowe's.

Eric and Troy, the two employees competing for the title of corporate brewmaster, will get kegging kits to and kegerators for storing their home brewed beer. (Yes, this might a subtle hint to share the spoils.)

Kevin and Jean, our cultured crew, are getting season tickets to the Tennessee Performing Arts Center.

Rustici Software is very much a lifestyle company. We strive to create an environment where we want to work and where others will want to work. That goal is often in conflict with growth. We have no ambition to be a large blockbuster company. We intentionally want to stay small. But how big is too big? I think the answer might be defined by our gift policy. I want to always know our employees well enough that we can give them a thoughtful and personal gift.

Labels: ,

8:43 AM 0 comments


The SCORM Engine as a "platform for e-learning"?
12.18.2008 - Mike Rustici

Tim and I have been discussing how our own experience in designing the SCORM Engine might directly apply to the "platform for e-learning" being discussed by LETSI. Behind the scenes, the SCORM Engine is essentially a platform that facilitates adding plug-in functionality to LMS's. In this case, the plug-ins are currently all learning standards. For instance, the available plug-ins allow an LMS to support, AICC, SCORM 1.1, SCORM 1.2, SCORM 2004 2nd Edition, SCORM 2004 3rd Edition and IMS Sharable State Persistence. We have high level designs to extend the SCORM Engine to support other plug-ins like a discussion boards or an assessment engine.

An added benefit of the SCORM Engine's architecture is its integration layer that allows it to tie into any LMS. The diagram below shows how the SCORM Engine's architecture allows for it to be integrated with any LMS and serve as a platform for supporting many content delivery mechanisms.



Should LETSI move towards a path similar to the one described here we would look forward to contributing our experience and lessons learned from the design of the SCORM Engine.

Labels: ,

7:11 AM 0 comments


"Which part of SCORM should I implement in my LMS?"
12.17.2008 - Tim Martin

In general, passion and anger don't mix with software standards for me. I believe we're doing good work, I think SCORM is really effective, and I hope we're doing our part to further its ongoing success. But... we often find ourselves mired in discussions over semantics or other companies' arguments about minutiae. Over these things, there is little need for passion and anger.

If you develop an LMS or determine its functionality, though, I have a favor to ask of you. Please, please, please... do not implement part of the SCORM standard. I have encouraged many prospective customers to steer away from SCORM. I have no problem with companies that control their content and their platform electing to avoid SCORM completely if they have no use for interoperability. But if you have use for some aspects of SCORM, for your sake and mine, finish the job, complete the implementation, even go so far as getting certified.

Why? Why not do just what you need?
  1. Do you really know what you need right now? Do you know your target content well enough to say that definitively? [No, you don't... you have no way of knowing for certain which data model elements are important to this piece of content.]
  2. Do you know what you'll need from the next piece of content? What if it comes from another tool or vendor?
  3. Side effects. As you have some success with one piece of content, it will give you a false sense of security. Some other piece of content will come along and fail to function, and the reason for its failure won't be apparent to anyone. These are the kinds of problems that will occupy you and others indefinitely. This is undoubtedly costly to your business, and not just in the short term.
  4. Your content vendors will hate you!
  5. There's simply no logical point at which to stop. Do you need to be able to retrieve the learner's name? Yes. What about the review mode? Well, probably, but does your content use it? What about interaction reporting? No, we have no content that reports interactions... It is a slippery slope in the worst sense.
So, I'm begging. Please stop now, stop before you start to implement a part of SCORM. If SCORM is important to you (and it should be in a lot of cases), then do it right. Go all the way. I'd love for you to use our tools to do it. But even if you don't, please finish the job.

Labels:

3:58 PM 2 comments


What is a "Platform for e-Learning"?
12.15.2008 - Mike Rustici

There has been a lot of talk in LETSI lately about what SCORM 2.0 should look like. Everything is on the table. Since there are so many use cases for e-learning, it has been difficult to narrow down the focus of what a specification for the next generation of e-learning should look like.

Some have proposed that maybe SCORM 2.0 should be more of a platform than a specification. Aaron Silvers introduced the phrase "Linux for learning" (Aaron discusses it some here). It has been bounced around a lot, there is a lot of enthusiasm around the idea, but it's exact definition remains a bit elusive. There is a thought that in a time of accelerated innovation, it makes more sense to focus on informal specifications and open source implementations rather than on formal standards. If that is the case, what is LETSI's role in the community? Does LETSI merely shepherd the development of specifications, or do they actually produce open source software?

It is sometimes hard for me to debate ideas in the abstract. It really helps me to see the merits (or demerits) of an idea if we can be concrete about how it will actually be implemented and what it will do. In this case, what does a "platform for e-learning" actually do? What problem(s) will it solve? What will it look like? Why would people actually use it?

Tim and I have batted these last questions around a lot over the last few weeks. We've come up with one answer that might represent a useful path forward for LETSI. This might be just a different way of stating what others have already stated, but here goes.

Ten years ago, every LMS and every content vendor needed custom hooks to get their applications to work together. Proprietary interfaces required vendors to modify their products every time they wanted to integrate with another vendor. The world looked like this:



After SCORM standardized the interface between LMS's and content, things got a lot easier. Now LMS and content vendors all just had to code to one single interface and things were a lot simpler. The world looked like this:



Today we are back in a similar situation, except the items being integrated are changing. The content integration problem has largely been solved (yes, it can still improve, but the path is known). The integration problem facing learning systems now stems from trying to integrate other systems and applications. It looks something like this:



It's a very similar problem to the one SCORM solved. Years ago, LMS vendors were being asked to integrate with many different types of content. Today, they are being asked to integrate with many different types of applications. Currently, LMS's integrate with things like virtual worlds, simulations, assessment engines, competency management tools, content repositories, reporting services, discussion boards, classroom management tools, intelligent tutoring systems, performance support systems, knowledge management systems, document management systems....and the list goes on and on.

Back in the day, each LMS and each content producer had a proprietary interface for performing integrations. Today's situation is similar. Today, many LMS's have their own proprietary plug-in architecture or API for enabling extensibility. For a great example of LMS extensibility and integrations, check out the number of modules available for Moodle.

Many LMS's are providing extensibility interfaces. Each is doing this differently. The industry wants more integration. The use cases presented to LETSI require system integration and extensibility. Perhaps standardizing LMS extensibility interfaces is the next big problem that LETSI should solve.

Integration and extension seem ripe for standardization. Why?
  • It is currently being done. As a standards body, we would not be innovating, but instead codifying established best practices.
  • It is in demand. LMS's are already expected to integrate with a number of systems and this number is rapidly increasing.
  • It is currently costly. Much of the cost of LMS implementations currently stems from integration services work.
  • It is currently painful. In addition to cost, the fragility of integrations makes it hard to justify changing systems. This creates vendor lock-in.
Many have already discussed developing a "platform for e-learning" or a "learning systems architecture". This post is saying the same thing, but getting a bit more concrete about what that means. To us, this platform/architecture is a way of adding new functionality to existing learning systems in a standardized fashion. A standardized platform/architecture enables functionality to be developed once and integrated into any system, just like content can now be developed once deployed to any system.

The key insight here is that this is something that is already being done and that it is an existing pain point with real business value. LETSI can define an architecture by codifying existing practices rather than inventing something from the ground up. Simpler integration benefits vendors and users alike.
2:37 PM 9 comments


Why can't my content find the SCORM API?
12.12.2008 - Joe Donnelly

This question comes up several times a month. From time to time, when you launch a piece of content, you may see a message box like this:



In order for communication to occur between the LMS and content, the LMS is obligated to provide an API. When you launch a piece of content, the first thing the content has to do is look for that API, in order to establish communication with the LMS. In some cases, that piece of content has what we call a 'poor API discovery algorithm'. While this can mean many things, it often means that the content will just search the frames in the current window for the API and if it does not find it, it will just quit and throw that error. There are a few ways around this.

1. Instead of having the content launch in a new window, launch it in the frameset. This way, we know that the content is in the same window as the API. In many cases, this eliminates the discovery problem.


2. If the content needs to be launched in a new window, you could re-code the API discovery algorithm to not only look in the current window, but look at its parent window and keep searching parent windows until it finds it (as the specification requires!) For more detailed code level information on this option, check out this article.

Since this is a pretty common mistake, we created a package property to help combat the behavior for our SCORM Engine users. Package Properties control how the SCORM Engine delivers a particular piece of content. You can specify how the content is launched, the navigation options available to the user, and the behavior and appearance of the content being delivered. SCORM Engine Package Properties can be controlled in a number of ways. Each implementation has defaults, some have an exposed UI, and others simply offer this control via imsmanifest extensions. (Controlling package properties via the manifest extensions is a post for another time.)

If you have any questions about how this works, please feel free to contact me at 615-550-9530 or you can email me with any questions at support@scorm.com

Thank you,

Joe

Labels:

2:22 PM 0 comments


"How is the economy affecting your company?"
12.11.2008 - Mike Rustici

There's been a lot of talk lately about the economy. It seems that the most popular question people have asked me lately is "how is the economy affecting your company?".

I don't have an insightful answer for them. Things are still plugging along. We have had some potential clients express concern about their finances and not wanting to take on any capital expenses. But, we are still closing deals and moving forward. The holiday season is always different, so it's hard to tell if the economy has had an impact on our sales or if we are just experiencing our normal year end tranquility.

Tim and I have spent a fair amount of time discussing how this might impact us. Our conclusion is shared; we're cautiously optimistic. A softening economy could actually increase our business. As companies cut budgets, one of the first things to be cut is training. However, people do still need to be trained, so we could very well see an increase in online training as a replacement for expensive classroom training.

The one thing I do know is that I that know Rustici Software has a long future ahead. We have been and will continue to be fiscally conservative. We carry no debt and we have a fairly strong cash position (this is our reward for forgoing explosive growth in prior years). We will be a bit more cautious in the coming months and we will ensure that all of our spending is prudent, but we have no plans to layoff employees or make any other significant cuts. We have an eye on the future and we will continue to invest our time and resources into innovative new products.

Labels:

4:09 PM 1 comments


SCORM Isn't Dead, But Apparently It Is Misunderstood
12.10.2008 - Mike Rustici

A recent entry on "Rod's Pulse Podcast" contained an audio interview with Dr. Bobbe Baggio, In the interview, Dr. Baggio asserts that "SCORM is dead". She also says that "people who work with SCORM understand what I mean". Dr. Baggio, I work with SCORM, I do understand what you mean and I do agree with your premise.

GASP! WHAT? The SCORM guy agrees with somebody who says that SCORM is dead! Hold on, don't panic, catch your breath. I did not say that I agree that SCORM is dead, I said that I agree with her premise, and as we'll see, those are two different things entirely.

Dr. Baggio's central premise is that "intelligent searching has eclipsed the need for metadata and tags". Amen, hallelujah. I absolutely agree. There are still some very valid uses for metadata, but for most of the world, intelligent searching will be good enough.

BUT, it is a long stretch to get from there to "SCORM is dead". To make such a leap represents a misunderstanding of what SCORM is and why people use SCORM in the first place. It is an understandable misunderstanding though considering the way SCORM was initially "sold" to the world.

In Dr. Baggio's view, SCORM is all about reuse. She views SCORM as being all about storing content in repositories to enable people to search those repositories and reuse content. Her postulation is that metadata is the key technological enabler of this functionality. I disagree with this view in three significant ways.

My first disagreement is that SCORM is all about reuse. Yes, reuse is one very significant goal of SCORM, but the real reason most people adopt SCORM is interoperability. Most people use SCORM so that they can import content created in any system into their LMS.

My second disagreement is with narrow definition of reuse contained in Dr. Baggio's arguments. Dr. Baggio's view of reuse is that an organization's content is all stored in a central repository. Because of the content's metadata that repository is easily searched, allowing people to find reusable learning objects to use in other courseware. This is certainly a valid type of reuse and it is the main view that has been "sold" by ADL as a driving factor behind SCORM. But, there are other types of reuse that are far more common in today's world. For instance, SCORM enables courses to be reused as a whole and across entities. For instance, content vendors (like SkillSoft) can produce a huge library of content that is sold to thousands of organizations. Because of SCORM (and other standards), SkillSoft only needs to produce one version of that content and it can be used by many of organizations without modification. This is reuse. This is what is happening in the industry. This is what has made SCORM the de facto industry standard for learning content. This is what SCORM is really good at. This is why SCORM is healthy, viable and far from dead.

My final disagreement is with the implicit assertion that metadata is the key technological enabler behind SCORM and as such, since metadata isn't necessary anymore, SCORM is dead. In my view, metadata is the least important aspect of SCORM considering the way SCORM is currently used by industry. Go ahead, take it away, it won't affect things. As I previously argued, SCORM is about more than reuse and content discovery, so metadata's irrelevance doesn't kill SCORM. But, let's assume for a moment that SCORM is only about reuse and discovery of reusable learning objects in a central repository. In other words, let's step into the view that Dr. Baggio espouses. Even in that world, SCORM adds a lot of value if metadata is replaced by intelligent searching. SCORM encourages content to be logically chunked, enabling reuse. SCORM removes technical dependencies allowing content to be portable across different environments. The interoperability that SCORM provides is still required when the discovered content is to actually be used.

I don't mean to disparage Dr. Baggio's remarks because I completely understand where her opinions come from. SCORM was sold to the public to do precisely what she envisions. When SCORM was first released, all the hype was about reusable learning objects pulled from central repositories. Metadata and reuse were all the rage. That vision is still valid, but unfortunately it hasn't emerged as we had hoped. (I believe the obstacles standing in the way of that vision are related more to business models and constraints than they are to technological deficiencies, but that's another blog post.) Along the way though, the world found that SCORM was very useful in a world without central repositories. SCORM is VERY widely adopted and very widely used. This adoption has happened voluntarily by industry. Broad industry adoption simply does not happen unless there is significant value in a technology.

Dr. Baggio made several other comments that I disagree with, such as "SCORM from the beginning never really worked really well, "if SCORM is going to work in your organization, you have to go into SCORM and customize it to meet your needs", "the need for SCORM has certainly gone away" and "if you look at the research about who uses SCORM, it's not being used". I disagree with all of these statements, but they do follow logically from her original premise. Since I've already argued against the root premise, I don't think these comments need to be addressed.

I do agree with a few other things she said, such as "since SCORM was invented, we have better technologies" and "SCORM might morph into something else". I absolutely agree with these assertions. SCORM is about 10 years old and due for some updating. I am very involved in the effort to define what SCORM 2.0 will look like. A new organization called LETSI has taken on that monumental task and their efforts have garnered a lot of support.

So, in short, I think that SCORM is anything but dead. A while back, we bet the company on SCORM's future. Today I am much more inclined to double down than to walk away.

Labels:

2:01 PM 6 comments


"Joe Smith answered Question 1 with B but the correct answer is C."
12.04.2008 - Tim Martin

I got a great question from one of our SCORM Engine clients (Brian) first thing this morning, so straight to the blog it goes.
We are getting very involved with developing a custom SCORM report that utilizes and displays interaction data. As we are looking through the information sent back by a SCORM 1.2 published course (using Lectora), we see ID, LearnerResponse, CorrectResponse values being passed in. With this information, we can build a report that tells someone "Joe Smith answered Question 1 with B but the correct answer is C." This may meet our need, but some of our clients are asking for a report that shows the actual text of the question and answer.
My research his showing that this is not a part of the SCORM standard, but do you have any recommendations or experience with capturing the actual text values associated with these variables?
First off, thanks to Brian for doing a bit of research before getting in touch with us. We're happy to answer the basic questions, but a pointed question like this one allows us to jump straight to the details they're seeking.

SCORM 1.2 has very limited capability in its data model for accepting details about interactions. Brian has this well understood... something to the effect of "Joe Smith answered Question 1 with B but the correct answer is C," is about as far as one can be certain of going in SCORM 1.2.

SCORM 2004 enhances this a bit. The question element (cmi.interactions.n.) now has an .id that is a long_identifier_type in addition to a description element. This description element (cmi.interactions.n.decsription) allows the content to record, typically, the question itself as a localized_string_type. This is a vast improvement from my perspective. Answers, as well, have improved in SCORM 2004. Because the vocabulary varies for different types of interactions, it isn't exactly straightforward. Taking multiple choice responses as an example, though, the content can at least record a collection of short_identifier_types.

So, what in the world did all that mean? Let's go back to Brian's example. In SCORM 1.2, he's right, the best you can do is:
Joe Smith answered Question 1 with B but the correct answer is C.
In SCORM 2004, you would hope to see...
Joe Smith answered Question 1, 'What is my name?', incorrectly. His answer was 'Bob' instead of the correct answer, 'Joe'.
This all sounds great, to this point, but now it's time for some caveats.
  1. This is entirely dependent on the piece of content in question sending along the full set of data. If the piece of content elects not to send along the correct response, that is its right. If it elects to send along no interaction data whatsoever, it can still be conformant. An LMS is 100% beholden to the content it is playing. [Note to content vendors: Please don't be lazy!]
  2. The Joe Smith question above shows the best side of the new answer functionality. Had the answers above been more sophisticated, it might have looked more like this:
Joe Smith answered Question 1, "Compare interactions in SCORM 1.2 and SCORM 2004," incorrectly. His answer was "Interactions_are_perfect_now.__Lovely," instead of "Interactions_are_somewhat_improved."
So, don't expect perfection in SCORM 2004, even if the content is behaving well. It is, in my book, something that might be worth tackling as the standard continues to evolve.

Later: I realized I didn't fully answer Brian's question here... The answer is, in SCORM 1.2 especially, reporting effectively on interactions is simply difficult. It might be possible, for content from a single vendor, to create a reporting mechanism that would allow you to establish an answer key of sorts... and then "join" that answer key to the answers from the interactions. Applying something like this broadly, across content vendors, is a problem we haven't even solved yet!


Labels: ,

8:51 AM 1 comments


"Can you recommend an LMS for me?"
12.03.2008 - Tim Martin

Ah, a relatively common question for us... People come to us asking for recommendations on content and LMS's with some regularity. I theorize that it's for one of two reasons...
  1. They think we're the governing body for SCORM.
  2. They know we aren't the governing body, but that we have expertise in the subject and have seen a bunch of LMS's.
To the first group... Sorry, that's not us. ADL is the governing body for SCORM at this point. They've shepherded it to this point and have stood up the Co-Labs and still manage the evolution of SCORM 2004. For what it's worth, they wouldn't be able to provide this sort of guidance either.

To the second group... you're right, we've seen a bunch of content and LMS's. On certain topics, we might even have useful insight for you. Our problem is this: we want no part of a conflict of interest. If we were to recommend an LMS, we would be choosing amongst our customers and our prospective customers. Each of my daughters does certain things better than her sisters, but I don't choose one of them to love more either. It just wouldn't be right.

So, we've elected to remain agnostic on the subject. I don't have a favorite LMS... in truth, I know a limited amount about each of them... our purview is really limited to the SCORM aspects of these systems.

If you are looking for an LMS, though, I would say this. Make absolutely certain that it is SCORM conformant, and not just a little bit. Lip service simply isn't enough to prove that a system really is conformant. I would look for further indication. Ask your sales person to import a course or two that you provide. Challenge the LMS provider on which versions of SCORM they support. If that vendor indicates they support some SCORM elements, but not all of them, ask them if they're crazy... [This topic, partial SCORM support, is a hot button for me. I promise I'll write about it another time. In fact, in an homage to Alton Brown's frequent "that's another show" references, I will begin tagging posts like this as "that's another post". None of you will find that tag particularly useful, but I certainly will when I need some new material.]

There are bunches of good LMS's out there. Many of them have great SCORM support. A good portion of those do so by implementing the SCORM Engine, and I'm more than happy to tell you if that potential LMS purchase is one of them.

Labels: , ,

9:34 AM 1 comments


Joel on Servanthood
12.01.2008 - Tim Martin

Joel Spolsky is a bit of an icon in the software development world. His blog and conferences are wildly popular, and, for the most part, Mike and I buy into a lot of what he has to say. In a recent article published in Inc. magazine, he had this to say.

"In our company, management's job is to get things out of the way so that all the great people we've hired can get work done."

I couldn't agree more. Whether this means drawing the line for our clients with regard to our responsibilities or breaking down the boxes from our new furniture to get them out of the office, that's what our job is in management. (Frankly, it's hard on me to describe myself with that word; it carries such negative connotations for me from prior employers.)

Joel has accomplished a great deal, but seriously, Joel, we all know you're not this tall...


Labels:

3:35 PM 0 comments


What to do with the interaction data?

Philip over at Pipworks posted some interesting questions related to Adobe's products specifically and what they should do with SCORM interaction data. I think the responses to this question are interesting in their own right (share them publicly, folks, not just with Adobe!)

My question goes a bit farther (and is a bit more self serving)... What would you like to be able to do with SCORM interactions in general? Would a service for housing that information be useful? What would you actually do with that service? Do you believe a service could be general enough to support multiple content platforms while at the same time being specific enough to be really useful?

Thoughts are welcome here or via email to info [at] scorm.com.

Labels:

8:37 AM 0 comments


Archives
August 2005
September 2005
October 2005
December 2005
January 2006
February 2006
April 2006
May 2006
June 2006
August 2006
October 2006
November 2006
December 2006
January 2007
February 2007
March 2007
July 2007
August 2007
September 2007
October 2007
November 2007
December 2007
January 2008
March 2008
May 2008
June 2008
August 2008
September 2008
October 2008
November 2008
December 2008
January 2009

Subscribe to
Posts [Atom]




Products

The ultimate tool for testing, developing and validating SCORM conformant content.


Case Studies

United States Marine Corps - Looking for the best SCORM delivery solution.



Call us for a Complimentary Consultation

(866) 49-SCORM  |  info@scorm.com
HOME |  LMS STANDARDIZATION |  CONTENT STANDARDIZATION |  TEST TRACK |  OFFLINE DELIVERY |  RESOURCES

CONTACT


Copyright © 2002-2009 Rustici Software, LLC. ALL RIGHTS RESERVED