It sounds like you guys have come up with some sort of consensus that is something like, "It's OK if the animations are too fast to grasp the first time because people can watch them again".
I'm the dissenter, for sure. In my field at least, I've never seen any animation praised for being too fast to understand the first time around. Even if you watch TV, and see that The Simpsons is jam packed with funny references, the basic story is crystal clear on your first viewing. About that covering plus: What's bugging me is that you obscure the number I'm thinking about while following your operation in my head. I'm mentally checking to see if I "get it" while I follow along. The next steps clarify, but you've already interrupted my train of thought. I'm not convinced you need much movement at all, to be honest. Just some modest graphical indication to signal that you are applying the operation in the moment. A bounce movement, a halo, a sparkle all do this. (Which is why Iiked the annimation no one else liked because it is successful in indicating "pay attention here" in an appropriate way). The best best best animation of all your animations is the one where the graph animation illustrates the actual mathematical point you are making. Here there is agreement between picture, the movement and the meaning you are communicating. Consistent, elegant & economical. C On Wed, Mar 17, 2010 at 8:40 PM, bob therriault <[email protected]>wrote: > Excellent points C, > > Although all are important, the one I would like to hone in on is the > second, which is what bugs you :) > > The challenge I see with transforming numbers visually is that a 3 morphing > into a 5 doesn't tell you much about addition. Also if we put the 2 in front > we have a 2 morphing into a 5 for the identical operation. My solution to > this point has been to pop out the operation to obscure the transformation, > which is what I believe bugs you. I can understand that, I just haven't > visually come up with a way yet to create a transformation that is both > meaningful and functional with regard to scalars and matrices. Have I got > the essence of what is bothering you, or is it something else? I must admit > I am also putting emphasis on the final 'frame' at the end of the animated > section, since if this has no meaning for the learner, as they study it then > it weakens the preceding animation greatly. > > Cheers, bob > > ps. I think you may underestimate the persistence of J learners. The power > of the language and the elegant solutions it reveals to problems provides > strong motivation. Having said that, of course the goal of the animations is > to flatten the learning curve, so we are not testing learner's motivation > levels in trying to understand the animation. We have the J dictionary for > that. :) bt > > On -Mar17-2010, at -Mar17-20103:58 PM, Catherine Lathwell wrote: > > > Ok - firstly - I wouldn't put ANY stock in my willingness to watch the > > animations over and over - I'm extra motivated because I'm making a film > > about APL. I would watch your animation 10 million times if that's what > it > > took to figure out what you were getting at. If my objective was to > learn, > > I most probably would not be this persistent. > > > > On the other hand - I would put a lot of stock in what bugs me. I have a > > trained eye - and have been taught to pinpoint discordance. People > without > > visual training are likely to point something else, usually close by. > When > > you get to the point of field testing, what will be important is what > people > > do - not necessarily what they say. But, I'm sure you know all this. > > > > In terms of background knowledge - yes that's all true. But I meant to > make > > a larger cultural point - we collectively learn to "read' what is on our > > screens in a certain way (more or less) by convention. This is a whole > > disciple in and of itself. And I think this is closer to what you are > > working against with the low minus. > > > > C > > > > > > > > On Wed, Mar 17, 2010 at 4:25 PM, bob therriault <[email protected] > >wrote: > > > >> Thanks as always for the feedback Catherine, > >> > >> I think the most important fact that I take away from your experience is > >> that you were able to understand something through repeated viewings, > even > >> though the number of examples provided made this a frustrating > experience > >> (especially when the animation hides the magic behind an operator > image!). > >> Past that I don't think I would extend this to every case of > >> misunderstanding. You are absolutely right that the background of the > >> learner affects how well they learn new material. In fact, I have heard > some > >> argue that most learning is just the learner repackaging previous > knowledge > >> and extending it into a new domain. The animations would/should/could be > >> accompanied by written text that may set the learner up for clearer > >> understanding. On the other hand, viewing the animation first may > provide a > >> higher level conceptual understanding to support follow up reading of > the > >> written portion. > >> > >> Cheers, bob > >> > >> On -Mar17-2010, at -Mar17-20109:45 AM, Catherine Lathwell wrote: > >> > >>> About that underscore thing... (*sigh* blush) > >>> > >>> I don't think my issue can necessarily be generalized to apply to other > >>> differences. So, I'm not completely sure that it makes sense to extend > >> this > >>> experience to all differences in J. (I don't want to preclude this, by > >> the > >>> way. I just don't think this case is conclusive). > >>> > >>> Let me explain why: > >>> > >>> We get used to reading things that we see a lot in a certain way. > So... > >> My > >>> initial reading of the under score is influenced by the fact that I > have > >>> looked at names that contained underscores. Remember when it was > >> customary > >>> to use them in file names? So lead by that association, my mind went, > >>> *doink* right to a name reference. And this of course, did not > compute. > >>> > >>> > >>> On Sun, Mar 14, 2010 at 2:04 PM, Skip Cave <[email protected]> > >> wrote: > >>> > >>>> Brian said: > >>>> > >>>> Why have the + signs in the last two examples when the arrows suggest > >> the > >>>> transition? > >>>> > >>>> Skip says: > >>>> I proposed an alternate option in my previous post. Rather than > popping > >>>> up the plus signs on top of the number, just leave the plus sign where > >>>> they belong - to the left of the number. Move the number as a ghost on > >>>> top of the plus, and then take the conjugate action. > >>>> > >>>> Brian said: > >>>> > >>>> Why have array and vector examples when the verb is scalar, anyhow? > >>>> Why not reduce all of the examples to scalars except maybe to > >>>> economize on time? The nonscalar activity is better covered in a > >>>> generic section on how verbs deal with higher or lower rank data, > >>>> except where a verb does this in a special manner as does the dyad > >>>> Append and its relatives. > >>>> > >>>> Skip says: > >>>> > >>>> This is an issue that I have also been struggling with. Just how much > >>>> information about a primitive should be in each NuVoc description? The > >>>> basic problem is the fact that NuVoc is a Reference/Tutorial. The key > >>>> word here is Reference. That means that a novice, who sees a J > >>>> expression somewhere, can jump into the NuVoc reference on primitive > >>>> descriptions at any point. So, the first exposure a newbie has to J, > >>>> could be any one of the primitive descriptions in the NuVoc. How > should > >>>> we handle this? > >>>> > >>>> This issue was brought home to me in the recent posts by Catherine > >>>> Lathwell. Catherine didn't understand why there was an underscore in > >>>> front of the numbers in some of the video examples of the conjunction > >>>> primitive. The underlying concept that underscore defines negative > >>>> numbers is a new concept to most people, and will cause confusion if > it > >>>> used in an example, before any explanation is given. > >>>> > >>>> That means that we either need to repeat general concepts in every > NuVoc > >>>> description, or we have a "read this first" section that we recommend > to > >>>> the novice before jumping into the NuVoc. Given the theory that > >>>> "learning is best accomplished by repetition", having concepts > presented > >>>> multiple times is not necessarily a bad thing. Perhaps a "read this > >>>> first" AND additional reminders or repeated examples in the primitive > >>>> descriptions would be a the best approach for a reference/tutorial. > >>>> After all, we are trying to take a new approach to the vocabulary, > >>>> making it more approachable for the novice, and not trying to match > the > >>>> functionality of the original vocabulary. > >>>> > >>>> I believe that the two Rs, reminders and redundancy, are the main > >>>> differences between a definition and a tutorial. The goal of a > >>>> definition is to specify all of the aspects of a function thoroughly, > >>>> with minimal redundancy, and with the assumption that all other > concepts > >>>> except the one under discussion are already understood by the reader. > A > >>>> tutorial is intended to teach the aspects of a function, which will > >>>> likely include considerable redundancy in the teaching process. The > >>>> redundancy will entail displaying different aspects of the same > concept, > >>>> as well as reminding the student of other new concepts when they occur > >>>> in the teaching process of one specific concept, all to reinforce > those > >>>> concepts. > >>>> > >>>> I have come to the conclusion that my problems with the current J > >>>> vocabulary aren't with its' conciseness, as much as it's lack of > >>>> reminders and repetition. I believe that the original vocabulary was > >>>> written to provide a complete specification of each primitive, with no > >>>> requirement for redundancy, and with the assumption the the reader has > >>>> perfect recall of all major J concepts except the one under discussion > >>>> (which is certainly NOT me). > >>>> . > >>>> In fact, redundancy and reminders in the current vocabulary were > frowned > >>>> upon, as they detract from the pureness and efficiency of the > >>>> definitions. The whole J vocabulary format was honed to remove all > >>>> elements of redundancy, to provide a clean and clear set of > definitions > >>>> with minimal repetitive information of any sort. The original > vocabulary > >>>> succeeded spectacularly in its goal of defining the full J language in > a > >>>> minimal form. Not surprisingly, the result was also an exemplary > tribute > >>>> to conciseness. > >>>> . > >>>> Unfortunately, I believe that that is exactly the wrong approach to > >>>> teaching new concepts, which seem to be a majority of the concepts in > >>>> the J syntax. A new concept should be introduced with very simple > >>>> examples, which are then gradually extended to more complex examples, > >>>> until a fairly thorough understanding of the general concept has been > >>>> conferred. The reader should be reminded of those new concepts again, > >>>> when they arise in new situations. Conversely, when a different new > >>>> concept appears in the process of explaining a specific concept, a > >>>> reminder of how that other concept works, is very helpful for the > >> novice. > >>>> . > >>>> This brings me to the conclusion that each primitive in the NuVoc > should > >>>> step through a fairly extensive set of examples of that primitive's > >>>> usage, going from simple to complex. Video graphic examples would > help. > >>>> Along the way, there should be reminders of any other new concepts > that > >>>> arise, which may not have been thoroughly assimilated as yet by the > >>>> newbie (underscore = negative). > >>>> . > >>>> It would be interesting to make a formal list of the general syntactic > >>>> concepts in J that are unique to it, or at least unique to those who > >>>> unfamiliar with other array languages such as in APL, K, QNial, etc. > >>>> This list would be a good starting point for the "read this first" > >>>> section of the NuVoc, as well as a reminder for those writing the > >>>> primitive descriptions, as to when to provide a reminder about other > new > >>>> concepts for the newbie when they occur in the tutorial process. For > >>>> example, the conjunction video could have a little balloon tip pop up > >>>> above the underscore the first time it appears, to remind the newbie > >>>> that underscore indicates a negative number. > >>>> > >>>> A start at the "new concept" list would be: the various number > >>>> representations (negative, complex, extended, etc), right-to-left > >>>> execution, operator precedence, monadic/dyadic functions, > >>>> multidimensional extensions to functions, rank, etc. I'm sure that > there > >>>> are many more, but I have to go for now. > >>>> . > >>>> Skip Cave > >>>> . > >>>> Brian Schott wrote: > >>>>> Bob, > >>>>> > >>>>> Yes, I like the most recent animations. Here is some of my thought > >>>> process. > >>>>> > >>>>> > >>>>> > >>>>> Why have array and vector examples when the verb is scalar, anyhow? > >>>>> Why not reduce all of the examples to scalars except maybe to > >>>>> economize on time? The nonscalar activity is better covered in a > >>>>> generic section on how verbs deal with higher or lower rank data, > >>>>> except where a verb does this in a special manner as does the dyad > >>>>> Append and its relatives. > >>>>> > >>>>> Shouldn't the animation focus on what the target does (e.g., 1r2 + _6 > >>>>> in the case of Plus) and what it does not do (e.g., 2 + 'a' in the > >>>>> case of Plus)? > >>>>> > >>>>> Great work, everybody, especially, Bob. > >>>>> > ---------------------------------------------------------------------- > >>>>> For information about J forums see > http://www.jsoftware.com/forums.htm > >>>>> > >>>>> > >>>>> > >>>> ---------------------------------------------------------------------- > >>>> For information about J forums see > http://www.jsoftware.com/forums.htm > >>>> > >>> > >>> > >>> > >>> -- > >>> Catherine Lathwell > >>> http://www.aprogramminglanguage.com > >>> ---------------------------------------------------------------------- > >>> For information about J forums see http://www.jsoftware.com/forums.htm > >> > >> ---------------------------------------------------------------------- > >> For information about J forums see http://www.jsoftware.com/forums.htm > >> > > > > > > > > -- > > Catherine Lathwell > > http://www.aprogramminglanguage.com > > ---------------------------------------------------------------------- > > For information about J forums see http://www.jsoftware.com/forums.htm > > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > -- Catherine Lathwell http://www.aprogramminglanguage.com ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
