Point and Shoot Chemical Informatics Software

One of my favorite software-related blogs is Signal to Noise. It's contributors are employees of the web application company 37signals, one of whom is the founder of the Ruby on Rails project. This company is very focused on its customers, and it shows. The information here ranges from software development strategies to product design.

A recent article discusses the concept of point and shoot software. The idea is simple: most people most of the time just want to take a picture. A point and shoot camera is exactly what they need, thus their popularity. People don't care if the exposure isn't exactly right or if the depth of field is too wide. Many of them know that if they had used an SLR and had taken the time to really set the shot up, that the result would be better. But they can't fit one of those things in their pocket. Even if they could, by the time they had configured it, the spontaneous moment they wanted to photograph would be gone.

I suspect that many users of software (both developers and scientists) just want the equivalent of a point-and-shoot camera. This is where a concise, dynamic language like Ruby really shines. It's one reason why semantically limited molecular file formats, like Molfile V2000, remain so popular. It's the reason lightweight, fast applications with a limited number of features and zero installation can mean the difference between an idea tested and an idea forgotten.

Don't think this applies to you? Take this test: when was the last time you used Google's advanced search options?

Of course, there will always be a small number of users that need something more powerful. But most users, most of the time, neither want nor need the "technologically superior" option. The guys at 37signals say you can't please both camps at the same time. Why should chemical informatics software be any different?