Java Development, Recruitment and Consultancy


OPAL login


 

Site Dancer

Java without the Palaver

The are many desktop sharing applications and services available but none that are designed specifically to just allow a master browser to control a group of remote browsers. If you have developed a browser based application and want to demonstrate it this is all you need. We have used SiteDancer to demonstrate a card fraud detection application simultaneously to boardrooms in India, London and New Zealand while using VOIP to describe it.

SiteDancer is designed to have a light touch. There is nothing to install and the beauty of it is that the application that your remote viewer is seeing is the real thing, not a screen-scrape, so all the graphics which you have slaved over to make the application look good will not be sampled and any animations will not look like they are having a nervous breakdown. When demonstrating to groups of mixed visual ability then some may wish to increase the font-size of their browser. Because of the way SiteDancer works this is not a problem and SiteDancer will still be able to control their browser.

Take a tour

Site Dancer can take you on a very brief tour of the Internet. The tour takes about 5 minutes during which you do not need to touch your browser... just sit on your hands! The tour is designed to illustrate:
  • how SiteDancer can control your browser
  • how good graphics look as the are rendered in your browser
  • using post-it notes to annotate a site during a demo
  • drawing on a site
  • control of forms and data entry
To take the tour just click here.

How it works - a technical overview

When a session is underway each unique host.domain is allocated a unique Site Dancer host so that for instance www.google.com may be allocated sd01.site.sitedancer.com. Master and slave browsers then reference the sd01 address. All communications from the browsers are then passed to the Site Dancer server. The server knows that requests for sd01 means requests to www.google.com and can forward requests to this application server as appropriate.

To allow control of the browser a javascript library is included in the pages fetched from the application server before it is passed to the browser. The page must always operate as the original author intended but whenever there is a change of state on the page we need to capture this and inform the central Site Dancer server. To do this the javascript we introduce, when it initialises, insinuates itself into the active elements of the page such that they are not compromised. When there is a change of state in the master's browser (like a form element being filled in or a mouseover) the details are sent to the Site Dancer server which then passes commands to the slave browsers.

All the slave browsers will immediately receive the event information. The Site Dancer javascript in the slave's page will then cause the slave's page to behave exactly as the original author intended had the master's action been performed locally.

Some of the problems we have overcome

The basic idea described above is not easily achieved such that it works for most sites. There have been many problems to be solved to make Site Dancer work reliably. The following lists just some of the problems we have had to address.

Event handler insinuation and event emulation

To add event handlers in such a way as to preserve the original functionality of the page yet capture events has required a great deal of experimentation to perfect.

Communications and Security

To drive the slave browsers in real-time requires that they maintain an open communication channel to the Site Dancer server to receive messages. Polling the server would not provide the sort of response we required. Initially this was done with a Java Applet but this was far from ideal as we had previously noted that approximately 20% of the browsers we encountered did not have Java enabled. In the light of this and the fact that applets are often blocked for security reasons, we therefore developed a javascript solution that also has the advantage that it does not get challenged by client's security software.

Pointer positioning

When the master places the pointer in a position on the page we require that the pointer is placed in a similar position in all the slaves' browsers. However, the slave's page may be laid-out very differently for various reasons:
  • they may be using a different browser to the master
  • they may be using a different screen resolution
  • they may have font-size set to large if they have reading difficulties
  • they may have the browser window sized differently
  • they may be using a platfrom that uses different fonts
To position the pointer it is necessary to view its position relative to objects on the page in the master and then to interpret this in the slave. This is a difficult problem. We have developed a technique of doing this that draws on an Artificial Intelligence approach used by Dr Mitch Harris in his work in robotics.

Annotation/Drawing on the page

The pointer positioning problem is confined to the locale of the pointer. When doing drawing the problem is greatly amplified. We have developed specific techniques to preserve a mapping between the master's page and the slaves' pages.

Cross-browser support

Any application that uses Javascript has to face the problem that there are differences in the implementation of the EMCA standard between the browsers. As we are extracting functionality from Javascript for which it was never designed we have had to deal with many undocumented differences between the browsers. It is now known to work with Microsoft Internet Explorer 6 and 7, Fire Fox on Windows, Linux and MAC OSX, and Opera on Windows and Linux. This represents approximately 96% of browser usage (http://www.thecounter.com/stats/2007/August/browser.php)

Page Caching

When the master requests a page to be retrieved from the application server by the Site Dancer server, the server fetches the page and then stores the page in a cache. The slaves must in general wait until the page is ready. This is very different from how a Proxy Server works. To implement such a scheme is very difficult as there are numerous pit-falls. The system needs to cope with local browser caching, differences in the detail of form submission fields,etc.

Limitations

Site Dancer does have some limitations. It cannot control sites that are entirely written in MacroMedia Flash, Java Applets or ActiveX objects. However, any actions in a browser that result in a page change will always work. To address these limitations we may publish an API whereby sites that use these technologies will be able to add local calls to the SiteDancer Javascript library so that they can use this technology.

The Future of Site Dancer

Site Dancer is currently a proof-of-concept tool that we actively use in-house. We are seeking commercial partners and investors to take the concept forward. If you are interested in this project please contact us.