Previous articles have discussed Firefly, the codename for a new 2D structure editor for the Web. Although it can be deployed as a self-contained applet on Web pages, Firefly is composed of modules that are readily re-used. By taking advantage of this design and Java's native UI toolkit Swing, new UI elements can be built with relatively little effort. This article outlines one such use - the creation of a file dialog that contains a molecule preview.

Many image processing applications such as Photoshop or GIMP provide an image preview that appears in file browser dialogs. Wouldn't it be nice if applications that process molecular structure files came with a similar feature? The screenshot below shows a file chooser with an embedded molecule preview based of Firefly's Painter component:

When a new molfile is highlighted, a new preview is automatically generated:

The molecule preview is capable of all of the customizations available in Firefly including background, bond, and atom colors, borders, and atom label fonts. No matter how large or small the molecule, and regardless of its starting coordinates, it will always be exactly scaled to fit the available space and precisely centered.

This dialog was rapidly implemented using the accessory capability provided by Swing's JFileChooser:

JFileChooser chooser = new JFileChooser();
PreviewAccessory accessory = new PreviewAccessory(chooser);

accessory.setPreferredSize(new Dimension(150, 150));

chooser.setAccessory(accessory);
chooser.addPropertyChangeListener(accessory);

// ...

Defining a JComponent implmenting the PropertyChangeListener interface is all that's needed to get a working molecule preview:

class PreviewAccessory extends DefaultPainter implements PropertyChangeListener
{
  // implementation
}

Swing has come a long way since the dark days of JDK 1.2. What started out as the dog-slow ugly duckling of user interface toolkits has developed into one of the best platforms for building desktop applications out there. Advanced tools such as the WYSIWYG interface builder Matisse and the polished components offered by JIDE make Swing an even more attractive option. The example described here is just one instance of how Swing's well-conceived design simplifies the job of building rich user interfaces.

Chemists can be very discerning when it comes to chemical structure aesthetics. This is not surprising, given the central role played by 2D chemical structures in the day-to-day work of many chemists. For example, consider the Wikipedia Chemistry/Structure drawing workgroup's ongoing discussion about achieving a consistent look for chemical structures on the online encyclopedia.

Several articles have discussed Firefly, a 2D chemical structure editor specifically designed for the Web. With major work on the rendering engine and structure manipulation interface complete, recent efforts have turned toward exposing drawing settings through a graphical user interface. Here I'll provide some screenshots of an interface prototype along with sample structures. I'll also briefly discuss the larger question of making 2D structure drawing styles portable.

Drawing styles are edited through a tabbed dialog containing a live preview window that uses the current structure or a default structure if none is available. The dialog is resizable, enabling users to immediately see the effects of changes on structures of varying sizes. Although this dialog could be bundled and deployed with the editor, its large footprint makes it more appropriate for use as an optional feature or as a standalone configuration tool in a Web application.

Changes can be rolled back entirely ("Reset"), canceled ("Cancel"), or accepted ("OK").

Let's say we'd like to apply a black background with white bonds, as used in some Power Point presentations:

  

After applying this change, we decide that we'd rather not use atom coloring:

  

After looking at this structure for a few seconds, we decide that narrower stereo bonds are needed:

  

After some experimentation, we find a more appropriate non-stereo bond width and double bond offset:

  

What about a Serif font? No, I don't think so:

  

But we could certainly reduce the size of the atom labels:

  

On second thought, the original atom sizes were fine, although changing font may require us to reconsider the atom label heights:

  

As you can see, the possibilities for customization are nearly endless. In practice, however, most chemists will adopt only two structure drawing styles that they re-use as needed: one for reports and manuscripts; and one for presentations. It will be interesting to see whether a third style makes it's way into the standard repertoire: Web.

Each chemist will want a way to save their styles, possibly share them, and easily apply them. Although a few systems for doing so are feasible, the most practical approach would be a stylesheet. Applying a stylesheet to any structure diagram would change its appearance, offering a simple mechanism to achieve a consistent look across documents.

Developing a universal (cross-editor) stylesheet system would be no easy task, given the wildly divergent capabilities of 2D structure rendering software. Despite the technical difficulty, the payoff for users is obvious.

Have you ever wanted to find a molecule on the Web using your favorite search engine in combination with a 2-D structure editor? InChIMatic is a service that lets you do just that. In this article, I'll show how InChIMatic can be used to look up molecules in the UsefulChem-Molecules blog.

For those who aren't familiar with it, UsefulChem-Molecules is a blog operated by Jean-Claude Bradly's research group at Drexel University that publicly archives molecules of interest. Each entry is a single molecule that may be linked to other Web resources.

Let's say you wanted to look up dithranol. This can be done by simply pointing your browser to inchimatic.com and drawing the structure:

When you're finished, select your search engine of choice (we'll use Google here) and press "Search". You'll be taken to the familiar results page. The second result links to the UsefulChem-Molecules entry for dithranol.

In performing this simple workflow, I noticed areas for improvement in both UsefulChem and InChIMatic:

• UsefulChem If you look at the entry for dithranol, you'll notice there are no linkouts. In essence, the entry is a bookmark without context. Although it's useful to know that the Bradly group is interested in this molecule, it would be even more interesting to know in what context. Each entry should contain at least one link giving the molecule a context.

• InChIMatic Using the back button on the Google results page takes you back to InChIMatic, but your molecule is gone. If you wanted to look for a series of related molecules, you couldn't edit your existing structure. As Firefly 1.0 nears completion, a top priority will be to incorporate it into InChIMatic and fix the back-button problem.

As you can see, between InChIMatic and UsefulChem-Molecules, we have the makings of a crude laboratory information management system. The problem is we're trying to use existing tools (search engines and blogs) for purposes they are ill-suited for. It can work, but it could also work much better.

What chemistry really needs is open, user-friendly systems specifically designed to archive and search chemical information of the type maintained by the Bradly group. But that's a story for another time.

The previous article in this series discussed the requirements of Firefly, a new 2D chemical structure editor for the Web. Another article discussed Firefly's design constraints and the importance of embracing them. Why so much focus on a structure editor? Simply put, the structure editor is the key link between chemistry and cheminformatics. Without the structure editor, there would be no audience for cheminformatics software.

So far the discussion has been rather abstract. To make it less so, the following four screenshots illustrate the user interface and rendering capabilities of a Firefly prototype. All molecules were drawn with the Firefly interface running on Linux. Screenshots were directly captured from the running application.

Cholesterol

The image below illustrates fused rings and stereo atoms. Also notice that the atom label for oxygen has one implicit hydrogen atom that is properly placed to the left.

Doxorubicin

This image illustrates both atom labels and aromatic bonding. Notice the improperly-placed quinone double bond. Refining Firefly's aromaticity perception is currently a top priority.

Flunoxaprofen

Firefly comes complete with a developer-overridable atom coloring scheme. Also notice the correct length of the internal carbon-nitrogen double bond line.

Uric Acid

One of the more difficult aspects of rendering molecules with implicit hydrogens is placing them in the correct quandrant. In this screenshot of uric acid, notice how the hydrogens occupy three different quadrants relative to their hosting nitrogen atoms.

The previous article in this series outlined the main technical constraints in the design of Firefly, a new chemical structure editor for the Web. Knowing the technical barriers you're up against is important in any software project, but understanding what the software needs to do is also important. This article offers a high-level approach to answering this important question.

Why Use an Editor at All?

The purpose of Firefly will be to conveniently convert the language of chemistry (structure diagrams) into the language of cheminformatics (line notations and file formats). There are certainly alternatives to using a graphical editor. For example, SMILES strings could be directly entered. Molfiles could be pasted into a window. But as a real-world solution, a graphical editor embedded in the host application is the only approach that makes sense.

Two Audiences

As discussed previously, the structure editor plays the pivotal role of linking consumers of cheminformatics software (i.e., chemists) with producers of cheminformatics software. As a result, the structure editor is one of those few pieces of software that is simultaneously "seen" and "felt" by chemists, and used as a building block by cheminformatics developers. For an editor to be successful, the needs of both of these audiences must be satisfied.

The Chemist Experience

To understand how to build a good structure editor, it's important to understand what's happening in the thirty seconds just before the editor is run. Typically, a chemist is in the middle of doing something important like answering a burning question, preparing a presentation, or setting up an experiment. Firing up a structure editor is actually a major distraction from that work-flow; it interrupts the scientific thought process with a mundane data-entry task far more complex than any text box.

Understandably, using a structure editor is not something that most chemists are enthusiastic about. And using a new structure editor, with its own quirky way of doing things, is potentially even worse. This makes it especially important that any new editor behave intuitively. But what exactly does "intuitive" mean?

ChemDraw and IsisDraw are the 500-pound gorillas of structure editors. They're everywhere - in universities (often bootlegged), at home, and in industry. Important portions of the ChemDraw/IsisDraw user interfaces make appearances in all major structure editors (e.g., ChemSketch). The two things that can be assumed about any prospective user of a new structure editor are that: (1) they have used ChemDraw/IsisDraw; and (2) their current editor is either ChemDraw/IsisDraw or something very similar.

For better or worse, ChemDraw/IsisDraw define the meaning of the word "intuitive" when it comes to 2D structure editors. When faced with any new editor, the first thing Joe the Chemist is likely to try is what works in ChemDraw/IsisDraw. Any attempt to innovate the user interface therefore needs to be very carefully considered. Developers who violate this "principle of least surprise" are likely to meet with well-founded resistance.

To summarize: Firefly should minimize the number of "innovations" it introduces into the user interface.

The Developer Experience

In contrast to chemists, developers are likely to be much more tolerant of innovations in Firefly. The reason is simple: there is no standard structure editor for Web applications. This leaves just a few basic requirements:

• Molfile input/output. Many tools exist, such as Ruby Open Babel, that can be deployed on a server and which will convert a Molfile into virtually any desired format. To fully satisfy developer expectations, it will be sufficient that Firefly can export and import Molfiles. Additional formats are unnecessary, at least for the 1.0 release.

• Designed with JavaScript in mind. All applet settings will be addressable though get/set methods. Using Java primitives as arguments to these methods will maximize developer productivity in languages such as JavaScript.

• Extensibility. A mechanism to conveniently extend the functionality of Firefly through JavaScript must exist.

• Adaptability. It must be possible to use Firefly as a 2D molecular rendering framework, independent of its user interface.

• Comprehensible Design. Firefly's design will be made more understandable through the use and documentation of Design Patterns. Monolithic classes and methods are to be avoided.

Summary

To be successful, Firefly must satisfy two very different groups of users: chemists who will interact with its graphical interface; and developers who will plug it into other software frameworks. These two groups have very different expectations and needs. Understanding, and embracing, these expectations will go a long way toward making Firefly the best editor it can be.

Image Credit: elbisreverri