If you build it (web services), will they come ?
A recurring thought came to me again last August while attending a conference called CSIG (Cyber-infrastructure Summer Institute for Geo-scientists), that there seems to be a rush to use new technologies whenever possible, commonly without considering why or how they’ll be used. I’ve experienced this first hand not only in technology companies, but research centric organizations, and other organizations. The common sentiment always seems to be the newer the gizmo, the better.
Do yourself a favor and take emotions or technical biases out of the equation, take stock of what you already have in place, and only then ask yourself if you really need that new shiny XYZ.
Is it necessary, or is it fluff ?
Do you have the time or resources to implement it ?
Who will use it ?
Will it serve _their_ needs ?
If it existed, _would_ anyone even use it
CSIG is a great conference, it showcases the latest and greatest tools in use by the GeoScience community, highlighting projects actually deployed and in use. But the one critical aspect that I thought didn’t get enough air time was how all of these things will or are actually being used by the community they’re intended to supply. The presenters had all accomplished some impressive feats, but only a few discussed how the results were actually being used by the intended audience.
The thought stuck more so than before, as it had more bearing on my daily work than in the past, due to my role developing code for SPIDR.
It got me thinking about SPIDR’s Web Service interfaces, and how they were being used, and if they could be improved.
SPIDR has been around for quite some time in various incarnations (since the late 90′s), and has evolved very well over time to support current paradigms. After a short bit of introspection, mainly by looking at usage statistics, the complexity of the then current client software packages, and going through the exercise of making a SOAP workflow with Kepler, it was apparent that our interfaces were too complicated for the intended audiences.
Outside of SPIDR itself which makes heavy use of web service calls internally, not many people were using the previous web service interfaces. Those that were using them were highly technical and very software development savvy. SPIDR’s target audiences are various science communities, which should not need web service development expertise to use this resource.
I made some initial steps, such as providing streamed CSV data via SPIDR’s SOAP interface so that clients like the Kepler one could more easily use the data. This simpler access mechanism helped illustrate that we could simplify elsewhere too, which helped the idea take root more broadly. The result of all of this has been a collaboration between us at NOAA/NGDC and our colleagues at the Russian Academy of Science’s Geophysical Center to export several new data formats, expose simpler web services, and provide more documentation for developers and data customers.
In addition to some other announcements that have gone out about them, SPIDR’s new web service interfaces are part of a public unveiling tomorrow (2/24/10) at a conference for IDL developers. This is the exact community the services are targeted at! The IDL client provides an even simpler abstraction atop the web services, in a programming language the intended science communities are very familiar with.
We built them. They’re very easy to use. Now, will the users come ?