One of the things that one must become accustomed to when using a Mac regularly is that drag’n’drop is actually an effective way to get real work done. Two main use case scenarios are considered: getting graphics images of molecules into presentation tools (e.g. Pages or Keynote), and getting raw data into another cheminformatics tool (e.g. uploading an SDfile to a browser-based application). Both of these are now functioning in the pre-alpha version of XMDS  (the OS X Molecular DataSheet), which essentially brings it to demo-ready status.

I’ve been using graphical user interfaces for decades now, and drag’n’drop has been there since the beginning. For the most part I have found it to be an irritating nuisance: the most common use case scenario has been accidently holding the mouse at the wrong time and watching the cursor change in order to inform me that as soon as I take my finger off the mouse, it’s going to do something that I don’t want, and good luck figuring out what that is (e.g. moving a file). Prolonged Mac use has changed that, due in parts to more universal implementation, better visual clues, more consistent behaviour, and subtle pressure toward making Finder into a central hub: dragging files from there into somewhere else is increasingly the most convenient way to get things done.

For interprocess communication, the traditional fallback with any workflow is to save the object as a file, switch tasks, then use the destination application’s interface to initiate a hunt-and-find operation. When the transfer is just a temporary placeholder, this is a hostile user experience for so many reasons: first of all, the need to pick a location and a recognisable filename is unnecessary and wasteful of our all too limited attention spans. The destination application probably doesn’t know the path, so the locating procedure probably requires a fair bit of clicking, and sometimes scrolling through long lists of irrelevant stuff. And thirdly it leaves a stain on the filesystem: you should probably come back and delete the file when it is no longer needed. This may all sound like a case of “first world problems”, but when preparing documents with many embedded graphics, or executing repetitive workflows that involve more than one software package, the headache starts to add up.

The two inter-process drag operations that are currently operational both require some parameters, since they are data export actions that need some instructions. Prior to capturing a picture of a molecule for use in another application, the format and rendering options need to be selected, hence the dialog sheet (see above right). This is prompting the user to decide whether to create a PDF or PNG, and what colour scheme and resolution to use. For the record, “single page” PDF files are incredibly useful as embedded diagrams in the Apple universe, and should be considered as the preferred format, since they are compact and will be rendered beautifully in all scenarios. Within the dialog, the preview image updates to provide an idea of what the output will look like, in terms of boundary shape and colour scheme.

There are 3 action buttons for the preparation dialog: Save As allows the graphical image to be saved to a file: the old fashioned way (which is of course still useful). Copy will place the content onto the clipboard, from where it can be inserted into any compatible app. This is also a very effective way to get things done, and is sometimes the most convenient method, e.g. pasting graphics into a word processing document at the current cursor position is an agreeable workflow. Pressing the Drag button adds another visible step: a temporary new tool appears on the right hand side of the toolbar:

The tool is entitled “Drag”, which is its way of telling you that you should click-and-haul the mouse over to some other application. In the screen capture above, the Pages word processor is running, and the end-result of the drag operation is to have the PDF-encoded diagram of a molecule inserted into the open document.

It’s not quite a one-click operation (because of the setup step) but other than that, it’s about as convenient as it gets.

While turning cheminformatics data into graphics for inclusion into manuscripts and presentations is one of the major value propositions of chemical software, the other important function is to be able to use multiple cheminformatics packages in any given workflow, since a single monolithic program often can’t do everything you need. While it often makes sense to export data explicitly to a file, using the necessary format, there are many operations that benefit from a more facile data passing interface.

Generating an MDL SDfile from the currently open datasheet makes it possible to interface XMDS with pretty much any other cheminformatics program, since this is the industry standard, for all its many faults. There is a setup dialog that allows several default options to be selected, and this has the same action buttons as for graphics preparation: Save As, Copy and Drag. One of the specific workflows that is very interesting is the ability to drag the exported content into a browser, which is functionally equivalent to having picked a file:

Note in the above screenshot the “Drag” icon in the XMDS toolbar is reminding us that the content is in SDF format. The window to the right, which is a browser session that is logged into CDD Vault, is awaiting a data import. By dragging over top of the Choose File button, this is short-circuiting the whole save/switch/click/locate/delete cycle, which means that it is now possible to create a new datasheet with XMDS, and upload it to the CDD data platform, all in a seemlessly file-free workflow.

These two examples are indicative of how XMDS is being constructed as an upstanding citizen amongst the native Mac app tribe.