Breakthroughs in technologies for managing and exchanging information always precede explosions in information exchange. From a safe distance, this principle seems completely obvious. Yet, like most obvious things, it's all too easy to forget in the heat of battle.

Recently, Peter Murray-Rust discussed the appalling state of data capture, dissemination, preservation and curation. His comments were prompted by an article written by Nico Adams. In it, Nico discusses his initial excitement by the publication of a large spectroscopic dataset, followed by his frustration in finding that the "data" really consisted of nothing more than flat images stored in PDF format.

The article in question is titled Preparation and Infrared/Raman Classification of 630 Spectroscopically Encoded Styrene Copolymers. Not having a subscription to the ASAP contents of this particular journal, I can only go by what appears in the abstract. From the abstract and title, it's clear that the dataset is the centerpiece of this article:

The barcoded resins (BCRs) were introduced recently as a platform for encoded combinatorial chemistry. One of the main challenges yet to be overcome is the demonstration that a large number of BCRs could be generated and classified with high confidence. Here, we describe the synthesis and classification of 630 polystyrene-based copolymers prepared from the combinatorial association of 15 spectroscopically active styrene monomers. Each of the 630 copolymers displayed a unique vibrational fingerprint (infrared and Raman), which was converted into a spectral vector. ...

Apparently, the technique enables polymer beads to be encoded with a spectroscopically-readable tag for use in identifying attached compounds at the end of a split-pool synthesis. Yet the supplementary material for the article consists of nothing more than static images like the one below:

For researchers hoping to build on the experiments described in the paper, and for those hoping to model or compile the results, static images like the one shown above are practically useless.

Why did this happen and why do incidents like it play out with bewildering regularity in chemistry?

Nico looks to scientists and publishers, whereas Peter focuses on the publishers as the root cause.

I understand the reasoning and share their concern about the problem, but I disagree about the cause.

The cause of this problem is neither the policies of publishers nor the lack of understanding of the problem by scientists - those are just symptoms. The root cause is a failure of cheminformatics itself. Simply put, 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.

The tool hasn't been built yet. No tool means that both scientists and publishers will continue to use the only tools they have any faith in, despite their obvious flaws. No tool leads to more of the same, from both scientists and publishers. No tool also means an enormous opportunity for the group that develops it.

Read Part 2 to find out why.

Image Credit: Neil T

Pssssst. Want to know a secret? Some of the best inventions are completely obvious. That is, given a half dozen years or so. At the time they're conceived, however, most good, obvious ideas just seem dumb, dangerous, or uninteresting. They have to - otherwise they'd have been developed already.

Case in point: the blog permalink. If you've ever read a blog, you know what a permalink is. It's the link you click when looking at a story headline in an RSS reader like Google Reader.

If you run a blog, you definitely know what a permalink is. It's the link that a Google user follows when they search for a topic you've written about. It's what other authors link to in their own writing, thereby increasing your ranking in Google. If your blog is anything like mine, Google drives a lot of your traffic, and the permalink makes it all possible.

A permalink is nothing more than a fixed, unique identifier (URL) for online content. Blogging would have never caught on without it.

I recently ran across Tom Coates' excellent essay on the lowly permalink. He describes the time around 1999-2000 when permalinks didn't exist. If you ran a blog back then and wanted to write about someone else's blog post, you had to link to the other blog's home page. As the author you linked to continued to post, the content you had discussed in your own blog disappeared from the other author's front page, making your link irrelevant.

It was a huge problem, yet few perceived it as such. Interestingly, Coates even admits to having been against the idea of permalinks because of their hacky nature. Besides, they didn't seem to do anything useful.

So the next time you're stumped while trying to find something to work on that matters, try picking up a dumb, dangerous, or uninteresting - yet obvious - idea and run with it. In six year's time your invention may become so well known that most people couldn't imagine the world without it.

Image Credit: mklingo

Designing good user interfaces is difficult work. One of the hardest things about it is what you're forced to give up: abandoning your hard-won mental map and adopting that of the user; stripping half the product's features - and then stripping half of what's left; and fending off featuritis with a big club as the product matures. Everyone knows these things are important, but for some reason we repeat the same mistakes over and over.

So it was with great enthusiasm that I found Robert Hoekman, Jr.'s new book Designing the Obvious. Good technical books collect illustrative examples and present them clearly. But great technical books provide a system for understanding the examples. Designing the Obvious is one of them.

As an example, have you ever considered a confirmation dialog to be a symptom of a fundamentally flawed application design? The next time you find yourself needing one of these doodads, consider this passage:

The only implementation-model piece of design I've seen while using Backpack is the JavaScript alert message that pops open when I attempt to delete something from a Backpack page. It asks, simply, "Are You Sure?"

While the message is a pretty standard confirmation message - which we're all used to seeing - it's a sign of the underlying system. It's a big ol' banner that says "I don't have an undo feature and the only way I can deal with you deleting an object from your page is to interrupt your workflow with this message to make sure you know what you're doing."

Hoekman's solution is simple - give your users an undo feature and ditch the confirmation dialog. This makes perfect sense, but how many times has the opposite been done instead?

Sometimes the obvious is far from obvious.