Ryan's Blog on NMR Software

Do You Run 15N, 19F, and 31P Experiments?

As I am closely approaching my one year anniversary of this blog (how time flies!), Arvin's post entitled, "How Do I Know if my Unknown Contains a Fluorine Atom",  reminded me an X-nuclei related post from almost a year ago.

In that post I highlighted a best practice document written by Gary Martin for acquiring ¹⁵N-¹H heteronuclear shift correlation data where he highlights an interesting application for ¹⁵N NMR prediction.

If you think that only benefits of a ¹⁵N NMR Predictor is for structure verification or validation, Gary is providing you with some additional tips and suggestions.

Check out his document here.

I want to personally thank Gary for his incredible contributions to the NMR community as well as for his guidance, collaboration, and contributions to the ongoing development and growth of ACD/Labs software.

Love/Hate Continued...

To follow my post from yesterday, Rich made a very interesting comment that I was hoping to address in today's post.

He suggests that perhaps a NMR Lite would be a good approach. I gave reason as to why we didn't take that approach and strip away existing features from 1D NMR Processor when developing the processing component in ACD/1D NMR Assistant yesterday.

But Rich makes a very good point in his comments:

For everyone else, it's all too easy to not even look at a piece of software who's fundamental purpose is obscured by layer upon layer of expert features. They just tune out and the only ones who end up using the software and giving feedback are the power users - which unfortunately reinforces the misconception.

For me, the key is to make sure that all these features don't get in the way of the primary reason someone is using the software. I don't have a problem with a wealth of features as long as it does not interfere with the main workflow.

Cathy Sierra is a blogger that I dearly miss for her daily insight on how to "create passionate users". Here's one of her takes. Specifically I like:

One of the themes I heard over and over at ETech and SXSW (Jason Fried, Craig Newmark, and others) was the developer mantra of "get out of the way." In other words, build the thing so that it stays the hell out of the way and lets the user get on with what they really want to do.

 

So as an adaptation of Rich's comment. Make the 20% REALLY clear, and hide the other 80% but still offer it.

I'm not sure it's the perfect solution, but I think it's a different approach.

For example, here's the first thing a user will see when they open a raw data file in 1D NMR Processor:

On the other hand, here is ACD/1D NMR Assistant:

Of course you don't want to create an environment where a user is drilling through menus looking for useful features, but we do provide users with the ability to hide or show toolbar buttons and action buttons on the interface so they can choose the interface most appropriate to them which can be altered as they get more comfortable with the software.

What do you think Rich?

Anyone else have an opinion they want to share in the comments section?

Avoiding the Love/Hate Relationship in Software

I had a conversation with Geoff, one of my ACD/Labs colleagues just yesterday.

He provided me with a great quote from a person he was talking to about software and usability.

He said:

"User-Friendly...hrmph...what that means to me is: love it for the first week, hate it forever!"

I think that's a great quote.

I think usability is incredibly important and should take high priority in the development of a software package.

However, while it is important we can't forget the term USE in "Ease of Use"

I find a lot of software packages out there that are very pretty, very intuitive, and very easy to use. They make a great first impression. You can use it for few days and fall in love. However, often times what happens is that after a week you decide you want to do more sophisticated things with the software but you can't. All of a sudden that love, turns to frustration, and sometimes ends up in hate.

I think this is one of the more difficult aspects of software development. I think most Product Managers and developers want their products to be easy to use. But you can't go overboard and oversimplify.

We went through the simplification process with the development of ACD/1D NMR Assistant. In the very early stages, we thought it might be a good idea to create a 1D NMR Processor Lite for chemists. We knew that 1D NMR Assistant would have the same NMR processing component as ACD/1D NMR Processor. But we also came to the conclusion that the interface and workflow in a duplicated form would not be appropriate for a new market, after all ACD/1D NMR Processor was developed for years with the NMR Spectroscopist in mind as they were the ones using it, providing feedback, and NFRs (New Feature Requests).

So while ACD/1D NMR Processor contains many features we don't anticipate most chemists will make use of (a quantitation tool, macro capabilities, group macro capabilities, intelligent bucketing, multiple baseline and phase correction algorithms, arithmetic, peak fitting, etc.) we decided to leave EVERYTHING in there. Perhaps 1 in 50 will become frustrated when their software can't execute a particular function for them, we're hoping we've avoided this issue by including all the features available in 1D NMR Processor within the Assistant package.

Linking to Meaningful Data in an ELN World

In a previous post, I asked the question, why does paper spectra continue to persist in chemistry?

Of course there is the next challenge, as Rich Apodaca points out on his Depth-First Blog in an earlier post:

The previous article in this series, suggested that the same dynamic applied to the compilation, management, and sharing of spectral data by chemists. More to the point:   

... cheminformatics has failed to deliver an inexpensive, robust, and truly usable solution to the problem of compiling, managing, and sharing spectral data for scientists of average computer skills. ...

To be sure, there are tools that address parts of the problem. But no solution addresses them all and that's why scientists and publishers resort to using obviously inferior solutions like PDFs.

Whether or not organizations and groups are resorting to inferior solutions is up for debate because it of course depends on the expectations of the end user. But his comments definitely struck a chord with me.

So the next question is:

"What is the best way to connect my analytical data to my ELN records TODAY?"

By far, the most common way that I have seen organizations connect the analytical data from our software to ELNs is via PDF.

But as Rich mentions in yet another post, for people who are looking to build on experiments or model or compile the results, static PDF images are practically useless.

I couldn't agree more.

So why do organizations choose this route?

The three biggest reasons I have heard are:

1. File size limitations in the ELN
2. The lack of a standard and supported analytical data format that is generic, open, lockable, and widely supported for years to come.
3. Currently,  PDF is more controlled for legacy support than analytical data.

As a result, PDF is the only reasonable approach for many, and it is certainly better than not connecting to a record of the data at all. 

I think the key is for vendors to work horizontally and to combine their strengths to deliver as Rich suggests a:

an inexpensive, robust, and truly usable solution to the problem of compiling, managing, and sharing spectral data for scientists of average computer skills.

But the file format remains an issue.

Work by the ASTM E13.15 Commitee has been ongoing for the past 5-6 years towards a universal analytical data file format. This file format is called AnIML (Analytical Information Markup Language), the developing XML standard for analytical chemistry data. Most vendors support the general directions of the ASTM E13.15 for a universal data format for analytical data.

A final note on the role of MEANINGFUL data in an electronic world. When I refer to meaningful data, I am referring to knowledge gained and stored in an actual data file as opposed to a static PDF. One of the unique features that ACD/Labs has maintained over the years is the ability to electronically assign NMR data to chemical structures to truly capture not only the data but the knowledge gained from the experiment. I think not leveraging this knowledge is an awful shame, especially in an electronic world, but I think it will come.

As of right now, While it is common that NMR Spectroscopists will assign their data electronically, it is very rare to find a group of chemists in the pharmaceutical industry, for example, who routinely use their processing tools to assign their data. Why?

1. They might not have the right software tools
2. It is not required. In fact, in some cases I have learned that it is forbidden. Why spend the time it takes to assign the data if it is not required or permitted?

A static PDF is indeed proof that an experiment was run, but does it contain information that supports a proof of the proposed structure? Where is the knowledge that was gained from this exercise?

I think 1D NMR Assistant significantly reduces the amount of time it takes to electronically assign a spectrum so now it is just a matter of finding an easy way to tie this assigned analytical data to the ELN.

I think there is a real opportunity here.

What are your thoughts?

Would you prefer electronic data over PDFs?

Is simply raw or processed data enough?

How important is maintaining the knowledge gained from the experiment (i.e. assignments)?

Thanks to Rich for the multiple inspirations for this and previous posts.