Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Updated the Flash progress bit

...

This section explains the algorithms implemented underneath to achieve the functionalities described in the above sections. To explain the algorithms, sequence diagrams, activity diagrams and code snippets will be provided wherever necessary.

LAMS 2.x activity page loading Mechanism

To fully understand how progress engine display the JSP of the next activity, we have to explain the activity page loading mechanism first. As you might know, the LAMS activities are classified into two big categories - complex activity and simple activity.

From the perspective of displaying these activities using JSP, we would like re-classify these activities into three major categories - Single frame JSP activity, multi-frame JSP activity and LAMS system JSP activity. These three categories and corresponding page loading strategy are explained as follows:

  • Single framed JSP activity - A single frame loading JSP is used to display the content of this type of activity. Referring back to the activity hierarchy designed in the object model, all simple activities as well as sequence activity falls into this category.
  • Multi-framed JSP activity - When we are dealing with parallel activity, single frame is no longer enough to display two or more activities on the same screen. It is therefore multi-frame needs to be initialized before the actual activity contents can be loaded into the JSP.
  • LAMS system JSP activity - A single framed JSP is also used for system activities. The difference between this category and single framed JSP activity is that the actually activity content won't be displayed directly. Instead, a LAMS page will be loaded to represent activity's content. Options activity is a good example - LAMS option page will be shown with all the sub-activities outlines and instructions rather than the contents of all optional activities.

Why did we make this classification? We want all activities contents are loaded by LAMS loading page rather than shown directly from Struts action forward. Why LAMS loading page is important? LAMS loading page has to exist because of two major reasons. Firstly, the loading page is a clean solution to add extra frame and clean unnecessary frame whenever required. Without using an intermediate loading JSP, we could not find a solution to achieve the same functionality.

Secondly, the loading page is a good place to send update progress bar message to the Flash client. If you are familiar with LAMS before 2.0, you will notice that the entry JSP page of each tool is doing updates of the Flash progress bar. This results in a tight dependency between tool and the Flash progress bar. Furthermore, update code on all tools' JSP generates duplicate code and consequently a maintainability nightmare.

Isn't the loading page is extra overhead and makes LAMS very "chatty" (ie a lot of calls to the server)? Yes, but for the benefits it has brought use, it was worth the overhead. If usage and/or profiling show an issue in this area then we will optimise the code however the overall methodology appears sound at this stage and there are other areas we can look at for performance improvements.

Move to next activity Needs updating


Figure 5 Move to Next Activity - Sequence Diagram

...

This has been changed to include a call to the "CompleteActivityAction", rather than going straight to then next activity.

Calculate the next activity at service layer

...


Figure 6 Calculate the Next Activity - Activity Diagram

...

Once the service layer progress engine calculated the next activity to move on to and returned the learner progress, the web layer progress engine needs to figure out what is the proper URL for the next activity. Figure 7 illustrates the algorithm to fulfill this functionality.

LAMS 2.x activity page loading Mechanism

To fully understand how progress engine display the JSP of the next activity, we have to explain the activity page loading mechanism first. As you might know, the LAMS activities are classified into two big categories - complex activity and simple activity.

From the perspective of displaying these activities using JSP, we would like re-classify these activities into three major categories - Single frame JSP activity, multi-frame JSP activity and LAMS system JSP activity. These three categories and corresponding page loading strategy are explained as follows:

  • Single framed JSP activity - A single frame loading JSP is used to display the content of this type of activity. Referring back to the activity hierarchy designed in the object model, all simple activities as well as sequence activity falls into this category.
  • Multi-framed JSP activity - When we are dealing with parallel activity, single frame is no longer enough to display two or more activities on the same screen. It is therefore multi-frame needs to be initialized before the actual activity contents can be loaded into the JSP.
  • LAMS system JSP activity - A single framed JSP is also used for system activities. The difference between this category and single framed JSP activity is that the actually activity content won't be displayed directly. Instead, a LAMS page will be loaded to represent activity's content. Options activity is a good example - LAMS option page will be shown with all the sub-activities outlines and instructions rather than the contents of all optional activities.

Why did we make this classification? We want all activities contents are loaded by LAMS loading page rather than shown directly from Struts action forward. Why LAMS loading page is important? LAMS loading page has to exist because of two major reasons. Firstly, the loading page is a clean solution to add extra frame and clean unnecessary frame whenever required. Without using an intermediate loading JSP, we could not find a solution to achieve the same functionality.

Secondly, the loading page is a good place to send update progress bar message to the Flash client. If you are familiar with LAMS before 2.0, you will notice that the entry JSP page of each tool is doing updates of the Flash progress bar. This results in a tight dependency between tool and the Flash progress bar. Furthermore, update code on all tools' JSP generates duplicate code and consequently a maintainability nightmare.

Isn't the loading page is extra overhead and makes LAMS very "chatty" (ie a lot of calls to the server)? Yes, but for the benefits it has brought use, it was worth the overhead. If usage and/or profiling show an issue in this area then we will optimise the code however the overall methodology appears sound at this stage and there are other areas we can look at for performance improvements.

Join a lesson with Retrieving Progress Data

...

We have already explained the algorithm of moving to next task on the LAMS server side. How do we achieve the visual indication of the movement on the Flash progress bar? Figure 15 9 explains the detail logic behind the scene. A Flash movie update script like following will be placed is embedded on the LAMS loading page :
<object classid="clsid:D27CDB6E-AE6D-11cf-96B8-444553540000" codebase="http://download.macromedia.com/pub/shockwave/cabs/flash/swflash.cab#version=6,0,29,0" width="1" height="1">
<param name="movie" value="../../learnerProgress_lc.swf?currentTaskId=xx">
<param name="quality" value="high">
<embed src="../../learnerProgress_lc.swf?currentTaskId=xx"
quality="high"
pluginspage="http://www.macromedia.com/go/getflashplayer"
type="application/x-shockwave-flash"
width="1"
height="1">
</object>
This script should update progress bar with current activity, attempted activity array and completed activity. Please refer to the notes on Figure 15 for the meaning of these variables. As these data has been calculated along with the server side "move to next task", we save all the extra calculation we did in LAMS 1.0. Furthermore, the (and the parallel and optional pages) and this movie opens a Flash pipe which passes the IDs for the current, attempted and completed activities. The code for the Flash swf is in the lams:Passon tag, so inclusion in a few jsps is easy.

Flash then updates the progress bar with the activity data, based on the design details that it received when the learner window was first opened. All the data has been calculated on the server side as part of the "move to next task". The data sent back to Flash is only a couple of bytessmall, which minimize minimises the Flash - Java communication cost. As a safe guard, Flash can send the request to server to restore the whole progress bar structure if there is an exception has been identified at Flash side. But we believe this won't happen very oftenissue on the Flash side.

One of the parameters passed to Flash is the design version. This is updated whenever a Live Edit is done, triggering Flash to get a new copy of the design when the version changes. This allows learners to see an updated design without having to exit/restart learner.

The code that actually moves to the next activity (on the "Loading Next Activity screen" is embedded in Javascript. If we are using the Flash progress bar then Flash calls the javascript method to advance to the next activity. This was done to eliminate timing issues we were getting between Flash updates and the JSP advancing. For this reason, the Flash progress bar had to be used in LAMS 2.0.

Non-Flash Progress Bar

In LAMS 2.1 we have introduced the Flashless learner interface (apart from Chat). If the learner is not using the Flash progress bar then the jsp calls the javascript to do the page redirect when the page is loaded. There is no need to update the non-Flash progress bar as that is generated only when the learner requests the progress display.

The non-Flash progress bar is generated using the ProgressBuilder class, which is based on the LearningDesignProcessor. During the parsing of the design, it builds a set of URLs to show completed activities. The data is then passed to a JSP for rendering. This is done every time, so we will have to watch that it doesn't become a performance issue - the code was done quickly rather than being coded to be quick. Having the work done on the server does increase the server load - normally the calculation of what should appear green, blue, etc is done in Flash and hence is done in the client. But it isn't done on every progress (as it in Flash) so hopefully it won't be a big issue.

Authoring Preview

When an author runs a preview, it actually runs a complete lesson, with a single learner in the class. There is no monitoring client. Apart from the differences mentioned for Gates and Grouping below, the following differences apply to Preview.

...