What is Hijax

Hijax, the term, is a play on words. It combines the words Ajax and Hijack to describe its core functionality. Hijax uses Ajax and Javascript where available to create those Web 2.0 effects to which we have all grown accustomed: shiny transitions and quick page interaction. It also Hijacks the HTTP reqeust when Javascript is availble and enables Ajax form submission, history, page loading, etc. When Javascript is not available, the page functions normally, except without the fancy transitions and Ajax page interactions.

Backwards compatibility is the core idea of Hijax: to create a rich client experience while not sacrificing anything in accessibility. The core Hijax proponents, and unobtrusive Javascript coders in general, stress that developers should progressively enhance rather than abandoning accessibility from the start. Jeremy Keith, who coined the term Hijax, states it best in his writeup at DOMscripting:

• Plan for Ajax from the start.
• Implement Ajax at the end.

This essentially means developing a fully functioning site before adding Ajax or Javascript effects. Then, when the core functionality is complete, we add in Javascript and Ajax while not breaking any of the functionality that previously worked.

This is normally accomplished by transferring most of the responsibility of data processing to the server, instead of relying on Javascript to do much of the heavy lifting. The implication is that by relying on the server we need less Javascript code to accomplish the same amount of interaction that would require much more Javascript. This in turn means less dependence on Javascript for normal page interactions.

In Practice

In practice, Hijax requires a modular web framework to be able to conditionally respond to differing types of requests. For example, a non Javascript capable browser will submit a form using standard urlencoded GET or POST parameters and standard HTTP headers. The browser then expects a full page to be sent in response. An Ajax form submission can submit the form as a serialized JSON or XML object with the X-Requested-With header set to XMLHttpRequest. The page would then expect perhaps a JSON object or a partial page response to load into a container. The server side script, in order to fully realize Hijax, must be able to flexibly respond to each of those requests.

Likewise, the Javascript library must be able to unobtrusively Hijack form submissions. jQuery is an excellent choice in terms of unobtrusiveness and community support. Many people report success in using the popular Form plugin with Hijax implementations. It allows the developer to remove all behavioral code from the markup and place it in the HEAD or in a separate included file. This approach to Hijax is vital as it removes the dependency on Javascript to normal form submission, and other page interactions.

Another excellent choice in Hijax frameworks is CakePHP. CakePHP already does most of the heavy lifting by determining request types and deserializing XML objects, among other features. This allows the developer time to focus on the actual implementation of the application rather than focus on creating a Hijax friendly framework. Much of the work is done by the RequstHandler component which handles converting request objects and setting content type specific layouts or views.

For Example

While the only example of Hijaxing an application in this post is by Hijaxing forms, it can be done with any Ajax technique. I am currently working with Hijax techniques in creating an accessible navigation system where non Javascript requests will get a standard querystring appended to the url, and Ajax requests will get a # appended, such that history is preserved in both instances. In order to preserve history with Ajax requests I am using the excellent History plugin. In the non Javascript instance a full page is included in the response, where in an Ajax response only the content of the page that changes is included in the response. In both cases the action code and the view code are almost exactly the same.

In Summary

Hijax, in summation, is not just another useless buzzword. Hijax offers web developers and designers the flexbility and interactivity of Ajax while at the same time ensuring that a site is usable by the greatest possible amount of users. As opposed to other Ajax frameworks or techniques that aim to make the web more interactive, Hijax aims to make the web more interactive and more accessible.

Since the initial release of Beanstalk Games last month, our team has been hard at work creating more features for our users to enjoy. My role in this, as the programmer, is to build the behind the scenes functionality of the site. My job is to make things work smoothly and plug in the designs from the designer and artist. My goal for Beanstalk Games is to make it as interactive as possible without compromising on security or performance. To this end I submit the following features to expect in future releases of Beanstalk Games.

Short Term Releases

The following features will be released within the next few weeks or so, as they require more development and testing time. I have implemented a graphical rating system which instead of the numerical system, allows the user to rate games using stars. The rating system, a jQuery plugin, can accommodate any graphic. The plan for the future is to use beans to tie in with the beanstalk theme. The graphical rating system has also provided the impetus to switch to the wonderful jQuery JavaScript library, which in turn has decreased page size and uncluttered some markup. Previously the site was using Prototype, which I find to be too old fashioned JavaScript and requires the use of onclick and other HTML event attributes. Also, in an effort to recommend similar games in the future, and immediately improve site usability, I have implemented a favorite game system where users can tag games as their favorites which then show up under a favorites header on the profile page. Once games have been added to a user’s favorite list, they can be removed from the profile page as well. Likewise I have implemented a recently visited games feature, where our system tracks which games a user views and displays that information on the profile page under a recently viewed games header. I have considered adding an opt-out option to the profile page as well, for users who do not want our system to keep track of their habits. Another addition to the review system is the useful review feature. This system allows user to recommend this review to other users. Those reviews with the most recommendations will float to the top and be displayed first.

Long Term Releases

Farther down the road are the following features that still require some significant development and design work. We will be implementing a parent/child review system where reviewers will have the opportunity to review a game for themselves along with the opportunity to review it for their children. Likewise we are implementing a professional reviewing system where industry reviewers are able to review the games on our site. These reviews will then be displayed along with user reviews. We also want to be able to recommend games that are similar to the currently displayed game. This metric will help the user as it provides an additional point of reference for new or unfamiliar games. This feature will make use of the game reviews as well as the recently viewed and favorite game features. I have also implemented an ESRB rating system where the games that have ESRB ratings will display the familiar E, T, etc. ratings. Similarly I am working on implementing an age range system where games will be associated with the age range of children or adults who will enjoy it most. We are also working on a system that will allow us to associate games for which we have retail copies. This will essentially link to our new upcoming Brighter Minds website.

Technical Discussion

I would now like to discuss some technical issues. These are generally the things that excite me most, as they allow me a respite to the usual grind that is programming. On the slate today is collaborative filtering. What I have learned about collaborative filtering is that it puts to use statistics that most sites already have to create a useful recommendation system. The general idea is that we start out with, for example, a table of user reviews of games. Clearly there is a great deal of information here including the user names, game information, and more. But collaborative filtering uses this potential mountain of data to find games that a given user would like or that are similar to a given game. This is done by examining the current user’s review history and finding the games he/she reviewed. The next step is to look at the entire review dataset to find games that others have reviewed that the current user has also reviewed.

After finding the review correlations there are two paths we can take to analyze the data. One path recommends games on a user basis, where we analyze user reviews and make recommendations from users whose reviews are similar. The other path we can choose is to analyze the reviews and make recommendations based on similarly reviewed games. The first technique is called user-item filtering, and the second technique is called item-item filtering. I plan on using the item-item filtering technique so its details follow.

Once we have this user-game matrix we apply a difference algorithm to the data set, which essentially computes the similarity between games that have been reviewed. This produces a matrix of game-game similarities. Popular difference algorithms are the Pearson score and the simple Euclidean distance formula. Once this is applied we can compute the review of the current user for the games he/she has not played. This computation can be done in a number of ways but the simplest is the weighted sum. We then select the highest computed reviews and recommend those games to the user.

In terms of performance, the most demanding operation is finding the game-game similarity matrix where we apply our difference algorithm. It is trivial to compute the user’s predicted review. To mitigate this, we can simply store the game-game matrix in a database table. The implication is that we then only have to calculate the matrix again if a time interval expires or games or reviews have been added. I am thinking of simply running this operation on a given interval, daily or weekly. Then, game recommendations are simply found by a look up in the similarity matrix table, a computation of the given user’s predicted review, and a sort on the closest matching games. The only sacrifice here is that new reviews or games do not get added until the matrix is updated, which may be up to seven days.

Another technique is to take the current user out of the computations. This essentially finds games that are reviewed similarly by a group of people. I have yet to research this technique further, but it does look promising, provided it does not require a significant increase in computation time.

How this applies to the games on Beanstalk Games is still to be decided, but one source of readily available information is the favorite and recently viewed game histories. Here the same techniques apply, but the review example changes from a review metric to a viewed/not viewed or favorite/not favorite metric, which is essentially the same as a 0 or 1 review. I only hesitate not using reviews because the dataset would be very sparse, which means the recommended games may or may not be accurate.

Honestly I am still rather foggy on the details of these techniques, and since I am writing this off line (gasp), here are some references for further reading. The resource I most recommend is the Collective Intelligence book from O’reilly with the penguin cover. A really great technical explaination I found on CiteSeer is called Item Based Collaborative Filtering Recommendation Algorithms. And a PHP implementation that I haven’t had a chance to look at is called Vogoo. Also the obligatory Google search.

Stay tuned for more exciting adventures next week.

BeanstalkGames coming soon!