[Jmol-users] Fwd: Jmol iPad app

[Bob H. <ha...@st...>]

Begin forwarded message:

> From: Robert Hanson <ha...@st...>
> Date: January 24, 2013 4:14:54 PM GMT+02:00
> To: undisclosed-recipients:;
> Subject: Jmol iPad app
> 
> Dear Jmol users,
> 
> The Jmol iPad app. The  obvious next step, right? So, I'd like to start a discussion with Jmol users and Jmol page developers. 
> 
> IF we were to work on an iPad app, what would it take to make it the "killer app" that would equal Jmol as the "killer applet."? What is it that makes Jmol/JSmol unique as an applet/JavaScript library? 
> 
> Some ideas:
> 
> -- scriptability - One of Jmol's key features is its high-level scripting language that lets both web developers and (knowledgeable) web users interact with it in ways that Jmol developers ourselves haven't  conceptualized. 
> 
> -- adaptability - Web page developers can put the applet in a context of their own choosing, with all sorts of interesting content around the applet that makes this particular page for a page visitor a particularly interesting and unique interactive experience.
> 
> Of these two, the first is probably very easy to implement in a Jmol app.  What about the second? 
> 
> My thinking goes like this: There are three groups:
> 
> -- Jmol code developers (meaning those of us writing the Java code)
> -- Jmol page developers (those using Jmol for their own creative ends using the code and interfaces developed by the Jmol code developers)
> -- Jmol users (those who visit the pages created by the Jmol page developers)
> 
> If you think about it, that second category is what makes Jmol unique. There are programs out there like pyMol and Mercury, and others that are created by code developers and  used by users. But what other programs involve the middle category? I think of Adobe Flash as something like that. Is that it? Jmol is more like Flash than it is like pyMol? Jmol provides the technology that page developers can use to design a unique experience for their page's visitors. This is what makes Jmol quite different from, say, a JavaScript library that allows one to pop up a 3D model on a page and pretty much leaves it at that. That's what the combination of controls and high-level scripting gets us. Right?
> 
> It seems to me, that if a "Jmol app" were to be valuable, it would still involve this triad of involvement. Wouldn't it be a waste of time to develop "just another molecule viewer" even if it is Jmol? That would be more like morphing the Jmol application into an iPad app, not the Jmol applet.
> 
> But how would we maintain that middle tier? 
> 
> One idea: The "Jmol app" by itself does little. But what it does do is interact with a cloud-based server (or perhaps any web site?) to pull context down and surround the viewer window with that context. So what a "Jmol context developer" (I can't think of the analogy in terms of iPad apps, because I don't think there is this category yet) would do would be to develop an actual web page with an actual computer using a standard browser and then through some sort of registered process upload, perhaps, a link to that page along with a thumbnail image and a set of searchable keywords or abstract. While that page could be viewed on the browser, some version of it could also be viewed within the Jmol app. When the Jmol app is opened, it would be like getting an index to all the Jmol pages in existence -- those adapted to this iPad idea. The user would  select the [what? -- applet? (does sound about right...)] of choice and off they go. That "applet" would pull context from the web, surround the Jmol window with that context, and there you have it. 
> 
> What do you think? Feedback? Suggestions? 
> 
> Bob
> 
> 
> 
> 
> 
> 
> -- 
> Robert M. Hanson
> Larson-Anderson Professor of Chemistry
> Chair, Chemistry Department
> St. Olaf College
> Northfield, MN
> http://www.stolaf.edu/people/hansonr
> 
> 
> If nature does not answer first what we want,
> it is better to take what answer we get. 
> 
> -- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900
>