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.

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

A previous article discussing the deployment of four free 2D structure editors has been fixed. The sample pages demonstrating how to obtain a molfile from each have also been restored.

A previous article outlined the major concepts behind Firefly, a new 2D structure editor for the Web. Structure editors are unique in that they require solutions to problems in so many different areas: graphical user interface design; chemical structure aesthetics; 2D graphics and geometry; molecular representation; and graph theory, to name a few.

These are important considerations, but they pale in comparison to the biggest design challenge: Firefly must be deployed and run in a heterogeneous network environment. This one constraint frames all of the basic design questions involving platform, programming language, footprint, and mode of deployment. And this is a Good Thing.

Platform, Programming Language, and Deployment

Considering the diverse array of hardware and operating systems on the Internet, it's amazing that anything works at all. Although standards save the day in most cases, there is no all-purpose solution when it comes to interactive Web technologies. Today, there are essentially three options for Firefly:

• Flash To my knowledge, no 2D structure editor has ever been implemented in Flash. (This alone sounds like a good reason to try it sometime.) As a platform, Flash has a lot going for it, including a large installed base, and the abstraction layer OpenLaszlo. On the down side, Flash support on platforms such as Linux has not been what it could be. As Flash continues to mature, this problem may become less important.

• Ajax Essentially nothing more than HTML and JavaScript - and no plug-ins of any kind. At least two editors have been written in Ajax: WebME and PubChem's editor. Ajax works in a lot of situations, but in my opinion it still isn't up to the job of creating a responsive, interactive structure editor.

• Java Applet A massive installed base, support for just about every kind of hardware in use, a robust object-oriented language with a powerful 2D graphics and GUI libraries, and it's even Open Source. Although Flash and Ajax have their advantages, Java is the best option for the foreseeable future. There are several Java structure editors to choose from, and for good reason. (Future articles will discuss what makes Firefly different.)

What about a Java application? Unfortunately, not even a user's ability to install software on their own machines can be taken for granted in the context in which Firefly will be running. For example, many companies enforce prohibitions against employee-installation of non-approved software. Machines found in libraries or other public places may face similar limitations. Given these real possibilties, an applet is the only option that makes sense.

As to the version of Java that Firefly is built on, JDK 1.4.2 seems to have become the unwritten standard. It's mature enough the have most of what Java has today, but is old enough to be on most machines. Even with this compromise, Firefly will have an impressive array of functionality to work with: Java2D, Swing, and many performance optimizations relative to earlier Java versions.

Footprint

High-speed Internet access is ubiquitous. Bandwidth is now a commodity. Memory is practically free and processors - don't get me started on processors these days. But developers who take massive bandwidth and staggering processor power for granted are setting themselves and their users up for many unpleasant interactions. Firefly must be lightweight, responsive, and fast to deploy under any network load and on 80% of the hardware on the Web. Limiting its footprint to 150K will increase the chances of success.

With such a small footprint, none of the currently-available open source Java cheminformatics libraries (e.g. CDK, JOELib, Octet) will be of much use. They are simply too big. Even the smallest of them (Octet) weighs in at about 300K. Of course, it's possible to strip out unnecessary features from these libraries. But even then, a great deal of unused functionality would remain. This is the unavoidable downside of general-purpose libraries. By developing a small cheminformatics library specifically designed to power a 2D structure editor, Firefly should be able to meet the 150K target.

Is 150K a realistic goal? My previous experience in developing Structure and Structure-CDK taught me that with Java2D, very lightweight structure-rendering code is well within reach. For example, the Structure-CDK jarfile is an unoptimized 39K. (But even Structure-CDK faces the same problem as other general-purpose libraries - it's much bigger than it needs to be. In other words, some Structure-CDK concepts may be applicable to Firefly, but the code itself must be completely re-written.)

When combined with the fact that a lot of cheminformatics functionality, such as structure clean-up, can be offloaded to a server, 150K begins to look like a very reasonable target.

As a final encouragement, consider that everything Java Molecular Editor does, including SMILES canonicalization, is contained in a jarfile no larger than 40K.

Wrap-Up

As you can see, even before a single line of code was written, Firefly's design was constrained in some very important ways. Identifying and embracing these constraints doesn't ensure success, but it greatly increases its chances. In articles to follow, I'll show how Firefly was designed to thrive within these constraints.

Image Credit: frogmuseum2