Dynamic (interactive) RSS

December 1st, 2004 Comments Off on Dynamic (interactive) RSS

The questions my friend asked me about SCORM continued to bother me after I posted my answers here. As I indicated in the post, I thought my answers were not quite satisfactory. That being so, I started to think about alternative viable solutions for the context in which the questions were asked.

After thinking about the issue, I turned myself to what she had mentioned about blogs. That, in turn, lead me (kind of obviously) to RSS. So I decided to try a little experiment.

In the context the question was asked, there is a need to minimize costs and complexity while retaining at the same time the ability to provide a rich interactive experience and aggregate data. Obviously, the best way to do that is to leverage existing infrastructure. RSS offers the oportunity to make this happen in very simple ways.

The experiment, then, was the creation of an interactive RSS feed, able to react to options made by its subscribers and to behave in a way that approximates that of a course executed under a LMS. As I will comment further down, RSS offers possibilites just as interesting as the existing standards in the area. When I began to code the experiment, the first problem I faced was the fact that most aggregators rewrite the contents of a post to eliminate HTML elements like script and object, which are considered dangerous. This comes from the fear generated by some articles written by Mark Pilgrim and other some months ago. Many aggregators implemented a complete removal of those elements considered dangerous without thinking about the consequences. It’s not apparently obvious, but an indiscriminated removal of arbitrary elements completely prevents the user of richer media.

The fear of the problems those elements can cause is warranted, but the solutions implemented are quite simplistic. Ideally, an aggregator would implement something like security zones (as browsers do). Trusted feeds could run in more privileged zones, while all other feeds would run in a default zone where all problematic content would be stripped before the post was shown in the screen.

To work around this limitation in the aggregators I use, I had to find another aggregator that allowed this kind of content. Bloglines, SharpReader, and FeedDemon block or rewrite content in various degrees of zeal. So I download FeedReader, which showed the content as I needed. NewsGator showed the content as well. As I only could test on Windows, I didn’t check any Linux aggregator.

In case you want to check the experiment now, go to the test area of this blog. Access the main page of the experiment and use your aggregator to subscribe to the URL specified in the page. Reload the page as much as you want to automatically generate a new feed, and remember to use an aggregator that allows Flash movies to run. If you don’t have access to one, open the entries in the browser as they show in your aggregator. After completing an item, force the feed to be refreshed in your aggregator. (By the way, since I couldn’t spend much time on the experiment, I implemented no error controle. If you experience problems, try to generate another feed. If no feed works for you, please let me know.)

Below are some considerations about the experiment:

As I said in the answer to my friend, there’s nothing in SCORM that can’t be easily duplicated if needed. The simplicity and limitations of the standard see to that. Also, given the nature of the client API, it can be reverse engineered easily. That implies, for example, that it’s possible to modify the experiment to really talk to a SCORM-compliant LMS, gaining the advantages provided by the standard without losing the benefits of RSS. Obviously, reverse engineered protocols are a moving target and should be avoided. But it’s possible to visualize a scenario where a LMS offers a second, and external, SCORM API that courses in alternative formats can use.

So the access to the LMS can be made directly (if the API is based on some combination of JavaScript and XML) ou through a proxy (if the API is based on Java or ActiveX). In any case, it wouldn’t be something complicated to do, especially considering that the SCORM data model is a small and fixed dictionary. In the experiment, for example, the approach is to talk directly to the server.

The possibility of external communication opens the door to the creation of a different API that can be adapted to the most diverse scenarios — more open scenarios than SCORM provides, and with a SCORM translation tied if necessary — without the need to introduct any limitations on the distribution of the courses.

Regardless of the use of SCORM, however, the use of RSS in a dynamic way offers a environment able to provide a complete learning experience. A unique and customized RSS for user is not a novelty, and it allows a granulated control over the user experience. Such a feed can even branch, displaying different entries according the choices the user has made. There are, nonetheless, some problems and limitations in the use of RSS for that purpose. They can’t prevent the use of RSS, but they should be considered anyway.

Firstly, the problem aforementioned of content rewriting. The correction of this problem involves the adaptation of aggregators themselves, which is far from an easy task. A temporary work around is the use of aggregators that don’t display such limitations.

Secondly, there’s always the possibility of running into problems with cross-domain scripting. That’s a problem with SCORM courses as well. Depending on the way the aggregator was implemented, it’s possible to avoid it completely. In case it’s not possible to avoid it, other solutions like the use of Flash movies can minimized the issue.

Thirdly, most aggregators don’t implement any kind of control over the refresh rate of a feed beyond the most basic. Ideally, an aggregator should be able to find the update information in the feed itself. In practice, it would be necessary to resort to manual refreshes. Updates at regular intervals are not a good options since it’s necessary to allow the user to pick the best time to read the entries.

Fourthly, since the feed is dynamic, its offline use if almost impossible, especially so because the client API required a connection to work.

Even taking those problems into account, it’s easy to realized that RSS can be used in this context without problems. There’s not need to use limited and unsecure standards, although existing code may benefit from them.

There are many other possibilities to explore too, not shown in the experiment. For example, the use of HTML forms communication through XML with the server, the use of new windows to provide a richer experience, Podcasting for video and audio, a more refined control over the feeds by way of the guid of each entry, etc.

The fact that a server is being used to distribute content should not be cause to think that all limitations inherent to SCORM were solved. Because of the misture of possible clients and servers, there’s a practical limit to the technology in use. RSS can extend the border further, but the border it’s still there at the end of the day.

Comments are closed.

What's this?

You are currently reading Dynamic (interactive) RSS at Reflective Surface.