Well, we’ve been living very publicly here at Rustici Software lately. While it’s not quite The Real World or anything like that, we’re becoming progressively more open about our approach and direction. This week, I’ve been working with our legal folks on our click through agreement for the SCORM Cloud. We’ve had great success publishing our term license agreement with annotations. Prospects and clients alike seem to respond to the clarity afforded by one layman’s annotations (mine), so I figured I’d try something similar here. Now that our lawyers are reasonably happy with the state of the click through agreement, I thought I’d share it here and see if anyone would like to comment. Please understand, I make no promise to change this agreement because of your comments! Certain elements are important to our legal staff, and are untouchable. I tried to convince them, for example, that using all caps for the warranty and limitation sections was like screaming. I said, "It’s bad form on the internet." They said… The Warranty Disclaimer and Limitation of Liability sections have to be in all caps because the courts (including Tennessee) have held that any language in a contract that deals with allocation of risk (i.e.waivers or releases of liability) needs to be conspicuous. All caps has been held to be "conspicuous." If you don’t like the all caps, we could highlight the language, bold it, or put it in a larger and different font than the rest of the agreement. I have concluded that blinking text is the right solution. Having said all that, I really do want to hear what you have to say. I figure that this agreement will be public soon enough, and if we’re going to hear complaints about it when we start using it, we might as well hear those complaints ahead of time. So, is there anything in the language below to which you react adversely? Do you understand what you’re entitled to do and how you’re limited? Is this a click through agreement you could tolerate as you build applications around the SCORM Cloud? Lastly, I apologize for the length of the document. At one point, I begged Amy to "cut 30% of the document". She certainly did her best, and I think the result is something simpler and more direct. Alright, you may either click away to something else (as I would) or, if you’re bold, enjoy the legal document! ___________________ RUSTICI SCORM CLOUD SERVICE TERMS OF USE BY CLICKING THE "ACCEPT" BUTTON, YOU ACCEPT AND AGREE TO BE BOUND BY THE BELOW TERMS OF USE WITH REGARD TO USING THE RUSTICI SCORM CLOUD SERVICE ("SERVICE") PROVIDED TO YOU BY RUSTICI SOFTWARE, LLC ("RUSTICI"). IF YOU DO NOT AGREE TO THE BELOW TERMS OF USE, CLICK "DECLINE" AND DO NOT USE THE SERVICE. TERMS OF SERVICE 1. You must use the Service only in accordance with these terms and conditions and the instructions, manuals or other materials regarding use of the Service that Rustici makes generally available to its customers. 2. You must comply with all applicable laws during the exercise of your rights under these terms and conditions (including but not limited to all copyright and export laws). 3. You are responsible for maintaining the security of your account and password. Rustici accepts no liability for any loss or damage from your failure to abide by this provision. 4. You are responsible for all content and materials posted to the Service and activity that occurs under your account. RESTRICTIONS 1. You must not use the Service to store or transmit infringing, libelous, or otherwise unlawful or tortuous material, or to store or transmit material in violation of third-party privacy rights. 2. You must not use the Services to store or transmit viruses, worms, time bombs, Trojan horses and other harmful or malicious code, files, scripts, agents or programs. 3. You must not interfere with or disrupt the integrity or performance of the Service. 4. You must not attempt to gain unauthorized access to the Service or its related systems or networks. 5. You may not use the Service for any illegal or unauthorized purpose. 6. You must not modify, adapt or hack the Service or modify another website so as to falsely imply that it is associated with the Service, Rustici, or any other Rustici service. PAYMENT 1. A valid credit card is required for paying accounts. A credit card number is not required for a free account. 2. You will be billed monthly starting on the 30th day after your account is created. 3. The Service is billed in advance on a monthly basis and is non-refundable. There will be no refunds or credits for partial months of service or refunds for months unused with an open account. 4. All fees are exclusive of all taxes, levies, or duties imposed by taxing authorities and you shall be responsible for payment of all such taxes, levies or duties, if applicable. WARRANTY DISCLAIMER THE SERVICES ARE PROVIDED "AS IS" AND WITHOUT WARRANTIES OF ANY KIND, WHETHER EXPRESS, IMPLIED OR STATUTORY, INCLUDING WITHOUT LIMITATION ANY IMPLIED WARRANTY OF MERCHANTABILITY, NONINFRINGEMENT OR FITNESS FOR A PARTICULAR PURPOSE, ALL OF WHICH ARE EXPRESSLY DISCLAIMED. LIMITATION OF LIABILITY IN NO EVENT WILL RUSTICI BE LIABLE FOR LOST PROFITS, OR FOR ANY INCIDENTAL, CONSEQUENTIAL, OR SPECIAL DAMAGES, HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY ARISING OUT OF OR RELATING TO THIS AGREEMENT, THE USE OF OR INABILITY TO USE THE SERVICES OR ANY MATTER RELATING TO THE SERVICE, EVEN IF RUSTICI HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. RUSTICI’S TOTAL LIABILITY UNDER OR ARISING OUT OF THIS AGREEMENT SHALL NOT EXCEED THE AMOUNTS PAID BY CUSTOMER FOR THE SERVICES. THESE LIMITATIONS SHALL APPLY NOTWITHSTANDING THE FAILURE OF ESSENTIAL PURPOSE OF ANY LIMITED REMEDY PROVIDED IN THIS AGREEMENT. TERMINATION 1. You may terminate your account and access to the Service at any time by submitting such termination request in writing to Rustici at support.cloud@scorm.com. 2. If you cancel the Service before the end of your current paid up month, your cancellation will take effect immediately and you will not be charged again. 3. Rustici, in its sole discretion, has the right to suspend or terminate your account and refuse any and all current or future use of the Service for any reason at any time. 4. Cancellation or termination of your account will result in the deactivation or deletion of your account or your access to your account. All of your content and materials will be immediately deleted from the Service upon termination or cancellation. MODIFICATION TO SERVICES Rustici reserves the right at any time and from time to time to modify or discontinue, temporarily or permanently, the Service (or any party thereof) upon notice, provided Rustici may not provide notice if such modification or discontinuation is for security or emergency maintenance purposes. You agree that Rustici shall not be liable to you or any third party for any modification, suspension or discontinuance of the Service (or any part thereof). OWNERSHIP 1. You acknowledge that as between you and Rustici, Rustici owns all right, title and interest in and to the Service and the accompanying documentation and all related modifications and enhancements. 2. You have no right to the Service except to the extent expressly granted in these Terms of Use and Rustici reserves all right, title and interest in and to the Service. 3. Rustici shall have a royalty-free, worldwide, transferable, sublicenseable, irrevocable, perpetual license to use or incorporate into the Services any suggestions, enhancement requests, recommendations or other feedback provided by you, relating to the operation of the Services. 4. So long as you are using the Service, you may build applications on top of the Service. Rustici claims no intellectual property rights over the material you upload to or build on top of the Service. Your uploaded material and material sitting on top of the Service remains yours. However, by setting your pages to be shared publicly, you agree to allow others to view and share your content. 5. Rustici does not pre-screen content, but Rustici has the right (but not the obligation) in its sole discretion to refuse or remove any content that is available via the Service. ENTIRE AGREEMENT; MISCELLANEOUS These Terms of Use are the sole and complete agreement between the parties and supersedes all prior agreements and understandings between the parties respecting the Service. The waiver of a breach or the failure to exercise any right hereunder shall not be a waiver of any subsequent breach or as a waiver of any other right. If any provision in these Terms of Use is determined unenforceable, such unenforceability will not affect the enforceability of the other provisions of these Terms of Use. The Terms of Use shall be governed by the laws of the State of Tennessee. Any dispute will be resolved in the state or federal courts, as appropriate, located in the Middle District, Tennessee. If there is litigation between the parties related to the Service, the prevailing party can recover its reasonable attorneys’ fees and other reasonable litigation expenses. The sections of these Terms of Use entitled "Limitation of Liability," "Ownership," and this "Entire Agreement; Miscellaneous" will survive after the termination or cancellation of these Terms of Use. Questions or notices for Rustici can be sent to support.cloud@scorm.com.

My recent vacation seems to have inspired Tim to write a few blog posts. I love that he did, but I think he missed an important point in his post about why we chose not to release the SCORM Engine under an open source license. While Tim may be the kind of guy to replace the toaster when it breaks, I’m a bit more inclined to do a bit of tinkering before giving up on it entirely. While I certainly don’t agree with the entirety of Richard Stallman’s philosophy, I do agree that a user has the right to tinker. This is something we’ve embraced since the very beginning of our company; nearly all of our licenses include access to the source code of the purchased product. We do not offer a no cost license nor do we offer a license that requires unencumbered distribution. We do most definitely however provide licenses with open source code. We don’t provide this access out of the goodness of our heart or because we think there is a moral imperative for software to be free. We do it because it makes good business sense. Here’s why: 1) We’re a small company, when we sold our first SCORM Driver license (then known as RSECA), we were two guys working out of a spare bedroom. We’re a bit more established these days, but on the grand scale of things, we’re still a small software company. Small vendors make big clients nervous. Let’s face facts, the odds are against the long term survival of any small company. Nobody wants to be stuck with a product from a defunct company. This is especially true for our products since so much of the value we provide comes from our continued enhancement of the products to track the continued evolution of the standards. Providing our source code in one way to greatly mitigate the concerns that big companies have in doing business with small companies. Even if we disappear, our clients will always be left with something they can continue to work with. 2) Our products are generally very tightly integrated into our clients’ products. To achieve this level of integration, some coding is almost always required. While we’ve isolated all of this work to our customizable integration layer, it is often quite nice to be able to reference the core source code directly to see how things work and explore what methods are available. 3) We sometimes get "free" help from our clients. Our clients are typically software developers themselves, many of whom love to track problems down all the way to their source. On the very, very, very rare occasion that there is a bug in our software, our clients can sometimes point us right to the problem and right to the fix they have already implemented in their system. We welcome anything that makes our lives easier, so thanks! 4) The biggest challenge we face when deploying the SCORM Engine is the fact that every LMS is slightly different. While there are many commonalities, each system has its own set of features and quirks that make it unique. For the SCORM Engine to be tightly integrated, it must be able to reshape itself to be consistent with each of these quirks. Over the years, we’ve seen enough of these that in most cases the integration layer is flexible enough to handle whatever requests are thrown at it. Occasionally however a client has a need that requires a customization. Providing them with the source code allows us to be able to make the required customization just for them while we build the flexibility to make that customization through the integration layer into our core product. Being so tightly integrated, clients occasionally want to modify the SCORM Engine to be implemented consistently with the rest of their code base. We generally discourage any customization since it hinders our ability to provide clients with future updates, but by providing the source code, we are able to let clients make the best decision for their particular needs. 5) Our products are at the very core of our clients’ products and they are vital to the operation of the products they serve. We provide very important and very visible functionality to our clients. It is important enough that it is worthy of examination. We recognize that the decision to outsource vital functionality can be a hard one (but also the right one!). We want to do everything in our power to make our clients feel comfortable with the quality and implementation of our products.

The chips I often eat at lunch give me time to read a bit more broadly on learning and education than our typical SCORM minutiae. My hope is this balance helps us innovate and avoid the myopia that can overcome those obsessed with learning standards. I found my way to a great article/aggregation of thoughts from Brad Burnham at Union Square Ventures. Fred is suggesting that the education industry may soon face the same challenges that currently confront the music industry and the newspaper industry. Like those industries, education can be peer produced, delivered as bits, and curated by a community. Like the music and newspaper industries, the cost structures embedded in the education industry’s current business models may be very difficult to support in the face of competition from hyper-efficient, web native businesses. Unlike the music and newspaper businesses, education plays several roles in current society. As I’ve mentioned before, my wife is largely anti-technology with regard to learning and education. (Our kids don’t even watch TV, let alone sit at the computer for hours.) This creates a great dichotomy when thrown against the technological nature of my job and the people I’m working with on a daily basis. These folks love technology for its own sake. In truth, I think it results in great balance too… Will what we’re doing actually help learners? Is it accessible for someone who doesn’t love learning technologies for their own sake? I have no conclusions for you today. These kinds of questions, complicated, deep questions, are what continues to make my job fun. Can we at Rustici Software provide infrastructure that plays a significant role in the reduction of the cost of eduction? Can it be pushed toward "0 + bandwidth" as Brad suggests? Can the SCORM Cloud play a role in that, and further, does SCORM even fit well with that intent?

SCORM Untethered is our disconnected player. We’ve built it as a set of components, and frankly, we’re not publicizing it a lot these days. It solves certain problems very well, but it has its limitations as well. (It only supports Windows clients and .NET server deployments). As of late, we’ve decided to leave Untethered as it is and see if our customers’ interests dictate changes. Having said all that, we still do get calls regarding Untethered with some regularity. Often we do an online demo to show folks what it can do out of the box. Occasionally, though, folks prefer to do something on their own schedule, so I put together a little SCORM Untethered Demonstration Screencast. Please understand, we are not a media production company! This is low fidelity… you can even tell where someone knocked on the door, forcing me to stop and restart. And apparently I didn’t get the microphone back in exactly the same spot. Oh well. I think this tells a pretty good story about what can be done with SCORM Untethered, though. If this is of interest to you, let us know.

Tom King recently tweeted a great blog post on ZDNet by Jeremy Allison that teaches some great lessons about standards and the creation of true interoperability. The ZDNet post is a reaction to a post by Rob Weir that explains how Microsoft created an implementation of the ODF standard that, while strictly conformant, actually serves to reduce interoperability as a whole. Achieving real interoperability requires that the implementer want to be interoperable. No matter how great a standard is, if an implementer doesn’t embrace it, interoperability for the industry as a whole suffers. Standards are merely tools which can be used or misused. These discussions so closely parallel what happens in our industry that I had to repeat them here. These are some of my favorite quotes and they sum up the important points quite nicely (note the quotes are mixed from the two links above, and words in [square brackets] and emphasis are mine): Surely if you implement a standard fully…, then you must have an interoperable product. So long as others also implement the standard as written, then everything should just work together. That’s the way things are supposed to work. One of the reasons is that standards themselves are often not perfect…[people are] claiming the ODF standard itself is at fault. Remember, it is not particularly difficult or clever to to take an adverse reading of a standard to make an incompatible, non-interoperable product. Take HTML…I could create a perfectly conformant browser implementation that makes all default text be 4-point Zapf Dingbats, white text on a white background. It would conform with the standard, but it would be perfectly unusable by anyone…you can create 100% conformant, but non-interoperable, implementations of most standards. Standards are voluntary, written to help coordinate multiple parties in their desires for interoperability. Standards are not written to compel interoperability by parties who do not wish to be interoperable. …if your sole goal is to claim conformance. If your business model requires only conformance and not actually achieving interoperability, then I wish you well. But remember that conformance and interoperability are not mutually exclusive options. A complete cynic would say that was what was intended…causing confusion in the marketplace like this was designed to make customers scuttle back to the safety of only using Microsoft Office Of course, I am not that cynical. I was taught to never assume malice where incompetence [lack of effort / taking the easy way out / having other priorities] would be the simpler explanation. …the concept of "Working to Rule". When a union is trying to negotiate with management, there are a broad range of options they can take before using the ultimate weapon of going on strike. One of these tactics is "Working to Rule". Normally in a working day, there are hundreds of small rules that people ignore in order to get their jobs done. From refilling the coffee machine for themselves…to fixing small problems with the machines they use for the job. "Working to Rule" means deliberately obeying every single one of these rules…Punctilious observation of every possible rule in order to disrupt orderly working. This is what Microsoft has done with ODF in SP2. So how do you do real interoperability? …we go out of our way to make sure we work with other vendors implementations. We attend interoperability testing conferences, where we work with the engineers of other vendors (including Microsoft engineers) to ensure that customers deploying any of our implementations don’t get any nasty surprises. We’ve changed our code to work with Windows 95 and 98, Windows mobile, Windows CE, Windows 7, Network Appliance, a host of un-named embedded versions of CIFS in different appliances, even old versions of OS/2. It’s not hard, it’s just careful, detailed work. The only rule is to follow the words of the Internet Engineering Task Force (IETF) for interoperability, "Be conservative in what you send, be liberal in what you will accept." Simply substitute "SCORM" for "ODF" above and you have a great explanation to questions we are often asked. "Why should I use the SCORM Engine instead of just using the ADL Sample Run-time Environment?" "I took a look at the specs, I think I can do this myself, it’s just code, why should I buy your products?" "What’s the big deal, it’s just XML and JavaScript?" "Why is your SCORM implementation so much better than X?" "Why does my content work in your product but not in X?" True interoperability is the answer to all of these questions. Achieving true interoperability requires going beyond the standard. It requires implementing the intent of the standard. It requires understanding what the authors meant to say rather than just what made it into print. True interoperability means you need to be able to read the standard and interpret it as others might, be that interpretation right or wrong. Being truly interoperable requires testing, testing and more testing to ensure that your products work with everybody else’s. More importantly, true interoperability requires you to be ready and willing to make changes to accommodate other companies’ differences of opinions…and to be able to do so in a way that doesn’t conflict with other implementations. Like Jeremy Allison says, "It’s not hard, it’s just careful, detailed work." At Rustici Software, achieving real SCORM interoperability is our mission. It isn’t something we do on the side, it’s not a back-burner task. SCORM isn’t something we do once and then move it, it is a constant process of evolution and innovation. There are some that give SCORM a bad rap. I can understand where they are coming from. Unfortunately we have an industry where several of the largest vendors have "worked to rule". Their implementations are technically conformant and they have a certification label from ADL, but they have stopped far short of achieving real interoperability. This can be incredibly frustrating to an end user and it’s easy to see how SCORM gets the blame. When you really get down into it though, SCORM is quite a good standard from a technical point of view. I think the people often underestimate the difficulty of the problem that SCORM is trying to solve. It does look simple at first glance, but the devil is always in the details. The real complication comes from the "very many to very many" relationship between content producers and LMS’s. There are literally thousands of LMS’s out there (a fact that surprised me when we got into this business). Compare that to the number of consumers of HTML or ODF content. According to Wikipedia, just 5 web browsers make up 98.89% of the market usage. The LMS market is FAR more fragmented, yet the expectations for seamless interoperability are just as high. Let’s just consider our expectations with HTML/CSS. Even after many generations of specifications, there are still slight variations in how web pages are rendered in different browsers. Just consider this blog home page as rendered in two of the top three browsers. Even when using the most common browsers, there are still slight differences. We know about these, they’re annoying, but it’s acceptable and those that seek to create interoperate by and large are able to. (and as an interesting aside, compare the browser compatibility of this page, designed largely by me, vs our home page which was designed by professionals who know their way around browser quirks) SCORM is no different, it certainly has its quirks, but by and large it enables interoperability for those who seek it. As Rob Weir says standards can’t "compel interoperability by parties who do not wish to be interoperable". What standards cannot do however, customers and markets can. If your vendor is "working to rule" and hasn’t implemented SCORM in a truly interoperable way, it significantly decreases the value you can realize from their product and it brings down the industry as a whole. Let them know that it is not acceptable. As SCORM evolves, we will certainly do everything we can do close the loopholes, but SCORM will only be truly interoperable if the industry demands it.

I love when I come upon some independent research that informs me of something I didn’t know. Truth be told, I base a lot of my assumptions about LMS cost on the original price offered by my first eLearning employer. (List price at PureSafety back in 1999 was $79/employee/year.) I get the sense that the industry might have changed a bit since then. So, when a random tweet pointed me to this blog post, I was psyched. Brandon Hall does a lot of independent eLearning research, most of which you have to pay for. I get that, I do, but it substantially reduces the amount of their stuff that I actually get to read. This post, however, shared some really nice aggregate numbers about LMS pricing. The average price for an LMS, based on a three year cumulative price: HOSTED (Saas) IMPLEMENTATIONS: 500 users: $68,977 10,000 users: $314,444 25,000 users: $568,201 100,000 users: $1,288,054 INSTALLED IMPLEMENTATIONS: 500 users: $48,231 10,000 users: $260,569 25,000 users: $486,076 100,000 users: $1,204,942 This, alone, is likely useful information for a lot of folks who read this blog. Brandon Hall undoubtedly has a lot to add beyond this top level of data. They’re studying, in particular, the low-cost LMS providers in this case. To qualify, a company has to be below average in all four categories. So, if you appreciate the information, follow up with Brandon Hall. For my purposes, this information is interesting because it allows me to assess the "reasonableness" of our pricing. First off, let me make it clear that I understand we are not selling an LMS. We are selling a piece of an LMS. What portion of an LMS is SCORM/AICC content delivery? This question interests me enough that I’ve wandered around much of the day asking folks about it. @timpmartin a very small percentage, maybe 10%, we use LMSs mostly for instructor-led classes & general reporting. @pipwerks, a regular reader of this blog For some, there was an important distinction: functionality vs use. If an LMS has 500 features, perhaps 25 of them relate to the delivery of standards based content. That would put the functionality number at, say 5%. That 5% of the LMS, however, might be used dramatically more than the other features, given its fundamental, core nature. If you were to use page views as a metric, or something similar, consensus among my sparring partners was that the number would be substantially higher. Might 50% of page views in an LMS relate to the delivery of content? My sense is that that might be a reasonable number. @timmartin expressed as a % of the actual functionality AVAILABLE in a LMS, <5%. expressed as a % of actual usage of the LMS, 50% Mike Rustici Also of interest was how an individual’s perspective affected their opinion on the subject. As we’ve long known, learning-focused individuals make use of SCORM/AICC less than training focused individuals. Put simply, people who care about recording completions generally care more about SCORM/AICC. @timpmartin Re. SCORM AICC. Very little in higher education. Our faculty do not use rapid development tools. No need for tracking. @mathplourde I love this stuff… I can’t get enough of how different people perceive value in varied aspects of an LMS. What’s the point? Well, frankly, this is all interesting to me in and of itself, but there’s a message about the SCORM Engine here as well. I believe the SCORM Engine fills a fundamentally important role within any LMS. Content delivery, in my mind, is what an LMS is there for. The following chart shows what portion of the cost of an LMS would be allocated to the SCORM Engine based on the average prices provided by Brandon Hall above. If an average LMS vendor sold one license of their product for 500 users, we would be eating a huge portion of their revenue… 70%. For a company making a single sale with 10,000 users, we’re coming in at 15%, still a large number. But as these "average" vendors resell their product, the SCORM Engine cost burden drops substantially. Take the red line, the 10,000 user line with 10 implementations… the SCORM Engine cost burden is down to 3%. By any measure, utility, functionality, or even support, content delivery is at least 3% of the effort burden in an LMS. If you intend to sell your LMS more than once, and I certainly hope you do, then the investment in a solid content delivery mechanism makes good sense.

I am a patient man. Slow to anger, slow to annoy. Frankly, some mistake my calm demeanor for apathy. But now they’ve done it. The folks on Twitter (and elsewhere in the community) have made enough comments about SCORM that I’m annoyed. That’s right, I’m actually a little irritated. I’ve been feeling, lately, like SCORM is my little brother. It’s OK if folks choose to pick on my bro, so long as they are constructive, or at least right. The comments I’ve been seeing lately range from misdirected to out and out wrong. - @jclarey SCORM? With an M? Gee, I always pronounced it "SCORN." - @Dave_Ferguson SCORM arrrgh. Go To HELL !! - @frdsrcks maltido Adobe SCORM Packager!!! - @bloggus Note: Congrats to @bloggus for catching Adobe in the crosshairs! Do any of you love SCORM like I do? #sarcasm - @johndavidblack Before I dive into a full fledged defense of SCORM, let me say this… I am not an outright fanboy for SCORM. I have implemented both content and LMSs with SCORM, and I understand the hassles intrinsic to the standard. I understand that SCORM can be a complicated problem. I’ll even go off the reservation here, in a way that will likely annoy some SCORM purists with whom we work regularly, and say this, "SCORM 2004’s sequencing and navigation? Well, it pretty much hurts my head." That’s right, there are pieces of SCORM 2004 that are great. I do believe that it’s better, in total, than SCORM 1.2, but it’s not all hunky dory. With that context, and with my self-loathing credibility intact, I’ll also say this. SCORM is really well put together. If you doubt that statement, I’ll ask you this… Have you read the specification? Can you really say you know the spec? I challenge you to read it as a software developer… the concepts are well documented. The examples are thorough. SCORM’s API is simple… it has a grand total of 8 methods. Seriously. The vocabulary is publicly defined and direct. Failure to make proper use of the standard is not an admonition of the standard itself! Has SCORM addressed every possibility? No. Is it iron-clad? No, it’s not. But is it fundamentally sound? Can those who are willing to dig into it implement it in a way that increases interoperability in a dramatic fashion? Absolutely. SCORM has moved eLearning interoperability miles ahead. This is undeniable. Complaints about SCORM’s impact on reusability are also more than reasonable. SCORM has admittedly failed in this regard, but that failure stems as much from the instructional design challenges as it does from SCORM’s technical shortcomings. So I’m going to ask you a favor, "Ye Olde Basher o’ SCORM". If you’re gonna go after my little brother, make sure you’re going after the right guy. If you’re complaint is with the standard itself, go ahead and attack the standard itself. (Say, if you think Javascript is an extremely limiting communication technique and webservices would be a better approach.) If that’s your beef, I’ll join in with you. But if you’ve got a conformant piece of content, and your LMS won’t import it, don’t jump on the standard, jump on your eLearning vendor! When your content won’t report completion in Saba, jump on Saba. If TestTrack is failing to represent SCORM 1.2 rollup effectively, as it is today, jump down my throat. But get it right; go after the right perpetrator. So, I’ll be inviting the "haters" to this page as I encounter them. Folks who twitter about how SCORM "kicked their cat" or "blew their house down" will be invited to vent… I’m all for the dialogue. And I’m all for the challenges. I’m no SCORM homer, but I’m also prepared to point the finger at the real culprit. As vendors fail to do their job well, we collectively need to understand when SCORM is failing and when vendors are failing. If you’re a hater, lay it out for all of us in the comments. Let me feel your pain.

On our website, we invite every visitor to ask us questions. Generally, these questions are about SCORM or something eLearning related. Sometimes, though, they aren’t. These questions, sometimes, are among my favorites… When you, our peeps, come up with some great questions, we’ll share them… So, challenge us. Dale, from Appleton, WI, asks this… (OK, he may not really be from Appleton, but Casey Kasam would want it this way…) On the topic of appropriate sides for schnitzel, the answer is always potatoes. The question is the preparation: fried, mashed, or potato salad? First, and most importantly, my mom says… False! Schnitzel is always eaten with spaetzle! And, it seems, my mom is right. auntcy1, a commenter on America’s Test Kitchen considers the spaetzle a given. From there, though, the consideration of potatoes comes into play. Potato salad, it seems, is worth dismissing because my wife, the foody, simply doesn’t like it. When you’ve grown up in a house full of women, you understand fully that when your wife says no, off you go. So, that leaves us mashed and fried. For this one, I’ll take the initiative and say… the answer is fried. Quite simply, a potato that crunches is better than one that doesn’t. I invite you all to argue, if you like, provided you understand that if you choose something other than fried, you’re just plain wrong.

We’ve been slaving away on our SCORM Engine 2009.1 release around here and John stumbled upon something pretty exciting yesterday. I thought I’d go ahead and share it… Mind you, these are anecdotal, but fairly representative, numbers. We often use some old Photoshop courses, provided by ADL, to do some of our testing come release time (in addition to everything in the test suite, and our automated tests). John was using the IE profiler to see how some sequencing/logging enhancements he’d made would affect performance… Prior to the enhancement, launching Photoshop Linear was taking 1.25 seconds of javascript processing time. Afterward? 0.17 seconds. Prior to the enhancement, clicking the "next" button took 2.18 seconds of javascript processing time. Afterward? 0.24 seconds. Our look ahead sequencer is already one of the distinguishing factors of our SCORM Engine. It allows us to avoid server round trips where most LMSs require them, thereby improving the learner’s experience. At the pace it ran in 2008.1, it was already vastly better than most LMSs. Now, it’s running 7 - 9 times faster. We’d been intending to hold 2009.1 until ADL was ready to test it. We’re getting tired of waiting, so we’re going to release before the testing opens. Watch for further news of the release here.

By background, Mike and I are both technical folks. We went to the same school, graduated from the same program. While we both speak conversational English (as opposed to off-puting tech), neither of us has great expertise in marketing. Opinions? Yes. Expertise? Not so much. We have known for years that we would eventually need help in sharing Rustici Software’s products and abilities with the world. We just knew that finding the right person would be a magnitude more difficult than finding the right developer. So, what did we do? We punted. We just kept finding great developers, handing over our development responsibilities to them, and taking on more of the marketing work ourselves. A few months ago, I was perusing Seth Godin’s blog as I often do, and I came upon this post about his alternative MBA program. First off, the program itself sounded incredibly interesting. Second, I came upon someone’s bizarre concept of hiring a boss. This was intriguing. Bold even. So, I clicked through. Can you say SERENDIPITY? (My mother certainly can; it’s among her favorite words!) I kid you not… Mike and I both read Susan’s site cover to cover and immediately knew that she got the single most important thing to us… tone. SCORM we can teach. Tone, in our book, is something that has to be innately understood. We were going to be asking someone to help us market our company, and it was fundamentally important to us that her voice, her ethos, be consistent with ours. So, we started to work our way through Susan’s well defined 10 step process. By about step 3, everyone in our offices knew that I was pretty excited. By about step 7, my dad was wondering what this was all about. (No, Dad, hiring process aren’t exactly what they were when you worked at the industrial brush company.) And finally, step 10, where Susan comes to work, is set to occur August 24th. We’re thrilled. Sincerely. Susan is going to be helping us define, market, and evangelize the SCORM Cloud and the applications that get built around it. We hope you’ll come check up on Susan, Rustici Software, and what we build together over the next months and years. Kudos to Susan on a bold approach to finding the right job. Kudos for voicing what we could expect of her and what we couldn’t. Kudos on her great taste in bosses.