I taught an eighteen year old teenage male and a fifty year old female. The male has basic user experience - email, IMs, surfing, and has a basic computer upbringing. The female has a degree in computer science and works as a test engineer. The female is a friend of mine and the male is her son; I was visiting with them this weekend. They were interested in the class I was taking this semester and volunteered to learn Scratch.
I gave them an overview of the class and showed them my first three projects. I then walked them through the basics of Scratch. I didn't want to spend too much time with the instruction; rather, just open the time we had to playing.
I found it challenging to not tell them how to best implement their animation idea; I had to let them play on their own and provide support when needed. It was interesting to see the son realize he could use a loop instead of repeating commands manually. He was stumbling across programming concepts without his mother and I explicitly instructing him. He immediately tested every small change he made to his animation as well. It was interested to see how he expected to immediately see the result of his work; this made it easier for him to debug.
The son easily experimented and navigated his way through Scratch while playing. Dragging and dropping blocks made it welcoming to play and not be tentative about making mistakes. This was very similar to my experience; there is nothing to lose by playing with the block construction. He found it satisfying to instantly see the results of your work, whether it worked or not.
Here is their project:
I taught a 65 year old business woman how to use Scratch. Her computer experience included word processing, spread sheets, some Photoshop, and that's about it. She does not surf on the Internet much, doesn't create online content, is not a gamer, has never made or updated a website, has never used Dreamweaver or html, and has never programmed. She uses a PC generally and when we worked together on Scratch we used my Mac, so there were some basic user interface issues to overcome. Despite all of these challenges she did great!
As she was not a gamer, and had no programming experience we started by going to the Scratch website and looking at different projects online for inspiration. Then I showed her the scripts for several projects in the Scratch programming environment. Next I opened my MAS Class Intro project and fooled around with the program, showing her functionality, gradually letting her take over the exploration. She added a Christmas tree to one of my landscapes, then decided that her project would be to make a Christmas card with music and animation. We approached it as a team effort, with her "driving" the process. When we started I helped a lot, and gradually "disappeared" letting her figure it out on her own.
She had some trouble understanding the syntax and logical structure of programs. For example it was hard for her to discern the difference between control blocks and motion or sensing. "Broadcast" was a command that was difficult - she didn't quite understand the separate scripts needed for each sprite or stage, and thus didn't understand cause and effect. So she would pull out any block with "broadcast" in it (like "receive broadcast") and put it in any script, not understanding who was causing and who was being affected. This felt partially like a problem with not seeing the script architecture all at once in one place. In the end she navigated the blocks by color coding, and by copying bits of scripts that worked in other places, which was absolutely fine. She had trouble understanding how to create and edit sprites and stages, and she avoided importing files or sounds or creating new sounds. She did use the paint program extensively. At first it was difficult, but with repetition she got pretty good at it. In general repetition was very important to her learning process.
When I learned Scratch about a year ago, my process was similar. I learned by copying bits of scripts, repetition, and following others along. The color coded blocks helped a lot, and having examples nearby helped too. When I learned, I learned in a group and so didn't get much personal support or much time alone with the project in my first attempts. I think you need a bunch of time exploring by yourself to really understand what you are doing. As a teacher, I think the limits of my knowledge definitely influence what my student can learn from me. So in order to inspire my student to great heights, I kind of need to understand at least some of those great heights myself. I think my student will play with Scratch again, but she needs more mentor time to get significantly motivated. And that mentor should be someone pretty good with Scratch.
We spent about 3 hours constructing the Christmas card, and she had a lot of fun making it. As a teacher, I struggled with the balance of being too present versus letting her explore on her own. She did take over the process eventually and learned a lot. She was excited enough about it to want to download the program at home and improve her card, and possibly make some new projects as well. It’s a testimony to your great Scratch design. Bravo.
Here is her project:
This is really embarrassing... :) I set out to teach Scratch to a student here at MIT – in fact a classmate B. from Pr. Gershenfled’s class ‘How to Make Almost Anything,’ who said he was coincidentally seeking ways to learn about it because he needed it for a class project - and he ended up teaching ME tricks and strategies for creating new functions in Scratch that I didn’t even suspect were possible. The student is younger than me and had no previous experience with Scratch. He had just briefly heard of it from a person who works on Scratch in the Lifelong Kindergarten. Save for this brief introductory conversation, he had no prior knowledge of Scratch, and had not even had time to look at its website yet. For sure, we shattered the traditional, hierarchical system of teacher-pupil, as those roles became blurred and reversed on several occasions throughout the session. To help him, there was his own motivation, since as I said, he was himself interested in learning Scratch and planned to do so in the near future.
Within what seems like seconds, B. had created a mini interactive dialogue between himself and his avatar, a round-shaped little man who responded to his questions, on time and correctly. 'Hi, how are you ? I'm fine thank you, etc. To do this, he needed to know how the input-output system works in Scratch. After going through the basics of sprites, costumes, backgrounds, and the most simple functions of the left hand side bar, like speaking, thinking and motioning, he asked me astute questions about how these input-output functions can be applied in his scenario so that his little sprite-avatar, whom he had created himself in Scratch, could respond to him. Soon after, he was explaining to me the system of input-output in Human-Computer Interaction and how to implement it in Scratch.
He also had a question about input that in fact neither of us could answer or find a solution to: he wanted to find out how he could keep his sprite-avatar moving while receiving input. Each time, his sprite, who was pacing along the screen from right to left and back, would stop half way when receiving an input [question] from B. before answering it. B. wanted him to keep moving and reply simultaneously. He asked me to ask to the class how to implement this - so your thoughts are welcome!
He was also very interested to learn about sensors and our project with the Scratch Sensor Board. I showed him SL’s video of our Dinolove story, which he watch appreciatively. He also wanted to see the code for this project and others, paying much attention to how such or such function had been written in the code.
To be fair and accurate, I should have said that B. worked for many years as a professional programmer before joining the Media Lab. He has been working with PHP, C#, C3 VB.net, Perl, Java Script and HTML CSS, nearly all which I am unfamiliar with. So it is perhaps no wonder then, that when it came to the code and technical specifications of Scratch, he was the one teaching me. In fact, I learned quite a bit from him, such as when he told me that when coding, one should always look at other people's codes, that this was a great way of learning how to code - which seems sensible enough but is a habit I hadn't acquired yet.
But apart from the most technically challenging tasks, I guided him in his discovery of Scratch, first by creating an account on the Scratch website and downloading the program, then we looked at a few projects, including mine. I then told him about all the social, educational, professional and artistic applications for Scratch projects, among others, and about the Scratch community and its concepts of open source collaboration.
The next day, he sent me his first Scratch project, which later evolved to version 2:
Quite an impressive start in my opinion, and I was pleased to see the lesson had already born fruit!
One important element of the interaction is that I was myself curious to carry out a little experiment. I decided to teach Scratch in Russian - which is why I chose B., because he is of Russian origin. He emmigrated to the US from Russia when he was five years old, which means that even though it's his mother tongue, his Russian was a little at the same level as mine, although for different reasons. Mine is still faulty in places, as it is not my mother tongue, and his is a little rusty since he hasn't spoken it in years.
I was just curious to see how I would manage teaching this essentially American program in another language, what kind of computer terms and Scratch 'jargon' I would be using as such, as transliterations from English, or which I would need to translate into Russian. Words like 'sprite', stage', etc. in this context might prove problematic I thought. But in the end, I found equivalents in Russian. I was wondering if the fun and all the experiences of Scratch could be easily translated and passed on into another language and culture. And my verdict is: Scratch is wonderfully transferable into even the very different Russian culture and language.
Of course, I had heard that Scratch is being implemented in Russia, and in other countries, but I just wanted to see for myself and expand the learning experience of my session.
And thus, I taught the whole session in Russian, which went very well. I have it on tape if anyone is interested! At some point though, there were interesting 'teaching' moments, when he would correct my grammar and I would remind him of a Russian word he had at the tip of his tongue but could not remember fast enough. Sometimes we would both instinctively use an English word to describe something in Scratch because there was no real Russian equivalent.
It was thus a kind of double learning experience, as we both were learning Scratch and Russian at the same time.
In conclusion, I can say that contrary to the old model of pupil-learning-from-teacher, we both brought something valuable to the table, and that our roles and strengths balanced each other, but in different ways, with his technical expertise and programming skills which by far surpassed mine, and my own experience of already having worked with Scratch and created projects.
So right from the start, we were learning from each other. And really, there is nothing 'embarrassing' about it! On the contrary, I believe this is the type of teaching interaction that should be embraced by schools and educators.
I helped a classmate from TIE who had no formal programming experience, but uses email like a pro and has experience with the following programs: excel, powerpoint, photoshop, pagemaker, indesign, databases.
We did it remotely since we didn't have time to meet in person. I started off explaining the interphase and had her do some basic stuff (get the scratch cat to walk 100 steps when the green flag is clicked, get the sprite to move where the mouse goes). I actually realized that I don't know the program particularly well and got a little sheepish trying to explain it. After a lot of "ok, try clicking on this menu... oh nevermind, maybe we'll try this one? no, not that either," she told me she had it under control and would just play around until she got it to work.
She wanted to do an animation of an xkcd.com comic, so she already had in mind exactly what she wanted to do. She also had enough experience with computers that she knew not to do anything too complicated, which probably made things easier. This took her about 20 minutes to do: kitty.
I think it would have been a lot easier to teach her had I had some sort of specific goal in mind of what I wanted her to create before setting her off on her own. She did great anyway, though!
For this week’s activity, I want to share my workshop experience last winter. I had a couple of Rhino Script workshops in which I taught Scratch on the first day. Rhino Script is a script language to generate 3D geometries in a CAD/CAM software called Rhino. I used Scratch to teach common programming concepts such as variable, array, loop, condition and function. I assumed that the key knowledge in using Rhino Script was not so different from any programming languages. Once students were familiar with these common ideas, they would be comfortable using Rhino Script later.
Most of students came from architecture school and a couple of students from engineering departments at MIT and Harvard. Most of them were graduate students. I prepared sample Scratch blocks to generate simple yet repetitive geometries like rotating triangles or transforming sine curves. After a couple of hours of Scratch practice, I jumped into teaching Rhino Script and repeated the same practice, generating repetitive geometry patterns.
As an introductory programming workshop, the method I used looked very successful. When I collected student’s comments on the workshop, they wrote their excitements and love of the idea of combining Scratch and Rhino Script. However I found an unexpected cartoon among the returned comments. One student draw a cute human figure with a knife on his heart. I realized that no matter how I tried to make the programming learning easy, still there were holes that I could not fill in.
This week’s contextual learning may be great help. Still I am looking for ways to identify what are the hurdles in programming learning. Why some people learned so fast and some people did so slow. What makes possible for children to learn programming even in their pre-school ages ? What makes impossible for adults to learn programming, to feel a fear of programming ?
I taught a 26-year-old roommate of mine, an architecture student visiting from Holland. He has extensive experience with 3D CAD software and graphics programs like Photoshop. One of his recent assignments was to learn some Rhino scripting to generate a concept based on a behavior from nature for his architecture studio. I knew that the behavior he had chosen was the flocking behavior of birds, so I thought I would try to teach him by developing something similar. He was very busy and sort of reluctant to spend time on this at all, so I figured that choosing a relevant project would help keep him interested. In the end, we wound up working for almost two hours together.
One of his first comments was about the aesthetics of other people's projects on the Scratch website. I think he had a hard time seeing Scratch as "for him" because his work involves very refined and sophisticated graphics - not the pixelated sprites so common in Scratch projects. Perhaps as a result of this, he made no connection between programming with Scratch blocks and programming in his brief introduction to Rhino scripting.
I have been programming since I was around 12 years old, so I forgot what it's like to not understand thinking in code. Teaching my roommate reminded me how very different it is. For example, when we made a variable, he didn't intuitively understand the difference between performing a calculation with a variable, setting its value, or taking action based on the value. Giving the variable a meaningful name confused him as he conflated changing its value with performing an action the variable's name alluded to. I also had to explain to him how we needed to say more than "multiply this variable by 10" and explicitly state "set the value to the result of multiplying by 10". This sort of abstraction and categorization wasn't obvious to him and I was reminded that very few situations but computer programming makes these differences apparent. To help him understand, I tried to use analogies (especially for understanding if..then logic statements) and the fact that only certain Scratch blocks fit with each other. By the end, he reflected that it was important to declare explicitly how you want your sprites to behave and then to carefully translate these ideas into code.
We didn't achieve our goal of simulating flocking, but we did produce a set of sprites that each had identical behaviors to produce some sort of pattern. From this, he said that he saw the potential for generating forms or animations for his work in architecture. Even though our set of rules wasn't "correct," I think he saw the power in being able to "set the rules" in the first place. He seemed to understand the potential for Scratch and programming in general as a tool. I think this appealed to him far more than looking at it as a toy or "fun" in any way, though his continued engagement well past the amount of time he said he would set aside led me to believe he enjoyed the experience!
I taught K., a visiting scientist in the media lab who wanted to learn scratch to teach her nieces over Thanksgiving break. She works for NASA so I want to say that she is somewhat familiar with programming and definitely computers. But she didn’t try to understand Scratch like a programmer.
I taught Scratch as if it was a story telling mechanism. Sprites were actors, the background can have different scenes, and you can broadcast different acts of the story. This model served as a good way to introduce the program. I then showed all the different projects online to show its potential to do other things besides story telling.
A challenge was making sure I taught them enough tools so that they can explore later. There are so many functions and tricks to learn that you can’t teach it all in 1 hr. It is something that they just have to play around with.
The experience was completely different from the way that I learned. It was more comparing Scratch to known computer languages like Java and C++. I was just trying to find the correlating functions; broadcasts are like globals and all the different sprites are like threads.
My learner was an MIT grad student (age 27, male, very experienced with computers, especially C++ and MATLAB). I intentionally let the learner explore the Scratch site on his own for a while, intending to mentor him whenever he has questions. However, he simply downloaded the manual and jump started the learning process by going through the instructions. He said that following the manual was the quickest way for him to learn new programming codes.
Since he was very experienced in other computer languages and was familiar with the process of figuring out how to navigate through computer programs, I wasn't much of a help to him. Comparing this to my own experience, I would have preferred to have someone go through the main features of the Scratch website, since I generally learn quicker through human instructions than manuals and I am not as nearly as experienced in computer programming as my learner.
This was a useful experience for me, because the difference in our learning processes taught me that people with varying experiences and personality types gain knowledge/skills in vastly different ways. It is important to keep this in mind when designing lessons and curriculum that caters multiple personality and learning types.
I taught Scratch to a friend of mine N.; early 30s, male, a medical physician. He has a few years computer programming experience when he was 8th-10th grade for his hobby. He said he is not a computer geek type, but curious to new & fun things. When I talked about the class to him, he showed interests in the tools I used in class such as Scratch, sensor board and WE DO. He said Scratch seemed very attractive because I enjoyed playing Scratch in the living room in our house (yes, it's my roomy), and almost forgot to turn off the oven. My cookies were burned because of Scratch!! That inspired him to learn how to use Scratch.
First I showed Scratch website, and explained how he can play around Scratch; before and even after creation such as sharing, getting comments and collaboration. Then, let him pick some projects from the site intuitively and downloaded them to see the codes behind the projects. Then he started making his first Scratch, and I gave some advices occasionally.
Here is his first project:
I will save the details for in-class discussion, but one thing I really want to share is that "teaching is learning"!!
I taught a MIT grad student who is 25 years old. She has no any programming experience before. Actually she has interest in scratch since couple weeks ago, she attended our class on which we showed our group project by making them on the board with sensors and scratch.
At the beginning, I showed her couple of examples online to see what kind of things Scratch could do. At that time, she really wanted start to work on the project instead of spending too much time on the other people's work . I introduced the function of different sections of the bricks and some important bricks. And then, she started the project by picking her favorite cartoon character, a frog. (Sorry, I don't its name). And then, she decided to make a very simple story: a male frog met a female frog and they fall in love. She did not think about any details, but just to start to look at the different functions of the bricks. Based on the discovery of those functions, she made the details of her story. For example, she found a function could turn color, and then, that became a part of her story. Sometimes she liked to ask, "if I want to let this walk in this way, how could I make it." Usually, I did not answer her directly, since she is a graduate student, she can figure it out by herself and that is important for her as a learning process.
During the process, she was really enjoying and testing those different bricks, and even she criticized the Srcatch itself.
This is the project she made in one hour:
I think this experiences is really close to mine, and the most important point to me is that, Scratch itself is not just a tool to make the animation or a game, but it is a tool to help you think and develop the ideas. I think it is the same to any other tools. For example, a pencil is not just a tool for an artist to draw what is in his mind, but rather it is a tool to help him think what he would draw. At that time, the mental and physical movement has an interaction go back and forth.
I taught a friend who is well versed in computer science and programming languages. He was able to understand all of the functionality and the way to tie things together very quickly - I'd say we were building complex applications in about 20 minutes.
I found that using the concepts of prototypes, e.g. SELF, to be very useful model to understand the environment.