I'd prefer to keep it in the basic mode.
I've just looked back at what I said about this last year - and I still agree with myself! At the risk of boring you all - I've included it again below... Also my (still limited) experience with children using VPL is that beginners don't really struggle with the the timer. One more thought is that since 1.4 now allows multiple actions per event, the complexity overhead for experimenting with the timer in basic mode is much reduced. i.e. one can just drop a 'timer start' in as an additional action touch button -> start motor, change colour (green) , start timer timer alarm -> stop motor, change colour, (red) This to me feels like a natural progression. A situation I have frequently seen is first time users wanting to time limit the motor action - i.e. they code a trigger for the motors then panic when it doesn't stop. >>> BEGIN - this is what I wrote before >>> My instinctive feeling and experience so far is that the timer should be available in basic mode. The following is mostly based on my personal opinion. I have been using VPL with children in school but I don't think I've seen a large enough sample (time / numbers) to draw evidence from. That said, I've not seen any children confused by it to the extent that I have thought that it shouldn't be in basic mode. >>The argument for moving it to the advanced mode is that it is not following the same "instantly event-driven" paradigm as the other basic blocks. True - and this can be challenging for the beginner. However, this argument seems to me to be more about categorisation than utility. The icon design for the timer clearly communicates visually that there is going to be some kind of delay or wait involved. (The most common beginner "error" I have seen with the timer is wanting to use it as a "sound alarm" action) >>The argument for keeping it in the basic mode is that it is easier to understand than states... Yes, and I think this point is really important. The timer is easier to understand than states *and* it naturally provides a bridge towards using and understanding states. A common "basic use" of the timer is to produce a temporary implicit state. So that the user can produce an A then B sequential behaviour. touch button => motors on , start timer timer alarm => motors off So - they are already thinking about states - they just don't know it yet. Having the timer available in the basic palette invites the user to play with it. Their first steps might be uncertain but they will learn and adapt through tinkering. Once they gain some proficiency they will want to extend its usefulness. The most common thing I have seen is the instinct to add another timer in the expectation that they can be chained together in a sequence. Then they realise that they need to be able to distinguish between these "two" timers - which will require states... So using the timer in basic mode naturally leads to an appetite for something not available in basic mode - I think this is a useful "breadcrumbing of the trail" to more complexity. The timer also introduces the very important concept that events do not just originate externally to the robot. Events can be under code control. It is good to have this visible as early as possible. >(the timer) ...allows relatively simple and quite interesting behaviours I strongly agree. The timer opens the possibility of exploring interesting behaviours in basic mode but *without* the added complexity overhead of managing states. The user can (safely) acquire some experience and mastery of the timer in a simpler environment before having to contend with states as well. >(the timer)...is very useful in conjunction with the music block. Particularly to "debounce" an event trigger (button or proximity) for a music block touch button => start timer timer alarm => play music In summary. Yes I agree that the timer is different to the other basic blocks and that adds "difficulty" to basic mode However the timer a) is incredibly useful as a stepping stone to bridge the *learning progression* towards the advanced mode. b) enriches basic mode (but without being too complex) <<< END <<< David On Tue, May 26, 2015 at 7:47 AM, Stéphane Magnenat <[email protected]> wrote: > Hello, > > At some point during the development of VPL 1.4, I moved the timer blocks > to the advanced mode on the basis of some internal consistency (these are, > like states, non purely reactive). I got some feedback from people who > would prefer to have it in basic mode. > > We will release 1.4 soon and I am wondering what you prefer, to have it in > basic or advanced mode? > > thank you, kind regards, > > Stéphane > > -- > http://stephane.magnenat.net > > _______________________________________________ > Aseba-edu mailing list > [email protected] > https://mail.gna.org/listinfo/aseba-edu >
_______________________________________________ Aseba-edu mailing list [email protected] https://mail.gna.org/listinfo/aseba-edu
