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.
_______________________________________________
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
