I agree with you 2010/3/19 Catherine Lathwell <[email protected]>: > 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 >
-- Björn Helgason, Verkfræðingur Fornustekkum II 781 Hornafirði, t-póst: [email protected] gsm: +3546985532 sími: +3544781286 http://groups.google.com/group/J-Programming Tæknikunnátta höndlar hið flókna, sköpunargáfa er meistari einfaldleikans góður kennari getur stigið á tær án þess að glansinn fari af skónum /|_ .-----------------------------------. ,' .\ / | Með léttri lund verður | ,--' _,' | Dagurinn í dag | / / | Enn betri en gærdagurinn | ( -. | `-----------------------------------' | ) | (\_ _/) (`-. '--.) (='.'=) ♖♘♗♕♔♙ `. )----' (")_(") ☃☠ ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
