Posts Tagged ‘Android’

Mobile-friendly solutions for viewing (WordPress) Blogs with embedded 3D molecular coordinates.

Sunday, December 11th, 2011

My very first post on this blog, in 2008, was to describe how Jmol could be used to illustrate chemical themes by adding 3D models to posts. Many of my subsequent efforts have indeed invoked Jmol. I thought I might review progress since then, with a particular focus on using the new generations of mobile device that have subsequently emerged.

  1. Jmol is based on Java, which has been adopted by Google’s Android mobile operating system, but not by Apple’s IOS.
    • An Android version of Jmol was recently released, to rave reviews! I do not know however whether the Jmol on these posts can be viewed via Android. Perhaps someone can post a comment here on that aspect?
    • HP has just announced it will open source WebOS, but it seems Java will not be supported so probably no Jmol there then.
    • Windows 8 Mobile (Metro) also seems unlikely to support it either.
  2. Apple has been prominent in touting HTML5 as a Java replacement. In practice, this means that any molecular viewer would be based on a combination of Javascript and WebGL technologies.  Whereas Java is a compiled language, Javascript is interpreted on-the-fly by the browser. Its viability has been greatly increased by very large improvements in the speeds that browsers interpret Javascript nowadays, but this speed is unlikely to ever match that of Java. The real issue is whether that matters. The other difference is that whereas a signed Java applet allows data to escape from the security Sandbox (and into eg a file system), Javascript is likely to be much more restrictive. These two properties mean that Javascript/HTML5 implementations make a lot of use of server-side functionality; in other words a lot of bytes may have to flow between server and mobile device to achieve a desired effect (and the user may have to pay for these bytes via their data plan).
    • One early adopter of the Javascript/WebGL HTML5 model has been ChemDoodle, which I illustrated on this blog about a year ago. I have tidied up the recipe for invoking it since then, and this is given below for anyone interested in implementing it. As of this moment, one essential component, WebGL, is only available to developers of Apple’s IOS system, but I expect this to become generally available soon. When that happens, ChemDoodle components on this blog will start working.
    • A new entrant is GLmol, an open source molecular viewer for Apple’s IOS. A version is also available for Android. I may give a try at embedding this into the blog.
It seems that the 3D molecular viewing options are certainly increasing, but at the moment there is some uncertainty in performance, compatibility and the ability to extract molecular data from the “sandboxes“. This last comment relates to the re-usability of data, which I particularly value.

Although this post has focussed on embedding and rendering molecular data into a blog post, the same principle in fact applies to other expressions. Perhaps the most interesting is the epub3 e-book format, which also supports Javascript/HTML5, and which seems likely to be adopted for future interactive e-books. Indeed, it should be possible to fully convert an interactive blog created using this technology to a e-book with relatively little effort. I have also illustrated here how lecture notes can be so converted.

If you get the impression that the task of a modern communicator of science and chemistry is not merely that of penning well chosen words to describe their topic, but of having to program their effort, then you may not be mistaken.

Procedure for creating a 3D model in a WordPress blog post using ChemDoodle.

  1. As administrator, go to 
    wp-content/themes/default

    (or whatever theme you use) and in the file header.php, paste the following

    <link rel="stylesheet" href="../ChemDoodle/ChemDoodleWeb.css" type="text/css">
  <script type="text/javascript" src="../ChemDoodle/ChemDoodleWeb-libs.js"></script>
  <script type="text/javascript" src="../ChemDoodle/ChemDoodleWeb.js"></script>
   <script type="text/javascript" language="JavaScript">
  function httpGet(theUrl)
   {var xmlHttp = null;
   xmlHttp = new XMLHttpRequest();
   xmlHttp.open( "GET", theUrl, false );
   xmlHttp.send( );
   return xmlHttp.responseText;}
   </script>
  2. From here, get the ChemDoodle components and put them into the directory immediately above the WordPress installation. They are there referenced by the path ../ChemDoodle as in the script above. You can put the folder elsewhere if you modify the path in the script accordingly.
  3. Invoke an instance of a molecule thus; 
    <script type="text/javascript">// <![CDATA[
var transformBallAndStick2 = new ChemDoodle.TransformCanvas3D('transformBallAndStick2', 190, 190);transformBallAndStick2.specs.set3DRepresentation('Ball and Stick');         transformBallAndStick2.specs.backgroundColor = 'white';var molFile = httpGet( 'wp-content/uploads/2011/12/85-trans.mol' );var molecule = ChemDoodle.readMOL(molFile, 2);         transformBallAndStick2.loadMolecule(molecule);
// ]]></script>
  4. The key requirement is that the body of the script (starting with var) must not contain any line breaks; it must be a single wide line. So that you can see the whole line here, I show it in wrapped form (which you must not use); 
    var transformBallAndStick2 = new
ChemDoodle.TransformCanvas3D('
transformBallAndStick2', 190,
190);transformBallAndStick2.specs.
set3DRepresentation('Ball and Stick');
transformBallAndStick2.specs.
backgroundColor = 'white';var molFile =
httpGet('wp-content/uploads/2011/12/85-trans.mol');
var molecule =ChemDoodle.readMOL(molFile, 2);
transformBallAndStick2.loadMolecule(molecule);
  5. The key data will be located in the path wp-content/uploads/2011/12/85-trans.mol which you should upload. Note that only the MDL molfile is supported in this mode (which makes no server-side requests). One can use eg CML, but this must be as a server request.
  6. If you want multiple instances, then you must change each occurrence of the name of the variable, e.g. transformBallAndStick2 to be unique for each.
  7. If you want to annotate the resulting display, server-side requests are again needed. I do not illustrate these here, but there is an excellent tutorial.

Tags:, , , , , , , , , , , , , , , , ,
Posted in Chemical IT | 11 Comments »

Science publishers (and authors) please take note.

Monday, October 24th, 2011

I have for perhaps the last 25 years been urging publishers to recognise how science publishing could and should change. My latest thoughts are published in an article entitled “The past, present and future of Scientific discourse” (DOI: 10.1186/1758-2946-3-46). Here I take two articles, one published 58 years ago and one published last year, and attempt to reinvent some aspects. You can see the result for yourself (since this journal is laudably open access, and you will not need a subscription). The article is part of a special issue, arising from a one day symposium held in January 2011 entitled “Visions of a Semantic Molecular Future” in celebration of Peter Murray-Rust’s contributions over that period (go read all 15 articles on that theme in fact!).

Here I want to note just two features, which I have also striven to incorporate into many of the posts this blog (which in one small regard I have attempted to formulate as an experimental test-bed for publishing innovations). Scalable-Vector-Graphics (SVG) emerged around the turn of the millennium as a sort of HTML for images. To my knowledge, no science publisher has yet made it an intrinsic part of their publishing process (although gratifyingly all modern browsers support at least a sub-set of the format). Until now (perhaps). Thus 10.1186/1758-2946-3-46 contains diagrams in SVG, but you will need to avoid the Acrobat version, and go straight to the HTML version to see them. However, what sparked my noting all of this here was the recent announcement by Amazon that they are adopting a new format for their e-books, which they call Kindle Format 8 or KF8 (the successor to their Mobi7 format). To quote: “Technical and engineering books are created more efficiently with Cascading Style Sheet 3 formatting, nested tables, boxed elements and Scalable Vector Graphics“. This is wrapped in HTML5 to be able to provide (inter alia) a rich interactive experience for the reader. In fairness, there is also the more open epub3 which strives for the same. Other features of HTML5 include embedded chemistry using WebGL and the same mechanisms are being used for the construction of modern chemical structure drawing packages.

It remains to be seen how much of all of this will be adopted by mainstream chemistry publishers. Here, we do get into something of a cyclic argument. I suspect the publishers will argue that few of the authors that contribute to their journals will send them copy in any of these new formats and that it would be too expensive for them to re-engineer these articles with little or no help from such authors. The chemistry researchers who do the writing (perhaps composition might be a better word?) might argue there is little point in adopting innovative formats if the publishers do not accept them (I will point out that my injection of SVG into the above article did have some teething problems). For example, you will not find SVG noted in any of the “instructions for authors” in most “high impact journals” (or, come to that, HTML5).

If one looks at the 25 year old period, in 1986 all chemistry journals were distributed exclusively on paper. My office shelves still show the scars of bearing the weight of all that paper. Move on 25 years, and all journals almost without exception are now distributed electronically. I suspect the outcome in many a reader’s hands is simply that they (rather than the publisher) now bear the printing costs themselves (despite or perhaps because of the introduction of electronic binders such as Mendeley). But it will only be when the article itself grows out of its printable constraints, and hops onto mobile devices such as Kindles and iPads in the promised (scientifically) interactive and data-rich form, that the true revolution will start taking place.

A final observation: you will not readily obtain the interactive features of 10.1186/1758-2946-3-46 on e.g. an iPad or Kindle because the Java-based Jmol is not supported on either. But Jmol has now been ported to Android, and its certainly one to watch.

Tags:, , , , , , , , , , , , , , , , ,
Posted in Chemical IT, General | 3 Comments »

Data-round-tripping: wherein the future?

Tuesday, December 7th, 2010

Moving (chemical) data around in a manner which allows its (automated) use in whichever context it finds itself must be a holy grail for all scientists and chemists. I posted earlier on the fragile nature of molecular diagrams making the journey between the editing program used to create them (say ChemDraw) and the Word processor used to place them into a context (say Microsoft office), via an intermediate storage area known as the clipboard. The round trip between the Macintosh (OS X) versions of these programs had been broken a little while, but it is now fixed! A small victory. This blog reports what happened when such a Mac-created Word document is sent to someone using Microsoft Windows as an OS (or vice versa).

As you might have guessed, the molecular diagram arrives largely dead, and not re-usable. Opening the .docx archive (it is nothing more than a zip file) reveals only a JPEG file residing inside. Nothing that can be chemically repurposed. If the reverse process is undertaken, of creating a chemdraw diagram, and pasting it into Word on Windows, one finds in the .docx two components; a bit-mapped image linked to an active object containing the data. Only the first of these is recognised if the file makes its way to a Macintosh; i.e. the same story, the data is again lost. So the bottom line is that Mac users and Windows users cannot, after all, exchange repurposable molecular diagrams using Word documents using this combination of programs. This is not good.

But let me remind what happened around 1993. The word processor was joined by a program called the Web browser. In 1996, the underlying content carrier, HTML, became XHTML (an instance of XML). Right from day 1 almost, such XHTML could, and frequently was repurposed. A memorable example is that search engines could use it to index the Web. The XHTML easily survived trips to and from clipboards. In 1996, CML joined HTML as a way of carrying chemical information capable of round-tripping without loss (if need be). There are other chemical XML languages in use nowadays, including CDXML used by the ChemDraw program. Word itself now uses XML (the x in .docx). So, after 14 years, why am I still describing the difficulties above? I am frankly at a loss to explain why there is still a need to write this post.

All is not entirely lost. The CML4Word approach is designed to enable (chemical) data round tripping from the outset. Although I do not yet know if the CML created and stored in the Word document using this mechanism is recognised anywhere outside of Word 2007 on Windows?  If anyone can let me know of examples where such a CML-enabled Word document can be used in other environments, I would be very grateful (but not on  OS X, as I know already).

And as I might have mentioned in the previous post on this topic, things may not however be getting better in that other carrier of information and data, the mobile phone/iPad, as exemplified by operating systems such as iOS or Android. Watch this space, as they say.

Tags:, , , , , , , , , , , , , , , , , ,
Posted in Chemical IT | No Comments »