

- #LIVECODE INDY LATEST VERSION SOFTWARE#
- #LIVECODE INDY LATEST VERSION CODE#
- #LIVECODE INDY LATEST VERSION PROFESSIONAL#
#LIVECODE INDY LATEST VERSION CODE#
Why not start with an architecture but retain total flexibility and control over the final product and the code you ship?
#LIVECODE INDY LATEST VERSION PROFESSIONAL#
No matter how “simple” and how powerful Livecode is, creating feature-complete professional software, for multiple platforms, is still quite time consuming, and filled with potential landmines. Without a well thought-out architecture to house your application, you will inevitably suffer with lost time, increased cost and lost revenue. Settings, screen responsiveness, forms, editors, wizards, disk & http IO, error-checking, and a multitude of other things.
#LIVECODE INDY LATEST VERSION SOFTWARE#
What, the words don't fit? Then buy a damned PC so you have room and mice to get real work done.AppStarterStack helps software entrepreneurs / developers to create production-ready multi-platform applications using the Livecode Engine.Įvery software needs an overall architecture for its user interface. Use English on the damned phones if your icons suck, which most do.

Is that a puking dolphin or a tadpole with pigtails? There's no roll-over pop-up like there is in mouse GUI's to tell me. Much of the industry has been aiming at the wrong target, solving a non-problem, and wasting resources doing it.Īn example of lost productivity in finger-land: I don't know what the hell 2/3 of the icons in my phone app mean. If most the work will actually be on desktops/laptops, such as business apps, then the extra pain to make them work with fingers and phones also is a time drain. Maybe there are 4 designers on Earth who can do all these well at the same time, but they probably don't work for you you can't afford them. Desktop GUI's are currently still the pinnacle of raw user productivity. They try to make fingers and mice happy at the some time, and phones and big screens happy at the same time, and usually fail, and doing all 4 lousy as compromise. The industry is not thinking things through, just chasing the latest fad butterfly, which has shat on productivity. Being super-flex has made a super-mess and turned bicycle UI science into rocket UI science for little practical gain. And UI's optimized for phones are rarely optimized for desktops and vice versa. Making them bend to phones is rarely a common need, at least for the majority of the app. You'll break your wrist trying the same thing in current web standards.Īnd most "productivity" applications are still ran on desktops/laptops. I used to mix flow-charts and rich GUI's on the desktop IDE's, kind of like those control panels in nuclear power plants. The fact HTML browsers had to split 3 ways (HTML/SVG/Canvas) and still can't over all 3 at the same time is a sign that something is broken (poorly factored) about web (non) standards. We wouldn't have to choose between HTML, SVG, and HTML5 Canvas to get more placement control AND common GUI widgets at the same time. This is not necessarily the same as WYSIWYG, although WYSIWYG would be an option since you don't have to have a server-side layout engine. Moving the layout engine to the server makes testing much easier because you then have ONE layout engine (of your choosing) instead of the 87 odd you get with all the variations of DOM engines on all the different browser brands and versions. It would be somewhat like XAML, but de-coupled from a layout engine, and more state-friendly (interactive). What's really needed is an HTTP-friendly & state-friendly GUI markup language that uses direct vector coordinates so that the layout engine can be on the server. It seems everyone just said, "the web is the future, shuddup and embrace its ways, and eat the extra costs as a sacrifice to The True Future."

I'm not sure we HAD TO sacrifice the good parts of them to get the benefits of browser-based applications. The old tools had warts, but they got better with time. The stateless web, and the screwy, inconsistent DOM layout engine that varies slightly per browser brand+version is friggen mess. It takes a team of specialist these days to write something that a 1 or 2 person shop could themselves do in 1/3 the time before.
