Helping newcomers anticipate that standalones can't save to themselves

classic Classic list List threaded Threaded
31 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Helping newcomers anticipate that standalones can't save to themselves

Richard Gaskin
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
  ____________________________________________________________________
  [hidden email]                http://www.FourthWorld.com

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Helping newcomers anticipate that standalones can't save to themselves

Ludovic THEBAULT

Le 15 août 2014 à 16:13, Richard Gaskin <[hidden email]> a écrit :

> 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

Hello,

What about a « test » mode that simulate the standalone comportment ?


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Helping newcomers anticipate that standalones can't save to themselves

Charles E Buchwald
Yes, I like the idea of a "test" mode. I prefer that my experience in the development environment match the final user experience as closely as possible.

I can imagine linking this test mode to what are now the View > Look and Feel > Emulated... menu items. And of course it would be great to have those Look and Feel menu items include iOS and Android... and updated from Mac OS Classic to OS X, and Windows 95 to something more current.


On 15 Aug 2014, at 9:21 AM, Ludovic THEBAULT <[hidden email]> wrote:

>
> Le 15 août 2014 à 16:13, Richard Gaskin <[hidden email]> a écrit :
>
>> 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
>
> Hello,
>
> What about a « test » mode that simulate the standalone comportment ?
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

--
Charles E. Buchwald
CEO/Director General
Museografica Digital
http://digital.museografica.com

Mac OSX 10.9.4, LC 6.6.2 Commercial

LC Developer Tools: http://buchwald.ca/developer-tools/

Email Notice: http://wp.me/P3aT4d-33


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Helping newcomers anticipate that standalones can't save to themselves

Bob Sneidar-2
In reply to this post by Ludovic THEBAULT
hmmm… it would be too much to ask that the test mode could simulate the windows environment on a Mac and vis versa. Fairly impossible I suppose to emulate Linux…

Bob S


On Aug 15, 2014, at 07:21 , Ludovic THEBAULT <[hidden email]<mailto:[hidden email]>> wrote:


Le 15 août 2014 à 16:13, Richard Gaskin <[hidden email]<mailto:[hidden email]>> a écrit :

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

Hello,

What about a « test » mode that simulate the standalone comportment ?


_______________________________________________
use-livecode mailing list
[hidden email]<mailto:[hidden email]>
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Helping newcomers anticipate that standalones can't save to themselves

Vaughn Clement
In reply to this post by Richard Gaskin
Hi Richard

Although I have not seen this occur in stacks I've created, I would like to
better understand where you are going with this topic? Are you starting a
new way to address specific issues with LiveCode, or suggesting changes to
the IDE?

Thank you

Vaughn Clement

Apps by Vaughn Clement (Support)
*http://www.appsbyvaughnclement.com/tools/home-page/
<http://www.appsbyvaughnclement.com/tools/home-page/>*
Skype: vaughn.clement
https://secure.join.me/appsbyvclement
FaceTime: [hidden email]
LogMeIn also avaialble
Call on "ooVoo" at address:  vaughnclement or 9282549062
Ph. 928-254-9062



On Fri, Aug 15, 2014 at 7:13 AM, Richard Gaskin <[hidden email]>
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
>  ____________________________________________________________________
>  [hidden email]                http://www.FourthWorld.com
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Helping newcomers anticipate that standalones can't save to themselves

Mike Kerner
In reply to this post by Bob Sneidar-2
How about going the other direction and fixing the behavior?

Technically, any standalone CAN edit itself, anyway, but there are all
sorts of things that might be able to be done with ancillary files to store
changes/updates.  When the standalone is going to set something, it checks
the file (like a settings file), first.  This is just like what happens
with the message path.

Polymorphism will make the product more powerful and let people do amazing
things with it.


On Fri, Aug 15, 2014 at 10:58 AM, Bob Sneidar <[hidden email]>
wrote:

> hmmm… it would be too much to ask that the test mode could simulate the
> windows environment on a Mac and vis versa. Fairly impossible I suppose to
> emulate Linux…
>
> Bob S
>
>
> On Aug 15, 2014, at 07:21 , Ludovic THEBAULT <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>
> Le 15 août 2014 à 16:13, Richard Gaskin <[hidden email]
> <mailto:[hidden email]>> a écrit :
>
> 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
>
> Hello,
>
> What about a « test » mode that simulate the standalone comportment ?
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]<mailto:[hidden email]>
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>



--
On the first day, God created the heavens and the Earth
On the second day, God created the oceans.
On the third day, God put the animals on hold for a few hours,
   and did a little diving.
And God said, "This is good."
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Helping newcomers anticipate that standalones can't save to themselves

Paul Hibbert
In reply to this post by Richard Gaskin
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 <[hidden email]> 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
> ____________________________________________________________________
> [hidden email]                http://www.FourthWorld.com
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Helping newcomers anticipate that standalones can't save to themselves

Vaughn Clement
Hi Richard

This is a good opening topic that can solicit comments. I have passed
through the frustration about documentation already, and I find I live on
the How To email to find answers. The forums seem to take forever to get
answers. Considering that the How To offers a good reference platform,
wouldn't make sense to build on the knowledgebase of the How to to provide
for a more organized reference tool? Can the How to be improved like the
forum where topics are simpler to locate using a category and keywords.
I've used the current system for the How to listings and I have found it
difficult to find answers based on the current search approach.

Thank you

Vaughn Clement

Apps by Vaughn Clement (Support)
*http://www.appsbyvaughnclement.com/tools/home-page/
<http://www.appsbyvaughnclement.com/tools/home-page/>*
Skype: vaughn.clement
https://secure.join.me/appsbyvclement
FaceTime: [hidden email]
LogMeIn also avaialble
Call on "ooVoo" at address:  vaughnclement or 9282549062
Ph. 928-254-9062



On Fri, Aug 15, 2014 at 8:28 AM, Paul Hibbert <[hidden email]> wrote:

> 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 <[hidden email]>
> 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
> > ____________________________________________________________________
> > [hidden email]                http://www.FourthWorld.com
> >
> > _______________________________________________
> > use-livecode mailing list
> > [hidden email]
> > Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Helping newcomers anticipate that standalones can't save tothemselves

larry
In reply to this post by Paul Hibbert
Great concept from Paul.
To that I would add this:  I agree 100% that the LC documentation is slowly
improving, but has a LONG way to go.
Speaking of tutorials, what would be really helpful is a series of videos
that are screen capture tutorials - someone who knows what they're doing
literally walking a newbie through a specific lesson.
As you all know, there is a ton of free or for purchase screen capture
software out there.  I am not sure the best way to organize this idea, but
if this list could somehow come up with an organized list of topics, then
one or more programmers on the list could create the video(s) for a
particular topic and post it somewhere.
Personally, I would recommend a series of videos that range from something
as simple as how to drag a button onto the IDE and set its properties (even
I could make that video) to something as complex as creating a plugin for
the IDE. (for someone else to make!)
If we had a video series such as this, I would absolutely encourage some of
my (young) grandchildren to learn programming basics with LC and the videos.
I really do believe that one of the great strengths of LC is that a "newbie"
can actually make a simple program that actually works - and not just "Hello
World."
I've never taken a programming class, but because of LC (and this list
helping me) I've written dozens of little programs that I personally use a
lot and a couple of "bigger" more sophisticated programs.
That's my opinion of what this list might want to think about.
Larry

----- Original Message -----
From: "Paul Hibbert" <[hidden email]>
To: "How to use LiveCode" <[hidden email]>
Sent: Friday, August 15, 2014 9:28 AM
Subject: Re: Helping newcomers anticipate that standalones can't save
tothemselves


> 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 <[hidden email]>
> 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
>> ____________________________________________________________________
>> [hidden email]                http://www.FourthWorld.com
>>
>> _______________________________________________
>> use-livecode mailing list
>> [hidden email]
>> Please visit this url to subscribe, unsubscribe and manage your
>> subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode 


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Helping newcomers anticipate that standalones can't save to themselves

Richard Gaskin
In reply to this post by Vaughn Clement
Vaughn Clement wrote:

 > Hi Richard
 >
 > Although I have not seen this occur in stacks I've created, I would
 > like to better understand where you are going with this topic? Are
 > you starting a new way to address specific issues with LiveCode, or
 > suggesting changes to the IDE?

That's a good question, and to be honest I'm not really sure, just
exploring options.

I kinda like the idea of a runtime emulator, but even if we could build
such a thing that can account for the many platform-specific things it
would need to be useful, we're still left with the same need:

If a person is able to know that they need to run a tool to discover the
implications of not being able to save to a standalone, the existing
Standalone Builder provides that.  The trick is being able to know that
this sort of evaluation has to be done at all.

Extending the documentation might be useful, but only to the degree that
any new additions will be read.

We could add all sorts of additional tutorials and such, but this issue
is already described in a very bold callout on the User Guide page that
discusses standalones (p 299).  If users aren't reading the primary
source of information on using LiveCode, what assurances can we have
that they'll discover any other discussion of this in some separate
tutorial?


Mike's very inventive, and I like where he's going with this:

 > How about going the other direction and fixing the behavior?
 >
 > Technically, any standalone CAN edit itself, anyway, but there are
 > all sorts of things that might be able to be done with ancillary
 > files to store changes/updates.  When the standalone is going to
 > set something, it checks the file (like a settings file), first.

One of the challenges with such an approach is that people use LiveCode
in a wide variety of ways, and in a few cases may rely on data being
cleared when the standalone is exited.

So maybe such a behavior could be limited to attempting to use a save
command on a standalone, in which it automatically clones that stack?
But then where would it be saved?  How would it know whether it should
be in the Documents folder, or Prefs, or App Support, or some other place?

Taking a broader view, for most apps it's not desirable to save UI
elements at all, populating the UI with data stored externally instead,
so when you deploy upgrades the new UI can display older data without
having to worry about the old UI.  And for separate data storage there
are many options, from text files to custom properties to XML to JSON to
databases and more - which one is the right fit for the application at hand?

Currently these are decisions we make, and once we understand that OSes
don't allow executables to write to themselves we design with this in
mind, and often enjoy the flexibility of having so many different
options for managing persistence.

In our local user group we kicked around some ideas for handling this,
but it didn't take long until what we were leaning toward was a sort of
framework.  But as useful as frameworks can be they can also be
limiting, and require learning even more to be able to do productive
work since we have to learn both LiveCode and the specific ways LiveCode
is used within the framework.


It's an odd problem, in that it's simple enough to accommodate once the
need is known, but difficult to know it's needed in advance.

I used to think that this expectation that standalones might be able to
save to themselves was limited to those with HyperCard experience, since
AFAIK Mac Classic (by virtue of its resource fork) was the only OS in
popular use that ever allowed this.  And given that both HC and Mac
Classic were killed off more than a decade ago, I would have expected
this issue to come up ever less often since.

Yet somehow even among young people, who've never used HC and in a world
where they've never seen any application save to itself, find themselves
with the expectation that this should be doable.

Not sure how that expectation happens, or how to prevent it, but it
comes up just often enough that I think it may be worth trying.

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

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Helping newcomers anticipate that standalones can't save to themselves

ScottR
Maybe having a saving data/reading data example stack included among the default LC splash screen examples could be an additional learning avenue.  The demo stack could dynamically generate a data stack in the system's Documents folder (for ease of writing/locating), as opposed to requiring the developer to manually place any files/folders.

Regards,

Scott Rossi
Creative Director
Tactile Media UX/UI Design

> On Aug 15, 2014, at 9:20 AM, Richard Gaskin <[hidden email]> wrote:
>
> We could add all sorts of additional tutorials and such, but this issue is already described in a very bold callout on the User Guide page that discusses standalones (p 299).  If users aren't reading the primary source of information on using LiveCode, what assurances can we have that they'll discover any other discussion of this in some separate tutorial?

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Helping newcomers anticipate that standalones can't save tothemselves

Richard Gaskin
In reply to this post by larry
larry wrote:

> To that I would add this:  I agree 100% that the LC documentation is slowly
> improving, but has a LONG way to go.

Agreed, and there's a series of projects underway to improve things.

Feel free to propose any specific ideas you have in the Open Source ->
Learning Resources -> Brainstorms forum so we can all work together to
see if we can turn these into actionable items:

<http://forums.livecode.com/viewforum.php?f=88>

--
  Richard Gaskin
  LiveCode Community Manager
  [hidden email]

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Helping newcomers anticipate that standalones can't save to themselves

Mark Talluto
In reply to this post by Richard Gaskin
On Aug 15, 2014, at 7:13 AM, Richard Gaskin <[hidden email]> 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?

I would think that this could be solved with a document titled something like: “Things you should know…” or “Getting Started” or “Read Me Before Starting” or something entirely different.
This document should be in the ‘User Guide’ and the intro screen that pops up for the first few times when LC is started.  It might be a useful Blog of things to know about LC when starting for the first time.  It should be in a document on the website in the documentation area as well.  

Bonus points for checking for the following in the script editor on compile and then popping up a dialog that states “Did you know…” or “this code will not work as in a standalone”.



Best regards,

Mark Talluto
CanelaSoftware.com
LiveCloud.io





_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Helping newcomers anticipate that standalones can't save to themselves

Stephen Barncard-4
In reply to this post by Richard Gaskin
On Fri, Aug 15, 2014 at 9:20 AM, Richard Gaskin <[hidden email]>
wrote:

> Yet somehow even among young people, who've never used HC and in a world
> where they've never seen any application save to itself, find themselves
> with the expectation that this should be doable.


It's what people new to programming (yet are frequent users) expect in an
app today, with apps like Final Cut Pro X , iTunes, iPad, most Apple OEM
apps requiring no 'saving'.  Thanks go to apple, although I'm sure this is
the way android apps are expected to work too.  These folks may not have a
concept of saving anything or worse, WHERE is being saved...

All these apps go out of their way to obfuscate the location of discrete
files 'so we won't have to worry our pretty little head' about them. Drives
me nuts.

Is Windoze/MS going that direction?

*--*
*Stephen Barncard - San Francisco Ca. USA - Deeds Not Words*
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Helping newcomers anticipate that standalones can't save to themselves

Richard Gaskin
In reply to this post by Mark Talluto
Mark Talluto wrote:

 > I would think that this could be solved with a document titled
 > something like: “Things you should know…” or “Getting Started”
 > or “Read Me Before Starting” or something entirely different.

Along those lines, earlier this morning I took a look through the
various introductory materials linked to in the Help menu and filed this
request to add the warning that appears on p 299 of the User Guide to
the Getting Started materials on the web which perhaps may be read more
frequently, which might explain why the User Guide's effort to cover
this has fallen flat:

<http://quality.runrev.com/show_bug.cgi?id=13194>

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

_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Helping newcomers anticipate that standalones can't save to themselves

kee nethery
In reply to this post by Richard Gaskin
I use the launcher/updater with the script/data stack model so my standalones can save changes into it’s stacks. Wonder if it would make sense to have a standard version of that launcher/updater so that newbies can just grab it and use it.
Kee


On Aug 15, 2014, at 7:13 AM, Richard Gaskin <[hidden email]> 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
> ____________________________________________________________________
> [hidden email]                http://www.FourthWorld.com
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Helping newcomers anticipate that standalones can't save to themselves

pmbrig
In reply to this post by Richard Gaskin
Would it be possible for the standalone builder to automatically create an .exe stack that opens invisibly and does only one thing: opens what the user has presented as the mainstack? Then things would work exactly the same as in the IDE and changes made to the mainstack  would be saved. Some attention would have to be paid to not messing up the message path, I guess, but it seems feasible on the face of it. (Of course, lots of things seem feasible when you don't really know what you're talking about….)

-- Peter

Peter M. Brigham
[hidden email]
http://home.comcast.net/~pmbrig


On Aug 15, 2014, at 10:13 AM, Richard Gaskin 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
> ____________________________________________________________________
> [hidden email]                http://www.FourthWorld.com
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Helping newcomers anticipate that standalones can't save to themselves

Mike Bonner
Late to this, but I like the Mark T thought idea.  I still remember when
the datagrid first came out, one specific part of the documentation was a
big bold link that said something like.. "What things do I need to know to
avoid needless headaches.."  It included things like building a
standalone/splashstack combination, and putting a fake datagrid stub
substack as part of the splash so that the builder would know to included
the datagrid stuff.

If a list of such things could be put together and shown on first run, it
might be a just the ticket.


On Fri, Aug 15, 2014 at 11:46 AM, Peter M. Brigham <[hidden email]> wrote:

> Would it be possible for the standalone builder to automatically create an
> .exe stack that opens invisibly and does only one thing: opens what the
> user has presented as the mainstack? Then things would work exactly the
> same as in the IDE and changes made to the mainstack  would be saved. Some
> attention would have to be paid to not messing up the message path, I
> guess, but it seems feasible on the face of it. (Of course, lots of things
> seem feasible when you don't really know what you're talking about….)
>
> -- Peter
>
> Peter M. Brigham
> [hidden email]
> http://home.comcast.net/~pmbrig
>
>
> On Aug 15, 2014, at 10:13 AM, Richard Gaskin 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
> > ____________________________________________________________________
> > [hidden email]                http://www.FourthWorld.com
> >
> > _______________________________________________
> > use-livecode mailing list
> > [hidden email]
> > Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> > http://lists.runrev.com/mailman/listinfo/use-livecode
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Helping newcomers anticipate that standalones can't save to themselves

Charles E Buchwald
In reply to this post by kee nethery
This would be awesome, Kee. I've been looking for something like that, myself.
(Do you have anything you would be willing to share off list?)

Not to bring up a sore subject, but something like this would be pretty easy to share and distribute... and might even be found by new users more easily... if revOnline was fixed up... and included a "basics" or "new users" and/or "templates" tag or category.

- Charles

On 15 Aug 2014, at 12:46 PM, kee nethery <[hidden email]> wrote:

> I use the launcher/updater with the script/data stack model so my standalones can save changes into it’s stacks. Wonder if it would make sense to have a standard version of that launcher/updater so that newbies can just grab it and use it.
> Kee

--
Charles E. Buchwald
CEO/Director General
Museografica Digital
http://digital.museografica.com

Mac OSX 10.9.4, LC 6.6.2 Commercial

LC Developer Tools: http://buchwald.ca/developer-tools/

Email Notice: http://wp.me/P3aT4d-33


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
Reply | Threaded
Open this post in threaded view
|

Re: Helping newcomers anticipate that standalones can't save to themselves

RogGuay
In reply to this post by kee nethery
I like this idea a lot!

Roger


On Aug 15, 2014, at 10:46 AM, kee nethery <[hidden email]> wrote:

> I use the launcher/updater with the script/data stack model so my standalones can save changes into it’s stacks. Wonder if it would make sense to have a standard version of that launcher/updater so that newbies can just grab it and use it.
> Kee
>
>
> On Aug 15, 2014, at 7:13 AM, Richard Gaskin <[hidden email]> 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
>> ____________________________________________________________________
>> [hidden email]                http://www.FourthWorld.com
>>
>> _______________________________________________
>> use-livecode mailing list
>> [hidden email]
>> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
>> http://lists.runrev.com/mailman/listinfo/use-livecode
>
>
> _______________________________________________
> use-livecode mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


_______________________________________________
use-livecode mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
12