RE: 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

<*> To visit your group on the web, go to:
     http://groups.yahoo.com/group/WebLabs-requests/

<*> To unsubscribe from this group, send an email to:
     [email protected]

<*> Your use of Yahoo! Groups is subject to:
     http://docs.yahoo.com/info/terms/