Helping newcomers anticipate that standalones can't save to themselves

Paul Hibbert paulhibbert at mac.com
Fri Aug 15 11:28:13 EDT 2014


From my own point of view, I struggled trying to understand some of the basic principles of using LC (Revolution as it was then), until I finally picked apart some sample stacks such as the calculator etc., then a few things started to fall in to place.

After that I looked for stacks that had a similar use or techniques to the project I wanted to build (I still do to an extent), to find ideas and learn about how LC works in ways that I maybe don't know or understand.

My biggest frustration at the time was the disjointed documentation and lack of structured tutorials, many people have also made the same comments over the years. I feel the tutorials especially have improved and the documentation is improving slowly.

Thinking back to when I discovered that I needed an anchor window (or "splash" screen), again I had to do more research to find out what was needed until I eventually understood the reasons and principles behind this process. Maybe this could be addressed with a good, well structured "My First Application" tutorial that ships with each new user download, or a package that's easily visible and readily available for new users to download. Currently there is just a free mobile template that tries to entice users to download the community version.

I'm sure there are enough teachers and ex-teachers on this list that could maybe help with this. A well structured tutorial can help to guide the new user with the right techniques from the start. 

Moving forward from the anchor window (or "splash" screen), I also feel a series of basic project templates (or starting points) could be useful, not as complex as the GLX framework, but something that already has an anchor window, preferences, menu bar and a few basic (commented) scripts for printing, saving etc.

Obviously these templates would be different for desktop, mobile or tablet, but starting from a template rather than a single empty stack would eventually help to guide the new user towards a better understanding of the techniques needed for each platform.

Paul


On 2014-08-15, at 7:13 AM, Richard Gaskin <ambassador at fourthworld.com> wrote:

> One of the most frequent frustrations new users have with LiveCode is the moment they realize the standalone they've built can't save changes to its stacks.
> 
> Often this happens very late in the process, just after building the standalone to test out the work they've been doing, and suddenly everything that worked so well in the IDE stops working, with no readily discernible cause.
> 
> So they come into the forums or this list, and folks mention everything from refactoring their work to use an anchor window (or "splash" screen) pattern, or completely rewrite everything to use an external text file or database or what have you.
> 
> The LiveCode User Guide's section on building standalones includes a bold purple callout box explaining this (p 299), but it's a testament to the usability of LiveCode that apparently a great many people can use it productively for many weeks without ever cracking the User Guide.
> 
> Clearly something more is needed.  What should that be?
> 
> Putting a note in the Standalone Builder might help, but if they've gotten that far it's too late, they probably have to start rewriting things.
> 
> How can we help users anticipate IN ADVANCE that no OS will allow their executable to write to itself, so they can write useful things from the very start?
> 
> -- 
> Richard Gaskin
> Fourth World Systems
> Software Design and Development for the Desktop, Mobile, and the Web
> ____________________________________________________________________
> Ambassador at FourthWorld.com                http://www.FourthWorld.com
> 
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode





More information about the use-livecode mailing list