Bioclipse – Rich Client

I’m at the Bioclipse workshop in Uppsala – excellently run by Ola Spjuth and colleagues. Rich clients – where the client has significant functionality beyond the basic browser – are critical for the interchange of scientific information. A typical example is Maestro (NASA image viewer) where the typical browser does not – and cannot – have the local power and functionality required. So NASA wrote their own and you can download it and run it locally.
It’s easy to confuse Rich clients with AJAX services. For, say, Google maps all the functionality is on the server – cut off the web and you cannot use Google Maps. The maps are downloaded during use (you can often see the tiles coming down and covering the area). Nothing wrong with this, but you have to do it the way that Google has designed – you cannot re-use the maps in different ways (there are doubtless complex copyright issues anyway).
But isn’t everything moving towards a “cloud” model where all our data, functionality, etc. is remote – on Google, Yahoo, or whatever? Yes, for a lot of our everyday lives. But I think science is different. (Maybe I’m stuck in 20th C thinking… but I’ll try anyway). A scientist – or their lab – has data which is mentally on their laptop, or in the instruments, or in the fume hood or wherever. Most labs are probably not yet prepared to store this in Google. And they have local programs and protocols which only run on their local machines.
Moreover relying on GYM (Google, Yahoo, Microsoft) to provide all your environment means a loss of control. Scientists have already lost much of their independence to publishers (they control what you can publish – I just heard today of a publisher who would only accept graphics as EPS – why? – because it makes it easier for their technical department.)
There are obvious challenges to using a Rich Client. If every discipline has their own then the user gets confused. The developer has to manage every platform, every OS (at least in the future). Doesn’t this get unmanageable?
Yes, if everyone does things differently. But if everyone uses the same framework it becomes much easier. And that’s what we have with Eclipse. It’s the world’s leading code development environment and there are thousands of commercial plugins. It’s produced by IBM and is Open Source, Free (obviously) and designed for extensibility. So it will prosper.
If the scientific community converges on Eclipse as a Rich Client then we have enormous economies of scale. That’s what Bioclipse is doing in the chemistry and bio-sciences. In fact, however, much of the work is generic – data manipulation, display, RDF, etc. so other sciences can build on that and contribute their own expertise.
There are downsides. Everybody is familiar with browsers – very few scientists yet know Eclipse. But that can change. Eclipse has many tools for easy installation, tutorials, guided learning, updates, etc. All for free. So we expect to go through a period of “early adoption”.
In my talk yesterday I described Bioclipse as Disruptive technology (WP) – technology which destabilises current practice and leads to improvements in quality and cost. Even more importantly it returns power to the scientist – they are in control of their data and how to repurpose it. We hope to develop Bioclipse as a browser-publisher so that the scientist works in an environment where they decide how to emit data, not subservient to the technical editing departments of publishers or the proprietary formats so common in chemical information.