Transcription
A WHITE PAPER FROM THE NAVY EDUCATION AND TRAINING & PROFESSIONAL DEVELOPMENT TECHNOLOGY CENTERUser Interface (UI) Interoperability for SCORM 2.0Jason HaagPrincipal Systems EngineerComputer Sciences Corp.Navy eLearningPensacola, FLjason.l.haag@navy.milABSTRACTAlthough one of the primary tenets of the Sharable Content Object Reference Model (SCORM) was topromote interoperability of learning content, it still remains one of the biggest challenges today. TheSCORM has been highly successfully in making the run-time communications and the learner’sperformance data associated with learning content, interoperable, by incorporating the IEEE 1484.11.22003 Standard for Learning. However, SCORM has remained silent about how a Learning ManagementSystem (LMS) can implement various technical aspects of the user interface. The SCORM has far too longdismissed several elements of the user interface as being “outside the scope of SCORM”. Ignoring how thelearner may interact with or access their content from an LMS (or other content delivery application) hasseverely and negatively impacted both the technical interoperability of SCORM content as well as the userexperience of the learner. Addressing “why” the learner may interact with various elements of self-pacedcontent is the primary responsibility of the content development team, but the SCORM should provide aspecification that would present options for “how” the learner might interact with multiple user interfacesregardless 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 toshare SCORM content packages between their various LMS implementations primarily due to differenceswith both user interfaces and the Application Programming Interface (API) Implementation. The vision ofplug-n-play interoperability of learning content is usually achieved only after several additional hours ofmodifying the content to work in a particular LMS implementation. In order to achieve adoption on aglobal scale, SCORM 2.0 must have a strategy to improve interoperability by standardizing the userinterface controls in further support of flexibility, usability, accessibility, and durability. This paperprovides a background and summary of the Navy’s successes with extending the SCORM to supportstandardized user interface options, and further proposes creating or incorporating a new user interfaceinteroperability specification and a recommendation for supplying a standardized API Implementation aspart of the Core SCORM.ABOUT THE AUTHORJason Haag's professional interest and background is in learning technology. He is currently employed byComputer Sciences Corporation as a principal systems engineer on the U.S. Navy’s eLearning programwhere he has been involved with implementing the SCORM for more than seven years. He is an ADLSharable Content Object Model (SCORM) technical working group participant, represents the US Navy onthe Defense Advanced Distributed Learning Action Team (DADLAT), member of the IEEE ComputerSociety, and IEEE Learning Technology Standards Committee (LTSC). He also operates and maintains afree SCORM resource website, CONFORM 2 SCORM, http://www.conform2scorm.com.
Learning Education Training Systems Interoperability (LETSI) SCORM 2.0 White Paper Solicitation - August, 2008User Interface (UI) Interoperability for SCORM 2.0PROBLEM DEFINITIONArguably, the most important of the “-ilities” of theSCORM is interoperability. One of the most criticalproblems with previous versions of the SCORM is thatit never required the implementation of a standard ability, will be the primary focus of this paper,but there is a secondary aspect of UI interoperabilitythat will be also be addressed: the SCORM ApplicationProgramming Interface (API) Implementation.Previous versions of SCORM primarily addressed theinteroperability of packaging the content and theinteroperability of the Run-Time Environment (RTE)CMI data model. Unfortunately, a standardizedapproach for supplying both the 1) UI for launchingthe content and the 2)API Implementation were notaddressed in SCORM, and consequently were left to besupported in proprietary methods by competing LMSvendors in the eLearning marketplace. As a result,interoperability has not been fully realized byconsumers of SCORM. In addition, previous versionsof SCORM did not account for inevitable changes tothe primary delivery medium: the web browser.Inconsistent User InterfacesThe US Navy has collaborated with the US MarineCorps (USMC), the US Coast Guard (USCG), andvarious other international military services andorganizations in contact with the US Navy for thepurpose of sharing their existing content libraries.Within the DoD community there are several webbased mandatory courses that often reflect the samesubject matter so making content sharable was the oneof the most obvious advantages that SCORM promisedto deliver. While the US Navy has experienced somedegree of success in sharing content with other DoDservices it did not initially happen without a great dealof additional modification and manual labor required tofirst make the content interoperable. The concept ofmaking content “plug-n-play” was a primary goal ofSCORM, but is has not been easy for contentdevelopers to achieve primarily because the UI forlaunching the content was not implemented in astandard manner by LMS vendors. The aforementionedtechnical modifications made to the content are usuallyattributed to making changes such that content willbehave in a consistent manner by uniquely differentLMS implementations. These launch behaviors andother UI aspects are inherent properties of the webbrowser such as the width and height of the browser,the browser toolbar, resizing, and the area where thecontent is first accessed within the browser windowhierarchy (e.g. frameset, new window, etc.). Theseaspects of UI severely impact the interoperability andmust be addressed in SCORM 2.0.Differing API ImplementationsIn addition to addressing the UI challenges associatedwith the web browser, SCORM 2.0 must supply astandardized methodology for supplying the APIImplementation. While the SCORM actually providedexample approaches to supplying the APIImplementation, LMS vendors did not often use thesame programmatic strategies or technologies and as aresult, interoperability and sharing of the content wasnot easily achieved without making majorprogrammatic changes to the content itself. WhileSCORM eventually improved run-time interoperabilityby removing all of the SCORM 1.2 optional aspects ofimplementing the CMI data model, the varioustechnologies employed by LMS vendors remainednon-standardized. The introduction of Sequencing andNavigation further complicated things and often madeeach LMS vendor’s API Implementation even moreunique and proprietary. Many LMS vendors often usedJava and/or other technologies to develop their ownAPI Implementation, and provided the API ininconsistent locations within the browser windowhierarchy. The resulting approach to accommodate thisinconsistency was to usually make changes to thecontent as well as the sample JavaScript-based APIwrapper provided by the Advanced DistributedLearning (ADL) initiative. Java remains atechnological challenge with the US Navy and USMCbecause of the tightly secured workstations that amajority of the learners use for accessing content.While Java is often touted as being platformindependent there still remain some accessibility andconfiguration challenges to its usage within the Navy.The prospect of not supplying a standardized APIimplementation will continue to provide furtherchallenges to the interoperability of content if notaddressed in SCORM 2.0. The code base andtechnology employed for the API implementation inSCORM 2.0 must be both ubiquitous and controlled in
Learning Education Training Systems Interoperability (LETSI) SCORM 2.0 White Paper Solicitation - August, 2008order to withstand inevitable changes to web browsers,operating systems, and other technological variablesthat are paramount to the delivery, portability, andinteroperability of the content. With the recentadvances in mobile standardization and best practicesprovided by the World Wide Consortium (W3C)Mobile Web Initiative, device independence should beanother key consideration. A standardized APIImplementation should utilize technology that wouldbe supported by any delivery platform and accessibleon any device. Finally, the code base for a standardizedAPI Implementation could be centrally controlled by aLETSI working group or IEEE working group so thatboth new technological innovations as well as changesto existing delivery platforms and devices could beuniformly supported.USE CASEThe US Navy deployed their first instance of aSCORM-conformant LMS during the era of SCORM1.2 (circa 2001). Many challenges to interoperabilitywere first recognized during the testing of SCORMconformant content that had only been previouslytested in the ADL Conformance Test Suite (CTS) andSample Run Time Environment (RTE). The SampleRTE provided content developers with an interface thatdiffered significantly from the actual interfaceprovided by the Navy’s LMS. Aside from subtledifferences in the API Implementation, the UI for theSample RTE launched the content in a frameset. Incomparison, the Navy’s LMS provided an interfaceusing several opener windows prior to providing theframeset where the API instance could be located. Inaddition, there were several obvious inconsistenciesbetween the Sample RTE and the Navy’s LMS inregards to the width, height, and other browser windowattributes. The same challenges to interoperabilitybecame more evident when the USMC attempted toshare a course titled, “Driving for Life” with the Navy.During the era of SCORM 1.2 there was no support ordirection for navigational elements associated with theUI. As a result, some LMS vendors implemented theirown proprietary navigation elements for their UI.Alternatively, some LMS vendors provided nonavigation support at all. This inconsistency left manycontent developers with the responsibility toprogrammatically control the internal navigationfunctions associated with “exiting” the course andclosing the browser window. This finding was the firstof many other interoperability challenges for SCORM1.2 (e.g. rollup, scoring, etc.). With the release ofSCORM 2004, some of the interoperability issuesassociated with UI navigation such as “exiting” wereaddressed, but several other UI challenges stillremained constant. As the Navy’s learner populationand content library continued to grow, so did therequirement to support a wider content distributionstrategy. The requirement to provide equal access tolearning opportunities throughout the Fleet forced theNavy to plan for content to be deployed to multiplelearning management systems and their respectiveenvironments such as classrooms, classified/SIPR,ships and submarines, and disconnected/offlineapplications. Interoperability soon became the USNavy’s primary goal when deploying SCORM content.As a result of these UI interoperability challenges, newdeployment requirements, and inflexible support ofSCORM 2004 from the LMS, the US Navy sought outa solution from Rustici Software, LLC. The Navy firstlearned of the Rustici SCORM Engine (RSE) productafter several discussions and collaboration with theUSMC. The RSE was being used by the USMC’sLMS and had been offered to the US Navy to fill theUI interoperability void that was inherently, andunfortunately part of the SCORM. The RSE productprovided an alternative to organizations such as the USNavy that were left with LMS vendors that providedproprietary and inflexible implementations of theSCORM. The RSE product acts as a third-partysolution that handles all aspects of the SCORM RTEand provides the LMS with a robust integration layerallowing the LMS to focus on LMS functionality whileletting the RSE take care of the complexities andinteroperability challenges of SCORM. The RSEprovides an enhancement to the SCORM by exposingUI properties that can be set for each course to controlprecisely how it is delivered to the user. These UIproperties can be specified by the content developer inthe content package via an extension to SCORMmetadata. An example of highlighting some of the UIproperties provided as a RSE extension to the IEEELOM are provided in Figure 1 using a sample SCORMmetadata file. This sample is not intended to representall of the metadata elements or the complete RSE XMLbinding, but is provided as an example to show thoseelements that provide support for UI interoperabilityvia the RSE. The sections highlighted in yellow inFigure 1 indicate where the SCORM has beenextended in the IEEE LOM metadata file.
Learning Education Training Systems Interoperability (LETSI) SCORM 2.0 White Paper Solicitation - August, 2008 ?xml version "1.0"? lom xmlns "http://ltsc.ieee.org/xsd/LOM" xmlns:xsi emaLocation "http://ltsc.ieee.org/xsd/LOM lomcustomco.xsd" iguration.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 "http://www.scorm.com/HSTMConfiguration.xsd" 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 thetechnical element of SCORM metadata in a containerelement named “HSTMConfiguration”. This element isalso the name of the RSE XML Schema (xsd)describing the XML binding of these parameters(which are used to validate the format of theextensions). A namespace declaration is made at thetop of the metadata file as well as adding the “hstm”
Learning Education Training Systems Interoperability (LETSI) SCORM 2.0 White Paper Solicitation - August, 2008prefix on the HSTMConfiguration element. Byproviding content developers with complete controlover how the content should be launched from theLMS, the challenges associated with UIinteroperability become non-existent. Navy coursesthat were originally designed to only launch eachSharable Content Object (SCO) in a frameset windowcould now work with any LMS integrated with theRSE such as the USMC’s LMS. As a result ofimplementing the RSE and extending SCORMmetadata, the US Navy is now able to provide aconsistent UI experience for learners of the US Navy’smany LMS environments in addition to sharing contentwith the USMC.STAKEHOLDERSThe stakeholders that would benefit most fromimplementing the proposed solution would be allconsumers and supporters of the SCORM including,but not limited to the following: learners, instructors,LMS vendors, content authoring applicationdevelopers, content developers, content providers,graphic designers, instructional designers, technicalimplementers, and LMS administrators.PROPOSED SOLUTIONA combination of solutions would be required to solvethe two UI interoperability problems defined in thiswhitepaper. The first solution is to supply astandardized API Implementation as part of the CoreSCORM. Addressing the UI aspects concerned withonly the web browser is not enough. As long as LMSvendors and other content delivery-based applicationsare afforded the option to develop their ownproprietary API Implementation, the interoperabilityproblem in SCORM will continue to exist. SCORMwas successful in standardizing the content so why notalso 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 beextended to provide a basic level of flexibility byadding some fundamental support parameters of theweb browser such as the default window size andwhether the content should be delivered in a newwindow or a frameset. However, since it should beexpected that SCORM will possibly be supported bymore than just PC web-browsers in the future a morecomprehensive specification and XML binding tosupport additional aspects of UI interoperability wouldhave to wait until SCORM 2.0. If one thinks aboutinteroperability on a larger scale than just web browserflexibility, it’s actually impacted by and many timesdirectly related to several additional concernsinvolving usability, accessibility, and durability.Addressing all of these concerns through a rative and dedicated working group effort ledby LETSI.UI Interoperability Based On UsabilityUsability is referred to in this whitepaper as applyingbest practices for the information architecture,functionality, internationalization, and designing visualelements of a specific UI. Usability should beconsidered as part of the proposed UI interoperabilityspecification for several of the obvious reasons, butone particular aspect that comes to mind is the methodfor providing visual indicators of the learner’sprogress. This concern has been discussed in the pastamong the ADL SCORM Technical Working Group(TWG) on their forums and a proposal for an ActivityTree Rendering (ATR) was previously submitted(Ostyn, 2007). The Navy addressed this ATR concernin the RSE through the element named“ statusDisplay ” in Figure 1. See Figure 2 below forhow the Navy has implemented the graphics (visualindicators) associated with the statusDisplay element as part of the ATR displaying the learner’sprogress.
Learning Education Training Systems Interoperability (LETSI) SCORM 2.0 White Paper Solicitation - August, 2008Figure 2: Screen Capture of User Interface (UI) Provided for theLaunched Content. The Legend of Visual Indicators is Located inthe Bottom Left.UI Interoperability Based On AccessibilityWhile the Navy’s LMS and UI for the ATR providesgood usability practices and visual indicators to displaythe user’s progress it does not provideinternationalization features, and more importantlydoes not fully cover web accessibility. The WorldWide Web (W3C) Consortium states that webaccessibility encompasses all disabilities that affectaccess to the Web, including visual, auditory, physical,speech, cognitive, and neurological disabilities. Ofequal importance is that web accessibility also benefitspeople without disabilities. The Navy’s UI for the ATRprovides basic support for web accessibility such asALT text and keyboard accessible functions, but thevisual indicators are based on colors and couldpotentially be confused by a color-blind user. Supportof web accessibility through a UI specification wouldlay the foundation optimal adoption of SCORM 2.0. Inaddition, if web accessibility were fully supported by aUI interoperability specification in SCORM 2.0 then itwould inherently benefit from other W3Crecommendations associated with web accessibilitysuch as the W3C Mobile Web Initiative’s (MWI)Mobile Web Best Practices. Figure 1 representselements that allow the content developer to control thewidth and height for their content, but these are staticparameters that currently only apply to a PC-based webbrowser. Most of the Navy’s SCORM content as wellas the Navy’s LMS are only functional from a webbrowser on a PC. One might assume that this is alsolikely the case for most other consumers of SCORM. Ifsuch W3C recommendations were supported in a UIspecification in SCORM 2.0 then content developerscould ultimately provide the learners with advancedoptions for alternate versions of their content fordisplay on multiple devices and browsers.UI Interoperability Based On DurabilityDurability in SCORM today implies that the learningsystems of the future will be compatible with SCORMcontent of today. For the most part, SCORM has beenvery successful in obtaining this goal today, but thepillar of durability will need to be expanded toaccommodate for more than just learning systems thatutilize PC-based web browsers. Content developersshould not have to modify learning content when webbrowsers change, but that has not always been the case.Proactive changes to the security models of webbrowsers as well as the addition of new features (e.g.pop-up blockers, tabular browsing, etc.) haveinadvertently broken some SCORM content. While thekey technology behind SCORM (ECMAScript,XHTML, and XML) remains durable, the userinterface designed for the many SCORM courses areoften not. In fact, most SCORM 2004 content todaystill contains embedded navigation that hindersinteroperability because standardizing the UI has notbeen addressed. The proposed UI Interoperabilityspecification could be periodically updated as neededto accommodate for custom UI experiences as well asresolve unforeseen technological changes to thevarious delivery platforms and devices (e.g. webbrowsers, mobile browsers, etc.). This proposal doesnot imply changing the technology behind SCORM,but instead adding support for a UI interoperabilityspecification to support potential changes to thetechnology changes made to the software applicationsresponsible for rending the content. By ensuring aclean separation of the UI from the LMS, the contentwill less likely become a victim of technologicalchange and will degrade more gracefully.INTEGRATION & OTHER ISSUESThe integration of a UI Interoperability specificationcould be achieved by incorporating support of currentW3C recommendations as well as building upon thelessons learned from the use case provided in thiswhitepaper. Given the multitude of mobile and webbrowsers that can now deliver web content, the effortinvolved with testing the proposed solution could bequite intensive. Former versions of the SCORM weresupported by a large support community and receivedresource funding from the DoD. While funding andresources are not a technical issue per se, they willmost likely become one of the biggest hurdles torealizing many of the ideas and technical proposals forSCORM 2.0. It should be recommended that theproposed solution be governed by a LETSI workinggroup and that all development work be made availableas an open-source project. The development of astandardized API Implementation would be a morechallenging proposition, but one that could potentiallyprovide unlimited interoperability benefits to theSCORM. Conceptually, these two proposed effortsshould be planned and integrated into the SCORM inconjunction with one another since they both addressissues related to interoperability.SUMMARYIn order to achieve adoption on a global scale, SCORM2.0 must have a strategy to significantly improvecontent interoperability by defining standardized user
Learning Education Training Systems Interoperability (LETSI) SCORM 2.0 White Paper Solicitation - August, 2008interface controls and options that will allow supportfor flexibility, usability, accessibility, and durability. Inaddition, SCORM 2.0 should explore an open-sourceapproach led by the LETSI SCORM community in thedevelopment of a standardized API Implementation.These two critical aspects of interoperability should beaddressed before entertaining any other ideas orproposals of replacing or enhancing the contentaggregation model, sequencing and navigation,metadata, and/or the CMI data model. Current versionsof the SCORM have been extended by the Navy toresolve some interoperability challenges to SCORM.However, the interoperability challenges still exist formany organizations and consumers of SCORM today.LMS vendors do not often use the same programmaticstrategies or technologies for supplying the UI and APIImplementation and as a result, interoperability andsharing of the content is not easily achieved withoutmaking major programmatic changes to the contentitself. By adopting the proposed UI Interoperabilityspecification and a standardized API Implementation,SCORM content of the future could be made moreinteroperable and shared by more than just the LMSapplications of today.ACKNOWLEDGEMENTSThe author would like to acknowledge the support ofthe sponsoring commands and organizations: NavyEducation 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).REFERENCESAdvanced Distributed Learning (ADL) Initiative,SCORM Documentation (n.d.). Retrieved August,2008 from: http://www.adlnet.gov/scorm/Mobile Web Best Practices 1.0, W3CRecommendation, Jo Rabin, Charles McCathie Nevileeds., 29 July 2009. Available Ostyn, C., Proposal for Activity Tree Rendering .Retrieved July 2008 from: the ADL TechnicalWorking WG/Rustici Software's SCORM Engine (RSE) MetadataExtension, Rustici Software Sofware, LLC., 3326Aspen Grove Drive Suite 304, Franklin, TN 37067:http://www.scorm.comWeb Accessibility Initiative (WAI)’s Web ContentAccessibility Guidelines (WCAG) 2.0, W3C ProposedRecommendation, Available at:http://www.w3.org/TR/2008/REC-mobile-bp20080729
interoperability of packaging the content and the interoperability of the Run-Time Environment (RTE) CMI data model. Unfortunately, a standardized approach for supplying both the 1) UI for launching the content and the 2)API Implementation were not addressed in SCORM, and consequently were left to be
