Reporting API 2.0.27 Posted

This update adds a new attribute called 'src' to the clip elements in the chronological history section of the result XML.  The src parameter is intended to indicate what action caused the IMO to change to a particular clip, whether it be a user click on an interaction, or a timeout, or a keyboard action, or something else. The purpose is to make it easier to accurately reconstruct the pathway a user took through the IMO, both for troubleshooting and analysis purposes. Please see Appendix A of the guide for the format of this attribute.

http://cfmedia.clicflic.com/web/misc/api/ClicFlic_API_current.pdf

Bug Fix for Sequential IMOs using Ordered Clips

A bug was detected in which interactions that had both an interaction item that auto-submits itself after a short time (a few seconds) AND a "Next" button, in which both interaction items are 'go to next clip in order'  could sometimes skip a clip (and the interactions on the skipped clip would not be displayed) if the next button was click just before the autosubmitting interaction item fired. In essence, the action of going to the next clip in order would happen twice.

For sequential assessments, like Multiple choice tests or SJT items, this scenario can occur. The result can be a loss of data.

The fix had to do with making sure that all autosubmit action timers connected with the current clip are cancelled when the clip is changed.

This change is now live and IMOs that may have this potential problem should be recompile and redeployed.  

Reporting API V 2.0.26 Released, Integration Enhancement

We have modified the sethistfcn which is used to receive result XML from the IMO by adding a second parameter to the function when it is called. The second parameter is an object. Currently, the object has only one field, but we expect to add more in the future. The single field is pctcomplt, which provides a number between 0.0 and 100.0 and indicates the calculated percent complete of the IMO.

Integrations can use this variable in a variety of ways, and avoid having to parse the Result XML just to retrieve it.

Existing implementations that do not accept two parameters should be fine and continue to function, as javascript will ignore the second parameter in this cases.

The revised API document is available at:
http://cfmedia.clicflic.com/web/misc/api/ClicFlic_API_current.pdf

Capturing IMO Log Messages - for troubleshooting

One of the problems with complex client-side programs is troubleshooting issues when there's a problem. You can show the error messages to the user, but that is usually frustrating for them and not typically helpful in locating the problem.

Based on a great suggestion from one of our clients, we have modified the IMOs to provide log messages to the javascript status function defined at runtime (statusfcn parameter). Implementations can then modify the status function however they choose to capture messages and, potentially, send them back to the server.

When set up for messages, the status function receives an object that has several fields:

status=msg (always set to 'msg' for messages)
eventid - the eventid provided at runtime for this imo.
level - 0=error, 1=warning, 2=info
text - the actual message.

You can capture these and then send the log messages back to a server URL using XMLHttpRequest.  That way, when a user complains about a problem in the future, you'll have more information available for troubleshooting.

Here's a simple example of a status function you could include on your page:

 function imoStatusFcn( o )  {
           
           var status=o.status;

            if( status==='msg' )
            {
                var msg = o.text;
                var level = o.level;
                var eid= o.eventid;

               
                if( (msg) && (eid) )
                    sendLogMessage( msg, level, eid);
            }
}

Reporting API 2.0.24 Posted

Yes, we have been busy here.  Version 2.0.24 is now out and available at
http://cfmedia.clicflic.com/web/misc/api/ClicFlic_API_current.pdf

Changes introduced by this modification are:


Expanded the statusfcn functionality to include log-style messages from the IMO. Messages are now sent with different levels (error, warning, and info). Using the statusfcn, hosting webpages can now capture these messages, for better error-handling, or for sending back to the server. 

Added two new IMO parameters that allow you to completely control what a user sees when they do not have a web browser that is compatible with the IMO. This allows you to more effectively control the user experience when the IMO cannot load.