eRaUI user tracking tool - Video Demonstration

We have put together a brief video demonstration of the eRaUI tracking system. This is already promising to be a useful standalone component which would be beneficial for anyone wanting to track user behaviour on their website. The demo shows how after visiting the NaCTeM website and performing a series of actions, we are able to play back the exact behaviour of the user (which has been recorded in our remote database). Currently we are able to capture and play back the following browser events:

• Mouse Movements
• Mouse Clicks
• Field Focus Events
• Change of window.location.href
• Precise timings of events
• browser viewport resize
• scroll events
• keypress events

Weekly Technical Meeting - 22nd September 2011

The eRaUI team met again on Thursday 22nd September for our weekly technical meeting. During the course of this meeting, we saw a demonstration of some of the current developments within eRaUI so far. This included a brief tour of the data collection, recording, playback and heatmap tools so far created. These tools already have significant useful functionality, despite being in an early alpha stage of development. Currently, the analytical component of eRaUI is able to:

1) Record a user's interaction with a web-application, including all clicks, mouse movements, key events and scroll events.

2) Identify recurring visitors across domains and determine essential analytics regarding their platform, browser and OS.

3) Play back their interaction with a web application; using a jQuery based 'replay' system.

4) Generate a heatmap indicating mouse clicks within the application - thus highlighting the areas within an application which are often visited / clicked.

We also discussed the following points:

User Identities within eRaUI - one of the difficulties with the current eRaUI proposal is the need to track individual users who may visit a website on multiple occasions. The currently proposed mechanism of cookie-based tracking makes it difficult to reliably keep track of the precise identity of users. However, it is possible, using cookies, to identify patterns of usage particular to recurring visitors in a way which is imprecise yet still meaningful. In order to address this difficulty, it is proposed that we consider a login system whereby users of eRaUI-enabled interfaces can uniquely identify themselves.

We discussed ways in which it might be possible to categorise users into levels (i.e. expert, novice etc) using ontologies. This method (essentially a dictionary of keywords corresponding to levels of use) would need to be specific to a particular field of website or web-application (i.e. research), which somewhat limits the generic applicability of eRaUI. It has been discussed that there may be more non-application-specific mechanisms by which to determine user type.

Another mechanism by which it may be possible to categorise user ability level is by monitoring users' behavioural pathways as they seek particular content items within the website. For instance, a novice user may take a long time to locate a particular tool within the NaCTeM website compared to an experienced user. By comparing the times taken to reach the same item, we can make inferences as to their experience level and categorise them accordingly. A short path to a particular item would mean an experienced user.

It has been suggested that the newly-created heatmap analytics system be made so that links within heatmaps can be followed to generate heatmaps of the pages which they link to. This will always be possible provided that data is available within these pages to generate a heatmap.

The analytics (heatmap and recording) systems are currently somewhat separate in terms of proposed functionality to the widget aspect of eRaUI. For this reason, it has been proposed that eRaUI might be implementable in an 'analytics only' form for users who may wish to benefit from the analytical data without placing a widget on their web-application.

It has also been proposed that we ensure that code is adequately commented so as to make our deliverables as redistributable and configurable as possible for end-users.

Weekly Technical Meeting - 15th September 2011

On Thursday 15th September 2011 the eRaUI team (Farhi, Eamonn, Yanguo and Sahithi) met up to discuss progress so far. We discussed some of the achievements so far for September:

• Producing a storyboard and development of the eRaUI blog. We also discussed the comments which have been made so far on the blog.

• Jisc Usability UK meeting on the 31st of August - this proved to be very informative and gave us insights into a tool which promises to be greatly beneficial in terms of connecting developers and web application designers to persons who are knowledgeable in the field of usability. Since usability is an essential facet of eRaUI, this could prove to be a very helpful tool. The meeting also enabled us to meet other people involved in Jisc funded projects.

In the meeting we also discussed the following objectives:

• Machine-learning algorithms - while at present the focus of eRaUI is on the mechanism of data-collection from clients upon which eRaUI is embedded, we also discussed some of the uses to which the data can be put once collected. There are a number of methods which could be used to organize this data and make it 'learnable' in such a way as to inform the functionality of an intelligent search client.

• User Profiling - we have already implemented some basic mechanisms in eRaUI for tracking users. A challenge is to divide users up into categories such as 'Novice', 'Expert', 'Researcher'. We discussed the respective merits of making this categorisation internal as opposed to explicit (i.e. requiring user-interaction to specify the category). We also discussed the possibility of making the categorisation customisable on a per-application basis - i.e. a business web application may wish to divide users by attributes such as 'business type' - i.e.. small, medium, global, etc. While the categorisation of users is a good starting point for matching users to content, the eventual aim is to match users to the content according to more subtle analytics which will evolve as more and more users interact with the application.

• We saw a brief demonstration of eRaUI so far - demonstrating its potential for scalable collection of user data across web applications with minimal difficulty to embed in any user interface. We also saw a working prototype of the predictive search mechanism which will aim to guide users to the content they require.

• We discussed the possibility for categories of user to evolve as the user interacts with eRaUI.

For next week we aim to produce a working realisation of the data collection (user-profiling/behaviour) which has so far been worked upon. This will take the form of an 'analytics' style playback of user interaction with web applications upon which eRaUI has been embedded, along with click-heatmap inspired indications as to user preferences in terms of preferred content.

eRaUI prototype - challenges

An interesting challenge which has arisen while building the prototype is the difficulty in allowing the widget to communicate via ajax with the eRaUI domain while the widget itself is embedded on a website residing on a different domain / server. Due to cross-domain restrictions, it is not normally possible to communicate within a webpage with a domain other than that from which the page originated. Fortunately, there is a workaround which involves:

• Instead of sending a simple data POST to the eRaUI server, we dynamically create a 'script' tag embedding a request for a target .js file. The data is sent to the .js in the querystring of the url.
• The response from the server takes the form of a javascript call to a function pre-defined within the widget code, which accepts the data and makes it available for processing. Thus we circumvent cross-domain javascript restrictions which are fortunately not applicable to embedded requests for .js scripts, even when the script resides on a different domain.
• Cookies can be handled too by means of an embedded iFrame. The iFrame creates a request for a page on the eRaUI server to which a uniquely generated id is sent by the widget. This could in theory be used to maintain user tracking across any domain in which the widget is embedded.

Deployment of eRaUI is simple - a single javascript include allows for the above functionality, thus making eRaUI easy to deploy upon any website.

Meeting on Thursday 8th Sep

Eamonn, Farhi and Sahithi met on the 8th September to discuss the direction of the project and consolidate progress so far. We discussed the objectives for September and came up with the following:

• Eamonn will work on the project report (see September objective no. 1)

• Investigate the use of heat maps for user modelling.

• User groups for evaluation of eRaUI - we have decided that each test group will contain 6 members.

• Creation of web server account for the deployment of a website simulating the functionality of NaCTeM. This would require the availablity of PHP and MySQL.

• Possibility for PhD research opportunities arising out of this project were also discussed.

Ideas

The following features could be integrated into eRaUI (when running in widget form) to enhance the user experience.

• Social Networking Icons – i.e. facebook and twitter (like / tweet)
• Print Page Icon
• Translate
• Contact Us
• Bookmark
• Feedback and bug reporting capabilities

Existing Softwares which place a widget (toolbar) within the browser window:

• · http://skysa.com
• · http://www.meebo.com/
• · http://www.wibiya.com/
• · http://www.apture.com/

Mechanisms of Deployment:

• · The most simple and feasible mechanism to deploy a browser-based widget is probably to add a javascript include (single line of code) to the section of a webpage.
• · Another possibility is to create a Wibiya Application – allowing eRaUI to be deployed inside Wibiya.
• · Could also feasibly be run as a Browser Extension (like the Google Toolbar) so that it could work with any website or web application.

Algorithms and methods for machine learning

Machine learning algorithms could be used to determine which features of eRaUI are being used on a website and which are redundant. Thus the application could switch features on and off according to the extent to which they are made use of. This might be particularly useful when taking into account detected User-Agent or resolving a client’s IP address to their geographic location. Machine learning algorithms could be used to determine what elements of eRaUI are best for presenting to the user.

Types of Machine Learning Algorithms:

• · Supervised Learning – less suitable because of the need for an element of human supervision.
• · Semi-Supervised Learning – same issues as Supervised Learning in terms of requiring an element of human supervision.
• · Reinforcement Learning – possible
• · Genetic Algorithms – it may be possible to allow the underlying algorithms to modify themselves in such a way as to present the most useful information to the user.

http://www.obitko.com/tutorials/genetic-algorithms/

• · K-Nearest Neighbour algorithm – this is a possibility – although it is the most simplistic of all machine learning algorithms
• · Cluster Analysis – although not an algorithm in itself, this could help with the process of separating user actions in such a way as to make them amenable to certain techniques.
• · Bayesian Methods

September Objectives

The objectives for August have been successfully achieved, and we are currently working on a prototype implementation of eRaUI based upon the specifications outlined in my previous blog post.

Here are the objectives and deliverables which we intent to achieve by the end of September 2011:

1. Write a report about August achievements and activities.
2. Investigate machine learning algorithms to carry out user modelling.
3. Design and implement this feature of machine learning user modelling into eRaUI prototype.
4. Organise at least 3 weekly technical meetings and one monthly meeting for evaluating the implementation of machine learning for user modelling in the eRaUI prototype.
5. Produce an evaluation / testing plan for eRaUI machine learning module.