Hello. New and can't find good baby steps

[dunbarx]

OK. What you say now is very positive.

And candid.

It was a long standing lament disguised as a joke wrapped around a complaint that we have no Danny Goodman for LiveCode.

Does it seem useful to create a lesson making that address book? Level one, make the stack, add find and sort stuff. Level two, add a Christmas function so it takes only family members and close friends and addresses envelopes. Level three, who knows?

It also might more of a learning thing,if it requires that much of the work for a series of functions that are only described, not shown, be done by the novice. So it can only have guidelines and hints for each of several tasks, presented as homework.

But this might be useful as a general starting point, and we can direct anyone who asks to that lesson.

Craig Newman

[mwieder]

Cybernicus-

I've finally got around to looking at this thread, and there's a lot to read here. You make some good points, and (having used the environment for some years now and having got started in xtalk with Hypercard in 1987) I have to agree with many of them, most notably regarding the state of documentation. This has been an ongoing discussion on the email lists for quite some time. There are many things that we old-timers take for granted that are confusing and nonintuitive for new users. And there are some annoying and embarassing bugs that really should be fixed. I don't think you'll get much argument about this.

But comparing LiveCode to HC, favorably or not, is not giving LiveCode a chance. It's an *entirely* different thing, in spite of the outward similarities with some UI elements and language familiarity. There's a world of difference, not just in cross-platform compatibility, but in graphics, internet features, multidimensional arrays, etc.

I'd suggest buying a personal license for $99 when your trial runs out. That way you've got enough to keep learning without a major investment and you can upgrade to the other parts you need later on. As Jacque mentioned, it really will take about six weeks to figure out what's going on, *especially* if you have to unlearn the Hypercard stuff. Forget everything you think you know about backgrounds, for one thing. And if you keep at it, do come here with questions - there are many folks here who have made or are making the transition, and in spite of the steep learning curve at first I think it's well worth the effort.

[FourthWorld]

Cybernicus, I appreciate your post and acknowledge that more than a few people have expressed similar concerns about learning LiveCode.

In RunRev's early days the key problem was a lack of information: very few resources, only the Dictionary, the User Manual and a handful of tutorials.

Today the problem is almost the opposite, of having too much information: in addition to the Dictionary and User Manual, there dozens of examples and tutorials included with the product, many dozens of online Lessons, the Script Conference stacks, hundreds of LiveCode-related resources on third-party sites, all the examples, tools and tutorials in RevOnline, the use-rev list, the developer list, the RevServer forum, and this forum. It's hard to know where to start with all that, or where to find the specific item you're looking for.

Given all that, I think it's fair to say RunRev has invested heavily in expanding the scope of materials available for learning LiveCode. I'm not saying it's complete or anywhere near ideal, just that they seem to be getting the message.

To help direct their efforts more effectively, it may be useful to better understand what you're looking for.

What sorts of information would you find ideal for learning LiveCode, or what specific things would you expect to find readily available that you haven't been able to turn up?

In the short term we can probably point you to existing resources to help with those, and in the long term your input may be quite valuable in providing the insight needed to refine RunRev's documentation investment into a form that's more usable.

[witeowl]

Here's my input in tutorials and documentation: They go from 0 to 120. I mean, really, the geometry manager is part of "basic"? What I've easily found basically jumps from "hello world" to developing a game, with little in between.

The course I'm taking (which I have to say is woefully lacking compared to the BYU course, but a credit's a credit, right?) started with a simple card with a picture, moved on to switching cards and making an ebook, then a simple calculator, and so forth. Livecode would greatly benefit from a series of lessons like that. I happened to be stubborn enough that I jumped in head-first (with the background support of the aforementioned course) and deconstructed and reconstructed a game as a huge learning experience (and an app that I can have my students use), but I can imagine that people without such motivation (and stubbornness) would just walk away in frustration.

Ultimately, Livecode is essentially billed as programming for non-programmers, but it doesn't often feel that way.

[mwieder]

Ultimately, Livecode is essentially billed as programming for non-programmers, but it doesn't often feel that way.

Yeah, there's a dilemma there. LiveCode has to target both the non-programmer market and the professional developer market and do both well. It's a hard task, and I'm not sure either one gets done well. I'm glad I don't have to cover all that ground myself. I think both markets are viable for LiveCode, and they both need more attention. Probably some more easy-to-get-started stacks available out of the box would go a long ways toward increasing the followthrough rate after the trial runs out. There's an AHA! moment that occurs at some point, and there's more work that could be done in terms of moving that forward so it happens during the trial period. Unfortunately, as Jacque pointed out, right now it really is about six weeks into the process when it clicks.

There *are* good resources out there, Devin's site at BYU being among the best of them, but they're scattered about and you sort of have to know they're out there in order to find them. That's very off-putting and a real disincentive for folks trying to figure out what this is all about.

[Regulae]

Hi all,

Can we "reengineer" LiveCode's learning curve?

I'm one of those folks who started out with Hypercard, and well remember the joy of discovering what was then called Revolution. It was version 1.1, with each successive version extending the programming language and introducing exciting new features, such as Data Grids, sophisticated blendLevels/graphic effects, behaviors, to name a few. Cross-platform deployment also advanced, recently to encompass the Web and, more recently still, the new mobile platforms. As the LiveCode environment has grown, so has the learning challenge facing new users.

LiveCode also aims to appeal to the widest spectrum of users. From people who are (initially) non-programmers, to experienced professional developers. Thus there are different types of newcomers. Let's call a newcomer who has no programming experience "Type 1". They are free of confusing expectations, but that's because, for them, everything is new and potentially confusing. The LiveCode language is especially newcomer-friendly (as was HyperTalk), but there's still a lot to learn, in an environment that offers such powerful deployment possibilities with all the complexity this necessarily involves.

The "Type 2" newcomer is the ex-HyperCarder (like me), who initially feels they have a head start. Stacks, cards, buttons and fields, scripts, messages- all seems familiar. LiveCode script looks familiar e.g. "on mouseUp" ... though the next challenge is learning the much richer LiveCode language (in my experience, the more you learn of it, the more you like it). Then there are those familiar ideas, like backgrounds, that are so much more powerful in LiveCode than in the original HyperCard, but still take quite a bit of getting used to. In the context of so much that is familiar, anything different comes as a surprise- there's certainly some "unlearning" to be done. Of course, given the age of HyperCard, today's type 2 newcomer may be relying more on recollection than on recent use.

The "Type 3" newcomer is already proficient in another language, e.g. Java, and so has the confidence of some programming experience behind them. They are used to looking at documentation, asking questions, problem solving- the "why doesn't this work?" scenario is all too familiar to them. They also bring many trouble-shooting techniques to the learning experience. For them, the LiveCode language can be surprisingly elegant- how much can be achieved with a single line of code. Occasionally, newcomers to the Forum mention this. But still, as anyone who has tried to learn a second language knows, there are always some things that don't mean what you expect, and yet other things which simply don't translate at all. It is almost a form of culture shock, and adaptation can be quite a process.

There may, of course, be more newcomer types, but this will do for now.

In a way, LiveCode has evolved faster than its instructional materials, resulting in a variety of older books, more recent RunRev tutorials, video tutorials, other web sites, in addition to LiveCode's own User Guide and dictionary. Given the breadth of LiveCode's capabilities, the diverse types of newcomers, and the disjoint array of instructional resources, LiveCode's learning curve is naturally a matter of some concern. Cybernicus has suggested that there are existing methods, used in other contexts, which (for whatever reason) have yet to be incorporated into the LiveCode environment. There is the potential to make LiveCode more intrinsically accessible. This is an exciting prospect well worth exploring. We can go further to ask- "Why stop there?". What more might we do to "reengineer" the learning curve (or perhaps, "curves", given the different newcomer types)?

It might be objected that LiveCode is already, as it stands, more "learnable" than other development environments/languages. It's also true that to learn anything new, particularly something that promises such benefits in the longer term, always requires a measure of persistence on the part of the newcomer. But the learning curve which has emerged through LiveCode's evolution need not be considered "fixed". Rather, it is open to deliberate redesign. There is no need to settle for a learning curve that is "relatively good" when it could be made optimal. Given LiveCode's great strengths in so many other respects, it's almost a shame to leave this one unaddressed. I should stress that it would be most unfair to overlook RunRev's own extensive efforts in this area, and I can't speak for the improvements they may already be planning. Even so, with its breadth of capabilities and wide range of potential users, LiveCode's learning curve may call for additional approaches.

We normally think of the LiveCode language as what we find listed in the dictionary- the language we use to write our scripts. However, we can also think of LiveCode stacks/standalones, with their buttons and links and fields and browser objects and players and animations ... the list goes on ... as a rich means of communication. A LiveCode stack is a powerful vehicle of expression. Many existing tutorials (as well as the documentation) are very much a matter of reading (or "telling" the user), and video tutorials provide a way of "showing" things. With a LiveCode stack we can have the user's involvement more self-paced yet active, communicating by providing meaningful experience. The advantage of such an approach is nicely captured in the saying, (variously attributed):

"Tell me and I'll forget, show me and I may remember, involve me and I'll understand"

The attached stack was an initial attempt in this direction. I prepared it in answer to a question on the Forum last year. I confess to much hesitation about re-posting it here, lest I be misunderstood as seeking self-promotion, or pretending to announce some great scripting innovation. This is definitely- most emphatically- not my intention. In the end, it seemed slightly wrong to suggest an idea without offering an example, however inadequate, and rather appropriate that in advocating LiveCode stacks as a means of communication, the idea itself be communicated with a LiveCode stack. I hope it's well behaved.

The noteworthy aspect is that most of the scripting in the stack is used to implement a "discussion" field that can float over the cards, as their content is being viewed/used. The scrolling of the discussion field is synchronised with the user's navigation through the stack, to give them a sense of control of the process. They can go back and forth. Various visual techniques are used with the aim of making the experience intuitively intelligible. The last card contains some thoughts about the approach used.

The answer to the original question on the Forum required few of LiveCode's features, such as browser objects, players, links and animations. Thus the stack only scratches the surface of what might be achieved. One can imagine the discussion leading the user through adding new controls to the card, changing their properties, editing their scripts. The user can be introduced to the IDE and supporting materials in a way that is guided, yet self-paced, supported, yet highly do-it-yourself - "...involve me, and I'll understand". Of course, entirely different approaches may prove superior- so much the better. Perhaps something much better has already been done- I would not be surprised. Still, it does raise the prospect that some of the existing tutorials and documentation, which newcomers currently find very disjoint, might be integrated using LiveCode stacks. Thus the idea is not that existing instructional material be abandoned, but rather, better exploited. Also, when we talk of "reengineering the learning curve", this need not necessarily call for a large scale effort, reworking the entire curve. Perhaps, for the different types of newcomer, certain "critical hurdle points" can be identified- targeting just these points may dramatically change the overall contour of the curve confronting them.

We can summarise:
1. LiveCode has evolved into a powerful cross-platform environment. This sophistication presents an instructional challenge.
2. LiveCode is intended for a wide range of users, from the programming novice to the professional developer. This compounds the instructional challenge.
3. This challenge has long been recognised, and is a matter of increasing discussion on the Forum. The diversity of existing resources leaves many newcomers confused, and doesn't always meet their needs. Unfortunately, they may abandon LiveCode before discovering its benefits.
4. Possibly, LiveCode's learning curve can be reengineered.
5. It has been suggested that there are some existing documentation and IDE methods, used in other software, which could be helpful here. Certainly, this is well worth exploring.
6. We've also seen, from points (1) and (2), that LiveCode presents some rather unique instructional challenges- perhaps we can use LiveCode's unique capabilities to invent solutions.
7. Because LiveCode continues to evolve, the refinement of the learning curve will be ongoing.

Obviously, a successful initiative along these lines would benefit RunRev by expanding their user-base. To be sure, this is an attractive commercial consideration- and fair enough, but perhaps there's more at stake. The Internet revolution has seen information increasingly become common property, and the world is collectively better informed as a result. LiveCode's combination of cross-platform programming power with (relative) ease of use has the potential to unleash new levels of creativity. Innovations which improve LiveCode's learning curve will enable more people to participate in this unfolding creative process. This, it seems to me, promises to be a worthwhile, and somewhat revolutionary, development.

Much of this is speculation on my part. I claim no special expertise or insight, nor do I know how to achieve all that has been proposed. If I only spoke of things I knew how to fully implement, I fear I'd lose the power of speech through lack of practice.

Regards,
Michael

[Cybernicus]

Here's my input in tutorials and documentation: They go from 0 to 120. I mean, really, the geometry manager is part of "basic"? What I've easily found basically jumps from "hello world" to developing a game, with little in between.

The course I'm taking (which I have to say is woefully lacking compared to the BYU course, but a credit's a credit, right?) started with a simple card with a picture, moved on to switching cards and making an ebook, then a simple calculator, and so forth. Livecode would greatly benefit from a series of lessons like that. I happened to be stubborn enough that I jumped in head-first (with the background support of the aforementioned course) and deconstructed and reconstructed a game as a huge learning experience (and an app that I can have my students use), but I can imagine that people without such motivation (and stubbornness) would just walk away in frustration.

Ultimately, Livecode is essentially billed as programming for non-programmers, but it doesn't often feel that way.

Thanks WO, that's exactly what I meant. They go from 0 to 120 without making sure the wheels are on the ground for mile 1 much less the other 119 of the 120 mph. And I wasn't asking for 1 though 119 to be filled in, all I was asking for was a first and second mile per hour (holding with the metaphor). It was very frustrating and I pulled out of bothering with it to wait for my HyperCard manual to come through an E-bay merchant. Turns out that book was sent to the wrong place so now I'm putzing about with this program again with a book I got from the library called "HyperCard 2.2 in a Hurry" by George Beekman. Anyway it really means a lot to hear you say that you could see how other people will just bail. I just go crazy with things that are so casual about whether or not people get value out of what they do. But that's my own crusade. Again, I find your post most consoling and appreciate it. Jim

[Cybernicus]

Ultimately, Livecode is essentially billed as programming for non-programmers, but it doesn't often feel that way.

Yeah, there's a dilemma there. LiveCode has to target both the non-programmer market and the professional developer market and do both well. It's a hard task, and I'm not sure either one gets done well. I'm glad I don't have to cover all that ground myself. I think both markets are viable for LiveCode, and they both need more attention. Probably some more easy-to-get-started stacks available out of the box would go a long ways toward increasing the followthrough rate after the trial runs out. There's an AHA! moment that occurs at some point, and there's more work that could be done in terms of moving that forward so it happens during the trial period. Unfortunately, as Jacque pointed out, right now it really is about six weeks into the process when it clicks.

There *are* good resources out there, Devin's site at BYU being among the best of them, but they're scattered about and you sort of have to know they're out there in order to find them. That's very off-putting and a real disincentive for folks trying to figure out what this is all about.

Truth be told, what I want to do with this software is so limited that I really started freaking out that I was stymied by such basic initial steps. Maybe some other who tried to "help" figured me for a "developer" but I have no plans of learning this software to build applications for other people. I just wanted something EASY that I basically ALREADY understood which would allow me to create a sort of "organic" document of all my ideas for a business so that I'm not just building up a huge volume of linear word processing documents or graphs. I really don't need to "calculate" anything or do animations or produce for new technologies like I-phone etc. I know there are package now where you can basically create your own hypertext documents where they take the form of a web page. But everything I looked into seemed to require programming. All I needed to do was simply flip cards and rudimentary stuff like that. I just seemed to encounter the inability to figure out basic distinctions like why the three kinds of buttons, or what are they looking for with some of these values and boxes on various object properties and hadn't even gotten to programming a button yet. There are a lot of idiosyncrasies with this program on the most basic levels like no context sensitive help, tool tips that merely repeat what the box already says, lack of bitmap text like HyperCard, what to do instead, when I experimented with a field and accidentally deleted it and couldn't "undo" the deletion, finding out you have a lot of limitations that demand that you use fields that there is no help for (like if I want a nice big text on a card with some artistic touches I envision, I found out after hours that it can't be done and that I have to do anything with my style in other programs and import them. Then there were idiosyncrasies about how to get graphics into the stack and not just paste them on a card. I got it to work but I still don't exactly know what I did right to get it to. Another thing was the way the various object property menus work and what does "this stack" mean in relation to what else you could choose.

These are not all crises but hey wound up being so frustrating that I lost the flow of the creative impulse I was tying to follow in turning to this software. I've had to put it down for a week just to reconstruct how I was feeling and remember exactly what I wanted to do with this. I assumed it could not be all that hard to get done what I had to, remembering my experience with HyperCard and Toolbook 20 years ago. But dang, it was a lesson in many many ways on what remains priorities to the software producer and user community.

[Cybernicus]

Hi all,

Can we "reengineer" LiveCode's learning curve?

..Regards,
Michael

Thanks for your comprehensive post, Michael. If I had to single it to one thing it would be making everything that gets a person to actually programming be as transparent as possible. Programming is something very much separate from simply operating within this environment to satisfy the basic requirements of each property inspector and what each choice will mean in terms of graphical representation in stacks and on cards. There can be no one-size-fits-all training vehicle and surely that's a big reason why there isn't one that seems to try. To make sure that the "type 1" person in your scenario makes it to buying a license where from they will have made an investment in a long term pursuit, it must be understood that people need to be led for a short while to face certain problems progressively and linearly so that they can interpret what small milestones they achieve. To jump too far into non-linearity right away gambles with the newcomer. Does anyone actually know how many people try the software and NOT by it? Probably not. There is no one-size-fits-all solution that can take everyone into facing every eventuality proactively but every newcomer can be led through a few simple exercises to face SOME interface issues which may be challenging. I found that there were far too many pitfalls and hurdles just to get though the initial threshold of getting anything done. I'm sticking with it and will resolve things in their own time. But if there were any new commitment by Run Rev to address learning issues, I think it should be on simply "leading" a user into facing interface requirements and what the choices will mean on the card in a stack. There can't be a jump from "Hello World" to "go find something that makes sense". It won't (unless you're really gifted and/or lucky). This will lead people to buy more licenses and perhaps increased "Rev-enue" can go into better documentation and some simple context-sensitive help which could make the difference.

[dglass]

Here's one that seems like it would be pretty painless to implement:

Have the ToolTipText include not just the corollary to the chosen option, but also a short description....

Preferences -> General:
Property Labels are: () Description of option, () Name of LiveCode property

This setting changes both the labels in the various inspectors, and the ToolTipText (hover help) for those labels.

However, for a new user, especially one with little or no experience with other programming tools (particularly those with a visual design interface), neither option is really clear.

Examples:
Focusable/traversalOn - ??
Opaque/opaque - this is supposed to help?

Better:
Focusable/traversalOn - This control can receive focus*
Opaque/opaque - the card background will show through this control
Lock Text/lockText - the user can't change the text

I've actually considered doing this sort of thing to my personal copy of LC, but by the time I know enough about each of the properties to write the blurb, I don't need the extra prodding, and a third-party extension of the IDE like this seems like a non-starter because the people who need it most aren't going to be immediately extending the IDE.

* - not the best example, but I'm sure somebody smarter can come up with something clear and concise**
** - and it doesn't even have to be all that concise if there's another option: Show expanded ToolTips (Yes/No) where 'No' puts the tips back to the 'original'.

[doc]

I believe that dglass makes a valid point up to an extent...

Each and every one of the selectable properties that can be seen in the property dialogs are explained (with helpful examples) in the LiveCode dictionary. The info is not missing.

A better idea I personally believe, is if the LiveCode team could/would link (as in click-able) the property labels directly to the corresponding dictionary entries, which would far simpler in terms of development labor, all the while exceeding anything that might be displayed in the tool-tips alone.

Finally I'll add this, hopefully without being unnecessarily offensive...
At some point, each LC user, regardless of previous experience (or lack thereof), must actually start using the product itself, taking advantage of the many great resources that ARE available to them.

IMNSHO, continually whining and bellyaching about what might be seen only as a personal preference ("It should be like this or that" -or- "I would rather that it was..." -or- "Product X does this and this and this...") is only an excuse for not even really trying.

Offering suggestions for future improvements is a good thing and always should be welcomed. Using those same suggestions as a crutch isn't beneficial to anyone.

What I'm really suggesting is that maybe one should hitch up their britches and take advantage of the resources provided and get on with the relatively short learning curve!

Best regards,
-Doc-

[dglass]

I believe that dglass makes a valid point up to an extent...

Each and every one of the selectable properties that can be seen in the property dialogs are explained (with helpful examples) in the LiveCode dictionary. The info is not missing.

A better idea I personally believe, is if the LiveCode team could/would link (as in click-able) the property labels directly to the corresponding dictionary entries, which would far simpler in terms of development labor, all the while exceeding anything that might be displayed in the tool-tips alone.

Now, that's a good idea! Very slick.

[Cybernicus]

..Finally I'll add this, hopefully without being unnecessarily offensive...
At some point, each LC user, regardless of previous experience (or lack thereof), must actually start using the product itself, taking advantage of the many great resources that ARE available to them.

IMNSHO, continually whining and bellyaching about what might be seen only as a personal preference ("It should be like this or that" -or- "I would rather that it was..." -or- "Product X does this and this and this...") is only an excuse for not even really trying.

Offering suggestions for future improvements is a good thing and always should be welcomed. Using those same suggestions as a crutch isn't beneficial to anyone.

What I'm really suggesting is that maybe one should hitch up their britches and take advantage of the resources provided and get on with the relatively short learning curve!

Best regards,
-Doc-

Saying you're hopefully not being unnecessarily offensive does not excuse being unnecessarily offensive. You have your experience and other people have theirs. These are legitmate issues we all discussed here. Your swaggering remarks about "britches" and "relatively short learning curves" punctuated with expclamation points add nothing whasoever EXCEPT unnecessary offense. Was it good for you? Keep it next time. No one needs your malevolent snottiness. a/h

[Dixie]

Cybernicus…

I second Doc's post… If you want to learn LiveCode, all the material to get yourself up to speed is there… perhaps it is just not presented in a way that you would like… but please, enough of this continual stream of complaints about LiveCode's failings as well as complaints directed towards people who have been trying and failing miserably to get you pointed in the right direction…

LiveCode might have some DNA from HyperCard, but it has evolved… it is a different beast… You are confronted with the same materials that everyone else has access to when they start to learn LiveCode and I have never heard such whingeing on this forum before…

But I agree, Doc is off the mark with his remarks that 'one should hitch up their britches … and get on with the relatively short learning curve'… What he perhaps should have said is 'It is time to shit or get off the pot!'

I am really getting tired of you 'having a go' at the posters on this forum who have been trying to help you… mmm… but thinking about it, perhaps Doc's remarks are not too wide of the mark and you might find yourself pleasantly surprised how 'short the learning curve really is' if you spend as much time trying to get a handle on LiveCode as you do trying to run it down…

John Dixon

PostScript :… Ok, ok… Klaus, Richard Gaskin… you can shoot me now!

[FourthWorld]

PostScript :… Ok, ok… Klaus, Richard Gaskin… you can shoot me now!

No shooting from this gun. Learning any language is simply going to take some work, and there are helpful resources for all them but few shortcuts to avoid active experimentation.

I've been spending the last couple years bringing my JavaScript chops up to speed, and while I'm now feeling comfortable with it it's not nearly as strong as my two decades with LiveCode and related dialects. It's taken a lot of work just to get where I am with JavaScript, in spite of the nearly unmatchable variety of learning resources out there.

At the end of the day, no matter how much I read, I still need to roll up my sleeves, cut some code, make a lot of mistakes, and fix 'em.

I've never seen any other way to learn any language.

With all the time spent with client-sever apps I decided to set up an Ubuntu server here in my office as a test bed. For a relative Linux newbie like myself it's a lot to learn, and even somewhat simple tasks like setting up a custom Drupal install require some experimentation to get it right.

But I decided at the start that no matter how broken I make things, I'm going to resist the temptation to reinstall the system. When you muck things up as badly as I have it's a strong temptation and sometimes the smart thing to do, but as a learning experience it compromises the opportunity to learn how systems fail and how to revive them.

I've been learning a lot with this new server, and while it's not always been easy and occasionally not even fun, it's certainly been educational.

Now I can move around on my deployed servers with confidence. Scar tissue is thicker than skin.