TrAVis (Tracking Data Analysis and Visualization Tools) Version 1.2 was briefly presented here. In the objective of making TrAVis better and especially match the real needs of the participants in the distance learning process, TrAVis has been introduced to a number of students, teachers and researchers from different disciplines. A survey has also been lunched to seek for the feedbacks from the users who had a 45 minutes hands-on session during the Summer School workshop in Grenoble last July.

With the survey data and some other significant comments from our colleagues, we are currently working on the development of TrAVis 1.3.

Besides the amelioration of the existing functional tools for tracking data visualization, a big number of bugs have been fixed and codings have been improved. In the next version of TrAVis, two new features will be added. Each feature contains a few more functional tools to allow users to automatically analyze and visualize the tracking data of the Computer Mediated Communication activities.

The first feature of TrAVis 1.3 will be called “Time Machine“. We aim at providing another possibility to the users, particularly the teachers, who wish to real-time monitor every action of a particular online student while he/she is using a Computer Mediated Communication tools (e.g. discussion forum). The “Time machine” will be equipped with flexible user interface that provides both the overview of every interaction of a user communication activity and in which the detail of each user action.

The second feature of TrAVis 1.3 will be called “Data Indicator Generator“. The current version of TrAVis does not allow user to look for the data indicators from the existing tracking data by their own. The reason is that the existing analysis methods are formulated to produce every data indicator without any user operation. Users can not chose which data indicator to or not to be viewed. We have thought about another interesting way to make the tracking data more substantive and if possible response more accurately to the expectation of each user. We are working on the conception of a functional tool that makes customization and personalization of the tracking data indicators possible with a few clicks from the users. With the “Data Indicator Generator” feature, TrAVis users will be able to control more efficiently the way tracking data indicator should be generated by the analysis components and to be next visualized by the visualization components.

Here some other new changes in TrAVis 1.3 :

• The cascading style sheet of TrAVis 1.3 is now compatible with the three world most used Web navigators: Internet Explorer, Mozilla Firefox and Apple Safari.
• The information tags are attached to each button of the principal menu of TrAVis.
• Graphics and background colors are modified.
• Ease of use graphic user interface (CSS, AJAX and Javascript)
• and a lot more to come…

We are expecting to give a demonstration of TrAVis 1.3 to our research team in January 2008.
I would like to thank my both advisors, Sébastien George and Patrick Prévôt for their times, their innovative ideas and for supporting my work.

… We can return server data to our Ajax application as text (using the responseText property of our XMLHTTPRequest call) or as XML (using the responseXML call).

In the many situations where we simply wish to update the content of HTML elements on our page, it becomes difficult to justify the added complication of using XML. Using the responseText property, we can persuade our server to return properly-formatted (X)HTML directly into the page, where it can be styled and presented via standard CSS techniques. The need for XML parsing, XSLT transformations and the like, all disappear.

This technique is coming to be known as AHAH (Asynchronous HTML and HTTP) and seems ideal as a lightweight, easy-to-implement method for building Ajax-style applications whose sole purpose is to run in a browser and update an HTML page.

The mathods for forming the XMLHTTPRequest have been covered in some detail elsewhere on this site, as have the means of sending the XMLHTTPRequest. Now let’s examine how those two functions may be combined into our AHAH call:

function callAHAH(url, pageElement, callMessage, errorMessage)
{
   document.getElementById(pageElement).innerHTML = callMessage;
   try { req = new XMLHttpRequest(); /* e.g. Firefox */ }
   catch(e)
        {
            try { req = new ActiveXObject("Msxml2.XMLHTTP"); /* some versions IE */ }
            catch (e) {
                          try { req = new ActiveXObject("Microsoft.XMLHTTP");
                                 /* some versions IE */
                               }
                          catch (E) { req = false;
                          }
                  }
         }
         req.onreadystatechange = function()
                                             {responseAHAH(pageElement, errorMessage);};
         req.open("GET",url,true);
         req.send(null);
}

Here we combine the creation of the XMLHTTPRequest object and the sending of the request into a single Javascript function, to which we pass four parameters: url, the address of the server routine we wish to call; pageElement, the id of the HTML element we wish to update; callMessage, some text to show in pageElement while the request is being carried out; and finally errorMessage, a message to display if our request should fail for any reason.

As can be seen from the code, our function calls a response handler called responseAHAH. To this we pass as arguments the identity of the page element we want to update, and the error message to display should our call fail. Let’s look at the code for this function:

function responseAHAH(pageElement, errorMessage)
{
   if(req.readyState == 4)
   { if(req.status == 200)
      { output = req.responseText;
        document.getElementById(pageElement).innerHTML = output;
      }
     else
      { document.getElementById(pageElement).innerHTML = errorMessage+"n"+responseText; }
    }
}

We can combine these two functions into a remote javascript file, and simply link it to our application, making AHAH very easy to use, and even to retro-fit into legacy HTML pages.

Link : original post

A few weeks ago a few folks discovered the REST section of the microformats wiki, which discusses “how to optimally use Microformats as the encoding for REST web services”, but has grown to include broader discussions of applying microformats principles to both protocols and javascript techniques.

One of those principles could be rephrased as: Why use XML when (X)HTML will do?

Perhaps another could be rephrased: Why bother with parsing/transforming when you can just get the data in a presentable format? After all, we all know that less code is better.

AHAH (Asychronous HTML and HTTP) is the result of applying both of those principles to the incredibly Web 2.0 buzzworthy AJAX. Strictly speaking, AHAH is simply a subset of AJAX, albeit a subset that openly de-emphasizes the X in AJAX.

AJAX Magazine provided a good overview of the advantages of AHAH over “traditional” XML-based AJAX.

Keith Devens summarized it well:

…instead of grabbing arbitrary XML and processing it on the client-side with Javascript or XSLT and inserting things into the DOM, you just grab bits of (X)HTML from the server and inject them directly into your page. So, the client side does much less logic and merely needs to say “replace the content in the element with this ID with the (X)HTML at this URI

So if you’ve been wondering what this AJAX stuff is about, take a look at AHAH, you might find it gets you 90% of the hyped user interface advantages with only about 10% of the hype (and effort for that matter). That’s the kind of 90/10 rule we like around here.

But don’t take our word for it. See what others have been saying about AJAX and AHAH.

I’m using these light-weight, but flexible and powerful technologies to develop the TrAVis (Tracking Data Analysis and Visualization Tools)