glenn9 wrote: ↑Wed Nov 08, 2023 2:30 pm
re user base
I think to increase LC`s visibility, and therefore its potential user base (& potentially income), is by `growing` new users by targeting education, especially schools.
I think for children to have an app (albeit desktop) up and running in literally minutes, I think would ignite passion for coding in quite a few children.
LC does indeed fill an important cognitive gap between Scratch and Python.
The argument against edu focus is that it's a long game, since schools (at least in the States) are strapped for funds and often gravitate to low or no cost tools, so the upside doesn't happen until graduation when those who will program on their own will choose the tool they know.
The irony is that the company is now mature enough that two and a half generations of students have gone from age ten to twenty.
best coding language
I think there is always discussion on the `best` programming language that you should learn and I`m reminded of the camera analogy, ie which is the best camera? - the one that you have with you at the time you need to take a photo...
I think this holds true for coding languages, ie its the language that you can make meaningful apps in, in the least amount of time.
this certainly applied to me in my desire to learn how to code, having previously tried and failed miserably as a hobbyist to make apps using BASIC, VBA, C# and Python, until I stumbled across LC during lockdown and made it my lockdown project to learn how to code.
Any tool outside the most popular will struggle among those learning to program as a hired hand.
So wisely LC Ltd has focused on Indy devs, where the project decision makers only care about results, not the popularity of the language.
This can work as long as the value proposition for LC is unquestionably high.
On the desktop, LC's productivity advantage is nearly unmatched. That could be made unquestionable if the Standalone Builder was extended to include a wizard to guide the dev through the various stapling/signing steps needed. That is the biggest pain point, and so poorly addressed in other tools that it makes a ripe opportunity for LC to solidify its differentiation.
As for mobile...
desktop v mobile
I remember reading somewhere in the forum, I think it was a post from Richard G, that in an ideal world developing in mobile should be as straightforward as developing for desktop and cited the scrolling field as an example of this.
I guess this is being addressed through LC`s work on a browser IDE, but I think this should be LC`s main focus, ie making moble development as easy as desktop - just imagine how children`s eyes would light up if they could put apps on their phones, as well as their desktops, in minutes!!
I believe the field scrolling example is especially useful because it's already been solved - a dozen times over by every dev I know who's written a script to automatically instantiate the native scroller region over any scrolling control.
So in an afternoon that could be added to the general lib already tacked on when making a standalone.
That would be only an interim solution, of course. Long term we'd want the engine to do that rather than rely on a less efficient scripted workaround.
But at least that workaround could be in the next version, very affordably, buying time for the finished solution a bit down the road.
And by using something so obvious and easily addressed as a UX awareness exercise, no doubt other paper cuts that impede development efficiency would become more readily recognized and addressed along the way.