first pass // second pass // final evaluations
Teacher's Pet: First Pass
by Jason Civjan
First off... if anyone likes this or a related idea, I'm open and could enjoy
working with others...
the knowledge:
The system I propose will teach children the fundamental concepts of programming
(such as using code blocks) as well as how to actually write code. They would
also learn the whole PROCESS of programming, from conceptualization, through
design and into implementation. This system will also help foster the desire
for the children to learn the material and possibly create a life-long excitement
about the subject.
the audience:
I will focus on late elementary-middle school aged (4th-8th grades) kids.
the environment:
Teacher's pet would be incorporated into a classroom environment, which would
include computers for every 2-5 children, an instructor and the actual pet
device(explained later).
the system:
intro:
Imagine this... a 4th grade classroom and the children are filing into their
second period, Computer Programming I class. The instructor, Mrs. Poole, tells
the children to quiet down and find a seat. Little Bobby looks around the
room and sees four large, round tables, each with five chairs and a computer
station. Bobby finds an empty chair at the closest table, with his friends
Eric, Steve, John and Ted. Ted is the first one there and takes the seat in
front of the computer screen.
"Class! Let's get situated! I have someone I want you to all meet!"
"C'mon, rex!"
Bobby turns his head around to see what Mrs. Poole is up to.
Mrs. Pool takes out a plastic bone, and wiggles it in front of her. As she
does this, Bobby's eye catches a small, cat-sized robot quickly rolling towards
her... It has a large light blinking joyously from it's top and it is letting
out a cry of "wheeeeeeeee!"
Mrs. Poole explains that Rex is this is the class pet and what this class
is going to do is work in groups to teach Rex some tricks this year. She further
explains that she has simply pre-programmed Rex to come to the bone when she
wiggles it and to blink his headlight when he hears his name. Furthermore,
she has made it so that whenever he is rolling at a certain speed, he will
let out his little scream...
"wow!" Bobby exclaims and asks if he can take a closer look at Rex...
this is going to be a great class!
Rex
Rex is a robot. He has wheels to roll around on and has the hardware that
enables him to jump and roll over. there are also slots to add a variety of
sensors, lights, etc...
He also has an input that allows him to be connected to the classroom computers
to have information downloaded to him.
He is usually happy and zipping around, but if someone puts in a code that
doesn't make sense, he slips into sick mode and doesn't play until someone
in the class finds the problem and corrects it(they are then the ones that
get to have their voices on Rex's audio tracks)...until the next problem.
Also, sometimes, Rex just gets sick for no reason at all(well...the teacher
decides this) just to have the kids go through the code and try to find the
problem... No new tricks are taught until Rex is feeling up to it!
the software
All of the computers have custom software that allows the children to program
tricks for Rex to perform and to look at all the tricks that Rex has already
been programmed with.
The software layout is, in one mode, an empty workspace with menus on the
top and right side of the window. The menus on the right side of the layout
contain pre-programmed, building blocks of code, in the form of buttons. Under
the menu: Rex>actions>play> is a button called 'Roll-Over', which
can be dragged onto the workspace. The child would then have to find an if
statement for this action, drag it onto the screen, and then draw a line from
the if statement to the then statement... so, if the child wanted Rex to roll
over when he sees a bright light, then the child would drag the button 'sees
light' from the Rex>senses>vision> menu
If the child double clicked on the button, a simple parameter box would pop
up and the child could make it so that Rex would only roll over if he sees
light brighter than a 50W bulb.
Also, the child could, at any time, toggle between the graphic buttons and
the flowchart layout and the actual code behind it(separate floating window).
When they do this, they can click on a button or other graphic element on
the workspace, and the code that is behind it will be highlighted in the full
code window.
The menus at the top of the workspace are the basic application menus. You
would be able to create new buttons by either a combination of existing buttons
OR by writing your own code, so this environment could really grow with the
child!
the instructor
The instructor would be there to assist the children in their coding and helping
them with any problems. Also, the instructor would set up RexShows for the
class to show off the tricks they taught Rex to their parents. However, the
kids are the ones that work in groups to come up with trick ideas and then
sit down and plan how to get Rex to perform the tricks... a real collaborative
learning environment!
the workspace
The working in groups to come up with tricks and then to design the program
and implement the program would be facilitated by the large, round tables
and ample supplies of crayons and paper. The children would only be allowed
to sit at the computer after they had shown the instructor a design plan for
their trick.
summary:
This environment of collaborative exploration, mild competition, play and
scaffold learning would really help with the special problems of Learner-centered
design that were discussed in the Learning Theory in Practice article
we discussed in class.
Growth: programming gets as complicated as the tricks and the child's ambition
do and will constantly press the child to grow and offer the child the support
they need at the next level.
Diversity: The idea of having them work in groups will allow the children
to teach and help each other and each child will be free to take control of
tasks that they are stronger at, thus allowing them to look at diversity as
an asset in the process.
Motivation: ...c'mon... you got a computerized pet... you create investment
by having the children make their ideas become reality...They get to work
on computers... heck, I'm jealous of 'em!
Anyway, I hope you enjoyed the idea...
-jason civjan-
Teacher’s Pet
Second Pass
by Ed Hess and Jason Civjan
for the first two iterations of this project please see:
Teacher's Pet
Checking Bark for Bite: analysis of Teacher's Pet
The second pass of Teacher’s Pet takes into consideration of several weaknesses
found in the first pass. We will attempt to further detail out some of the
components of the system as well. Scaffolding, the problem of one Rex for
25 students, the actual laying out of the general lesson plan for the course
itself, and the GBS design criteria (as described in the Schank, Fano, Bell,
and Jona paper) will all be addressed below.
Description of the Teacher’s Pet Hardware
Rex is a simple form of a more generic robotic animal toy. The hardware itself
could be thought of as a blank robotic base from which you can add on specifically
designed, modular sensors and outputs. More sophisticated animals may be created
by older students by adding different sensors, more sophisticated locomotion
systems, and so forth... Rex is designed to be familiar and friendly, with
an interesting set of capabilities, but not so many as to be overwhelming.
Basic Rex Capabilities
Output
Move (roll)
Bark
Wag
Blinking collar (to show data transfer events)
Move ears
Jump/Flip
Input
Eyes: (light sensors, wall sensors, camera)
Nose: (Detection of short range radio wave 'scent' put out by programmable
objects)
Touch: (contact closures, pressure sensors)
Ears: (Rex can respond to sound events like the clapper)
Other stuff:
Additional objects are available, such as a programmable fire hydrants, that
may act a reference points, or that may be programmed to have different scents.
At more advanced stages, multiple Rex's may be used, to create potential for
distributed systems type application.
One Rex Per Classroom For the Younger Ones:
As stated in the original pass, there would be ONE Rex in the classroom. This
is to create a sense of urgency in the class, where the students are motivated
to outdo their classmates as far as teaching the class dog new tricks. Also,
the confusion of having a decentralized system of many computerized dogs running
all over the place would be too much for the children first learning the system.
The issue of having many students use a single Rex has been addressed in the
software by using a "RexSim". This allows the students to test their
code on an animated Rex, who would do the actions that are commanded by the
students. If their code is buggy, RexSim would get ill until they fixed the
code. As RexSim goes through what their code commands, that particular piece
of code would be highlighted, allowing the student to relate the code to the
animated action. RexSim would allow the students to test pieces of their code
as well as the entire program they have written. After getting their code
working properly, the students would be allowed to upload the code into Rex.
See the debugging section for details.
Some Scaffolding Aspects
Hints
If students are stuck, a "Big Dog" (BD) may be called by blowing
a whistle, granting hints to novice users. BD is the protector of the neighborhood
and refers to the kids as ‘little buddy’, whom he says can whistle whenever
they need him to help them out, since they are new to the neighborhood. When
in need, the students can click on the whistle and BD will come running. BD
appears and shows Rex how to do certain things. In the beginning, students
are given unlimited whistles. At higher levels of student expertise, the number
of allowed whistles is limited, reducing the amount of scaffolding. The narrative
attributes this to that BD feels that the kids are getting the hang of the
neighborhood and that he needs to spend more time helping the kids who are
new and don’t know as much.
Lesson Plan
A lesson plan will be created for the instructors to follow. The lesson plan
would have the instructor show each of the groups of kids how to do the most
basic elements for the first week or so. This would include a tour of "the
neighborhood", or the software of the system, and some examples of what
you can make Rex do. This will give the students a base from which to start
exploring and motivation to learn the system. Emphasis will be placed on the
design process. And the teacher will show specific examples of how ideas go to
paper, then onto the computer and then finally to Rex himself.
The second couple of weeks would have the students become more familiar with
the system by working to create some smallish, well-defined tricks for Rex to
perform. Here students are actually building small chunks of code that will
create a library from which they will be able to draw from on their final
project. These small tricks would be in the ‘When rex sees the wall, he will
turn the other way’ or ‘if rex gets within six inches from his bone, he will wag
his tail’.
The remainder of the semester would have the students, in groups, ‘have at it’
in designing a more involved program of their own choosing. The teacher would
have them plan for the first week of this long project and would give them some
guidance on what a reasonable project scope would be. Some of this planning
would be in a sort of functional analysis, defining the high level behaviors
(functions) that they will need to create to reach their ultimate goal. These
would be set out on paper before the students start trying to create the code
on the computer. Then, when Rex does the trick that they taught him, they will
be able to see how the trick went from ideas to paper to computer to real-life
action!
Other aspects of scaffolding are built into the programming environment, such
as useful forms of feedback, and support for writing modular code.
Description of the Software/Programming Environment
The software environment, or ‘the neighborhood’ consists of a main area that is
essentially a flowchart where the child can drag code blocks from the code
block palette, located along the right side of the screen. The code block
palette consists of libraried blocks of code that are organized for the child
in a file hierarchy system for easy access to the code blocks the child is
looking for. The child can add code they create to the palette at anytime.
RexSim sits on the bottom of the screen until the child highlights some code
and clicks on RexSim, whereupon RexSim will act out the code given to him. BD
will appear at the bottom right of the screen if the child hits the whistle
(help) button.
If a child double clicks on a code block palette, the parameters box for that
block will appear. Also, each code block has a toggle in which the child would
be able to access the underlying code for that block in the program code. Some
features of our proposed system include:
i) Visual Drag and drop programming
The software has a palette of basic code blocks, which may be dragged onto a
grid and linked to create a trick or behavior. The student can toggle between
the actual code and various levels of the code blocks (which can be grouped
into an overlying behavior that they perform). Also, the code blacks can be
clicked upon to open a parameters box, where the student could adjust the
parameters for that specific chunk of code… when they adjust the parameters,
they could also have the ‘code’ window open and see how changing one parameter
effects the code. The students would actually have to go into preferences to allow
themselves to change the code at the code level (without having to go through
the parameters window) and would have a large number of ‘undos’ to get them out
of trouble when they find it.
ii) Modularity
Essentially, the code blocks are icons that have a descriptive title indicating
what they do. They may be expanded to reveal the code blocks that went into
creating them. The most basic code blocks do not contain additional code. When
the students have programmed a useful behavior of a decent size, they can group
it together in a new block which may be put on the palette of code blocks.
iii) Wizards for difficult program structure
The palette also contains specialized code blocks for creating conditional
statements and other complex programming structures. They act as
"Wizards" by providing a basic structure that the students can fill
in to create the code they want.
iv) Simulator/Debugger
The software will include a simulator/debugger. The simulator is essentially an
on-screen Rex that will do what the code tells him to do. When the students
decide to run some code that they have created, they press a button and Rex’s
yard pops up, and Rex goes through his paces. Rex will complain if the code
will not execute at all, and may call Big Dog if necessary. The RexSim will
allow a large number of students to use a single or small number of Rex units
because code can be tested off line. When a significant amount of code has been
written and successfully executed, a group of students can upload it to Rex to
see their ideas in action.
The debugging mode may be turned on or off by the students. The debugger
highlights each code block (procedure/command/function) as it is executed so
they can see the relationship between a particular step and Rex’s behavior. The
highlighting will show when how control jumps between threads as well, since
there will eventually be multi-process behaviors being created in the Teacher’s
Pet system.
The GBS Design Criteria
You may be wondering what the GBS criteria have to do with this project, tho,
if we weren’t such avid subscribers to the multi-theoretical method, Teacher’s
Pet could be designed to fit totally within the GBS guidelines. We did, however,
feel that the Design Criteria set down by Schank, Fano, Bell and Jona, in the
paper ‘The Design of Goal-Based Scenarios’ were a good evaluation device for
our system. It seems that if you hit these key points, you have a pretty darned
good system.
i) Thematic Coherence- The theme of teaching Rex to do tricks directly relates
to the goals of teaching the children the fundamentals of programming, because
that is exactly what programming is about- going through the process of
designing tricks for computers to do and using their language to teach them how
to do the tricks. The theme motivates the kids in a way that talking
programming doesn’t.
ii) Realism/Richness- The idea of realism is covered in the process of having
them take their ideas from their head to paper to the computer and then to the
actual pet. This shows the child how these pieces of the process build on each
other to create something that actually works in the real world! They see how
their ideas can be translated into real action!
Richness is, again, embedded in the process. There are multiple ways to do any
of the programming involved. It is up to the students to find the solution to
their problem and they are free to tinker until they find a solution that works
for them.
iii) Control/Empowerment- The idea that the students know that they are
responsible for the end result is also inherent in the process of designing.
They will have tabs of their entire process where they can see how they made
Rex perform his trick every step of the way… thus knowing that the process they
went through directly relates to the trick Rex is performing.
iv) Challenge Consistency- The students are directly responsible in setting the
challenge level of the task. They pick a quite complex trick to teach Rex, but
can break it down into more manageable, smaller tasks once they sit down and
figure out exactly what functions need to be done to complete the task. Also,
the layers of working with code blocks and/or the actual code itself allows the
child different challenge levels. If the child gets into a place where they
cannot figure out how to break their problem down into more manageable tasks,
then the student can always whistle for BD…
v) Responsiveness- RexSim offers the student immediate feedback on their code
at any stage of completion. He helps the students to make sure that they are
building bug-free code that makes sense throughout the process.
vi) Pedagogical goal support- The activities the student embarks upon to teach
Rex tricks is directly correlated with what programmers do to create new
programs. There is no fluff or irrelevant activities to distract the students
from their mission.
vii) Pedagogical goal resources- fellow classmates, BD and the teacher offer
the students all the resources (and different levels of resources) they need to
complete their mission.
We hope you have enjoyed our ideas!
-jason civjan-
Ed Hess
contact:
jcivjan@hotmail.com
by Jason Civjan
Alright, now it's time to assess the proposed system based on the knowledge we
have learned thus far in the class. This knowledge falls into two categories;
How people actually learn as proposed by the paper by the Committee on Learning
Research and Educational Practice and the Commission on Behavioral and Social
Sciences and Education and the concept of Learner- Centered Design as
laid out in all the other articles we have read thus far... Also, I will
address two concerns that were raised in class concerning my system... here
goes...
How People Learn
Here, i will assess by going through each point the article(skipping ones I
believe have been addressed elsewhere) "'How People Learn: Bridging
Research and Practice" makes and figuring how well the Teacher's Pet
system addresses this issue:
the learners' needs:
-Student's preconceptions on how the world works when they step into the
classroom actually are exploited in my proposed system. At the ages of
Elementary/Middle school, programming and robots are a magical world and NOT
dry, sometimes painful lines of instruction in cryptic languages. I think the
system is set up to further this sense of excitement... and, by the time they
unveil the code beneath, hopefully, that would be a new level of wonder to
them.
Teacher's role:
Designing the Classroom Environment:
Learner Centered Design
Here, I will explore the University of Michigan's concepts of Motivation,
Diversity and Growth as the fundamentals of LCD, as well as the
Norman/Spohrer's additions of Effectiveness and Viability into the mix(their
idea of Engagement is the same as University of Michigan's idea of Motivation).
Motivation- The children are motivated by the want to have the pet carry out
their ideas and the desire to keep ahead of their peers. I believe I've
addressed this well in the interactions of the children, their interactions
with the pet, the scaffolding of the visual and the source coding toggles, and
the integration of debugging drills into their environment. I would have to
assess the system in practice to think of where more motivational engagements
could fit in.
Diversity- I think that diversity is covered by the idea of working in groups
and in the adaptability of the software itself. What could be missing is that
this may be a problem that needs to be specifically addressed when individual
problems come up. I could look into allowing the software to be customizable to
specific children, such as allowing them to set their individual preferences
that automatically load up when they are on the computer. Also, making these
preferences seem less like the child needing help and more like a child's
personal choice to individualize the software... so that we minimize the
element of embarrassment to the child for getting the support they need...
Growth- I have to say that I think that growth has been addressed in the
system. The coding gets more complex as the child is motivated to make the pet
do more interesting actions. In turn, this motivates the child to actually
start writing their own code to allow for these complexities... the system not
only grows with the child, but motivates the child to grow! I think that there
is always going to be room to further this as well and look at all the places
this idea can be reinforced in the system.
Effectiveness and Viability of the system are both difficult for me to
evaluate... I definitely see the system as both potentially effective and
technologically viable. I could address the parts of the system if questioned,
but I don't think I'd be able to objectively evaluate either of these until I can
test what I have and see where the pitfalls of this system in fact do lie.
Classroom Concerns
I heard two major concerns in class pertaining to my system. If there are more,
please feel free to e-mail me... I strive on criticism(it makes me think)...
pats on the head are nice too(they make me think I am smart)...
-jason civjan-
jcivjan@hotmail.com