Re: [Jmol-users] Fwd: Jmol iPad app
I've been asked some time ago, about a facility aimed at students for combining a web textbook with the ability to interact with 3D models. The textbook could be something close to wikipedia, that is articles with links making it easy to jump to a glossary for example, or to scientific publications related to the subject. The 3D views in the textbook would lead to a Jmol viewer surrounded by controls so that the student could explore by themselves the aforementioned model, searching for interesting features. All of this could be done through webpages especially now that we have Jsmol. But if an app is created for iPads (or other tablets as as Otis points it, Apple policies regarding iOS and apps are more than questionable), it could be a good idea to have the user clicking on a link (this could be a thumbnail or anything clickable probably through a custom urlscheme) from an article, and the app opening with the corresponding view of the 3D model + commands. I can see what it would look like if there is only "simple" interactions (a button throwing a script). What I can't see is how we can make more complex widgets that for example poll informations from the applet and create a context accordingly (for example an interactive sequence viewer, etc...) without reinventing a whole web-browser ! The idea of a repertoire of Jmol "slides" opening at startup looks great Paul Le 24 janv. 2013 à 16:39, Bob Hanson a écrit : > > Begin forwarded message: > >> From: Robert Hanson >> 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
[Jmol-users] Fwd: Jmol iPad app
Begin forwarded message: > From: Robert Hanson > 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 > -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. ON SALE this month only -- learn more at: http://p.sf.net/sfu/learnnow-d2d___ Jmol-users mailing list Jmol-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jmol-users
