Depth-First: Tag designingtheobvious

Building a Unique Chemistry Journal: Responses to Questions from Nature Chemistry

Rich Apodaca — Thu, 08 May 2008 14:48:00 -0400

Neil Withers of the soon-to-be-launched chemistry journal Nature Chemistry has asked for feedback to some questions about the best ways to display chemistry research papers on the Web. Here are some responses:

(1) HTML vs PDF: does anyone read the HTML articles? Do you read the PDF on-screen or print it out?

I've used PDFs both for offline archiving and sharing of especially important articles as well as one-off printing of a paper I'm interested in. I rarely read a paper on-screen if I can avoid it.

Typical workflow: (1) download PDF; (2) print it out; (3); let paper sit while I go do something in the lab that can't wait (or bring it with me); (4) put paper onto a rather large stack of papers just like it; (5) pull paper out of stack from time to time as needed; (6) (optional) file paper in an increasingly chaotic system of folders or recycle it.

This system is bad, and I cursed it weekly during my time as a research chemist. Most of my colleagues had similar experiences.

There are plenty of opportunities to address pain points with the Web. Some ideas:

Make it very easy to find papers on the Nature Chemistry site. If I know a paper is trivial to find, I'm less likely to print it out in the first place. Good search may not be enough (see question 3).
Make the online version as readable as it can be. Minimize fluff like menus, ads and general clutter. Maximize things that promote readability like reasonable column-widths, appropriate fonts, and attractive and readable images.
Add conveniences that make it easier to read the paper online such as hover-popups that display 2D chemical structures for trivial names and IUPAC nomenclature (see below).

Paper is portable but Web documents are alive. Both can be readable - for example, I never print out a blog posting to read it.

(2) Big vs little graphics: what does everyone else think about the tiny size of the graphics in ACS html articles?

Graphics should be sized appropriately. ACS HTML articles are a good example of failing to design the obvious. You'd never read a blog post that looked like those articles, so it's not surprising everyone prints out the PDF.

Another problem is over-wide columns. It's puzzling why journal publishers would ignore all of their hard-won design experience just because a document appears as a Web page. If the ACS used a narrower column width, the Web version would be more readable. For example, check out this article from Beilstein Journal of Organic Chemistry. The only thing I'd change is to make the font larger.

Both problems are correctable using the right software and techniques.

(3) Tagging/’semantic web’: what do you think about the toys on the RSC’s Project Prospect? What kind of things would you like to see tagged/linked to other content in Nature Chemistry? For instance, Steve would love to do something with named reactions.

If by tagging, you mean giving users the ability to tag articles like Flickr allows photos to be tagged, and for other users to make use of those tags while searching, I think it's long overdue and could be a game-changer. It would clearly play to the strength of the Web as a medium.

I must confess that I'm not a fan of the implementation of Project Prospect, although the idea has a lot going for it. There's too much bling and a lot of it fails on my Linux/Firefox 2 system.

The one Prospect feature well worth adapting would be the one that lets you get a 2D structure by clicking on a trivial name or IUPAC name. But there's a much better way to implement it:

Turn it on by default and get rid of the floating right-hand menu.
Make the structure appear, without clicking, by simply hovering the mouse over the trivial name or IUPAC nomenclature. Be sure the delay is set right so that it's not popping up unintentionally.

That's all there is to it. It needn't be complex, just usable.

Another possibility: harvest all of the 2D molecular structures appearing in articles over a given period of time to be displayed in a dense, hyperlinked graphical abstract format ideal for quick browsing.

(4) 3D molecular structures: do these help your understanding of a paper?

Rarely, and in many cases they just add clutter. For almost all small molecules, a properly laid-out and well-drawn 2D chemical structure is more useful. If a central point of discussion in a paper is a 3D structure, then that would be a good use of the technology.

(5) How useful to you are InChIs and SMILES?

Not very. Research chemists rarely care about this kind of technology. They'd much rather have a good-looking 2D chemical structure. InChIs and SMILES, if available, should be hidden away and only brought out when requested. A more basic problem is neither system will be able to encode all of the molecules your journal's authors are likely to discuss.

(6) Forward linking: the RSC and Elsevier/Science Direct offer this – do you use it? Would you use an RSS feed that alerted you to new citations of a particular paper.

It could be useful provided that clutter could be kept to a minimum. It's essentially a form of linkback (see below).

An RSS feed that published linkback activity might be useful, but many of the chemists I know still don't know what RSS is. On the other hand, a page (or email service) that could keep an interested reader updated on linkback activity on all of their papers of interest simultaneously could be very useful.

(7) Would you actually comment on papers if there was a comments box at the end?

Like Egon Willighagen, I'd probably use my blog to do it.

However, most chemists don't maintain blogs or other websites and for them I can see how the ability to post comments would be useful.

Both kinds of users could be accommodated through a combination of comments and linkbacks. Provided that a good spam filtration system were used, this two-pronged approach might be very useful to readers.

Blogs are just the tip of the iceberg, though. Web publication technologies are creating all kinds of opportunities for creating highly focused, constantly evolving, collaborative mini-reviews on special topics. Linkbacks would create value for both readers and authors of these mini-reviews as well as forward-thinking scientific publications that embrace them.

(8) We really like the Biochemical Society’s HTML article style (sample one here) – do you?

No. Frames makes that site very difficult to navigate.

It will be very interesting to see how Nature Publishing Group takes advantage of its opportunity to create something unique among chemistry publications. Asking the kinds of questions they're asking now, and doing so in the way they're doing it, shows they're at least on the right track.

Just a Flesh Wound

Rich Apodaca — Wed, 30 Apr 2008 18:24:00 -0400

SEMANTIC KNIGHT: None shall pass without formally defining the ontological meta-semantic thingies of their domain something-or-others!

HACKER: What?

SEMANTIC KNIGHT: None shall pass without using all sorts of semantic meta-meta-meta-stuff that we will invent Real Soon Now!

HACKER: I have no quarrel with you, good Sir Knight, but I must get my work done on the Web. Stand aside!

SEMANTIC KNIGHT: None shall find anything on the Internet without semantic metadata!

HACKER: So be it!

HACKER and SEMANTIC KNIGHT: Aaah!, hiyaah!, etc.

[HACKER chops the SEMANTIC KNIGHT's first argument off by building efficent statistical/heuristic search engines]

HACKER: Now stand aside, worthy adversary.

SEMANTIC KNIGHT: 'Tis but a scratch.

HACKER: A scratch? Your argument has been cut off!

SEMANTIC KNIGHT: No, it isn't.

HACKER: Well, what's that, then?

SEMANTIC KNIGHT: I've had worse. None shall have an effective syndication network without RDF Site Summaries!

[clang]

Hiyaah!

[clang]

Aaaaaaaah!

[HACKER chops the SEMANTIC KNIGHT's second argument off by building the blogs/RSS/Aggregators/Bloglines/etc. network ]

HACKER: Victory is mine!

SEMANTIC KNIGHT: Have at you!

[kick]

HACKER: Eh. You are indeed brave, Sir Knight, but the fight is mine.

SEMANTIC KNIGHT: Oh, had enough, eh?

HACKER: Look, you stupid &^%$# You've got no arguments left.

SEMANTIC KNIGHT: Yes, I have.

HACKER: Look!

SEMANTIC KNIGHT: Just a flesh wound.

[kick]

HACKER: Look, stop that.

SEMANTIC KNIGHT: You won't be able to get machine-machine services without an ontology to formally describe all the relationships!

[kick]

HACKER: Right!

[whop]

[HACKER chops the SEMANTIC KNIGHT's third argument off by building SOAPy and RESTful services with only implicit semantic descriptions]

SEMANTIC KNIGHT: Right. I'll do you for that!

HACKER: You'll what?

SEMANTIC KNIGHT: Come here!

HACKER: What are you going to do, bleed on me?

SEMANTIC KNIGHT: I'm invincible!

HACKER: You're a looney.

SEMANTIC KNIGHT: The SEMANTIC Knight always triumphs! Have at you! Come on, then. I have an battalion of KR theorists on my side!

[whop]

[HACKER chops the SEMANTIC KNIGHT's last argument off with an army of actual code writers]

SEMANTIC KNIGHT: Oh? All right, we'll call it a draw.

HACKER: Come on, folks, let's go.

SEMANTIC KNIGHT: Oh. Oh, I see. Running away, eh? You yellow ^&^%$s! Come back here and take what's coming to you. I'll bite your legs off!

-Michael Champion, xml-dev list

Solve Web Application Scaling Problems With Signed Applets

Rich Apodaca — Fri, 25 Apr 2008 13:12:00 -0400

My Favorite Eclipse Shortcut: Quick Fix

Rich Apodaca — Fri, 11 Jan 2008 10:27:00 -0500

Eclipse is one of those great tools that is both easy to learn and extremely powerful. Eclipse's power comes, in part, from the number of features it offers, which seems to grow with every new release. This creates a problem though; the more features that are added to Eclipse, the more difficult it is to find them. This article focuses on one feature that every Eclipse user should know about: Quick Fix.

Let's say you're creating a class from scratch and you need to add a variable. Because you're working in Java, you'll also need to specify a type. If that type is one that doesn't already appear in the file you're working on, you'll either need to create it or import it. It may not seem like a big deal to scroll to the top of your file, add an import statement, and scroll back down to continue writing, but it can really break the flow of concentration - especially considering that it may need to be done several times in just one method.

Wouldn't it be great if Eclipse could handle this tedium for you?

Enter Quick Fix. In this example, we're creating a class called Molecule and need to add a List to hold its atoms. We begin by declaring the atoms variable:

Eclipse recognizes that List is a new type. Instead of manually inserting an import statement at the top of the file, let's use Quick Fix.

Highlighting the error and pressing [Ctrl-1] opens Quick Fix and gives us a list of options to choose from:

Quick Fix can also create a class or interface template instead of importing a class, as the screenshot above suggests.

We need to import the java.util.List interface. Double clicking on the Import 'List'(java.util) option inserts the import statement and allows us to continue writing:

Eclipse is packed with these kinds of useful but hard to find features. Future Depth-First articles will highlight some of them.

If You Want to Change the World, Build the Tool First - Part 2

Rich Apodaca — Thu, 20 Dec 2007 12:14:00 -0500

Let's face it - real change is painful for most people. Think back, for example, to your last big change at work, and chances are pretty good that the experience was not entirely enjoyable - especially if the change was imposed on you.

As designers of tools, it's easy to forget just how unpleasant change is for your users. Being closely involved and invested in the development of your tool only makes it harder to empathize with the people whose routines you'll be interrupting.

When innovations fail to catch on, it may be tempting to explain the situation in terms of users not "getting it," or through the intervention of outside forces with their own agenda. But more often than not, the real problem results from the innovation failing to offer a reasonable promise of compensation for the inconvenience that change brings.

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. Let's take each of the requirements one at a time:

Inexpensive. One of the chronic problems in vertical markets like chemistry software is the lack of ubiquitous tools. Lack of ubiquity is a recipe for balkanization. Because chemistry software tends to be highly specialized and expensive to develop, suppliers must and do pass these costs onto customers. Change linked to money is especially hard to accept. The key, therefore, to developing the ideal tool is to relentlessly focus on keeping development cost low so as to deliver a low-cost (or free) tool. It's all but guaranteed that the ideal tool will take advantage of multiple pieces of Open Source software.
Robust. Few things are more difficult than trying to convince a skeptic to try a new, unreliable technology. Getting the last 20% in reliability is orders of magnitude more difficult than getting the first 80%. Part-way simply won't cut it.
Usable. A steep learning curve is a surefire deterrent to adoption. Chemistry has a long history of software with poor usability. Who could blame jaded users for turning away from "yet another piece of software." Make it obvious or don't make it at all. Tying the tool to a specific operating system or browser is an especially bad idea; "usable" means usable by everyone.

The ideal solution must also address the three key needs chemists have with respect to using their spectra:

Compile Spectra Contrary to an apparently popular belief among non-experimental chemists, most experimental chemists create their own spectra. There may be a "spectroscopist" who handles unusual cases, but the vast majority of spectra are created and interpreted by the chemist. They need a tool that requires no thought or planning to get a spectrum from the instrument into a database and ultimately onto their desktop.
Manage Spectra During any given year, an organic chemist of average productivity can generate hundreds of spectra. It's a safe assumption today that these will be in digital format. The volume of data creates its own set of problems: where to store the spectra, how to store them, how to find them again, and how to manipulate them once they are found. Tagging the spectra in such a way that the sample history can be reconstructed is critical.
Share Spectra One of the primary channels for sharing spectral data is through scientific publication. The tool must offer an obvious solution for scientists to compile their data into packages that publishers can work with and readers can do something with.

The analogy that springs to mind is blogging. As early as 1994, blogging was technically possible - all the pieces were in place and the demand for online content was mushrooming. But why didn't it happen? There was no tool that actually made it cheap and easy to blog. Staring in 2000-2001, those tools started to appear. Today, we take it for granted that anyone who wants to publish their own writing can do so almost immediately.

The availability of the tool did what years of discussion failed to do; it changed behavior. It succeeded by offering a reward that more than compensated for the pain of change.

The development of a ubiquitous tool for spectral data compilation, management, and sharing is an opportunity with a potentially big reward for the group that gets it right. It's one of those uninteresting, widespread problems that creates a natural scarcity of good solutions and people willing to develop them. Most players in the field have concluded (prematurely) that the solution(s) already exists, and so are reluctant to get involved.

What more could you ask for as a developer?

Image Credit: Daniel Morris

If You Want to Change the World, Build the Tool First - Part 1

Rich Apodaca — Tue, 18 Dec 2007 12:19:00 -0500

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

Designing the Obvious: Permalinks and Paradigms

Rich Apodaca — Wed, 03 Oct 2007 08:32:00 -0400

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 the Obvious

Rich Apodaca — Fri, 28 Sep 2007 08:29:00 -0400

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.