Source: Molecule of the Day    Rendering: ChemWriter

A quiet revolution is taking place in the way the primary research literature gets reviewed. Like all revolutions in their infancy, this one looks hungry, raggedy and generally not respectable. But that could change rather quickly given the right technology.

Research Blogging is a brand new service that aggregates commentary about the peer-reviewed literature appearing on blogs.

Let's say Mary the Chemist finds a procedure in a paper on reductive amination that solves a problem she's been having in isolating her products. After having used the procedure awhile, she notices that one class of substrate not described in the original paper gives much lower yields than those reported. Not having the resources to create a complete paper around her observation, she decides to write about what she found and post it to her blog.

If that were the end of the story, it's very unlikely Mary's posting would be of much use. Although Mary's blog is read by a couple of hundred people daily, few of the readers on the day her posting appeared had an interest in reductive amination or the paper she discussed. And none of her readers on that day were able to follow up on her observation.

Mary continues to post to her blog and eventually her observation, of potentially great value to the right chemist, gets buried in the archives (and on page 3 or 4 of most Google searches).

Enter Research Blogging, a Web-based database associating blog entries with references to the peer-reviewed scientific literature. Some time before writing about her observations, Mary signed up for a Research Blogging account and registered her blog with the service. At the time she wrote her observations on the reductive amination reaction, Mary applied special markup to the posting to make it readable by Research Blogging's automated system.

Instead of disappearing into the digital abyss, Mary's observation becomes permanently associated with the original paper.

Although Research Blogging's user interface is currently primitive, it's unlikely to remain so for long. The founders of the service appear both motivated and committed, recently forming a non-profit corporation to support their work.

In the future it's not inconceivable that Barry the Chemist, after having finished doing his CAS search on reductive amination methods would next turn to Research Blogging to make sure he really knows everything written about the three most promising peer-reviewed papers he's considering using.

Research Blogging is a wonderful idea with great potential to fill a significant need. Like any new technology, though, there are some issues to work out. The next article in this series will offer some ideas.

If you wind the clock back enough years, the world of graphical user interfaces was ruled by standardized look-and-feel specifications. This approach was taken in an effort to centralize all of the GUI coding in applications, make it easy to document the application (everyone knows what a slider does, therefore it doesn't need to be described), and work around the relatively poor graphics performance of desktop computers.

But the last decade's collision between the computer industry and the consumer has led to a huge increase in the emphasis on aesthetics in user interfaces: for everything from brand awareness to increasing the comprehensibility of sophisticated systems, to eye-catching coolness to draw the customer in, to just plain "Wow!" ... Aesthetics are in.

-James Gosling, Forward to Filthy Rich Clients

The "destandardization" of the GUI has been underway for several years. From Web applications like Picnik to Flash video players to Apple's iTunes application, users are getting increasingly used to the idea that not every program needs to look like Microsoft Office, and that some of them never should have in the first place.

Now, it's possible to infuse Java Swing applications with the look and feel of this new breed of GUI. The new book Filthy Rich Clients shows how. Covering topics ranging from threading to animation to compositing, this well-written book is a goldmine for anyone wanting to break out of a GUI rut.

The use of reflections, animation, fading and the like in serious applications may seem frivolous. But used in the proper context, these effects can add a great deal to usability and appeal.

Today's frivolous use of memory and CPU cycles has a strange way of becoming next year's must-have feature.

The previous article in this series discussed the construction of an Ant build environment for JSpecView. This article will show how to use Ant to build an HTML harness to test the resulting Applet and jarfile.

Availability of Source Code

Robert Lancashire, the lead JSpecView developer, has kindly agreed to host the complete source code for this series of tutorials on the JSpecView SourceForge project page.

Overview

Our goal for this session is to create an Ant task that will assemble a directory of HTML pages for testing the JSpecView applet. To do this, we'll add a new demo task and some supporting files.

Editing the build.xml File

The main change we'll make is to add the demo task itself:

<target name="demo" depends="jar">
  <mkdir dir="${demo}" />
  <copy todir="${demo}">
    <fileset dir="${resources-html}" />
  </copy>
  <copy file="${build-lib}/${unix-name}-${version}.jar" tofile="${demo}/lib/${unix-name}.jar" />
</target>

This task creates a demo directory and copies into it the contents of a new resources/html directory, along with the jarfile built with the jar task.

Other changes to the build.xml file are necessary. In the interest of brevity, they have been omitted. Those interested should download the source package to be available shortly.

Creating the resources Directory

Think of the resources directory as a place to hold non-Java files that will get used by our Ant tasks. Our first addition to this directory will be a directory called html. Here, we'll create a new directory called demo1. It will contain an HTML document with an embedded JSpecView applet (index.html), along with a JCAMP-DX file (netanilineH.jdx) and the excellent JActivating JavaScript tool.

Using the demo Task

We can run our new demo task just like the others:

If all went well, you should see a new demo directory with the following structure:

Viewing the Result

You can view the result online here. The applet loads and displays the JCAMP-DX file netanilineH.jdx. Notice that the spectrum is interactive; zoom and display properties can be set by right-clicking in the applet Window.

Conclusions

This tutorial has show how to build a simple HTML test harness for JSpecView. With this important step complete, we can begin to customize JSpecView itself. Future tutorials will show how.

Source: NASA