Re: Retraining robots
"Ken Kahn" <[email protected]> Sat, 20 Mar 2004 14:32:03 -0800
| Newsgroups | gmane.education.weblabs.requests |
|---|---|
| Message-ID | <0cc001c40ecb$2d0db700$997ba8c0@LAP68> |
Here's a summary of a meeting I had with Gordon and Yishay on this topic last Monday: The minimal change that we agreed would address these issues is that when retraining you see the record button from time travel. The mouse cursor becomes visible and all you can do is use the mouse to click on the record button to take over. So retraining acts like a special case of time travel where you are replaying and may want to record over part of it. I think we agreed (this is almost a week later) that if you do nothing then when the robot finishes redoing his old training you still have to click on the record button to continue. Sound reasonable? Best, -ken P.S. This enhancement will not make it into the next release. ----- Original Message ----- From: Gordon Simpson To: 'Weblabs Requests' Cc: Celia Hoyles Sent: Wednesday, March 10, 2004 5:14 AM Subject: RE: [WebLabs-requests] Retraining robots Hi, Comments inline... > First off ,there is a confusion here about mouse movement -- > it has zero effect during retraining. So all the kids need to > be told is don't click any buttons (on the mouse or keyboard) > until they are ready to take over. I wonder if given those > instructions whether the interface needs to be made more > clever or not. You're right - the user has to press a mouse button or key to take over. Perhaps part of the problem is that we weren't clear enough explaining how retraining works and that clicking a mouse button or key 'takes over control'. I actually suspect that some kids may have clicked the mouse to stop the robot running around doing things that they weren't controlling! Our kids tend to be quite impatient. And to be fair, it's the first time they tried retraining and some level of confusion can be expected for novice users trying new features etc. But I maintain that the interface for taking over control is non-intuitive. In the rest of toontalk, when you move the mouse your hand/character/ helicopter/or robot (if in a thought bubble) moves. During retraining, moving the mouse does absolutely nothing. This (the absence of the usual/expected mouse effect) is the ONLY cue that the robot is replaying what he had been previously trained to do. It's quite confusing to suddenly find that moving the mouse does nothing, and a typical response might be to assume something has gone wrong and to click a button etc (a responsive mouse pointer is a sort of expected windows feature). There is also no cue at all to tell you that clicking a button or pressing a key will 'take over control'. Time travel doesn't suffer from these problems. Moving the mouse moves a mouse pointer. Taking over control is achieved by explicitly clicking on the record button. > In this particular case you could tell the kids to retrain > the robot to do additional things afterwards so they just sit > back and watch until the robot stops and then they have > already "taken over". That's exactly what we wanted them to do. We showed how to do this on the projector before kids tried it themselves. But somehow, about half the kids still pressed a mouse button or key before the robot did his thing and then were confused when they ran the robot and it only did the action they taught it, not including the stuff it was previously trained to do. > Regarding problem 1 (that it isn't so clear you are retraining vs. > training) I don't see it as an issue for this activity. Is it? It's true that the kids had only one robot, sucked it's thought bubble and then entered retraining - so they shouldn't have thought the robot was untrained. But I still think that if the robot looked different to an untrained one, kids MIGHT be less surprised/ confused that the robot started doing things when they enter retraining. But perhaps if the interface for taking over control was altered then this wouldn't be necessary. > P.S. I was sceptical of this idea of a task involving > retraining someone else's robot like this but it seems like > it has potential in this case. We felt it worked pretty well, apart from the confusions about retraining under discussion of course. > ----- Original Message ----- > From: "Yishay Mor" <[email protected]> > To: "Ken Kahn" <[email protected]> > Cc: "Gordon Simpson" <[email protected]>; "Weblabs > Requests" <[email protected]>; "Celia Hoyles" > <[email protected]> > Sent: Wednesday, March 10, 2004 11:27 AM > Subject: Re: [WebLabs-requests] Retraining robots > > > > Inline. > > > > Ken Kahn wrote: > > > > > Hi all. > > > > > > I'm not sure that retraining is very important. I think the best > style > > > (both cognitively and practically) is to keep your robots > "small". > > > Lots of simple robots is easier to think about and easier to > > > manipulate and edit than a few complex robots. If a robot > is trained > > > to do only a handful of steps then training over again > rather than > > > retraining is straightforward. And the repetition may be > helpful in > > > understanding the robot better. Kids don't seem to mind the > repetition > > > as much as adults. > > > > You're right about this. We're not thinking of having kids > go through > > long debugging sessions using retraining. However, we did find it > useful > > to use retraining as part of a structured task. Kids are > given a robot > > that divides (a copy of) n by d, and sends out the result. > Their task > is > > to change this robot so that it generates the reciprocals. > They do it > by > > retraining. Using this approach, the TT programming is aligned with > the > > mathematical idea under investigation. See the task template at: > > > http://www.weblabs.org.uk/wlplone/Members/ioe/my_reports/Repor > t.2004-03-03.3222/index_html > > > > We also pilot a new methodology in this template, which we call > > task-in-a-box. Let's talk about this on Friday. > > > > > Regarding problem 1, there are some differences and there is an > issue. > > > Many people name robots after training them - in that case only > > > trained robots have names (either generated or edited). Beginning > > > rather recently the drop feedback now makes it clear whether the > drop > > > is back in the thought bubble (because it was removed to edit more > > > easily) or the drop is to the robot to retrain. In the first case > the > > > thought bubble wiggles rather than the whole robot. > Untrained robots > > > don't make this distinction. Also for the most part > people grab an > > > untrained robot when they need one so there isn't much risk of > confusion. > > > > IMHO, these distinctions are too subtle for most mortals to notice. > > > > > Regarding 2 I think this would be useful but needs to careful > design. > > > I think reusing the time travel controls would be confusing. Not > > > convinced that this should be a high priority enhancement. > > > > It all depends on how extensively we want to use retraining. I find > the > > time travel metaphor very intuitive in this case. Instead of moving > the > > whole world back in time, you're only sending this one robot back to > the > > point when it was trained. Alternativly, or as an intermediate > solution, > > when I go into retraining any mouse movement will invoke > time-travel, > > and when the robot completes its run time travel is > invoked. If I want > > to retrain, I click the record button. If I accidentally > touched the > > mouse, I hit play. > > > > - Yishay > > > > > ********************************************************************** > > Yishay Mor > > > http://ioewebserver.ioe.ac.uk/ioe/cms/get.asp?cid=4381&4381_0= 7303 > [email protected] Ph +44(0)20 7612 6963 F +44(0)20 7612 6964 > AIM,Yahoo: yishaym; Jabber: [email protected]; ICQ: 179772099 > > If this helped you, please take the time to rate the value of this post: > http://svcs.affero.net/rm.php?r=yishaym > ********************************************************************** > celebrating 100 years of excellence in education > www.ioe.ac.uk/centenary > > > > ------------------------------------------------------------------------------ Yahoo! Groups Links a.. To visit your group on the web, go to: http://groups.yahoo.com/group/WebLabs-requests/ b.. To unsubscribe from this group, send an email to: [email protected] c.. Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.