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
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
