Goodbye browser deployment
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller, robinmiller
-
- Livecode Opensource Backer
- Posts: 8
- Joined: Fri Jul 15, 2011 1:27 am
Goodbye browser deployment
I am a relatively novice user of livecode and I use it almost exclusively to program psychology studies. The ability to track time, perform random assignment and safely send the data to a simple text file has worked very well for me. As I am sure most of you know, runrev has removed their support of browser/web deployment because of the plugin issues. This is very disappointing to me as a researcher because asking someone to spend time on a survey/study becomes exponentially more difficult if I must ask them to install an .exe or .app on their computer. It is a technological barrier as well as a psychological barrier.
Does anyone know of a solution to this issue? Is there some way to get livecode to work without participants having to download an app for tablets/phones, .exe, or .app?
Thanks in advance,
Otis
Does anyone know of a solution to this issue? Is there some way to get livecode to work without participants having to download an app for tablets/phones, .exe, or .app?
Thanks in advance,
Otis
Re: Goodbye browser deployment
depending on how advanced your stack layouts are, you might be able to create a simple stack to html/js convertor and that way no-one has to install anything..
-
- VIP Livecode Opensource Backer
- Posts: 10043
- Joined: Sat Apr 08, 2006 7:05 am
- Contact:
Re: Goodbye browser deployment
Hello Otis -
Whether a plugin or a standalone, both require downloading and installing a copy of the LiveCode engine. In both cases the actual stack files the user interacts with can be easily downloaded at runtime from any web server, so you can update them at any time and the user always has the most recent build automatically.
A standalone has the additional benefit of being able to provide a UI dedicated for your app, in contrast to a browser designed for web pages in which things like "Go Back" have no meaning in a plugin stack and can cause data loss.
Standalones can also be more secure than a plugin. While both involve compiled proprietary code and therefore the user can never be completely certain it's playing by the rules, for users that trust the app's maker enough to install the engine a standalone offers a secureMode global property which is even more restrictive than the limitations of a browser plugin in terms of modifying locally-stored data (secureMode prevents all local storage, even things as small as cookies).
And if your audience trusts you enough to allow local storage, you can craft your own smart caching to support an offline mode, something that's not possible with most plugin implementations.
With all the benefits of standalones over a browser plugin, I think you summed it up well when you wrote: "It is a technological barrier as well as a psychological barrier."
Technically, it's equally simple to run an installer for a standalone as it is for a browser, and arguably simpler for you to deliver stack files to it over the web since they don't need to be converted into a plugin-compatible format.
But psychologically, you're right on the mark. Many people *believe* that browser plugins are somehow more secure and simpler to use than a native app, and as long as such beliefs exist they must be addressed in conversations with relevant stakeholders.
In most cases a review of the actual benefits and limitations of standalones vs. browser plugins quickly helps stakeholders acknowledge the benefits of the former.
That said, there are some cases where a plugin was never truly what the stakeholders wanted, but didn't fully understand that they require installation just like any other compile code. Many want a solution that "just works" with the software they already have, their browser, and they didn't think it through far enough to realize that a plugin doesn't really provide that, that they'd still need to install some compiled object code.
In such cases where no LiveCode engine -- either standalone or plugin - would be an acceptable solution, you'll have to consider JavaScript driving HTML instead of LiveCode scripts driving stacks. The great thing about using JavaScript is that you don't need to spend a lot of time evaluating alternatives: as the only scripting engine included with every browser, we have no choice in the matter.
One nice thing about the Web is the ubiquity of tools available. You may even find a site that offers services close enough to what you need that you can use an off-the-shelf solution.
And if not, JavaScript is only getting ever more important each year, so it's well worth the time spent learning it. And as Sean suggested, some stack layouts can be translated to CSS with relative ease.
Whether a plugin or a standalone, both require downloading and installing a copy of the LiveCode engine. In both cases the actual stack files the user interacts with can be easily downloaded at runtime from any web server, so you can update them at any time and the user always has the most recent build automatically.
A standalone has the additional benefit of being able to provide a UI dedicated for your app, in contrast to a browser designed for web pages in which things like "Go Back" have no meaning in a plugin stack and can cause data loss.
Standalones can also be more secure than a plugin. While both involve compiled proprietary code and therefore the user can never be completely certain it's playing by the rules, for users that trust the app's maker enough to install the engine a standalone offers a secureMode global property which is even more restrictive than the limitations of a browser plugin in terms of modifying locally-stored data (secureMode prevents all local storage, even things as small as cookies).
And if your audience trusts you enough to allow local storage, you can craft your own smart caching to support an offline mode, something that's not possible with most plugin implementations.
With all the benefits of standalones over a browser plugin, I think you summed it up well when you wrote: "It is a technological barrier as well as a psychological barrier."
Technically, it's equally simple to run an installer for a standalone as it is for a browser, and arguably simpler for you to deliver stack files to it over the web since they don't need to be converted into a plugin-compatible format.
But psychologically, you're right on the mark. Many people *believe* that browser plugins are somehow more secure and simpler to use than a native app, and as long as such beliefs exist they must be addressed in conversations with relevant stakeholders.
In most cases a review of the actual benefits and limitations of standalones vs. browser plugins quickly helps stakeholders acknowledge the benefits of the former.
That said, there are some cases where a plugin was never truly what the stakeholders wanted, but didn't fully understand that they require installation just like any other compile code. Many want a solution that "just works" with the software they already have, their browser, and they didn't think it through far enough to realize that a plugin doesn't really provide that, that they'd still need to install some compiled object code.
In such cases where no LiveCode engine -- either standalone or plugin - would be an acceptable solution, you'll have to consider JavaScript driving HTML instead of LiveCode scripts driving stacks. The great thing about using JavaScript is that you don't need to spend a lot of time evaluating alternatives: as the only scripting engine included with every browser, we have no choice in the matter.

One nice thing about the Web is the ubiquity of tools available. You may even find a site that offers services close enough to what you need that you can use an off-the-shelf solution.
And if not, JavaScript is only getting ever more important each year, so it's well worth the time spent learning it. And as Sean suggested, some stack layouts can be translated to CSS with relative ease.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
-
- Posts: 1
- Joined: Mon Oct 22, 2012 7:42 pm
Re: Goodbye browser deployment
Otis,
thanks a lot for your post. I am researcher in psychology as well and I have been using Livecode for a couple of years. Livecode works great for me and I would never switch back to one of the less flexible research softwares available on the market.
Recently, the need to employ online studies in our department increased immensely due to a lack of lab space and I was wondering if there is some convenient way, both for me and for the participants, to employ Livecode for online studies. One of my interns started to put some effort into finding an answer to this question just a couple of days ago and I would be happy to keep you updated on the progress.
Also, how did you learn to program in Livecode? I find it difficult to refer students to the tutorials, because a lot of stuff thought there is not tailored to the needs of psychology research. I learned programming in Livecode when I was a research assistant and my boss took the time to teach it to me. As the number of students in our lab is currently increasing, I wonder if there is some more time efficient way to teach the basics.
If the latter question is too much off-topic, you can also send me an email: cecile.schain [at] uni-muenster.de.
Looking forward to hearing from you!
Cécile
thanks a lot for your post. I am researcher in psychology as well and I have been using Livecode for a couple of years. Livecode works great for me and I would never switch back to one of the less flexible research softwares available on the market.
Recently, the need to employ online studies in our department increased immensely due to a lack of lab space and I was wondering if there is some convenient way, both for me and for the participants, to employ Livecode for online studies. One of my interns started to put some effort into finding an answer to this question just a couple of days ago and I would be happy to keep you updated on the progress.
Also, how did you learn to program in Livecode? I find it difficult to refer students to the tutorials, because a lot of stuff thought there is not tailored to the needs of psychology research. I learned programming in Livecode when I was a research assistant and my boss took the time to teach it to me. As the number of students in our lab is currently increasing, I wonder if there is some more time efficient way to teach the basics.
If the latter question is too much off-topic, you can also send me an email: cecile.schain [at] uni-muenster.de.
Looking forward to hearing from you!
Cécile
Re: Goodbye browser deployment
Hi Cécile,
this is not really off-topic, but would eventually be a bit too long for this forum.
I will write you off-list erm. off-forum
Best
Klaus
this is not really off-topic, but would eventually be a bit too long for this forum.
I will write you off-list erm. off-forum

Best
Klaus
Re: Goodbye browser deployment
I'm coming into this thread a little late, and my needs may be a little different, but this is the closest information I've found for what I want to do. I have a simple project for doing crossword puzzles I've written that i'd like to put online. What are the steps involved? I'm assuming there would need to be a web page that users would find that has information about the app, but then is the whole thing downloaded if no plugin for the browser is used? Or can the engine be downloaded and the app worked "in place". If new puzzles are added, does the whole thing need to be downloaded again? The mechanics of deployment are more daunting than writing the app and the crossword puzzles!
Thanks,
Dave
Thanks,
Dave
Re: Goodbye browser deployment
Hi Dave,
You could adjust your app to download the puzzles from a server. People won't need to download the whole app again and again. They would just download tiny amounts of data containing the puzzles.
I think this would also be a very nice app for iPad and Android, even if it needs some changes.
Kind regards,
Mark
You could adjust your app to download the puzzles from a server. People won't need to download the whole app again and again. They would just download tiny amounts of data containing the puzzles.
I think this would also be a very nice app for iPad and Android, even if it needs some changes.
Kind regards,
Mark
The biggest LiveCode group on Facebook: https://www.facebook.com/groups/livecode.developers
The book "Programming LiveCode for the Real Beginner"! Get it here! http://tinyurl.com/book-livecode
The book "Programming LiveCode for the Real Beginner"! Get it here! http://tinyurl.com/book-livecode
Re: Goodbye browser deployment
Thanks for the reply, Mark. At this point I don't have mobile app capability. I'm a hobbyist and started working with Rev way back, but have done very little overall. I agree that crossword puzzles would make a lot of sense for iPads or Android. I'll have to experiment a bit. I haven't put anything up for downloading since Apple's MobileMe disappeared.
Dave
Dave
Re: Goodbye browser deployment
Hi Dave,
Please, contact me privately (see signature). Maybe we can work something out.
Kind regards,
Mark
Please, contact me privately (see signature). Maybe we can work something out.
Kind regards,
Mark
The biggest LiveCode group on Facebook: https://www.facebook.com/groups/livecode.developers
The book "Programming LiveCode for the Real Beginner"! Get it here! http://tinyurl.com/book-livecode
The book "Programming LiveCode for the Real Beginner"! Get it here! http://tinyurl.com/book-livecode