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

Richard Gaskin ambassador at fourthworld.com
Tue Oct 8 12:19:07 EDT 2019


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.

-- 
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com






More information about the use-livecode mailing list