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: vclem...@gmail.com 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 <paulhibb...@mac.com> 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 <ambassa...@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 > > ____________________________________________________________________ > > ambassa...@fourthworld.com http://www.FourthWorld.com > > > > _______________________________________________ > > 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 > > > _______________________________________________ > 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 > _______________________________________________ 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