Breeze Training Article

Breeze Tracking

There are two distinct stages of content tracking. The first is at launch, and the second is while the content is communicating with the Breeze server.

Content Launch

When a learner selects an activity from Breeze, the Breeze Communication Server launches the content and passes two parameters to the URL: AICC_SID and AICC_URL. (This is similar to the AICC standard.)

NOTE: The Breeze Communication Server may create and pass additional parameters to the content.

When the Breeze Communication Server launches an activity, it includes the following three parameters.

Suppose that the content is hosted on http://www.macromedia.com/content/viewer.htm. When the content is launched through the Breeze Communication Server, the URL may look like this:

http://www.macromedia.com/content/viewer.htm?aicc_sid=4561237011%2D621&aicc_url=http%3a%2f%2fwww%2emacromedia%2ecom%2ftrack%2easp

Remember that all parameters must be URL-encoded.

AICC_SID

The session ID that uniquely identifies a user and session. The session ID is passed from the content to the Breeze Communication Server in all tracking commands. The Breeze Communication Server uses this ID to know what user and session correspond with the data that is being sent.

AICC_URL

The URL for the activity to pass tracking commands. This is the tracking URL or file that comprehends and parses the tracking commands from the content and issues responses back to the content.

HTTP Tracking Commands

The standard communication mechanism employs the HTTP-Post method. The request body of this method contains parameter data and AICC-formatted data. The parameter data appears first. The Breeze formatted data appears after the AICC_Data parameter. The following table summarizes the parameters for the HTTP-Post method.

The request, including the HTTP request body, is sent URL-encoded as content type application/x-www-form-urlencoded. See "Structure of Breeze Communication Data" for explanations of data in all commands.

The response to the activity’s HTTP request contains a response code and formatted data. The response is not URL-encoded but is sent as content type text/plain. The first line is reserved for the response status, and the second line is reserved for the version of the AICC protocol, followed by the Breeze formatted data, if appropriate. The following examples illustrate the commands that are supported by Breeze. Only a subset of the full AICC commands can be tracked through the Breeze communication mechanism.

GetParam

GetParam retrieves information about the activity.

Parameters

Command=GetParam
Version=3.5
Session_id={SESSIONID}

Returns

Error={Error Number}
Error_text={Error String}
[Core]
Student_ID={Student ID}
Student_Name={Student Name:  Last Name, First Name}
Lesson_Location={Location of where user left off}
Lesson_Status=
Score=

[Core_Lesson]
{Free-form text}

NOTE: Breeze does not return the key phrase "aicc_data=" before the [CORE] section.

PutParam

PutParam sends an activity’s tracking data to the server. The format for the data is defined in CMI 001 5.2. See PutParam (PARAM.CBT).

Parameters

Command=PutParam
Version=2.0
Session_id={SESSIONID}
Aicc_data=
[Core]
Lesson_Location={Location of where user left off}
Lesson_Status={Status:  Not Started, Incomplete, Completed, Passed, or Failed}
Score={Score}
Time={Time in Session}

[Core_Lesson]
{Free-form text up to 4K}

Returns

Error={Error Number}
Error_text={Error String} 

Structure of Breeze Communication Data

This section describes the structure of Breeze communication data.

The following table summarizes the data that Breeze Communication Server provides.

[Core] Student_ID The student’s logon name.

[Core] Student_Name The student’s full name (First Name SPACE Last Name).

[Core] Lesson_Location Information that tells the activity where the student left off. The activity should bring the student back to this point. The activity determines the format for this data, and the activity should know how to act on it.

[Core] Lesson_Status The activity’s status from the last time the student accessed it. Always empty.

[Core] Score The numeric score from the last time the student accessed the activity. Always empty.

[Core_Lesson] The data created by the activity and stored by the Breeze Communication Server to pass back to the activity for the next time the activity is run. There are no defined keywords. Everything between the [Core_Lesson] section header and the next section header is the core lesson data. Like activity location information, format of this data is private to the activity. The activity creates it and should know how to interpret it. Here are some examples of the types of data that activities might store in this section:

• Bookmarks in an activity
• State of a complex simulation
• List of questions asked during a quiz and the learner’s responses

The following table summarizes the most important data that activities might send back to the Breeze Communication Server. For more information, see your Breeze Communication Server administrator.

[Core] Lesson_Location Information about where the student left off in the activity. The format for this data is up to the activity, and the activity should know how to act on it.

[Core] Lesson_Status The status of the activity when the student leaves it:

• Passed The activity was finished and passed.
• Completed The activity was finished but not necessarily passed.
• Failed The activity was finished but not passed.
• Incomplete The activity was begun but not finished.
• It is necessary to include only the first letter of the status words (p, c, f, i), and capitalization doesn’t matter.

[Core] Score The numeric score the student achieved on the activity.

[Core] Time The amount of time the student has spent on the activity. Must be in HH:MM:SS format (for example, 00:23:15). Must be included for accurate tracking of the amount of time the student has spent working on the activity.

[Core_Lesson] Data created by the activity and stored by the CMI system to pass back to the activity for the next time the activity is run. There are no defined keywords. Everything between the [Core_Lesson] section header and the next section header is the core lesson data. Like the lesson location information, the format of this data is private to the activity. The activity creates it and should know how to interpret it. Here are some examples of the kinds of data that activities might store in this section:

• Bookmarks in an activity
• State of a complex simulation
• List of questions asked during a quiz and the learner’s responses

PutInteractions

An activity can store a record of the interactions that the learner has completed in the activity. Interactions data is formatted as a table with rows and columns. Each line is a row. The columns are separated by commas in each row. Fields may or may not be enclosed in quotation marks. If the field has spaces or commas, it must be enclosed in quotation marks.

The first row in the file contains the column names, one in each field. Possible column names are:

• course_id Same as Course_ID in GetParam. This is an optional field.
• student_id Same as Student_ID in GetParam. This is an optional field.
• lesson_id Unique activity identifier. This is an optional field.
• date Date the learner initiated the interaction. Must be in MM/DD/YY format.
• time Time the learner initiated the interaction. Must be in HH:MM:SS format
• interaction_id Unique interaction identifier. Should match up to the breeze-manifest.xm file.
• objective_id Objective identifier for this interaction.
• type Type of interaction (one of true-false, choice, fill-in, long-fill-in, likert, matching, performance, sequencing, or numeric).
• correct_response Expected (correct) response to the interaction. Follows guidelines for standards-based responses (for example, True/False – "true" or "false"; Multiple Choice – letters or numbers; Fill-In – alpha-numeric string; Matching – pairs of identifiers separated by a period).

Special considerations may be required when publishing to Breeze. If a question has multiple required fields, the required fields must be enclosed in curly brackets. For example, suppose that the correct answer to a multiple choice question is A and B. The correct response is supposed to be formed as {A,B}. However, if the correct response is supposed to be a single answer, it appears simply as A.. This is true for all question types, although it is not noticeable in some cases, such as true/false. With fill-in and short answers, additional behavior must be considered.

For fill-in-the-blank question types, which are very similar to short answer question types, more than one blank can appear in a single question; for example, "The <0> is <1>" ("The <sky> is <blue>").

For communication with the Breeze Communication Server, the blank fields are separated with a comma, so the correct response might look like this: sky,blue. However, because both sky and blue are required, the correct response must be enclosed in curly brackets: {sky,blue}. To extend this example, suppose that a fill-in-the-blank question contains two blanks, with more than one possible answer in one of the blanks. The example looks like this: "The <0> is <1>" ("The <sky> is <blue;black;gray>").

Because one of "blue", "black," or "gray" is the correct answer, they are separated by semicolons, indicating optional responses. The correct response is {sky,blue;black;gray}. This response follows the standard described earlier.

Because users can enter free-form text, they could enter "sky" in the first blank and "for the birds; which, in my opinion, are pretty" in the second blank. However, this student response would conflict with the tracking use of both semicolons and commas. It is necessary to escape the semicolon and comma characters that are sent to the Breeze Communication Server. For consistency, the escaping is done by using "\". Because "\" has special meaning in JavaScript and ActionScript, it must in turn be escaped with another "\". Therefore the following is sent to Breeze: {sky,for the birds\\;which\\, in my opinion\\, are pretty}.

• student_response The actual learner response to the interaction. The guidelines are the same as those for correct_response, just described.
• result Judgment or acceptability of the learner response: "C" for correct; "W" for incorrect.
• weighting Numeric factor that indicates the relative importance of the question as compared to other questions.
• latency The time from the presentation of the stimulus to the completion of the measurable response. Must be in the format HH:MM:SS.

Example

"course_id","student_id","date","time","interaction_id","objective_id","type_interaction","correct_response","student_response","result","weighting","latency"
"0","0","03/24/2005","15:31:22","Interaction20002","Quiz10004","choice","B","B","C","10","00:04.06"

ExitAU

ExitAU isn’t required by Breeze, because all data is stored once it is received through the tracking mechanism. ExitAu does not require any parameters to be passed.

Rules

This section discusses rules and related information that may be helpful in developing content for Breeze or Breeze Meeting.

Some tracking data is maintained across multiple sessions

Launching content across multiple sessions maintains lesson_location and [Core_Lesson] data. If you want to maintain lesson_status, score, or time data, you must do so in the core_lesson field.

Data is reset (across sessions) when the learner receives a status of "passed" or "completed"

When the learner receives a "passed" or "completed" status, all tracking data is reset. The next time the learner launches the content from Breeze, the lesson_location and core_lesson fields return empty values.

Breeze expects status based on the type of content that is launched

Breeze expects the lesson status to be based on the type of content that is launched when the learner completes or passes the content. Until the learner actually completes or passes the content, the lesson status is sent as "incomplete." If the content contains a quiz, when the learner finishes the quiz, the content sends a status of "passed" or "failed" based on the score (compared to the passing score). If the content does not contain a quiz, when the learner completes the content, the status is sent as "completed."

If the content does not contain a quiz, the status is typically based on the learner having viewed 100% of the slides.

Page 2 of 3

Previous Page

Next Page