Chapter 2 Background and Related Work
2.4 Run Time Environment (RTE)
Except for CAM, SCORM also define the run time environment. It includes three parts, (1) Launch mechanism: how the learning management system startup up learning content (2) Application Program Interface (API): the communication model between learning management system and learning elements (3) Data Model: the data format to communication between learning management system and SCO. We will give a brief introduction as follow.
(1) Launch mechanism
Every learning management system follow the model “Launch” startup the learning resource which is suit for SCORM data type through API.
(2) Application Program Interface (API)
API could show LMS the SCO’s state. Learning elements could also obtain the parameter for showing material resource through API. For example, require student’s information from LMS, and according to student’s grade and ability providing for different level learning material. SCORM define 8 kinds of different API as show in Figure 2-7
Fig 2-0-7 The process of API adapter Table 1 The definition of SCORM API
According to the course structure configure in content package, LMS present course material in user’s browser, and follow by sequence( Refer to imsmanifest.xml in tag <organization> configuration ) to launch Asset or SCO.
For the type of Asset, LMS will present directly through HTTP protocol. The communication between SCO and LMS will be control by API mechanism.
SCO communicate with LMS through calling API, such as calling LMSInitialize API when the communication starts and calling LMSFinish API when communication is ending. They also call
LMSGetValue API and LMSSetValue API to exchange some data as data model format between LMS and
SCO. The SCORM specification also stipulate that LMS must provide “API Adapter” to implement these API function. While a SCO were browsed, it would hierarchical searching the API Adapter location recursively for taking API from the web page’s location. In this way, course editor do not need to take care the communication problem when author teaching material. They only needs to add the user
interface such as JavaScript files provide by LMS to applying API. The architecture is show as figure 2-8.
Fig 2-0-8 Run-Time environment
(3) Data model
Data model is a common data format for transmitting data between LMS and learning resources. With this common format, LMS could control learning resource’s state or student’s learning portfolio. SCORM integrate AICC CMI Data Model standard specification, and define eight kinds of data type. In our thesis, data model do not take into consideration.
2.4 Related research
2.4.1 Packet SCORM
In year 2004, Lin published the Packet SCORM [4] prototype. They build their own
SCORM LMS Server cooperating with specific packet SCORM RTE in mobile device side and show in Figure 2-9 and Figure 2-10. The added more assist function to keep the data while the server is offline and lake of storage. But they only published a prototype especially focus on client side. The evaluation and detail about this system is not yet published so that we only have an elementary draft. We can not find out how they solve the problem about JavaScript with Java Applet support. Without JavaScript support, this system will as like a set of static html files. Besides, they do not discuss about the accept rate and problem while exporting their course to other LMS and importing course from other LMS.
Fig 2-0-9 The system architecture of Packet SCORM
Fig 2-0-10 The run time snapshot of Packet SCORM
In [7] discuss about the reflow method for Packet SCORM. Reflow mechanism is an important function for Packet SCORM which increase the readability of the mobile device. In our paper will use their method to reflow SCORM document.
2.4.2 CCU new architecture
In year 2002, Professor Hsu published a SCORM-based e-learning Environment for Mobile device [5]. They discuss about due the lack of JavaScript supporting, if somebody use a mobile device connecting to LMS server, the result will as like the Figure 2-11.
Fig 2-0-11 The result of use mobile device connecting to LMS server
In order to solve this problem, they bring up a new architecture as show in Figure 2-12.
Fig 2-0-12. SCORM-based e-learning Environment for Mobile device architecture
2.4.3 Opera8.5 for mobile device
We try to finding out a real mobile device that supporting the JavaScript ability. From now on, the most suitable mobile device browser we find is “opera8.5 for mobile device version”. It almost supports every function, but still gets into some trouble that can not
2.5 Document Presentation Format Analysis
In order to transform an existing SCORM format documents, we have already collect some common used SCORM document with taking their snapshot. And that try to summarizing they general type while adapting to small size. Table 2-1 list the result after we analysis.
Table 2 Common SCORM document type analysis
Type Action
Type1: Flash base type Do nothing Type2: Html base type Do nothing
Type3: Chaotic type Authoring this file Type4: Unknown type Do nothing
2.5.1 Description for all of these sample type z Type1: Flash base type:
A Flash base presentation type usually integrated a Flash file into html document.
Figure 2-13 is an example source code for Flash base document. In this document, html body only present a Flash file (named fofts2_component.swf ). Figure 2-14 shows original snapshot on PC, and Figure2-15 is a file after resize it’s pixel to 300
* 200. In summary, Flash base document can not modify the presentation size. It needs sidelong scroll bar to browsing the page. Unless edit a new document which is suit for specific mobile device.
Fig 2-0-13 A Flash base document source code.
Fig 2-0-14 Type 1: flash base presentation format
Fig 2-0-15 Type1:flash base format resized
z Type2: Html base type
Html base presentation type stand for writing html code as simple as possible. In this way, we can calculate a page’s width, and rewrite a page. For example, if a picture was putting in a html document and the width is not enough, we can take
some process so that suit for reading. As show in Figure2-16 and Figure2-17, after resize the page’s pixel, the document will adjust it self.
Fig 2-0-16 Type2:html base presentation format
Fig 2-0-17 Type2: html base format resized
z Type3: Chaotic type
Chaotic type means this kind of document can not be resizing. This is because the relative position in the document is fixed. May be they use many blank space to edit the document. After changing the pixel, the presentation becomes confused. The only way to overcome this drawback is write this course material again. Figure 18 and Figure 19 is the examples.
Fig 2-0-18 Type3:Confused presentation format
Fig 2-0-19 Type3: Confused format after resized
z Type4: Unknown type
Some SCORM document type was layout by specific mechanism, even we look into the source code, it hard to understanding how they write. They control the layout style not only using blank word. We do not research any more about this type because of the time.
Fig 2-0-20 Type4:Unknown presentation format
Fig 2-0-21 Fig2-21 Type4: Unknown format after resized
2.6 Discussion and Conclusion
The system architecture about “Packet SCORM” [4] and [5] implement not only the server side framework of LMS but also client side structure. Therefore, if we use their own authoring tool to editing a new course and execute on their LMS, these processes are sure to getting less problem. But if we need to export the course material to another LMS and the user still use mobile device, we need to design a new SCORM document.
It wasted time and resource. In this paper, we try to focus on how to utilizing the content side to reduce overhead for authoring a new document again. Next chapter will discuss about our system architecture and method of thinking.
Chapter 3 System Architecture
3.1 Chapter Introduction
In this chapter, we will introduce the framework of our system. Ch 3.2 discuss with our system architecture. Ch3.3 discuss with the toolkit composition of every component.
Include the flow chart of transformation process. Ch3.4 introduced the content adaptation component.
3.2 System overview
Fig 3-0-1 Toolkit architecture of our system.
The workflow of our transformation tool parsing a file with SCORM document format, do some authoring process and export the document. As depicted in Figure 3-1.
In this chapter, each part of the architecture will be detail described.
3.3 Toolkit composition
Figure3-2 and Figure3-3 show the workflow of our processes.
Import &
Unzip
Fig 3-0-2 Workflow of toolkit
Fig 3-0-3 Toolkit authoring process
SCORM
In face, a SCORM base document has two level ranking. First level is resource view which each file is unique. And then we transfer target file individually. We use resource component to handling it. The second level is manifest view which control by the file
“imsmanifest.xml”. This level identity the architecture of SCORM document, and we use Manifest Component to handling it.
Roughly, our system does follow steps:
Step 1: Import an existing SCORM format document or create a new document.
Step 2: Configure system parameter.
Step 3: Edit the file “imsmanifest.xml”, and add a new SCO head page
(named top.htm) which includes original structure over original structure.
Step 4: Add hyperlink “previous page”、”next page” and “top page”
to every.html( or .htm) format page.
Step 5: Apply “page rebuild” and “picture edit” for html format page Step 6: Preview whole document from top page
Step 7: Export document or edit every html page from source code editor.
3.3.1 Attribute Table Component
In order to adapting for different kind of mobile device, attribute table configuration needs to access first. The most important thing here is pocket PC’s pixel setting. With appropriate setting, the transformation job con process well.
3.3.2 Manifest Edit Component
As show in Figure3-4, the left side of frame will provide navigation ability. This
device. While browse on mobile device, this navigation portion waste space. In order to reducing the left navigation frame page, we parse the “imsmanifest.xml” file, change document structure as show in Figure3-5 and Figure3-6, it means we divided original page as show in Figure 3-4 into two pages.
Fig 3-0-4 The original page of SCORM SRTE
Fig 3-0-5 The snapshot after reduce left navigate page
Fig 3-0-6 The navigation of SCORM
3.3.2 Resource View Component
Resource view component response for individual file level handling. In order to
cooperate with Figure 3-5 and 3-6, we add three links in every .html format page in resource view. They are “navigation page”, “previous page” and “next page” which enable user to browse between SCO and return to main page.
.
3.3.3 Content Adaptation Component
There are many related transferring method about adapt to mobile device while browse web site. This is resource level modification. The Content Adaptation Component responsible for this portion. In fact, even the default browser, pocket IE, have support partially page adaptation.
3.3.4 Preview Component
We use preview mode to form a temporality html document and automatic open browser for examination with particular pixel size format. In preview mode, the JavaScript will also be supported so that it can simulate as if in mobile device.
3.4 Content Adaptation
SCORM specification does not define what kind of source file it should be, it only provides for the rule for communication and appear sequence. Therefore there are too many possibility that source will be. As the document presentation format analysis is chapter2.5, some document format can not be transformed well due to the original design. For example, a Flash base SCORM document is hard to decompose unless
design on mobile device at beginning. In order to simplify our research, we actually deal with html postfix document. There are many research discuss with how to adapting document on mobile device. In our thesis, we will deal with picture first. Other further mechanism will not mention here.
3.4.1 Picture transform
While a picture’s pixel size is large than pocket PC, it will cause difficult to browsing.
Therefore, we provide the functionality to resizing this picture by editor.
3.5 Limitation for Mobile device
Due to the storage and computing power of mobile device becomes more and more powerful, some limitation before can be overcome now. After all, there are still some problem needs to be solve because of the difference between mobile device and PC. We will bring up some assumption to achieving the presentation of SCORM on mobile device. Include the connection problems, browser functionality support and storage limitation.
3.5.1 Connection problems
Due to the key point that we focus on handling content side first, we assume that the mobile device is always online to simplify the system complexity. In fact, the specification of SCORM supposed that the run time environment wad web base architecture, the LMS side need keep tracking client side’s activity and refresh information. It is hard offline unless rewrite the LMS architecture. This is out of our
objective. In this way, we suppose that server side and client side are always connected.
We use pocket PC with wireless supported to keeping the connection.
3.5.2. JavaScript and Java Apple supportability
In general, the browsing functionality in mobile device seldom supported either JavaScript or Java Apple method due to the restriction of computing power and operating system support.
It’s an unsolved problem in this paper so that we assume the JavaScript will work in future version of mobile device browser.
The first reason is that the operation of JavaScript immediate involve with LMS side. If we want to adjust the functionality of JavaScript, LMS side middleware must be added.
This is out of our base key point to focus on content side.
The second reason is that after a series of testing, we find out the mobile device browse
“Opera 8.5” could partially support this functionality. We suppose the newer version of the software will overcome the JavaScript restriction. The base requirement for SCORM is:
z First, support JavaScript version 1.2.
z Second, the browser support Java VM to load Java Applet.
z Third, Java VM needs supporting the JavaScript calling Java Applet method.
Owing to reason one and reason two mention above, we use browser IE6.0 and execute
on personal computer. But resize the display of browse to simulate mobile device display.
3.5.3. Storage limitation
We do not deal with temporary storage problem because we expect that the file size of single SCO is small. In general, SCORM document will be parsing in server side and then deliver single page as server-client mode. Unless the page it invoke external file such as movie or PowerPoint file, otherwise the document will not cause storage limitation.
Chapter 4 Implementation
4.1 Developing environment – “Reload Editor”
Due to SCORM specification is complex and needs much time to implementation all of the mechanism. We use an existing open source software “Reload editor” [7] as show in figure10. This software is implementation by Java language. We use their document structure handler and parser to accomplish our mechanism.
Fig 4-0-1 Snapshot of Reload Editor.
4.2 System view
We use wireless802.11 to keeping the connection. In this way, we do not care about the connection problems. The Figure 4-2. and Figure 4-3. are the snapshot of our mobile device toolkit.
Fig 4-0-2 The plug-in snapshot of our toolkit
Fig 4-0-3 The snapshot of source code editing function
4.2.1 Resource view component modification
In resource view component, we add three links to html document, they are:
1. We add a hyperlink (Top) to return top.html page. The html code is as follow:
<P align="right"><a href="top.html">Top</a></P><P> </P>
2. Add a JavaScript control code in first page of every SCO SetValue("adl.nav.request","continue")
3. Add a JavaScript control code in last page of every SCO SetValue("adl.nav.request","previous")
As show in Figure4-4, we use a SCORM 2004 data model function ” ---adl.nav.request ” navigate browsing. This function enable browse from one SCO to another SCO.
Fig 4-0-4 Example SCO for modification
4.3 Rte view
As the picture show in Figure 4-4, we create a page “top.html” represent the document structure and combine with Assets. In Fiure4-5, we add a link “Top” at left side of document. There are no existing navigational frames, in order to browse this teaching material, the additional link is necessary. Although this link decrease browsing convince, but save space.
Fig 4-0-5 top.html view Fig 4-6 Asset View
4.4 Discussion
In this chapter, we had demonstrated our transformation tool and sample result.
However, there are many existing problems while implement this tool. For example, we want to design this tool and browsing on pocket PC. But there comes the problem that the pocket IE do not support the JavaScript invoke Java Applet well. They either only support Java Applet function or JavaScript function partially. Other research implement their owe RTE and framework to overcome this problem, but we do not want to build up our own RTE due to the limitation of time. We believe that this problem will be solved soon due to the advancement of software version support. The other problem is sometimes when we export SCORM document to another LMS RTE,
our document can not adjust to their configuration. Maybe this is because there are some conflict setting between “Reload Editor” and the RTE.
Chapter 5 Conclusion
There are growing amount of people start to enjoying distance education courses not only using their PCs but also using mobile devices such as Pocket PCs. Because Pocket PCs are easy to carry, these devices are considered as a proper platform for E-learning. In this thesis, we focus on the issue of transferring the current PC based Sharable Content Object Reference Model (SCORM) document to particular mobile device. Because we focus on document itself, there are related restriction such as connection needs to keeps alive and JavaScript functionality needs to be supported.
We develop a transformation tool kit to re-write existing document. It saves developing time and makes the existing document more powerful.
5.1Conclusion
The main purpose of crafting this toolkit is to reduce the efforts of developing applications for multiple mobile devices. For this reason, we discuss them in two criteria: rapidly development and write once, generate multiple application user-interfaces.
From the rapidly development aspect, it is important to reduce the efforts of learning how to use a new toolkit for developers. Therefore, the toolkit is provided with the simply steps as the interaction medium.
From the write once, generate multiple specific document aspect; it is completely feasible through our toolkit by using the transform technology. While a new mobile
device appear, we only need to change the parameter setting and a new SCORM base document can be easily produced.
5.2Future work
There are multiple improvements available for our system. First, since the version of SCORM 2004 supports sequencing control, most SCORM base document support this functionality. We need to do more discussion about sequencing control rules. Second, the JavaScript and Java Applet support need to solve so that our tool kit can really running on mobile device. Third, the media format support should be more clearly and efficiently, since the variety of SCORM document format.
Chapter 6 Reference
[1] http://www.adlnet.org Advanced Distributed Learning (ADL) (2003) [2] Universal Learning Format (ULF) Technical specification(2002) Version 1.0,
http://www.saba.com
[3] IMS Simple Sequencing Specification, IMS Global Learning Consortium, Inc.
(2006), http://www.imsglobal.org.
[4] Nigel H. Lin, Timothy K. Shih, Hui-huang Hsu, Hsuan-Pu Chang, Han-Bin Chang and Wen Chieh Ko, “Pocket SCORM”, Proceedings of the 24th International Conference on Distributed Computing Systems Workshops (ICDCSW’04) 2004
[5] 許政穆、許健飛、鐘國麟。“Design of the SCORM-based e-Learning
Environment for Mobile Carriers”。WISCS 2003 網路教學系統平台與內容標
Environment for Mobile Carriers”。WISCS 2003 網路教學系統平台與內容標