I was doing some housecleaning on my computer this morning and ran across something I wrote up a long while back and never put out. I wonder what other gems I might have lying around.
Hope this helps.
Interactions

Interaction Identifiers
Organizations should define naming conventions for cmi.interactions.n.id so that each interaction has a unique identifier, at least within the scope of the Sharable Content Object (SCO).
Score

Development of Algorithms
Instructional designers and developers should collaborate in the development of the algorithms used to calculate scaled scores. 

Methods for calculating score
- Keep a running tally after each questions is answered.
- Use the interactions data model element to record the learner’s score and loop through all questions tallying up how many results were correct and incorrect.
- Other - there are many individual methods for how and when to calculate the score.
Calculating Scaled Score
There are many ways to calculate scaled score, one of the more common ones is:
(Sum of each question's Value * Weight ) / Total weight possible.
Completion Status
Setting Completion Status 
To make the course, or package, “completed,” use a combination of completion status on the SCO(s) and sequencing rules (as mentioned in the SCORM Content Aggregation Model (CAM) Version 1.3). This may involve a series of sequencing rules that appear as the following:
This indicates that the item associated with this sequencing rule doesn’t count towards your course completion.
When this sequencing rule is on a parent - in the manifest:

An LMS will ignore any children of a parent in the manifest with regards to any requirements for course completion — whether you use “completion_status” on any of those SCOs or not. You can still designate these SCOs as completed. Assuming you’re developing with “completion status” to achieve some result, more work either with your code or with sequencing in the manifest will be required to take advantage of “completion status”
In any other instance, however, the LMS will pay attention, going all the way down into the children to look for what to ignore.
Launch Data
Availability of data
Launch Data is dependent on the existence of information provided by the manifest. For example, the next application scenario will use Launch Data to display text in Spanish, instead of English. The information in the manifest that pertains to Launch Data is detailed in the highlighted text below:

� � � - 
� � � � � � 
� � � � � � SPANISH
� � �


The element provides initialization data expected by the resource (i.e., SCO) referred to by the after launch. To send data to the SCO for use after the SCO is launched, the combination of including and using Launch Data in the SCO is a good solution.
The availability of Launch Data, however, occurs after the SCO has initialized. Depending on your implementation, your content may load before the SCO initializes. If your content is dependent on information supplied by the manifest, and you can’t control the timing of the SCO initializing communication with the LMS, you may wish to use a Query Object and pass information to the SCO (or asset) using parameters.
Using the parameters attribute enables the developer and ID to specify the best graphic for each community without the development of multiple sets of content.
Such an in your manifest may look like the following:
-
This name/value pair is sent as a parameter to the SCO. It can be accessed the same way that any GET data would be accessed, appended to the URL. Continuing this example, it is possible to include JavaScript on the SCO to parse this name/value parameter, sent to the SCO from the manifest.
/**********************
* Function: get_params()
* Description: This function is used to get the parameters from the
* query string
***********************/
function getparams()
{
var strSearch = window.location.search;
var idx = strSearch.indexOf( ‘?’ );
if ( idx != -1 )
{
var pairs = strSearch.substring( idx + 1, strSearch.length ).split( ‘&’ );
for ( var i=0; I < pairs.length; i++ )
{
nameVal = pairs[i].split( ‘=’ );
gparams[ nameVal[ 0 ] ] = nameVal[ 1 ];
}
}
}
Once get_params() is called in the SCO, it is possible to make use of the data sent via the query object.
Please note: there exist limitations of the query object, such as string length, that should be considered before depending on the query object as a viable development solution.
Comments From Learner
All SCORM-conformant LMSs are required to support character maximums of 4000 characters per comment. Likewise, LMSs are required to support comment maximums of 250 comments.
Each LMS vendor is free to support more than the respective required maximums.
If no value is specified for the location of a comment, then the comment is assumed to be applicable to the entire SCO. It is up to the SCO to define the location of any given comment from the learner.
The timestamp for a comment from learner is in the format of (second, 10, 0). Per the RTE:
The time (second,10,0) data type represents a point in time. This data type shall have a required precision of 1 second and an optional precision of 0.01 seconds [1]. Implementations should be aware of this required precision versus the optional precision for it may impact implementation decisions. For example if an application is expecting the optional precision, it may not be supported. The SCORM dot-notation binding defines a particular format for a characterstring to represent a point in time. The format of the characterstring shall be as follows:
YYYY[-MM[-DD[Thh[:mm[:ss[.s[TZD]]]]]]] where
- YYYY: A four-digit year (1970 >= YYYY >=2038)
- MM: A two-digit month (01 through 12 where 01=January)
- DD: A two-digit day of month (01 through 31, depending on the value of month and year)
- hh: Two-digits of hour (00 through 23)
- mm: Two-digits of minute (00 through 59)
- ss: Two-digits of second (00 through 59)
- s: One or more digits representing a decimal fraction of a second). If fractions of a second are used, SCORM further restricts the string to a maximum of 2 digits (e.g., 34.45 – valid, 34.45454545 – not valid).
- TZD: Time zone designator (“Z” for UTC or +hh:mm or –hh:mm). The hh and mm shall adhere to the requirements defined above for hh and mm. The time zone designator uses the extended format as defined by ISO 8601-2000. The extended format requires the use of the colon “:” as a separator between the hours and minutes. If the difference between local time and UTC is required then the time can be expressed in hours and minutes (i.e., 03:10) or if the time difference is exactly an integral number of hours, then hours only (03). The leading zero is required for hours less than 10.
At least the four-digit year must be present. If additional parts of the time are included, the character literals “-“,”T”,”:” and “.” are part of the character lexical representation [1].

Example:
- “2003”
- ”2003-07-25T03:00:00”
Credit
A SCO should not base reporting decisions based on whether it is being experienced for credit or not. Much of the implied meaning of this data model element is handled on back end systems (LMS).
If a course is being taken for no-credit and the SCO still sets status and scores, then let the LMS will determine what to do with these scores and status as SCORM does not state whether or not a Run-Time Environment (such as an LMS) must support a mechanism for initializing this value.
From a SCO’s standpoint, the cmi.credit element is read-only. Because of this, the value has to be initialized some where outside of the SCO (since the SCO cannot set the value). Many implementations demonstrate that there is a way to signal that a learner is taking a course for credit or no credit. If an LMS supports this mechanism then the cmi.credit is initialized to whatever value the learner (or an administrator/instructor requires) chooses.
If an LMS does not support a mechanism then the default value (“credit”) must be returned by the LMS when the SCO makes a get request.
However, this assumes that when content is experienced for “credit” that the SCO will report a score, success status etc. This is not necessarily true. What it means to give credit for performance is not defined.
This could have many meaning depending on many different implementations, organizations, communities of practice, etc. For example, in an organization taking a course for credit might signal the LMS (or some piece of the LMS) to record information into a Training Record, which is outside the scope of SCORM.
Objectives
Objectives, like Interactions, require a unique identifier. Organizations should define naming conventions for cmi.objectives.n.id so that each objective has a unique identifier.
The Objectives Data Model Element is considered a “Local Objective” in terms of Sequencing & Navigation. Objectives, in this sense, have their own set of progress information within the SCO they reference and are considered separate from other learner activities. This means that Objective information referenced in one SCO by the Objectives Data Model Element cannot be directly referenced by another SCO.
Multiple SCOs may, however, reference a shared “Global” Objective. Global objectives can be used to make sequencing decisions. More information on how global objectives may be implemented can be found in the SCORM 2004 Sequencing & Navigation Version 1.3.1 document. (Section 3.10.1).
Overall Development
Pop-Up Windows

In order to track the learner’s activity, it is best to avoid using any additional pop-up windows, especially if you are unsure what LMS will be displaying your content.
SCOs and Assets

Do not arbitrarily decide what content will be a Sharable Content Object (SCO), collaborate with the project team and decide before you begin any development.
508 & Assessment Feedback

A screen reader only sees content that is available on the initial page load. If any text is dynamically generated with JavaScript, or a dynamic text field in flash, the screen reader will not recognize it. In order to make feedback accessible, it is best to display it on a new page.
Meta-data

Keep a running record of key information about text and file attributes. Update your meta-data on a regular basis.
Bookmarking

If you have a multipage SCO, it is best to set a bookmark when each page unloads. This will account for any unexpected exits, and upon returning, the learner will be brought to the last page they were at before leaving. We recommend creating a function that uses cmi.location and cmi.exit. This function should be called when the page unloads.
Manifest
Group all dependent resources together and then reference them with a common name.
Make sure all ids within the scope of the same manifest are unique. They may be developed to be globally unique.
Open the manifest in Internet Explorer since it is an xml file. This is one quick and easy way to test to see if the xml file is well formed. Once you have ensured that it is well formed, then test your manifest with an XML validating parser (this can be done by testing the manifest in the SCORM Conformance Test Suite).