Looking for a defined path to learn Rev (for new users)
jim at visitrieve.com
Thu Nov 19 07:52:57 CST 2009
It seems to me that your are trying to lead horses to water, who are neither
thirsty nor want to drink. ;-)
But you raise an interesting point. We talk about the world embracing
revTalk and revlets because the language is so easy. And, indeed it is. But,
when I think back to when I first found rev, the major paradigm shift was
not the language, but the concept of stacks and cards and how this equated
to a windowed GUI. And, had I not had 15 years of extensive programming
experience in another rev, called Revelation, which is PICK on the PC and
which is very, very similar to rev in that it is a scripting language with
chunks, no variable typing, compiling is at the individual script level, so
you run and program at the same time, and many, many other similarities, I
would have also probably had to go through a paradigm shift with the concept
of chunks and where to put or organize scripts.
So, assuming there are programmers who know how to program in other more
traditional programming languages, it's not the revTalk language itself that
is the major barrier. It's not a great leap to move from using equal signs
for variable assignment to using "put," or using "is" instead of a double
equal sign. And certainly not having to use line ending characters like
semicolons or bracketing blocks of code using curly brackets is freeing and
a no brainer to embrace.
The leap is in the structure and not the language. So while I think your
"course outline" rightfully starts out with stacks and cards, I think, more
than how to create, the focus in the beginning needs to be on the "theory"
of stacks and cards and how these equate to the structures they are already
Next, needs to be the theory of chunks and variables and then followed by
theory of scripting and where to place blocks of code and what makes this
all work or ties it all together, which is the message path. Also, before
you get into objects you need o cover the theory behind commands and
functions and how, in general, scripts are organized.
I think without making this paradigm shift first, a programmer used to top
down or OOP programming will just feel like a stranger in a strange land and
will not "hear" your lessons on buttons and fields because he will be
sitting there still trying to get his bearings. So, I think you need focus
on the lay of the land first. Once a programmer has this down pat, the rest
is easy and almost doesn't have to be taught because there is so much
documentation that can easily be looked up for syntax and details.
Also, you don't have to write all of this from scratch. Much of it is
already available and just needs to be pieced together for your particular
As I say, you raise an interesting point, because this applies to not just
your fellow teachers, but all those we expect to embrace revlets and
Aloha from Hawaii,
Alejandro Tejada wrote:
> Previously, i have wrote about my fellow teachers that
> i have invited to use RevMedia in their classes.
> If you read those comments, you had learn that
> they expect to receive training from the source,
> from Runrev, not unlike Microsoft and Adobe
> offers with their certification programs.
> The idea of learning on their own, do not attract
> too many of them. I know that this is the result of
> previous experiences in trainings for other softwares.
> This training should be offered in teacher's
> native language. Although, revTalk should be keep
> as an English-like programming language, without
> trying to translate commands, functions, handlers,
> messages and tokens to another languages.
> (Different of Apple Computer, that actually localized
> HyperTalk to many languages)
> These teachers actually want that RevMedia, have an
> interface more similar to Office programs like Word or
> PowerPoint. The idea of scripting visual effects for
> transitions from a card to another, or hiding or showing
> a control seems so alien to them, that i suspect that
> this useful feature (for their specific kind of work), would
> be underutilized or unused at all.
> Now, i am looking for comments about this idea:
> To make easier for Teachers (or users), to know in which level
> of expertise they stand, divide clearly the learning experience
> in different levels, just like HyperCard do.
> The following paragraph was copied from this page:
> There are 5 user levels within Hypercard. The top most level,
> and easiest to use, is Browsing. This allows the user to navigate
> through Stacks and look at information but not to add or modify it.
> (My comment:
> Given that Rev is multiplatform, i should add another
> ability to this level that should be carried to others levels:
> The ability of making clear and understable reports of failures or
> malfunction of stacks to their authors, using screenshots and
> written reports. This is really important and should be so easy, that
> do not become a burden.)
> The next two levels Typing and Painting allow the user to add or modify
> written and graphic information. The last two levels are Authoring
> and Scripting.
> (My comment:
> The Authoring level requires very good tutorials about
> each part of Rev interface, because, as i wrote before, many Teachers
> expect to take advantage of their experience using Office Software,
> they learn to use Rev. In fact, editing text in Rev seems (to many of
> really "primitive", because they compare this task with their
> in other programs. Rev needs to add menu items for common text
> transformation functions like Uppercase or Lowercase, Sentence Case,
> bulleted list, etc. or an accessible plug-in method to add them to a
> My approach to tackle this fear to authoring have been teaching them
> 1) how to create a stack
> 2) how to create cards (i told them that these are pages...)
> 3) how to navigate between cards (and their visual effect transitions)
> 4) how to change stack and cards properties (size, background colors,
> etc. This part serves to teach them about inheritance of properties.)
> 5) how to create fields, buttons, image canvas (yes, if you could paint
> on them is an image canvas), vector graphics, etc.
> 6) Changing key attributes of these objects (Some key attributes, not
> 6) how to import text, images and graphics.
> 7) how to hyperlink (text hyper linking should be a lot easier for
> 8) how to show and hide controls (Now they learn that all these objects
> are called controls inside RevMedia)
> 9) how to group controls and show them in different cards
> 10) Optimizing and reducing the Size of stack content.
> Final Project: Choose one of the Gutenberg Project ebooks and
> convert many of their chapters in a stack that shows concepts
> like: multiple cards, hyperlinks, text formatting, optimal use of
> visual effects transitions, groups placed in multiple cards, use of
> colors, textures and blends.
> This is my what i want to teach them to learn authoring in
> RevMedia. Did i miss some important points (that they should
> learn) in previous description?
> About reaching the Scripting Level, i could tell you the reactions that
> i have observed when i show them five binders of printed documentation
> from Rev dictionaries and other materials. (Notice that i have not
> all documentation available.)
> My favorite remark: "Do you actually expect that i learn all this to
> this program?"
> Obviously the answer is no, but i bet that this is the reaction of many
> when they learn about the extension of the revTalk language.
> I believe that they should learn to comment and debug other
> people's code, while they start learning to write their own handlers.
> By any chance, Have you seen the expression of fear when a newbie
> choose "Quit" from the script editor and the whole program closes?
> (He was expecting to "Quit" only the task that he was doing, that is,
> quit scripting a control in the stack)
> I believe that we could make a stack that "guides" newbies in this task
> of commenting other people code.
> I would like to read comments on the Authoring part, because
> this is the topic of the tutorials i am working now.
> Thanks in advance for your comments!
> View this message in context: http://n4.nabble.com/Looking-for-a-
> Sent from the Revolution - User mailing list archive at Nabble.com.
> use-revolution mailing list
> use-revolution at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
More information about the use-livecode