Considering work with livecode server

[Richard Gaskin]

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
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com