We originally introduced the world to SCORM Cloud in 2009. If you count it’s predecessor, TestTrack, it dates back even earlier. Since then, the website has remained largely untouched. We figured it was way overdue for a change. On March 24th, 2017, we rolled out an updated SCORM Cloud user interface. Initial reviews have been fantastic!
“Loving the new @SCORMCloud #UI – nice, clean #design!” #development #scorm
“The new dashboard looks amazing.”
“The new portal is fantastic. The new layout and design looks amazing. Thank you for the hard work and effort.”
While most features have remained the same, there are a few items that have shifted around to make them easier to use- the xAPI LRS and Invitations for example.
To see more about all of the changes, check out this handy guide to navigating the new Cloud UI.
This week LTG (our parent company) announced the formal acceptance of their bid to acquire NetDimensions. Depending on who you are and what you know, this may or may not seem like a big deal, or even a potential threat.
I wanted to quickly, publicly, and officially alleviate any concerns you may have.
When LTG acquired us a little over a year ago, Mike and I made clear that it was crucial to us that Rustici Software be allowed to serve its customers in exactly the way it always has… agnostically. We’ve never recommended amongst our LMS or content providing customers. We just wouldn’t do it, and we won’t do it. And that’s still true today, with full knowledge of the NetDimensions acquisition.
A related story: LTG owns a content authoring platform, gomo learning, which does not use any Rustici products. At the same time, we have provided our SCORM Driver product (which also supports xAPI/cmi5) to Articulate, Adobe, and Dominknow, competitors of gomo’s.
Early in the integration process, we were asked by gomo folks if we could integrate gomo directly into SCORM Cloud as a way to introduce their product to our many users of SCORM Cloud. Doing so almost certainly would have brought some prospects to gomo and increased the revenue of the group as a whole, and could have potentially brought Rustici some referral revenue as well.
We refused. And LTG supported that choice.
(gomo has also been given the freedom not to acquire our software, too, for what it’s worth because they already had a reasonable solution in place.)
This autonomy is crucial to our ability to serve so many of the vendors in the industry, many of whom compete with each other.
If some of the folks at NetDimensions ask my opinion about how and whether they should adopt xAPI, I will certainly offer it, just as I would for any other LMS vendor who calls upon me. If those same people ask me to inform them about another LMS vendor’s plans in this regard, I merely point them to publicly available information. More directly: we will offer our services and products to NetD, and they will have the ability to procure them, just like we would with any other LMS provider.
So, congratulations to LTG and NetD both. It’s an exciting combination for parts of the group, and business as usual for Rustici Software.
Today we’re excited to announce support for a new specification in SCORM Cloud- cmi5, which is something that doesn’t happen all that often in its history. Along with making cmi5 support readily available in SCORM Cloud, we’ve also added support for cmi5 to some of our other products including SCORM Engine and SCORM Driver.
Obviously, supporting a variety of specifications is a huge part of what we do well at Rustici Software. More than anything, though, I think it’s important for us to be conscious of, and to explain well to all of you, when and why we add support for a particular specification.
So, what is cmi5?
cmi5 is technically a profile of xAPI which means it piggy backs on top of things already well defined in xAPI, but adds specificity in others. For cmi5, this means that certain xAPI statements are required, and launch is handled in a very specific way.
For me, it’s the launch piece that’s so important. From xAPI’s advent years ago, there have been issues with launching content. In the earliest days, we at Rustici Software defined a very simple launch specification that several content vendors picked up on. It was good enough for the time being, but it wasn’t really good enough in practice.
So, over the last couple of years, many people including Bill McDonald (as Chair of the working group) and Art Werkenthin and others at RISC have put a lot of energy into considering how their AICC work could be applied to launch in the xAPI world. The result is that we have a good solution for launching content via xAPI.
Why it matters
Years ago, as we at Rustici Software and others around us started evangelizing xAPI, we made some mistakes. We talked about all of the things that could be enabled by xAPI, the things for which it was necessary but not sufficient. Over the last year or two, we’ve really started to fill in the gaps to make it sufficient as well. And while launch isn’t the dreamiest of capabilities for which xAPI is a solution, it is absolutely fundamental.
If content launch is ultimately going to transition from SCORM to xAPI, cmi5’s support for launch will be a requirement. And further, so many other activities actually benefit from having a well defined, implemented, and adopted specification for launch. So for now, we’re excited to share that Cloud now offers vendors and others a great place to test cmi5 based launchable activities. We hope this helps spur the development of many xAPI/cmi5 adopters.
Here at Rustici Software, we’ve been spending a lot of time lately hosting SCORM Engine and Content Controller installations on behalf of our clients. And we have learned a lot of interesting lessons from the experience. I’ll be talking about hosting SCORM Engine here, but all of this stuff applies directly to Content Controller as well.
We started hosting things for folks because we realized several things all at once:
Our clients are having to spend way too much time and money to host our products themselves. We kept seeing integrations falter because of delays in provisioning infrastructure and cost issues. Finding dev/ops folks that can deploy and manage web applications is really difficult and really expensive, and so a lot of our clients were settling for inadequate deployments that didn’t scale and didn’t hold up well under pressure
Hosting web applications well is really hard. It’s not too hard to stand up a server and run Engine on it. It’s a lot harder to build a secure, highly available Engine environment that can hold up under heavy traffic spikes, scale to meet demand, and not cost a fortune.
We are really good at hosting web applications. Our experience building SCORM Cloud taught us that we’re actually really, really good at hosting web applications at scale, and it felt like we were in a great position to provide a useful service that saved our clients time, money, and hassle.
What’s a user? How many can we support?
When folks are integrating with SCORM Engine, two questions always come up: “how do I build a system that can serve X number of users?” and “I’m not really sure how many users I have, how do I spec a system based on a wild guess?”
We thought about this a great length, and decided that there are two numbers that really matter:
Concurrent Users – The number of users that the system can serve at once.
System Population – The system’s ability to serve a given annual user base.
System Population, in particular, is a number that we thought about a lot. Engine installations very rarely have every registered user of the system engaged at once. But sometimes (like right before a deadline) they all pile on at once, so we designed our Managed environments to be able to grow and shrink so that they can meet peak demand without costing the Earth.
Once we figured that out, we went and locked ourselves in a dungeon laboratory* for a few weeks and ran load tests against every kind of setup we could think of. We came out of that with a set of system specs that we could look at and say, “yup, this will do the job for X Concurrent Users and Y System Population, and here’s what it will cost to make it go.”
When we looked at the economics of our clients hosting a robust, production-quality web application, it was clear that the cost of the computer hardware wasn’t the problem. Nor was datacenter space, bandwidth, storage, or any technical bits. It was the human beings and human intelligence needed to build and maintain that were our client’ greatest cost and most scarce resource.
When you add it all up, the annual costs for hosting a production-quality web application that is going to serve a population of 50,000 users quickly goes north of $150,000. That’s too much. Way too much.
Fortunately, we’ve got a lot of people here at Rustici that do this kind of thing all day long and are really good at it, which lets us provide Galaxy-class Managed Hosting of our products at a fraction of what it would cost our clients to host themselves. We can provide a production quality, geographically redundant, highly secure, zero-touch Managed environment for under $35k annually. That’s a huge savings in time, money, and effort. To get an idea of what it might cost using our services to host your instance of Engine or Content Controller, check out our fee schedule.
So, when considering Engine or Content Controller, remember that you have options when it comes to who handles the deployment. We’re here to help. Just ask.
*Well, it was more like a nice sunny office with hot coffee, snacks, and ping-pong, but a dungeon sounds way cooler.
We’ve launched a new services group.
For years, we have relied on our products to be the solution to a number of complex problems facing companies that use elearning standards. If you’re building an LMS or authoring tool and you need AICC or SCORM or, more recently, xAPI, we have products that can do the heavy lifting. That’s been our bread and butter.
But we also have insights from years of thinking about experiential data and hearing how customers report on it. And we know that the problem isn’t always solved at the immediate boundary of our products.
It’s those considerations that brought our services group to life.
What We Do
We help vendors and organizations consider how to use elearning standards to accomplish their goals. These goals include delivering learning materials to their people and selling their products to discerning buyers.
We work on problems related to the elearning standards, namely, AICC, SCORM, and xAPI.
In the case of SCORM and AICC, we can help with problems of thinking through how both historical and newly captured data could be expressed as xAPI; we can help rethink complex learning systems; and we can do sophisticated custom elearning development.
Of course we also think hard about xAPI, the newest in the family of learning standards we closely follow.
Where You Come In
We want you to ask us a question. You can learn more about how we’re responding to the questions we’ve already heard. These are things we anticipate. Maybe something on this list prompts a question you were getting ready to ask. So, ask away- we’re listening and ready to help.
Older Posts »