User Interface (UI) Interoperability for SCORM 2.0


Published on

Some of the Department of Defense (DOD) services have had negative experiences when attempting to share SCORM content packages between their various LMS implementations primarily due to differences with both user interfaces and the Application Programming Interface (API) Implementation. The vision of plug-n-play interoperability of learning content is usually achieved only after several additional hours of modifying the content to work in a particular LMS implementation. In order to achieve adoption on a global scale, SCORM 2.0 must have a strategy to improve interoperability by standardizing the user interface controls in further support of flexibility, usability, accessibility, and durability. This paper provides a background and summary of the Navy's successes with extending the SCORM to support standardized user interface options, and further proposes creating or incorporating a new user interface interoperability specification and a recommendation for supplying a standardized API Implementation as part of the Core SCORM.

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

User Interface (UI) Interoperability for SCORM 2.0

  1. 1. A WHITE PAPER FROM THE NAVY EDUCATION AND TRAINING & PROFESSIONAL DEVELOPMENT TECHNOLOGY CENTER User Interface (UI) Interoperability for SCORM 2.0 Jason Haag Principal Systems Engineer Computer Sciences Corp. Navy eLearning Pensacola, FL ABSTRACT Although one of the primary tenets of the Sharable Content Object Reference Model (SCORM) was to promote interoperability of learning content, it still remains one of the biggest challenges today. The SCORM has been highly successfully in making the run-time communications and the learner’s performance data associated with learning content, interoperable, by incorporating the IEEE 1484.11.2- 2003 Standard for Learning. However, SCORM has remained silent about how a Learning Management System (LMS) can implement various technical aspects of the user interface. The SCORM has far too long dismissed several elements of the user interface as being “outside the scope of SCORM”. Ignoring how the learner may interact with or access their content from an LMS (or other content delivery application) has severely and negatively impacted both the technical interoperability of SCORM content as well as the user experience of the learner. Addressing “why” the learner may interact with various elements of self-paced content is the primary responsibility of the content development team, but the SCORM should provide a specification that would present options for “how” the learner might interact with multiple user interfaces regardless of the technology medium employed to deliver the content (e.g. web browsers, mobile devices, etc) . Some of the Department of Defense (DOD) services have had negative experiences when attempting to share SCORM content packages between their various LMS implementations primarily due to differences with both user interfaces and the Application Programming Interface (API) Implementation. The vision of plug-n-play interoperability of learning content is usually achieved only after several additional hours of modifying the content to work in a particular LMS implementation. In order to achieve adoption on a global scale, SCORM 2.0 must have a strategy to improve interoperability by standardizing the user interface controls in further support of flexibility, usability, accessibility, and durability. This paper provides a background and summary of the Navy’s successes with extending the SCORM to support standardized user interface options, and further proposes creating or incorporating a new user interface interoperability specification and a recommendation for supplying a standardized API Implementation as part of the Core SCORM. ABOUT THE AUTHOR Jason Haags professional interest and background is in learning technology. He is currently employed by Computer Sciences Corporation as a principal systems engineer on the U.S. Navy’s eLearning program where he has been involved with implementing the SCORM for more than seven years. He is an ADL Sharable Content Object Model (SCORM) technical working group participant, represents the US Navy on the Defense Advanced Distributed Learning Action Team (DADLAT), member of the IEEE Computer Society, and IEEE Learning Technology Standards Committee (LTSC). He also operates and maintains a free SCORM resource website, CONFORM 2 SCORM,
  2. 2. Learning Education Training Systems Interoperability (LETSI) SCORM 2.0 White Paper Solicitation - August, 2008 User Interface (UI) Interoperability for SCORM 2.0 PROBLEM DEFINITION LMS implementations. These launch behaviors andArguably, the most important of the “-ilities” of the other UI aspects are inherent properties of the webSCORM is interoperability. One of the most critical browser such as the width and height of the browser,problems with previous versions of the SCORM is that the browser toolbar, resizing, and the area where theit never required the implementation of a standard user content is first accessed within the browser windowinterface (UI). This topic, user interface hierarchy (e.g. frameset, new window, etc.). Theseinteroperability, will be the primary focus of this paper, aspects of UI severely impact the interoperability andbut there is a secondary aspect of UI interoperability must be addressed in SCORM 2.0.that will be also be addressed: the SCORM ApplicationProgramming Interface (API) Implementation. Differing API ImplementationsPrevious versions of SCORM primarily addressed the In addition to addressing the UI challenges associatedinteroperability of packaging the content and the with the web browser, SCORM 2.0 must supply ainteroperability of the Run-Time Environment (RTE) standardized methodology for supplying the APICMI data model. Unfortunately, a standardized Implementation. While the SCORM actually providedapproach for supplying both the 1) UI for launching example approaches to supplying the APIthe content and the 2)API Implementation were not Implementation, LMS vendors did not often use theaddressed in SCORM, and consequently were left to be same programmatic strategies or technologies and as asupported in proprietary methods by competing LMS result, interoperability and sharing of the content wasvendors in the eLearning marketplace. As a result, not easily achieved without making majorinteroperability has not been fully realized by programmatic changes to the content itself. Whileconsumers of SCORM. In addition, previous versions SCORM eventually improved run-time interoperabilityof SCORM did not account for inevitable changes to by removing all of the SCORM 1.2 optional aspects ofthe primary delivery medium: the web browser. implementing the CMI data model, the various technologies employed by LMS vendors remained non-standardized. The introduction of Sequencing andInconsistent User Interfaces Navigation further complicated things and often madeThe US Navy has collaborated with the US Marine each LMS vendor’s API Implementation even moreCorps (USMC), the US Coast Guard (USCG), and unique and proprietary. Many LMS vendors often usedvarious other international military services and Java and/or other technologies to develop their ownorganizations in contact with the US Navy for the API Implementation, and provided the API inpurpose of sharing their existing content libraries. inconsistent locations within the browser windowWithin the DoD community there are several web- hierarchy. The resulting approach to accommodate thisbased mandatory courses that often reflect the same inconsistency was to usually make changes to thesubject matter so making content sharable was the one content as well as the sample JavaScript-based APIof the most obvious advantages that SCORM promised wrapper provided by the Advanced Distributedto deliver. While the US Navy has experienced some Learning (ADL) initiative. Java remains adegree of success in sharing content with other DoD technological challenge with the US Navy and USMCservices it did not initially happen without a great deal because of the tightly secured workstations that aof additional modification and manual labor required to majority of the learners use for accessing content.first make the content interoperable. The concept of While Java is often touted as being platform-making content “plug-n-play” was a primary goal of independent there still remain some accessibility andSCORM, but is has not been easy for content configuration challenges to its usage within the Navy.developers to achieve primarily because the UI for The prospect of not supplying a standardized APIlaunching the content was not implemented in a implementation will continue to provide furtherstandard manner by LMS vendors. The aforementioned challenges to the interoperability of content if nottechnical modifications made to the content are usually addressed in SCORM 2.0. The code base andattributed to making changes such that content will technology employed for the API implementation inbehave in a consistent manner by uniquely different SCORM 2.0 must be both ubiquitous and controlled in
  3. 3. Learning Education Training Systems Interoperability (LETSI) SCORM 2.0 White Paper Solicitation - August, 2008order to withstand inevitable changes to web browsers, 1.2 (e.g. rollup, scoring, etc.). With the release ofoperating systems, and other technological variables SCORM 2004, some of the interoperability issuesthat are paramount to the delivery, portability, and associated with UI navigation such as “exiting” wereinteroperability of the content. With the recent addressed, but several other UI challenges stilladvances in mobile standardization and best practices remained constant. As the Navy’s learner populationprovided by the World Wide Consortium (W3C) and content library continued to grow, so did theMobile Web Initiative, device independence should be requirement to support a wider content distributionanother key consideration. A standardized API strategy. The requirement to provide equal access toImplementation should utilize technology that would learning opportunities throughout the Fleet forced thebe supported by any delivery platform and accessible Navy to plan for content to be deployed to multipleon any device. Finally, the code base for a standardized learning management systems and their respectiveAPI Implementation could be centrally controlled by a environments such as classrooms, classified/SIPR,LETSI working group or IEEE working group so that ships and submarines, and disconnected/offlineboth new technological innovations as well as changes applications. Interoperability soon became the USto existing delivery platforms and devices could be Navy’s primary goal when deploying SCORM content.uniformly supported. As a result of these UI interoperability challenges, new deployment requirements, and inflexible support of USE CASE SCORM 2004 from the LMS, the US Navy sought outThe US Navy deployed their first instance of a a solution from Rustici Software, LLC. The Navy firstSCORM-conformant LMS during the era of SCORM learned of the Rustici SCORM Engine (RSE) product1.2 (circa 2001). Many challenges to interoperability after several discussions and collaboration with thewere first recognized during the testing of SCORM- USMC. The RSE was being used by the USMC’sconformant content that had only been previously LMS and had been offered to the US Navy to fill thetested in the ADL Conformance Test Suite (CTS) and UI interoperability void that was inherently, andSample Run Time Environment (RTE). The Sample unfortunately part of the SCORM. The RSE productRTE provided content developers with an interface that provided an alternative to organizations such as the USdiffered significantly from the actual interface Navy that were left with LMS vendors that providedprovided by the Navy’s LMS. Aside from subtle proprietary and inflexible implementations of thedifferences in the API Implementation, the UI for the SCORM. The RSE product acts as a third-partySample RTE launched the content in a frameset. In solution that handles all aspects of the SCORM RTEcomparison, the Navy’s LMS provided an interface and provides the LMS with a robust integration layerusing several opener windows prior to providing the allowing the LMS to focus on LMS functionality whileframeset where the API instance could be located. In letting the RSE take care of the complexities andaddition, there were several obvious inconsistencies interoperability challenges of SCORM. The RSEbetween the Sample RTE and the Navy’s LMS in provides an enhancement to the SCORM by exposingregards to the width, height, and other browser window UI properties that can be set for each course to controlattributes. The same challenges to interoperability precisely how it is delivered to the user. These UIbecame more evident when the USMC attempted to properties can be specified by the content developer inshare a course titled, “Driving for Life” with the Navy. the content package via an extension to SCORMDuring the era of SCORM 1.2 there was no support or metadata. An example of highlighting some of the UIdirection for navigational elements associated with the properties provided as a RSE extension to the IEEEUI. As a result, some LMS vendors implemented their LOM are provided in Figure 1 using a sample SCORMown proprietary navigation elements for their UI. metadata file. This sample is not intended to representAlternatively, some LMS vendors provided no all of the metadata elements or the complete RSE XMLnavigation support at all. This inconsistency left many binding, but is provided as an example to show thosecontent developers with the responsibility to elements that provide support for UI interoperabilityprogrammatically control the internal navigation via the RSE. The sections highlighted in yellow infunctions associated with “exiting” the course and Figure 1 indicate where the SCORM has beenclosing the browser window. This finding was the first extended in the IEEE LOM metadata file.of many other interoperability challenges for SCORM
  4. 4. Learning Education Training Systems Interoperability (LETSI) SCORM 2.0 White Paper Solicitation - August, 2008<?xml version="1.0"?><lom xmlns="" xmlns:xsi=""xsi:schemaLocation=" lomcustomco.xsd""> <general> <identifier> <catalog>NEL</catalog> <entry>CNL-DFL-1.0</entry> </identifier> <title> <string language="en">Driving for Life</string> </title> <language>en</language> <description> <string language="en">The purpose of this course is to facilitate the understanding of knowledge necessary toensure safe driving practices for Marines and Sailors. Specifically, this course will focus on the driving scenarios that cause a high number ofdeaths in the target population and how to react to potentially dangerous driving situations.</string> </description> <keyword> <string language="en">Driving</string> </keyword> <keyword> <string language="en">Safe Driver</string> </keyword> <keyword> <string language="en">Driver Safety</string> </keyword> <technical> <HSTMConfiguration xmlns=""> <controls> <showFinishButton>yes</showFinishButton> <showHelp>yes</showHelp> <showProgressBar>yes</showProgressBar> <showCourseStructure>yes</showCourseStructure> <courseStructureStartsOpen>yes</courseStructureStartsOpen> <showNavBar>yes</showNavBar> <showTitleBar>yes</showTitleBar> <statusDisplay>combined</statusDisplay> </controls> <appearence> <courseStructureWidth>300</courseStructureWidth> <displayStage> <width>1024</width> <height>768</height> <fullscreen>no</fullscreen> </displayStage> </appearence> <behavior> <disableRightClick>no</disableRightClick> <preventWindowResize>no</preventWindowResize> <launch> <sco>frameset</sco> <player>new window</player> <wrapScoWindowWithApi>yes</wrapScoWindowWithApi> </launch> </behavior> </HSTMConfiguration> </technical></lom>Figure 1: Sample Metadata File with User Interface (UI) Interoperability Controls Supported by the RSEThe RSE extension elements are placed within the describing the XML binding of these parameterstechnical element of SCORM metadata in a container (which are used to validate the format of theelement named “HSTMConfiguration”. This element is extensions). A namespace declaration is made at thealso the name of the RSE XML Schema (xsd) top of the metadata file as well as adding the “hstm”
  5. 5. Learning Education Training Systems Interoperability (LETSI) SCORM 2.0 White Paper Solicitation - August, 2008prefix on the HSTMConfiguration element. By web browser such as the default window size andproviding content developers with complete control whether the content should be delivered in a newover how the content should be launched from the window or a frameset. However, since it should beLMS, the challenges associated with UI expected that SCORM will possibly be supported byinteroperability become non-existent. Navy courses more than just PC web-browsers in the future a morethat were originally designed to only launch each comprehensive specification and XML binding toSharable Content Object (SCO) in a frameset window support additional aspects of UI interoperability wouldcould now work with any LMS integrated with the have to wait until SCORM 2.0. If one thinks aboutRSE such as the USMC’s LMS. As a result of interoperability on a larger scale than just web browserimplementing the RSE and extending SCORM flexibility, it’s actually impacted by and many timesmetadata, the US Navy is now able to provide a directly related to several additional concernsconsistent UI experience for learners of the US Navy’s involving usability, accessibility, and durability.many LMS environments in addition to sharing content Addressing all of these concerns through a UIwith the USMC. interoperability specification will require a collaborative and dedicated working group effort led STAKEHOLDERS by LETSI.The stakeholders that would benefit most fromimplementing the proposed solution would be all UI Interoperability Based On Usabilityconsumers and supporters of the SCORM including, Usability is referred to in this whitepaper as applyingbut not limited to the following: learners, instructors, best practices for the information architecture,LMS vendors, content authoring application functionality, internationalization, and designing visualdevelopers, content developers, content providers, elements of a specific UI. Usability should begraphic designers, instructional designers, technical considered as part of the proposed UI interoperabilityimplementers, and LMS administrators. specification for several of the obvious reasons, but one particular aspect that comes to mind is the method PROPOSED SOLUTION for providing visual indicators of the learner’sA combination of solutions would be required to solve progress. This concern has been discussed in the pastthe two UI interoperability problems defined in this among the ADL SCORM Technical Working Groupwhitepaper. The first solution is to supply a (TWG) on their forums and a proposal for an Activitystandardized API Implementation as part of the Core Tree Rendering (ATR) was previously submittedSCORM. Addressing the UI aspects concerned with (Ostyn, 2007). The Navy addressed this ATR concernonly the web browser is not enough. As long as LMS in the RSE through the element namedvendors and other content delivery-based applications “<statusDisplay>” in Figure 1. See Figure 2 below forare afforded the option to develop their own how the Navy has implemented the graphics (visualproprietary API Implementation, the interoperability indicators) associated with the <statusDisplay>problem in SCORM will continue to exist. SCORM element as part of the ATR displaying the learner’swas successful in standardizing the content so why not progress.also the API Implementation? Supplying the SCORMcommunity with a standard API Implementation shouldbe addressed before entertaining any other ideas orproposals of replacing or enhancing the contentaggregation model, sequencing and navigation,metadata, and/or the CMI data model.SCORM 2.0 must have a strategy to substantiallyimprove interoperability through standardized UIcontrols that provide optimal flexibility. The secondpart of the combined solution to the UI interoperabilityproblem is to create a UI interoperability specificationas part of the Core SCORM. Support for this“flexibility” aspect of the UI could actually be part ofthe SCORM 2004 specification today. In fact, thecurrent ADL content packaging schema could even be Figure 2: Screen Capture of User Interface (UI) Provided for theextended to provide a basic level of flexibility by Launched Content. The Legend of Visual Indicators is Located inadding some fundamental support parameters of the the Bottom Left.
  6. 6. Learning Education Training Systems Interoperability (LETSI) SCORM 2.0 White Paper Solicitation - August, 2008 XHTML, and XML) remains durable, the user interface designed for the many SCORM courses are often not. In fact, most SCORM 2004 content todayUI Interoperability Based On Accessibility still contains embedded navigation that hindersWhile the Navy’s LMS and UI for the ATR provides interoperability because standardizing the UI has notgood usability practices and visual indicators to display been addressed. The proposed UI Interoperabilitythe user’s progress it does not provide specification could be periodically updated as neededinternationalization features, and more importantly to accommodate for custom UI experiences as well asdoes not fully cover web accessibility. The World resolve unforeseen technological changes to theWide Web (W3C) Consortium states that web various delivery platforms and devices (e.g. webaccessibility encompasses all disabilities that affect browsers, mobile browsers, etc.). This proposal doesaccess to the Web, including visual, auditory, physical, not imply changing the technology behind SCORM,speech, cognitive, and neurological disabilities. Of but instead adding support for a UI interoperabilityequal importance is that web accessibility also benefits specification to support potential changes to thepeople without disabilities. The Navy’s UI for the ATR technology changes made to the software applicationsprovides basic support for web accessibility such as responsible for rending the content. By ensuring aALT text and keyboard accessible functions, but the clean separation of the UI from the LMS, the contentvisual indicators are based on colors and could will less likely become a victim of technologicalpotentially be confused by a color-blind user. Support change and will degrade more gracefully.of web accessibility through a UI specification wouldlay the foundation optimal adoption of SCORM 2.0. In INTEGRATION & OTHER ISSUESaddition, if web accessibility were fully supported by aUI interoperability specification in SCORM 2.0 then it The integration of a UI Interoperability specificationwould inherently benefit from other W3C could be achieved by incorporating support of currentrecommendations associated with web accessibility W3C recommendations as well as building upon thesuch as the W3C Mobile Web Initiative’s (MWI) lessons learned from the use case provided in thisMobile Web Best Practices. Figure 1 represents whitepaper. Given the multitude of mobile and webelements that allow the content developer to control the browsers that can now deliver web content, the effortwidth and height for their content, but these are static involved with testing the proposed solution could beparameters that currently only apply to a PC-based web quite intensive. Former versions of the SCORM werebrowser. Most of the Navy’s SCORM content as well supported by a large support community and receivedas the Navy’s LMS are only functional from a web resource funding from the DoD. While funding andbrowser on a PC. One might assume that this is also resources are not a technical issue per se, they willlikely the case for most other consumers of SCORM. If most likely become one of the biggest hurdles tosuch W3C recommendations were supported in a UI realizing many of the ideas and technical proposals forspecification in SCORM 2.0 then content developers SCORM 2.0. It should be recommended that thecould ultimately provide the learners with advanced proposed solution be governed by a LETSI workingoptions for alternate versions of their content for group and that all development work be made availabledisplay on multiple devices and browsers. as an open-source project. The development of a standardized API Implementation would be a moreUI Interoperability Based On Durability challenging proposition, but one that could potentiallyDurability in SCORM today implies that the learning provide unlimited interoperability benefits to thesystems of the future will be compatible with SCORM SCORM. Conceptually, these two proposed effortscontent of today. For the most part, SCORM has been should be planned and integrated into the SCORM invery successful in obtaining this goal today, but the conjunction with one another since they both addresspillar of durability will need to be expanded to issues related to interoperability.accommodate for more than just learning systems thatutilize PC-based web browsers. Content developers SUMMARYshould not have to modify learning content when webbrowsers change, but that has not always been the case. In order to achieve adoption on a global scale, SCORMProactive changes to the security models of web 2.0 must have a strategy to significantly improvebrowsers as well as the addition of new features (e.g. content interoperability by defining standardized userpop-up blockers, tabular browsing, etc.) have interface controls and options that will allow supportinadvertently broken some SCORM content. While the for flexibility, usability, accessibility, and durability. Inkey technology behind SCORM (ECMAScript, addition, SCORM 2.0 should explore an open-source
  7. 7. Learning Education Training Systems Interoperability (LETSI) SCORM 2.0 White Paper Solicitation - August, 2008approach led by the LETSI SCORM community in the REFERENCESdevelopment of a standardized API Implementation.These two critical aspects of interoperability should be Advanced Distributed Learning (ADL) Initiative,addressed before entertaining any other ideas or SCORM Documentation (n.d.). Retrieved August,proposals of replacing or enhancing the content 2008 from: model, sequencing and navigation,metadata, and/or the CMI data model. Current versions Mobile Web Best Practices 1.0, W3Cof the SCORM have been extended by the Navy to Recommendation, Jo Rabin, Charles McCathie Nevileresolve some interoperability challenges to SCORM. eds., 29 July 2009. Available at:However, the interoperability challenges still exist for organizations and consumers of SCORM today. 20080729LMS vendors do not often use the same programmaticstrategies or technologies for supplying the UI and API Ostyn, C., Proposal for Activity Tree Rendering .Implementation and as a result, interoperability and Retrieved July 2008 from: the ADL Technicalsharing of the content is not easily achieved without Working Group:making major programmatic changes to the content By adopting the proposed UI Interoperabilityspecification and a standardized API Implementation, Rustici Softwares SCORM Engine (RSE) MetadataSCORM content of the future could be made more Extension, Rustici Software Sofware, LLC., 3326interoperable and shared by more than just the LMS Aspen Grove Drive Suite 304, Franklin, TN 37067:applications of today. Web Accessibility Initiative (WAI)’s Web Content ACKNOWLEDGEMENTS Accessibility Guidelines (WCAG) 2.0, W3C Proposed Recommendation, Available at:The author would like to acknowledge the support of sponsoring commands and organizations: Navy 20080729Education Training and Professional DevelopmentTechnology Center (NETPDTC), the Department ofNavy (DoN) Program Executive Office for EnterpriseInformation Systems (PEO (EIS)), Computer SciencesCorporation (CSC), Rustici Software LLC, and thefederation for Learning Education and TrainingSystems Interoperability (LETSI).