Where do we want LiveCode to go? (was "Re: Where LiveCode is Now")

[JJS]

If you watch the movie a bit on the link i posted about the webapps, it 
is quite interesting. Superfast loading, works on all platforms, on all 
browsers. Pages and applications. Works even Offline via caches. All 
your work is synced when going online again (in case you have a bad 
connection or whatever).

People adjust to speed, once you have a faster system with SSD for 
example and you go back to your previous computer which is slower, slow 
networking, slow harddrive etcetera, you get irritated quickly. So 
that's why i say, the HTML5 export is a nice thing to experiment, but no 
visitor is going to return after the first time of long waiting, not 
even if the 2nd time is somewhat quicker.

So i think Progressive Webapps is going to be the next leading thing and 
not only because Google wants it, but because it's already majorly 
supported by all webbrowsers.

Maybe this could be a new feature for LC server and apps. Just a wild 
thought.


Op 8-10-2019 om 18:19 schreef Richard Gaskin via use-livecode:
> Pi Digital wrote:
>
> > I also don’t trust this statistic of 3 seconds. Count out 3 seconds
> > and see if that feels uncomfortable to you to give up.
>
> 3 seconds is the shortest threshold I've seen suggested as critical.
>
> But there's no debate on the principle in general: longer load times 
> lose users.
>
> Awareness of this is not new.  Jacob Nielsen first drew attention to 
> it back in the '90s, with his methodology and results summarized here:
> https://www.nngroup.com/articles/response-times-3-important-limits/
>
> Here Neil Patel brings this into the web era, with links to the 
> original research:
> https://neilpatel.com/blog/speed-is-a-killer/
>
> Among the other links in Patel's article is the report from Google on 
> the 3 second threshold, worth reading for the many useful details it 
> provides. While we may nitpick details on their methods, there's no 
> doubt Google has enough data to make such a claim.  So the most severe 
> rebuttal that can be reasonably offered might be assuming a margin of 
> error of 50%, making the threshold 4.5 seconds - which happens to be a 
> quite close to what other devs regularly achieve, according to the 
> first set of charts here:
> https://www.thinkwithgoogle.com/marketing-resources/data-measurement/mobile-page-speed-new-industry-benchmarks/ 
>
>
>
> There are many other research citations to be found (even more if you 
> have access to the ACM library), and the general takeaway is that as 
> web use grows, and network speeds increase, and more devs are aware of 
> and supporting the benefits of delivering a great experience quickly, 
> users increasingly expect a page to be downloaded AND rendered for use 
> within just a few seconds.
>
> The exact number of seconds may vary from study to study, but the 
> principle remains constant across all research I've seen on the 
> subject spanning more than two decades.
>
> ---
>
> All that said....
>
> It's useful to remember those expectations are for loading web PAGES, 
> not necessarily for loading web APPLICATIONS.
>
> Of course a web app exists within a page, but the distinction is in 
> its utility: generically, a page is something you read, with the 
> outcome being obtaining information, while an app is something you 
> use, with outcomes that can vary but are often more significant to the 
> user than something that can be read.
>
> Not even LC Ltd. would suggest using LC's HTML export to produce 
> simple textual articles for the web.  It's more work and loads much 
> slower than using simpler web-native methods.
>
> I outlined the sweet spot for LC's HTML export a couple months ago:
> http://lists.runrev.com/pipermail/use-livecode/2019-August/255911.html
>
> It boils down to:
>
> IF
>   you have an existing LC app
> AND
>   its functionality would be non-trivial to translate to JS
> AND
>   it's of high value to your specific audience
> THEN
>   using LC's HTML export might be a good solution.
>
>
> Assuming the landing page on your site and most other content is 
> simple HTML, and your audience has reason to believe your app is 
> valuable enough to them to be worth the wait, they'll wait.
>
> In such a relatively specialized circumstance, stats describing user 
> behavior on generic pages don't apply.
>
> Looking ahead, WebASM is now supported in enough browsers that it's 
> become practical to replace the current LC C++ engine -> JS method 
> with LC C++ engine -> WebASM.  Doing so will benefit download, 
> unpacking, and rendering times, in addition to general runtime 
> performance.  It would be useful to hear from the team on when they 
> think they may be able to embark on that transition.
>
> ---
>
> Another option underutilized in our community remains one of the LC's 
> secret strengths:
>
> Streaming apps: Native apps with web benefits.
>
> A slim standalone that can download UI and code stacks from a web 
> server along with data deliver all the benefits of a web app in terms 
> of the user always having the latest version and the ease for the 
> developer in delivering updates.  But it avoids the janky rendering 
> experience of browser content, and a UI overloaded with a plethora of 
> browser controls that have nothing to do with your app's 
> functionality.  Bonus that you can cache what you download to support 
> fully offline workflows.
>
> The only additional cost to the user is a one-time download and install.
>
> In some cases this is seen as prohibitive, and in a subset of those 
> cases that perception may actually reflect reality.
>
> But it's worth noting that many of the same orgs that say "No, we 
> can't download and install an app, it's got to be in a browser!" are 
> the same orgs that bypass the browser for mobile where they invest 
> heavily for the superior user experience a native app provides.
>
> -- 
>
> Many factors go into the decision of whether an application experience 
> is best delivered natively or within the confines of a browser window, 
> and there's enough written all over the web that we don't need to list 
> them all here.
>
> I don't believe there's any single "best" for all possible apps.
>
> If we evaluate the capabilities of what we're delivering, the needs of 
> the audience we're delivering to, and the full range of options are 
> our disposal, we can make the best choice for the project at hand.
>