Like many others I too was “wowed” by the vision offered by Google Wave and the potential for changing how we communicate via the web. Within the business of STM publishing Google Wave caused a huge stir, purely because it seemed to offer a “new paradigm” for collaboration, especially for global authorship and writing of scientific journal articles and the potential for redefining the “scholarly authorship workflow”. Yet, it was not to be. Like thousands of others, I eventually received my Wave invite and eagerly logged in to participate with the brave new “Wave world”. Along with like-minded colleagues, I created Waves and spent time playing with collaborative authorship but, sadly, the experience did not meet our hopes and visions for a new world of collaborative content-creation. The “Wave experience” failed, in some part, not because it was a bad idea but because user behaviour had not sufficiently evolved to define the norms for a Wave experience. In addition, there was simply no way to take your wave-created content and export it to mundane applications like Word or TeX for use in standard workflows. In my opinion, that was a catostrophic failure of vision. Yet, the demise of Google Wave most definitely should not be seen as an experiment which failed, for most certainly it did not. The huge “buzz of expectation” must, surely, have been fed from, or be predicated by, some innate recognition that we want “some way” to work together in ways that the current set of web technologies don’t yet quite deliver. Wave created a hope and vision for how we might work together without borders or time constraints, with the ability to create tools and plugins that allowed us, in theory, to create and interact with content-types previously held hostage within the sandboxed domain of our desktop computers. Yet, the process of creating robots or plugins to create a “distributed, shared, experience with everyday tools” was still far too deeply rooted in complex development frameworks. In hindsight, it would have been far better to talk to software companies to create “Wave ready” toolsets to bootstrap the user experience and foster engagement, especially for authors of complex scientific content. Among the first experiments in the “STM publishing world” were tools to support and share authorship of LaTeX code: none of which were really satisfactory.

node.js

I must predicate this with a disclaimer: I am intrigued, fascinated and in awe of node.js but readily admit that I’m not sure precisely why. To me, it seems to be in the same “solution domain” as Google Wave: comet servers. If you have not heard of node.js, take a few minutes to peruse the following content. For STM publishing, herein lies some really cool opportunities… just Google for “node.js” and ask yourself: non-blocking IO, server-side JavaScript, massive connectivity, now there’s an interesting paradigm for STM content applications?