Custom login pages

Most EKP sites will use a custom login page rather than the standard page that ships with EKP. This is done by creating a file named login.wm and placing it in the WEB-INF/conf/ directory. The contents of this page are essentially HTML, with some placeholders for dynamic content that use the Velocity Template Language (VTL).

The standard login page, which can be used as a guide, can be extracted from the file WEB-INF/lib/ekp.jar using a zip utility such as WinZip or WinRAR. The location of the page within the ekp.jar file is com/netdimen/tx/auth/login/login.wm for EKP 4.7 and above, or com/netdimen/tx/login/login.wm for EKP 4.6.

One important point that is easy to overlook is that the page should contain the code shown below immediately after the opening <form> tag of the login form.

  #if ($target != "")
  <input type="hidden" name="target" value="$target" />
  #end

This code will ensure that, if a user who is not logged in attempts to access a page that requires authentication (which would happen if the user's session had timed out, for example), EKP will "remember" which page the user was trying to access and forward the user to that page after prompting her to log in. If users are always forwarded to the default start page after logging in, even if they were prompted to log in while trying to access another page, it is most likely because the above code is missing from the login page template.

(Note that the default static index.html page simply redirects the user to the dynamic login page described above. We recommend leaving the index.html page as-is and simply creating a login.wm page as described above, to avoid duplicating the custom login page HTML code.)

If your EKP site is hosted by NetDimensions, these steps will normally be performed for you by our staff.

Directory services and hosted EKP sites

Consider the following scenario, which is not uncommon. An organization wishes to make use of an EKP site that is hosted outside of their network. The organization has already implemented a directory service (Active Directory for example) that is most likely accessible via LDAP. Naturally, the organization would like their users to be able to access EKP using the usernames and passwords stored in the directory service. Below are three ways in which this could be accomplished.

1. Usernames and passwords could be exported from the directory service (using a tool such as CSVDE for Active Directory for example) and imported into EKP. The import could be performed manually using EKP's CSV User Data Loader, or it could be automated using EKP's APIs or import scheduler. Users would log into EKP using EKP's standard login page.
2. The EKP site could be configured to connect directly to the organization's directory service using LDAP to perform authentication. Again, users would log into EKP using EKP's standard login page.
3. A login page could be created on a web server in the organization's DMZ that connects to the organization's directory service and implements an authentication service for EKP as described in this previous post.

The first approach has a few disadvantages.

• It is not real-time. For example, a password change in the directory service will not take effect on the EKP site until the next time the usernames and passwords are synchronized.
• For extra security, systems that support password-based authentication might store a cryptographic hash of a password, from which it is infeasible to recover the original password, instead of storing the original password. (In fact EKP does exactly this, which is why it is not possible to export passwords from EKP.) Thus, it might not be possible to export passwords from the directory service.
• Even if it is technically possible to export passwords from the directory service, replicating passwords on a system outside of the organization's network might violate the organization's security policies.

The second approach avoids these problems. However, it does require that the organization's directory service be accessible from outside the organization's network, which often will not be the case. (This would of course be the preferred approach if the EKP site was hosted inside of the organization's network.)

The third approach has several advantages.

• It is real-time. For example, when a password is changed in the directory service, the new password will immediately be effective for accessing EKP.
• It does not require passwords to be exported from the directory service or replicated outside of the organization's network.
• It does not require that the directory service be accessible outside of the organization's network via LDAP.
• In cases where the organization already has a web site or portal that authenticates against the directory service, the authentication service for EKP can be combined with the existing site, thus providing single sign-on between the existing site and EKP.

This third approach should be the preferred approach in most cases where the EKP site is hosted outside of the organization's network.

Specifications and copyright

IMS Global Learning Consortium: Today the IMS Global Learning Consortium (IMS GLC) announced plans to initiate a pilot project in the distribution of interoperability specifications under a form of Creative Commons license.

There's a murky relationship between technical interoperability specifications and standard copyright. Here's an example.

Every SCORM-conformant content package needs to contain a set of W3C XML Schema documents. Since SCORM content packaging is derived from the IMS Content Packaging specification, one of these required documents is an IMS Content Packaging schema document, which contains an unambiguous IMS GLC copyright notice.

Based on this, it seems one could make a reasonable case that every SCORM-conformant content package is a derivative work, and hence an infringement of IMS' copyright.

Adopting a framework such as Creative Commons seems like a sensible way forward.

SCORM and AICC compared

GerryWaz: Anyone know of a good, dispassionate comparison of the two standards? Strengths and weaknesses of each?

In matters of technology, newer is frequently equated with better. However, while SCORM is the newer specification and is more widely supported, there are valid reasons for using courses and management systems based on the AICC specifications.

Below are some points to consider when deciding between AICC and SCORM. (We consider only SCORM 1.2 and SCORM 2004, since earlier versions of SCORM are effectively obsolete.)

Packaging and deployment

Thanks to SCORM's well-defined packaging model, deploying SCORM courses is often as simple as uploading a zip file. Historically, deploying AICC courses involved more steps due to the lack of a similar packaging model for these courses. In late 2006, AICC published a packaging specification for AICC courses. However, this is still not part of the core AICC specification, so neither AICC-conformant courses nor AICC-conformant LMSs are required to support it. (EKP supports AICC course packages.)

Ease of development

SCORM-conformant courses communicate with an LMS by calling methods of a JavaScript object called the API adapter. AICC-conformant courses communicate with an LMS by sending HTTP messages to the LMS, and interpretting the LMS's responses. (This communication method is known as the HTTP AICC CMI Protocol, or HACP.) Where courses are developed without the aid of specialized course authoring tools, it's usually considerably easier to implement SCORM communication than AICC communication. (However, most specialized course authoring tools shield the developer from these differences.)

Technical requirements

A conformant SCORM API adapter must implement complex rules for validating tracking data and reporting errors and, in the case of SCORM 2004, for evaluating and enforcing sequencing rules and processing navigation requests. Because of this complexity, many robust implementations use Java technology to implement the API adapter, meaning that Java must be available on the user's machine. (Both EKP and ADL's reference implementations use Java to implement the API adapter.) On the other hand, since AICC courses use direct HTTP-based communication, LMSs typically don't require Java to track AICC courses. (However, the courseware itself might still require Java.)

Cross-site scripting

Cross-site scripting occurs when content loaded from one web site in a browser attempts to read or manipulate content loaded from another web site in the same browser. In general, cross-site scripting presents a security risk, and browsers rightly restrict it in most cases. However, these restrictions can also interfere with tracking of courses where the courses reside on a different web site from the LMS. The problem is usually more serious for SCORM courses than for AICC courses. As described above, SCORM courses communicate with the LMS using JavaScript calls, and these are almost always blocked when the course and LMS reside on different sites. On the other hand, due to the nature of AICC communication, AICC courses have greater choice about the specific technology used to perform the communication, and different technologies enforce different policies regarding cross-site communicating. For example, an unsigned Java applet may not communicate with a site other than the one from which it was loaded, but a signed Java applet may do so if the user explicitly grants permission. Even without the use of browser plug-ins such as Java or Flash, an AICC course can implement course-to-LMS communication (but not LMS-to-course communication) simply by using standard HTML forms.

Sequencing

The AICC, SCORM 1.2 and SCORM 2004 specifications all provide sequencing mechanisms—that is, mechanisms for specifying rules concerning the order in which independently trackable units of content can be delivered. (In SCORM terminology, these units of content are called shareable content objects, or SCOs. In AICC terminology, they are known as assignable units, or AUs.) However, only the SCORM 2004 specification requires the LMS to support these mechanisms. On the other hand, it's always possible to implement sequencing in a way that is internal to the SCO or AU. So this is only an issue if you aim to reuse SCOs/AUs at a level of granularity below the course level.

Internationalization

The polite term for the AICC specification's support for internationalization is “boneheaded .” In particular, the AICC specification specifically prohibits the use of Unicode character encodings (e.g. UTF-8, UTF-16), instead requiring the use of one of the ISO 8859 family of encodings. Whereas Unicode encodings support virtually all modern languages, the ISO 8859 encodings support only a very limited set of languages, with Asian languages being particularly poorly supported. (Chinese, Japanese and Korean are all unsupported for example.) There's no good reason for this restriction, and in practice many systems "extend" the AICC specifications to support other encodings. (For example, EKP supports a wide range of encodings beyond the ISO 8859 family, including both UTF-8 and UTF-16.) However, a further problem is that the AICC mechanisms provide no clear way to specify which encoding is being used, so trial and error is often necessary in order to ensure non-English text displays as intended.

Tips on integrating Articulate-created content with an LMS

On Articulate's Word of Mouth Blog, Gabe Anderson has posted a useful checklist of things to look for when integrating Presenter- or QuizMaker-created content with an LMS.

Search EKP's catalogs from your browser's search box

EKP 5.0 makes it possible to search EKP's course catalogs directly from the search box of Internet Explorer 7 or Firefox 2.

When a user visits EKP using Internet Explorer 7, the drop-down arrow of the search box "lights up" to indicate that EKP has been added to the drop-down menu.

To add the EKP search provider, select Add Search Providers from the drop-down menu, then select Enterprise Knowledge Platform by NetDimensions.

Internet Explorer will prompt you to confirm that you want to add the search provider.

After clicking Add Provider, select Enterprise Knowledge Platform by NetDimensions from the drop-down menu.

With the EKP search provider selected, initiating a search from Internet Explorer's search box opens EKP's catalog search results page directly.

Similarly, when a user visits EKP using Firefox 2, the drop-down arrow of the search box "lights up" to indicate that EKP has been added to the drop-down menu.

To add the EKP search provider, select Add "Enterprise Knowledge Platform by NetDimensions" from the drop-down menu.

With the EKP search provider selected, initiating a search from Firefox's search box opens EKP's catalog search results page directly.

How can I publish an Articulate Quizmaker quiz as an AICC course package that I can import into EKP?

Articulate Quizmaker is capable of publishing quizzes as both SCORM and AICC content. EKP can import and deliver both formats. One advantage of publishing as AICC content is that learners do not have to have Java installed in order to take the quizzes. However, there are a few points to bear in mind when publishing Quizmaker quizzes as AICC content. By following the steps below, you can publish a quiz as an AICC course package and import the package into EKP.

1. Click the Publish button in the Quizmaker toolbar.
2. In the Publish window, choose LMS from the left menu.
3. In the LMS field under Output Options, select AICC.
4. Click Reporting and Tracking...
5. Under LMS Course Information in the LMS Metadata window, complete the Description and Creator fields. Note that if you leave these fields blank, Quizmaker will omit these fields from the published AICC files, resulting in files that are invalid according to the AICC specification. Therefore, in order to produce a valid AICC course package, you must complete these fields before publishing the quiz.
6. The default value of the Filename(URL) field is http://www.servername.com/quiz/index_lms.html. While it's possible to replace this with the full URL at which the quiz will be published, it's easier to simply remove the initial portion so that the value becomes just index_lms.html. (Note that the value should not contain any slash characters.) If you then import the quiz into EKP as an AICC course package as described below, EKP can automatically deduce the full URL needed to launch the quiz.
7. Click the OK button to dismiss the LMS Metadata window.
8. In the Publish window, under Output Options, ensure that the check box labeled Zip files is checked.
9. Click Publish.

The resulting zip file can be imported into EKP using the Import Content Package function (Manage > Catalog Manager > Import Content Package)—simply follow the on-screen instructions.

In summary, the important points are as listed below.

• Be sure to complete the Description and Creator fields in the LMS Course Information section of the LMS Metadata window.
• Enter index_lms.html in the Filename(URL) field.
• Under Output Options in the Publish window, ensure that the check box labeled Zip files is checked.
• Import the published zip file into EKP using the Import Content Package function.