William Prothero wrote:

> Richard,
> I did understand that the server was pretty much like php, but I
> didn’t know how much beyond that it could go in terms of dynamic
> interaction with screen objects.

LC Server does have the ability to export graphics, but being at the far end of an HTTP connection it's not quite what you're looking for.

As for client-side option:

> The reason I wanted to look into it’s use in a browser is that for
> education, lower level grades use a lot of browser based materials
> because they don’t require kids to download apps and the most
> disadvantaged of kids can mostly use a browser. Also, teachers are
> pretty much max’d out and want to keep things the way students are
> accustomed. Building a single web-based app that avoids the world of
> all the mobile apps and desktop idiosyncrasies is attractive.

Yeah, it's a funny thing I see as you do, but can't quite wrap my head around:

On mobile devices, it's all "No, it can't be in a browser, it MUST be a native app!"

But then with a larger screen it's somehow "No, it can't be a native app, it MUST be in a browser!"


These days I tend to consider browser first, looking at native apps (desktop or mobile both) only when there's some solid reason not to use a browser.

But there are many reasons, and for most of the last several years just about everything I make is a slim standalone that pulls stuff down from web servers, so for the small cost of a one-time install the user always has the latest and greatest without ever having to think about it again.

> My experience is that building the app in Livecode is the easy/fun
> part and getting it on the wide variety of platforms (Apple, windows,
> Chromebooks, iPads, the Android variations, etc, etc) is the time-
> consuming/mind-numbing challenge. I have build iOS apps and hate to
> spend my time fighting the deployment issues.

If you need platform coverage that broad your options are narrow. The design requirements for such a range of screen sizes require a deep re-think for most UI layouts, something that CSS is designed to handle but little else is.

> My comments are from the perspective of a guy who is retired, enjoys
> building useful education tools, and gives away my creations for free
> to pay back the National Science Foundation for all the support I got
> while working. So, I’m trying to maximize my satisfaction from this
> hobby.
> I came to Livecode from Director and Shockwave. I love Livecode, but
> wish it could do the same in a browser that it does so well with
> desktop and apps.

If you're not bound to market expectations you may be able to call the shots. Do what you want, and if people's preoccupations prevent them from enjoying it their loss. :)

Browsers are DEEPLY, VASTLY different from native apps. Born for trading research papers with everything else we enjoy grafted on after the fact, browsers handle content with a built-in reflow logic that no authoring environment for desktop can or even should be expected to match, any more than we bite into an apple expecting it to taste like an orange.

A small subset of things can port nicely, and my preferred way of working is authoring with custom LC tools and generating web-ready HTML from those.

If the only interaction you need is hiding/showing things and maybe a few other things, it would be fairly straightforward to write library in LC and a matching library in JavaScript, so you can author away to your heart's content by just setting properties, and the interaction behavior carries over nicely from your desktop authoring to the browser viewing.

 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 ambassa...@fourthworld.com                http://www.FourthWorld.com

use-livecode mailing list
Please visit this url to subscribe, unsubscribe and manage your subscription 

Reply via email to