danielhordern.com
Mousepainter

What is it?

Web hosted paint-visualiser. Brief - very simple for once: Lets put Design Studio on the web - take as much of the existing technology's as possible, build an app, and somehow put it on the web for all to use.

Implementation was a far more interesting proposition - consider four teams, a tight (inflexible) release date and two continents. This was a team effort - the teams being Rubicon in the UK concurrently developing a complete new web-site for ICI which we had to integrate with, Extraprise project managing, ICI (the client) creating the masses of data / images / schemes required to drive the decorate process.

Technologies

The front end application was implemented as a java applet, developed in Borland J Builder.

At the back-end: IIS, ASP, ADO, javascript and vbscript were used to provide the communication between client and back-end.

COM objects provided the layer between ASP / scripting and the existing visualiser engine.

Much of the data ended up living in an oracle database - although ADO enabled this detail to be transparent.

What was cool about it?

The coolest thing for me was seeing a bandwidth-heavy kiosk application being transformed into a bandwidth-light n tier application - the physical decoupling of user-interface illustrated what had been developed over the last few years - a set of technologies and a set of UI's / applications using those technologies. Although this was always a design goal, seeing it physically happen really pushed home this truth to ourselves, and hopefully to the client.

The java-applet was way cool - Using the swing library was not an option (the applet being browser based) we developed an in-house light-weight framework that supported drag n drop, non-windowed, layered controls. The entire framework and application came in at under 200Kb!.

Bandwidth was incredibly important - many users would be dialling in. The applet loaded data from the server as required - i.e. colour-ranges are downloaded on demand. The applet showed good use of multi-threading, keeping the UI alive while working / waiting for data.

The server-side COM layer built on our existing visualisation code was thread-safe, and extremely efficient both in memory use, and transactions per sec (exceeding our stated goals).

Thanks

Andrew Ratcliff - Made the impossible possible! an absolute pleasure to work with

Scott Ritchie - the pixelshifter extraordinaire

Siamak Aghii - one of the most talented programmers I have had the pleasure of working with

What did it look like?