高中生以 Greenfoot 學習 Java 程式設計的學習效果

全文

(1)國立臺灣師範大學資訊教育研究所碩士論文. 指導教授：吳正己博士. Exploring the Learning Effects of Teaching Java Programming with Greenfoot for Senior High School Students 高中生以 Greenfoot 學習 Java 程式設計的學習效果. 研究生：楊士青撰中華民國 102 年 8 月.

(2) 中文摘要程式設計是電腦科學教育的重要一環，但是對初學者來說確相當困難。本研究使用 Greenfoot 程式發展環境並以微世界(microworld)及建構主義的理念來輔助學生學習。 Greenfoot 是用來學習 Java 程式設計的微世界架構 (microworld framework)，以支援教學活動，提昇學生的學習興趣，支援學生的探索式學習。本研究進行為期八週的 Greenfoot 課程，實施對象為四十位高中一年級學生。課程內容涵蓋 Kölling 的 Greenfoot 教科書第一到第五章，另外加上了四個補充案例，作為學生課堂練習之用。本研究蒐集資料以質性方法為主，包括無干擾現場觀察、學生作業方析、學生問卷及教師訪談，以瞭解使用 Greenfoot 之學習成效。研究結果顯示，學生對 Greenfoot 提供的聲光動畫功能很感興趣，但隨著程式案例難度的增加，興趣逐漸降低；學生對於將一個案例中學到的技能，轉移到另一個案例上，感到相當困難；此外，學生喜歡嚐試修改 Greenfoot 案例，使其產生不同的動畫效果，有助於他們觀察程式行為，達到程式設計學習之目的。建議教師在教材設計上以觀念為主，發揮 Greenfoot 的優點，在案例中加入更多的聲光動畫功能，並支援更多學生的探索式學習。關鍵字：Greenfoot, 程式設計, 微世界, 學習興趣, 探索式學習. i.

(3) ii.

(4) ABSTRACT Learning to program is an important topic in computer science education, but is difficult for novice programmers. This study sought to assist the learning of the students with the Greenfoot programming environment and the idea of constructive learning. Greenfoot is a microworld framework that is dedicated to learning Java programming, in order to support the teaching, create the learning interests and support the explorational learning of the students. An eight-week Greenfoot class was given to a class of 40 senior high school students of 10th grade. The class covers Chapter 1 to 5 of the Kölling’s Greenfoot textbook, with four additional scenarios are given the students for the practice of the class. The data are collected primary through qualitative methods, including unobtrusive qualitative field observation, student project analysis, student survey, and teacher interview, in order to evaluate the learning effect with Greenfoot. The results show that the students display their interest with the sounds and animation functionality of Greenfoot in their learning process, but their interest decrease in time as the level of difficulty increases. The students have difficulty to transfer the skills they learned from one scenario to another. The students like to modify the Greenfoot scenarios in order to create their own animation effects. The modification of the Greenfoot scenarios helps them observe the behaviors of their programs and learn to program. Future teaching materials should focus on programming concepts instead of scenarios. More sounds and animations and explorational learning supports should also be added to the scenarios to employ the benefits of Greenfoot. Keywords: Greenfoot, explorational learning. programming,. iii. microworld,. learning. interest,.

(5) iv.

(6) ACKNOWLEDGMENT Dr. Cheng-Chih Wu (吳正己) supervised and guided this research in the past two years. I learned a lot from him, including the attitude as an educator and a scholar, the philosophy of computer science, and how to convert a raw idea into a academic thesis. Dr. Janet Mei-Chuen Lin (林美娟) gave me many concrete suggestions in the middle and later stages of the research. She also pointed me out the weakness of this research method. Dr. Tsan-sheng Hsu ( 徐讚昇 ) gave me important critiques and suggestions. I owe them many thanks. Jean Hue-Ching Kao ( 高慧君 ) from Nan Gang High School ( 南港高中 ) sponsored this research from the beginning. This study would not be possible without her help. We worked together for the past 16 months on the Greenfoot community and the Greenfoot class in Nan Gang High School and online. She gave me constant help throughout this process whenever this research stuck at somewhere or whenever I ran out of ideas. Annie Mei-Wen Chen (陳美文) pointed me out the weakness of this research in the latter stage of the research. These critiques were very important in refining this research. I wish her to get here doctorial degree soon. Dr. Liang-Wen Lin ( 林亮雯) offered me many ideas and suggestion in the qualitative research method throughout this process. I owe them many thanks. Anny Yi-Fen Chen (陳怡芬) from Taipei First Girls High School (北一女中), Meng-Kai Peng (彭孟凱) from Tainan Girls’ Senior High School (台南女中), ChiuYen Chen (陳秋燕) from Tao-yuan Agricultural & Industrial Vocational High School ( 桃園農工 ), Yang Chi ( 楊騏 ), Estea Kuo-Chuan Chen ( 陳國全 ) from Wen De Elementary School (文德國小), Dr. Chia-Ching Tso (左家靜), and Kuan-Ying Huang ( 黃冠穎 ) gave me important inputs in the beginning stage of the research. These inputs are critical in determining the direction of this research. Ching-Yin Hsu (許瀞尹), Hui-Chi Chuang (莊惠淇), Chi Yang, Yi-Fen Chen, and Helen Chian-Rong Ye (葉千榕) kept encouraging me, supporting me, discussing with me and giving me all kinds of suggestion throughout this research. They are always my best friends. Jhih-Ping Wu (吳致平) and Shiou-Chi Weng (翁孝齊) helped me on the rehearsal prior to the oral exam. Wei-Ling Lee (李威霖) offered to help the observation in the middle to the research, although that did not work out. And, of course, all the NTNU ICE members that support me throughout this time. I owe them many thanks. Sz-Ping Sun ( 孫賜萍 ), Kai-Ju Tsai ( 蔡凱如 ), and the OSS Application Consulting Centre (教育部校園自由軟體數位資源推廣服務中心) help sponsoring the workshops and the online resources of the Greenfoot Taiwan community. These v.

(7) resources are critical to the Greenfoot Taiwan community, and to this research. Most importantly, thanks to my dearest Dr. Mandy Yan-Chiou Wu ( 吳燕秋 ). She supported me in every aspect throughout this research. She gave me constant critiques, suggestions, ideas for the qualitative research method and many other things about a scholarship thesis, and encouraged me. She is the best person I could ever met. Finally, I would like to give my memory to my grandma, Chin-Tao Wang (王金桃 ), who passed away during the first year of the research. She supported me for decades in all aspects. I owed her thousands of thanks. I would like her to see me in my academic dress with my master degree, which is never possible now.. vi.

(8) TABLE OF CONTENTS List of Tables..................................................................................................................ix List of Figures..................................................................................................................x 1. Introduction..................................................................................................................1 1.1 Learning to Program with Java.............................................................................1 1.2 Greenfoot as a Programming Microworld Framework.........................................2 1.3 Research Statement...............................................................................................4 2. Literature Review........................................................................................................7 2.1 Review of the Microworlds...................................................................................7 2.1.1 The Theories of the Microworlds..................................................................7 2.1.2 The Logo Programming Language................................................................8 2.1.3 Karel the Robot.............................................................................................9 2.1.4 Alice.............................................................................................................11 2.1.5 Scratch.........................................................................................................13 2.1.6 Greenfoot.....................................................................................................15 2.2 Study of the Learning Effect of the Microworld.................................................18 2.3 Previous Research Greenfoot..............................................................................19 3. Research Method.......................................................................................................21 3.1 Participants..........................................................................................................21 3.1.1 The Students................................................................................................21 3.1.2 The Teacher.................................................................................................21 3.2 Research Tools....................................................................................................22 3.2.1 The Greenfoot Software..............................................................................22 3.2.2 The Questionnaire of the Student Survey....................................................23 3.2.3 The Outlines of the Teacher Interview........................................................24 3.3 Instructional Design............................................................................................24 3.4 Procedures...........................................................................................................26 3.5 Data Collection and Analysis..............................................................................28 3.5.1 Field Observation........................................................................................28 3.5.2 The Uploaded Projects of the Students.......................................................31 3.5.3 The Student Survey.....................................................................................31 3.5.4 The Teacher Interview.................................................................................31 4. Results and Discussion..............................................................................................33 4.1 The Overall Attitude of Interest and Exploration of the Students.......................33 4.2 The Engaging Functionality of Greenfoot..........................................................34 4.3 The Exploration and Active Learning Behaviors of the Students.......................36 4.4 The Discoverability of Greenfoot.......................................................................39 4.5 The Flexibility of Greenfoot...............................................................................40 4.6 The Achievement of the Students.......................................................................41 4.7 The Difficulty in the Practice of the Students.....................................................41 4.8 The English Language Issue...............................................................................43 5. Conclusions................................................................................................................45 vii.

(9) 5.1 The Interest of the Students.................................................................................45 5.2 The Exploration of the Students..........................................................................46 5.3 The Difficulties of the Students..........................................................................46 References......................................................................................................................49 Appendices....................................................................................................................55 A. The Student Survey Questionnaire...........................................................................57 B. The Outlines of the Teacher Interview......................................................................59 C. The Greenfoot Class..................................................................................................60 Week 1 Introduction..................................................................................................60 Week 2 if-statement...................................................................................................63 Week 3 Creating Objects (The new Command).......................................................64 Week 4 Practice: if-statement....................................................................................65 Week 5 Variables, with Practice................................................................................66 Week 6 Loops and Arrays.........................................................................................67 Week 7 Practice: Loops and Arrays..........................................................................68 Week 8 Comprehensive Practice...............................................................................69 D. The Observation Items..............................................................................................70 E. A Sample Observation Sheet.....................................................................................72 F. Examples of Raw Field Observation Records...........................................................73 G. A Sample Transcription Sheet...................................................................................74 H. The Definitions of the Tags.......................................................................................75 I. Examples of Transcribed Records..............................................................................79. viii.

(10) LIST OF TABLES Table 4.1 Questions 1, 2, 3, 7, and 11: The General Interest and Engagement of the Students with Greenfoot................................................................................33 Table 4.2 Questions 7, 8, 9, 10: The Attitudes of the Students towards the Engaging Functionality of Greenfoot.............................................................................35 Table 4.3 Questions 4 and 5: The Attitudes of the Students towards the Documents...40 Table 4.4 Questions 4 and 5: The Comparison of the Use of the API Documents in Greenfoot.......................................................................................................44. ix.

(11) LIST OF FIGURES Figure 1.1 The Greenfoot programming environment 2.3.0............................................3 Figure 1.2 Kolb’s learning circle.....................................................................................3 Figure 2.1 A simple Logo program that draws a pinwheel..............................................8 Figure 2.2 The pinwheel drawn with the program in Figure 2.1.....................................9 Figure 2.3 A Karel program that walks by the right wall until it finds a beeper...........10 Figure 2.4 The world for the program in Figure 2.3......................................................10 Figure 2.5 The Alice world, version 3.1........................................................................12 Figure 2.6 The Scratch programming language and its environment, version 2.0........14 Figure 3.1 The classroom...............................................................................................27 Figure 3.2 The links between the behaviors of the students, the teaching events and the goals and features of Greenfoot....................................................................30 Figure 3.3 The resulted theories....................................................................................31 Figure 4.1 Student 2-7 places a lot of worms to form a disk that holds the lobster......36 Figure 4.2 Student 3-3 turns the worms into heart-shaped hamburgers........................37 Figure 4.3 Student 4-2 makes a flock of worms move like sea gulls............................37 Figure 4.4 Student 4-9 inverts the rules of the game.....................................................38 Figure 4.5 Student 4-1 adds 500 worms to the map......................................................38 Figure C.1 The wombat scenario...................................................................................60 Figure C.2 The asteroids scenario..................................................................................61 Figure C.3 The fat cat scenario......................................................................................62 Figure C.4 The little crab scenario.................................................................................63 Figure C.5 The Pac-Man scenario.................................................................................65 Figure C.6 The piano scenario.......................................................................................67 Figure C.7 The emoticon scenario.................................................................................68 Figure C.8 The tank wars scenario................................................................................69. x.

(12) CHAPTER 1: INTRODUCTION. 1.1 Learning to Program with Java Learning to program is one of the important topics in the computer science education. In Taiwan, programming is listed as an elective course of the computer science curriculum in the senior high schools curriculum standards. The computer science curriculum in the senior high schools curriculum standards lists four targets, which are all related to the ability of programming of the students (Ministry of Education, 2008): [1] 1. To train the students the ability to learn computer science related subjects in depth. 2. To train the students the spirit of research to explore the diverse domains of computer science. 3. To train the students the ability of logical and innovative thinking. 4. To train the students the ability to integrate and utilize computer tools for problem solving. Among the many different programming languages, Java is one of the major contemporary programming languages. Java is a general-purpose, object-oriented programming language. It is listed as the second most popular programming language in the world (TIOBE Software, 2013). [2] Java is widely taught in colleges and universities in the United States, and is used in AP Computer Science courses and exam since 2004. Java is also the programming language used for the mobile applications on the Android operating system, where Android is the most popular mobile operating system in the world (Gartner, 2013). [3] Java has become one of the de facto general-purpose programming languages in industry environments nowadays. The same happens in campus. Object-oriented programming has become very popular in the campus. Many high schools and universities are teaching C++ or Java, instead of C, Pascal, in their courses. In United States, the Advance Placement program has moved from Pascal to C++ on 1999, and then to Java on 2004, reflecting the programming paradigm shift from procedural programming to object-based programming, and then to object-oriented programming (Carter, 2009). [4] Java, as a general-purpose, strongly-typed, text-based programming language, suffers the same critiques of other general-purpose, text-based programming languages. Jenkins (2002) summarize seven difficulties of programming, including: [5] 1. Programming involves multiple skills, like syntax, semantics, structure and 1.

(13) style, that form a hierarchy. 2. Programming involves multiple processes, translating a specification into an algorithm and then into code. 3. The programming language itself is hard. 4. Programming is a new subject comparing to other subjects in education. 5. Exercises are normally like student marks, stock levels, baseball statistics or bank accounts that are dull, not interesting. 6. Programming has a reputation of difficult. 7. Students does not learn programming with their own pace.. 1.2 Greenfoot as a Programming Microworld Framework The difficulties to learn to program urges the need of educational programming environments, or microworlds, in order to help both the teachers to teach and the students to learn to program. Papert (1980) defines the term microworld as a “…subset of reality or a constructed reality whose structure matches that of a given cognitive mechanism so as to provide an environment where the latter can operate effectively.” But only an environment is not enough. This environment must provide a structure that supports the exploration of the learners. Papert further argued that “The use of the microworld provides a model of a learning theory in which active learning consists of exploration by the learner of a microworld sufficiently bounded and transparent for constructive exploration and yet sufficiently rich for significant discovery.” [6] Greenfoot is a framework to design microworlds in order to learn Java. Greenfoot is a free and open source software released under General Public License (GPL). [7] It was proposed by Henriksen and Kölling in 2004, [8] developed in Kent University, first released in 2006, with its current version 2.3.0. Figure 1.1 shows an example of the Greenfoot window. The projects in Greenfoot are called scenarios. On the right of the window is the class diagram showing the class hierarchy. There are two base classes in Greenfoot: the World and the Actor. On the left of the window is the world where Actors act in. Actors in the World can move, turn, and interact with one another. Greenfoot is turn-based. For each turn, the act methods of all the Actors are called. On the lower-left of the window is the execution controls. Users hit the Act button to run scenario for one turn, or hit the Run button to run the scenario continuously. There are two types of Actors in Figure 1.1: Wombat and Leaf, both of which are subclasses of the base class Actor.. 2.

(14) Figure 1.1 The Greenfoot programming environment 2.3.0 The Greenfoot team lists three initial design considerations: 1. Closing Kolb’s learning circle by providing an environment that learns can actively experiment and build their concrete experience with. In other words, to support the exploration of the learners. Concrete Experience Active Experimentation. Reflective Observation Abstract Conceptualization. Figure 1.2 Kolb’s learning circle 2. Creating the interest of the students to the programming. 3. Supporting the teachers in teaching. The Greenfoot team further elaborates the design goals of Greenfoot (Kölling, 2010, p. 14:7): [9] 1. From the student’s perspective, the goal is to make programming engaging, creative and satisfying. 2. From the teacher’s perspective, the goal is for the environment to actively help in teaching important, universal programming concepts. To support the students, the team lists eight sub-goals: 3.

(15) 1. Ease of use. 2. Discoverability. 3. Support engaging functionality. 4. Flexibility. 5. Quick feedback loop. 6. Availability. 7. Social interaction sharing. 8. Extendibility. Among these sub-goals, the interest and exploration of the students are the two of the main themes. To support the teaching, the team lists six sub-goals: 1. Visualization. 2. Interaction. 3. Consistent mental model. 4. Concepts before syntax. 5. Avoid cognitive overload. 6. Support for teachers. These sub-goals form the constructive learning structures of Greenfoot to support the learners.. 1.3 Research Statement The interest and exploration of the students have been two of the major concerns of constructivism, of the microworlds, and also of Greenfoot. An in-depth qualitative inspection to the learning experience of the students with Greenfoot is needed in order to understand whether and how the designs of Greenfoot invoke the interest and the active exploration of the students. There has been many researches concerning learning to program with Greenfoot in the recent years. But most of these researches focus on the achievement to learn to program. Few of them concern about the learning experience with the design of Greenfoot itself. This issue is especially important for non-native English-speaking societies like Taiwan. Java is one of the high-level programming languages. The high level programming languages mimic the natural human language, which is English, in order to be easily learned and understood. Most of the researches with Greenfoot are conducted in native English-speaking societies. The students in native Englishspeaking societies can still read and discover the meanings of the program lines even if they do not have any programming knowledge. However, in a society where English is not its native language, the students cannot discover and explore the meanings of the program lines by themselves. The students here have an additional difficulty in 4.

(16) discovery and exploration than students in native English-speaking societies. An indepth examination on the learning experience with Greenfoot in non-native Englishspeaking societies like Taiwan is especially important. The purpose of this study is to explore the learning experience with Greenfoot for the senior high school students. This study seeks to answer the following questions: 1. How does Greenfoot create the interest and engagement of the senior high school students, if there is any, in their learning experiences of Greenfoot? 2. How does Greenfoot invoke the active learning and exploration of the senior high school students, if there is any, in their learning experiences of Greenfoot? 3. What are the difficulties in the learning experience of Greenfoot of the senior high school students, if there is any, and how to improve? By identifying the interest and active learning behaviors of students in their learning experiences of Greenfoot, the senior high school teachers can have a better understanding to the benefits and difficulties of Greenfoot, to whether they could choose Greenfoot as their teaching tool, and to how they can improve their class designs in order to utilize these benefits and improve from these difficulties.. 5.

(17) 6.

(18) CHAPTER 2: LITERATURE REVIEW. 2.1 Review of the Microworlds 2.1.1 The Theories of the Microworlds Papert first suggested the term “microworld” in 1980 in his article “Computerbased microworlds as incubators for powerful ideas“. In this article, Papert defines microworld as “a subset of reality or a constructed reality whose structure matches that of a given cognitive mechanism so as to provide an environment where the latter can operate effectively” (p. 204). Microworlds, in this sense, was not limited to computational learning environments. It could actually refer to all kinds of educational tools. However, “the availability of a technology for microworlds”, in Papert’s words, has made it possible for the microworld development to be systematically refined and theory-based. But only a tool or an environment is not enough. Papert knows that learners need support structures. He further argued that “The use of the microworld provides a model of a learning theory in which active learning consists of exploration by the learner of a microworld sufficiently bounded and transparent for constructive exploration and yet sufficiently rich for significant discovery” (p. 208). In other words, microworlds must support learners’ constructive learning process. Other people has defined “microworld”, too, and they hold similar perspectives. Latour defines “microworld” as “a tiny world inside which a student can explore alternatives, test hypotheses, and discover facts that are true about that world. It differs from a simulation in that the student is encouraged to think about it as a ‘real’ world, and not simply as a simulation of another world.” [10] diSessa (2000), while discussing his experience teaching with his microworld Boxer, defines “microworld” as a “… genre of computational document aimed at embedding important ideas in a form that students can readily explore. The best microworlds have an easy-tounderstand set of operations that students can use to engage tasks of value to them, and in doing so, they come to understanding powerful underlying principles. You might come to understand ecology, for example, by building your own little creatures that compete with and are dependent on each other.” (p. 47) [11] The common of these definitions of microworlds is that: Microworlds are to support the constructive, learner-directive learning process, so that learners can readily explore and discover the ideas embedded in them. Papert and Harel (1991) proposed “situating constructionism”, which can be understood simply as “learning-by-making”. [12] This is achieved by providing the learners a subset of reality that represents the 7.

(19) cognitive knowledge structure. There are many computer programming microworlds.. 2.1.2 The Logo Programming Language Papert’s proposal of the “microworld” concept was meant to describe the Logo programming language, the first computer programming microworld. The Logo programming language was created by Bobrow, Feurzeig and Papert in 1967 (Feurzeig, 1969). [13] In Logo, the user poses as a small turtle (the hollow triangle in Figure 2b and 3b) moving around the space by user commands. Its basic commands are composed of simple words from the daily English conversation, although there are equivalent short hand notations: FORWARD or FD for move forward, BACK or BK for moving backward, RIGHT or RT for right turn, LEFT or LT for left turn, REPEAT for the repeating structures, and BYE for exiting the Logo program. The turtle responses and moves by these user commands, providing feedback to the user. The turtle also leaves the user a graphical trace of its path of where it had traveled. With feedback, students can experiment and explore the programming commands, and learn the mathematical and computational concepts behind from the feedback of the commands and the combinations of these commands. Figure 2.1 shows a simple Logo program to draw a pinwheel, using the repeat structure. Figure 2.2 demonstrates the graph drawn with the program in Figure 2.1. These screen captures were taken with Berkeley Logo run on a modern Linux desktop. Berkeley Logo can be downloaded from http://www.cs.berkeley.edu/~bh/logo.html . The first Logo in 1967 ran on a mainframe. With the first Logo, the commands were typed in and the resulted graphical trace were print out in paper with teleprinters (Cynthia Solomon, n.d.). [14] Today, Logo has a great number of descendants and derivatives, including Scratch (Boytchev, 2013). [15]. Figure 2.1 A simple Logo program that draws a pinwheel. 8.

(20) Figure 2.2 The pinwheel drawn with the program in Figure 2.1 With experimenting words and numbers from their daily English conversations in Logo, learners can then learn the mathematical concepts behind these numerical operations and their graphical representations. The Logo programming can then support the learners’ constructive learning process.. 2.1.3 Karel the Robot Pattis (1981), in his programming textbook “Karel the Robot: A Gentle Introduction to the Art of Programming”, proposed a new robot simulation language called Karel the Robot. [16] Karel the Robot is another important computer programming microworld. Karel is a robot living in a small world of “streets”. Karel can walk around, detect the surrounding environments, put a beeper on the ground or pick it up. Like Logo, the commands of Karel are also composed of simple daily English words. But the scope of commands are much simpler. There are only 5 commands: move, turnleft, putbeeper, pickbeeper and turnoff. Karel also has a group of detectors like front-is-clear, front-is-blocked, next-to-a-beeper, not-next-to-a-beeper, facingnorth… etc. Other commands can be created using user-defined procedures. For example, the command turnaround can be defined as two turnleft commands sequentially, while the command turnright can be defined as three turnleft commands sequentially. Karel also features repeating structures. Learners can program Karel the Robot with these commands to do specific tasks, solve quests, mazes and puzzles. The students can learn to computer programming concepts from solving problems with Karel. Figure 2.3 is an example Karel program, and Figure 2.4 is the robot world for this program. In the robot world in Figure 2.4, Karel is the larger-than (>) sign at the left of the graph. The larger-than (>) sign indicates that Karel is facing right. The asterisk sign (*) at the right of the graph indicates the beeper. In this lesson, the goal of Karel is to find and stop at the beeper. The above screen captures were taking with Turbo HAL, a Karel interpreter with a look like Turbo-PASCAL, running in the DOS emulator under a modern Linux desktop. Turbo HAL can be downloaded from 9.

(21) http://www.coedu.usf.edu/it/faculty/gsmith/WebProg1/karel.html . The first Karel simulator in 1981 was written in PASCAL. At the time when the Karel textbook was published, students composed their Karel programs with text editing systems, and ran their Karel programs on cursor-addressable display screens with Karel simulators (p. viii-ix).. Figure 2.3 A Karel program that walks by the right wall until it finds a beeper. Figure 2.4 The world for the program in Figure 2.3 Karel uses a syntax and control structures much like PASCAL, but with the variables and data structures removed. It has the following features (p. vii–viii): 1. Karel comes with a textbook of designed problems and practices, and can be learned using this textbook even with only hand simulation. 2. Students can learn PASCAL much easier after they are familiar with the Karel syntax. 3. Many important programming concepts require students to be adept with the programming language first. By learning a simpler programming language, student can get adept with the programming language faster and reach these important programming concepts earlier. 4. Many students are afraid with the numerical nature of computing. It would be more intuitive, easier to understand and less hostile to remove these numerical elements first.. 10.

(22) 5. A robot moving through the street visualizes the programs, which is a better scaffolding that students are much adept than information moving through the circuits of a computer. Item 1, 2 and 4 above make Karel different than Logo. Comparing to Logo, Karel is more problem-oriented. Its support structures are very clear for the students. It is aimed at learning a general-purpose programming language. It removes numerical elements from the programming language itself in order to be more engaging to the novice students. But, as a microworld that uses the syntax of PASCAL but not plain English words, Karel needs more on teachers’ guidance than self-discoverable. As a microworld, Karel also features commands from simple daily English words, so that students can easily understand. It has a simplified programming subset of only five commands that can still operates effectively. However, Karel needs more on teachers’ guidance than self-discovery. The idea of learning a general-purpose programming language by programming a robot to solve problems with a simpler, non-numerical set of commands is an important step in creating programming microworlds. The idea of Karel inspires many people, and derives many clones and variants. Karel++ is an object-oriented version of Karel, and is for students to learn C++ and Java (Bergin, 1997). [17] Karel J Robot is a Java clone of Karel the Robot and is for students to learn Java (Bergin, Pattis, Roberts, and Stehlik, 2005). [18] Monty Karel (2008) is a Python clone of Karel the Robot and is for students to learn Python (Bergin, Stehlik, Roberts, and Pattis, 2008). [19] Karel R Tuesday is a Ruby clone of Karel the Robot and is for students to learn Ruby (Bergin, Stehlik, Roberts, and Pattis, 2012). [20] JKarel is another Java clone of Karel the Robot (Wellenius, 2003). [21] Guido van Robot is another clone of Karel the Robot that is based on the Python programming language (Elkner, 2004). [22] Although Karel is old, its design ideas are still current these days.. 2.1.4 Alice Alice is a modern 3-D animated microworld. It is developed by a team led by Randy Pausch from Carnegie Mellon University, and was first released in 1999. One of Alice’s team member, Steve Cooper (2010), has written an article “The Design of Alice” that details the characteristics, advantages and weakness of Alice 2 and Alice 3. [23] The current version of Alice is 3.1. Alice features 3-D animation. Users of Alice create their programs that animates their characters or interact with other in the Alice world. Although Alice supports all kinds of activities, including games, it is mostly mentioned for storytelling. Alice features drag-and-drop programming. Programming blocks are drag-and-drop with mouse and snap together. Learners of Alice can skip the syntactic frustrations and focus on the semantic difficulties (p. 15:5). Alice claims to be inspired by both Logo and Karel the Robot. As a successor of Karel the Robot, Alice hides the numerical state change and replaces them with primitive methods, so that students does not have to face the hostile numerical part of programming first (p. 15:4). Alice is aimed at pre-CS1, at-risk students, but it is suitable for students from 12 to 18 years old (p. 15:6–15:7). Figure 2.5 shows a sample Alice code editing window. The upper left is the 11.

(23) scene. The lower left is the method panel. The right side is the code editing panel. The lower-right is the control panel. Alice users drag-and-drop methods from the method panel, or control structures from the control panel, to the right code editing panel to compose their programs. Although Alice users compose their program with program blocks but not text typing, the underlying programming language Alice uses is still Java. The object structure in Alice follows the object structure in Java. Objects are generates from classes, methods in the method panel are organized under the classes, and classes are inherited from one another. Users can even program the Alice world with Java in NetBeans (p. 15:6).. Figure 2.5 The Alice world, version 3.1 The major difference of Alice from other microworlds is that Alice is 3-D animated. The 3-D animation feature make it very difficult on older machines without hardware graphical acceleration enough hard disk, and memory. On the other hand, the 3-D animation nature makes Alice very suitable for storytelling. With 3-D animation, characters in Alice can raise their hands, sit down, wake up, walk, jump and pose any gesture you like. This is not possible with other 2-D microworlds. Storytelling is an important aspect of Alice. Storytelling appeals to almost everyone. Alice was doing great in engaging female students but not only the majority males (p. 15:9). It attracts students from all kinds of cultures and races, too. The animated nature of Alice has another benefit: The change of object state can be clearly seen. The default time of each animation is one second. The students can easily see the change of object state from the animation (p. 15:3). But, on the other hand, Alice does not have collision detection (Cooper, Kölling, Maloney, Resnick, and Utting, 2010, p. 17:9). [24] This is a major disadvantage when creating games. As a microworld, Alice is ahead of its time in many senses. It uses 3-D animation that not many computer can work with at the time of its first release. It limits its subset of reality to the 3-D scene storyboard. It features storytelling to engage then at-risk pre-CS1 students, female students, students from different cultures and races. It lists all the available class and methods as program blocks. Students can explore and discover what they can do with their characters with these program blocks. 12.

(24) Alice has textbooks, tutorials, teacher communities as its support structure for both the teachers and the students. These features of Alice supports the constructive learning process of the learners.. 2.1.5 Scratch Scratch is both an educational programming language and a development environment. Brennan et al. (2009) have written a very legible article, “Scratch: Programming for all”, to introduce Scratch and its design principles. [25] Another article written by Eastmond, Maloney, Resnick, Rusk, and Silverman (2010), “The Scratch programming language and environment”, discuss the designs of Scratch in detail. [26] Scratch is developed by Lifelong Kindergarten group in MIT Media Lab led by Mitchel Resnick and his colleagues, and was first released in 2006. Resnick and his colleagues had been working closely with their supervisor Papert with the LEGO Company developing LEGO MINDSTORMS and other robotic kits. They observed how kids are having fun tinkering with LEGO bricks. They decided to create an educational programming environment features brick-like structures and remove all the syntax burden (Brennan et al., 2009, p. 63). Scratch is listed as a derivative of Logo (The Logo Foundation, n.d.). [27] Scratch tries to “lower-the-floor” (Brennan et al., 2009, p. 63), and is suitable for 8-16 years old students (Eastmond, Maloney, Resnick, Rusk, and Silverman, 2010, p. 16:2). The current Scratch version is 2.0. Scratch 2.0 is a web application that runs entirely on a browser. Figure 2.6 is a sample Scratch editing page for a cat walking in the maze. The upper-left pane is the stage where things happen. The lower left pane are all the sprites (characters) that appear on the stage. The middle pane lists the command bricks that are available to compose the program. The right pane shows the scripts you are programming. Comparing to the majority of class-based object oriented programming languages, Scratch is class-less, prototype-based. There is no classes of objects that share the same behaviors. If you want to have two sprites of the same behavior, you have to copy the code from one to the other.. 13.

(25) Figure 2.6 The Scratch programming language and its environment, version 2.0 With Scratch, users no longer compose their program with text editing. Users compose their program by mouse drag-and-drop the command bricks from the middle pane to the right scripting pane. Command bricks has their shapes and connectors. Two or more command bricks can only snap together if their shapes or connectors fit. These shapes and connectors give clues for the command structures that users can easily figure out, and make Scratch self-discoverable. This is the first feature of Scratch: More Tinkerable. Scratch’s Tinkerability enables active exploration of the learners (Brennan et al., 2009, p. 63). Another important feature of Scratch is that it is more general-purposed. Comparing to a walking turtle that leaves its trace (Logo) or a robot that solves quests (Karel), Scratch could be almost anything you want. With Scratch, users can create games, tell stories, share photos and music. Users can easily import 2D graphics, photos, sound or music for their projects. Users can create meaningful projects that meet their interests. This is the second feature of Scratch: More Meaningful. Scratch can be used to create engaging projects that attract the users (Brennan et al., 2009, p. 64). The third feature of Scratch is More Social. Since Scratch 2.0, Scratch became a web application. Scratch 2.0 is not only a microworld, but also a social network. Users create and share their projects directly on the web. They can interact with other users. They can browse, derive, read and learn from other people’s projects. They can give and receive comments on their works. Scratch enables collaborative learning among the learners. As learning is a social, collaborative process, collaboration is also an important aspect of the constructive learning (Brennan et al., 2009, p. 65). As a microworld, Scratch’s commands may seem quite rich. It categorizes its 14.

(26) commands into eight categories so that the command lists are not too overwhelming. Besides this, Scratch has a very intuitive user interface that learners can readily explore. It can be used to create all kinds of projects that engages the users. And it is built on a platform that encourages collaborative, social learning. All these designs make Scratch a microworld that support learners’ constructive, self-directed learning process.. 2.1.6 Greenfoot Greenfoot, fist released in 2006, is the newest member among these computer programming microworlds or microworld frameworks. The original idea of Greenfoot was first proposed by Henriksen and Kölling in 2004, in their article “Greenfoot: Combining object visualization with interaction.” In its earliest idea, Greenfoot tried to root its theory in Kolb’s learning circle (Henriksen and Kölling, 2004). Figure 1.2 demonstrates the Kolb’s learning circle. It is often very difficult to cover all the four aspect of the Kolb’s learning circle. A lecture class on concepts of objects would be centered on “abstract conceptualization”. When students process their “active experimentation”, they tend to be struck by their syntax errors, and hence their “concrete experience” tend to focus on syntax problems rather than concepts of objects. The designers of Greenfoot want to close this learning circle, to enable students to “… manipulate, experiment with, and observe objects, not merely lines of source code.” Students should be able to active experiment with and build concrete experience of the object concepts with this tool. The other important designing consideration mentioned in this article is to create the interest: “… The activity students engage in through use of the tool should be engaging and relevant to the students.” There are other design considerations, too. Engaging and relevant activities highly depend on the cultural and personal backgrounds of the students. The tool should be flexible in its activities. Also this tool should support the teachers. It should be easy to create scenarios for the teachers (Henriksen and Kölling, 2004). But the two most important design considerations are still: 1. Students can active explore, environment and build concrete experience on this environment; 2. Creating the interest of the students. With these design considerations, the team lists several initial design goals (Henriksen and Kölling, 2004). 1. Experimentation and visual feedback. 2. Flexible scenarios. 3. Clean illustration of object-oriented concepts. 4. Easy development of scenarios and exercises. 5. Support migration to other environments. The design goals 1 and 3 are going to support the exploration, experiment and constructive learning process of the learners. The design goal 2 is going to support the engagement of the students. These two themes continuously appear among the microworlds and microworld frameworks. The Greenfoot team specifically mentioned Karel the Robot as its precedence. 15.

(27) The greenfoot design was originally inspired by considering the combination of aspects of two popular teaching environments, Karel the Robot and BlueJ. (Henriksen and Kölling, 2004) Indeed, Greenfoot does resemble Karel the Robot in many aspects. 1. Greenfoot is aimed at learning a general-purpose programming Java. It uses standard Java as its programming language. Karel the Robot is aimed at learning PASCAL. Its programming language adapts all the language structures of PASCAL. 2. As Greenfoot uses standard, text-typing Java as its programming language, Learners need more support structures on the programming language itself. Greenfoot comes with a textbook, “Introduction to programming with Greenfoot”. [28] This is the same with Karel the Robot, which uses PASCAL syntax and comes with the textbook “Karel the Robot: A Gentle Introduction to the Art of Programming”. 3. Greenfoot emphasizes the importance of the “concept first” pedagogy, by present the important object concepts visually at the first contact of the students. Karel the Robot emphasizes the important to teach concept earlier, too, with a simplified programming language so that students can finish learning faster and reach the programming concepts earlier. 4. Greenfoot postpones the variables and data structures to a later stage of the learning, and replaces them with “commands” (methods that perform actions but do not return values). This avoids the fear of students with the numerical natures of programming at their first contact. This is adapted from Karel the Robot, which removes the numerical elements at once and postpones them to the later stage when students are learning PASCAL. Alice, as a successor of both Logo and Karel the Robot, adapts this principle, too (Steve Cooper, 2010). But Greenfoot does not stand to be a modern Java clone of Karel the Robot. In addition to these features of Karel the Robot, Greenfoot steps further. The Greenfoot team describes Greenfoot as “… not a micro world, but a meta framework for micro worlds.” Karel, Turtle Graphics or the Marine Biology Case Study … has the disadvantage that the scenario is not flexible. If the framework gives you robots and beepers, then that’s what students deal with: robots and beepers. Whether they like it or not. (Henriksen and Kölling, 2004) So Greenfoot steps further. Greenfoot is a microworld framework that is used to create microworld scenarios. On one hand, this means that Greenfoot must provide a simple API that teachers can easily create their own scenarios for their students. On the other hand, Greenfoot must be flexible enough to provide different scenarios that matches the interests of students of different cultural and personal experiences, in order to create the interest of the students and engage them. But, as the above item 2 mentioned, like Karel the Robot, Greenfoot requires more support structures than other microworlds or microworld frameworks. Four years after Greenfoot was released, in his article “The Greenfoot programming environment,” Kölling further elaborated the ideas of Greenfoot. He 16.

(28) lists two main design goals of Greenfoot (Kölling, 2010, p. 14:7-14:8): 1. For students, to make programming engaging, creative and satisfying. 2. For teachers, to actively help in teaching important, universal programming concepts. He further describes these two goals in detail. To engage the students, the subgoals are: 1. Ease of use. The system must be very easy to learn. Students can focus themselves on the programming concepts without being stuck with the system. 2. Discoverability. The system must be self-discoverable. Students must be able to find out the functionality they need to achieve their goal. 3. Support engaging functionality. The system must support functions that engage the students, like the sounds, images, animations and object interaction. 4. Flexibility. The system must be flexible that meets the different interests of students from different gender, race, and culture. 5. Quick feedback loop. The system must provide quick feedback loop. Students can experiment, observe, and build their knowledge on them. 6. Availability. The system must be easily available to all kinds of underlying systems. This includes cost and system load. It should be able to run on with average hardware. Students should be able to install and practice it at home. 7. Social interaction sharing. The system must enable sharing of projects among its learners, and encourage social, collaborative learning. 8. Extendibility. The system should be extendable, so that it can connects to different hardware (game controllers, etc.) or software. The sub-goals 1, 2, 5, and 6 of the students are three important aspects to support a self-discoverable environment that students can readily explore and experiment with. The sub-goals 3 and 4 are to create the interest of the students and engage them in programming. The sub-goal 7 supports the social aspect of constructive learning. To support the teaching, the sub-goals are: 1. Visualization. visualized.. Important but abstract programming concepts should be. 2. Interaction. The interaction of the students with the system should help them to build the programming concepts. 3. Consistent mental model. The interaction with the system should be consistent so that students can build a consistent mental model. 4. Concepts before syntax. Students should first face the concepts but not the syntax issues when the first encounter the system. 5. Avoid cognitive overload. All extraneous complexity (that are not directly relevant to the concepts students are learning) should be able to be avoided, and all peripheral tasks should be able to be automated and hidden. 6. Support for teachers. A teacher support network should exists to support the 17.

(29) teachers. The sub-goals 1, 2, 3, 4, and 5 are to create a model of learning that matches the cognitive map of the knowledge of the students. The sub-goal 6 is to support the teacher themselves.. 2.2 Study of the Learning Effect of the Microworld Brindley, Eccleston, and McDermott (2008) in their article “More than a good story – Can you really teach programming through storytelling?” discuss about the learning effect of the Alice. [29] This article describes their experience with the introductory programming module in Robert Gordon University. The initial emphasis of this module was placed on syntax rules, data types, and basic control structures. Primitive ideas about objects are given to students at the end of the module. Further object-oriented programming were given in their second module. However, this introductory programming module were problematic. Both the engagement and achievement of at-risk students were low. The major difficulty students were facing is the mathematical nature of programming. Students, especially those at-risk students, tend to have the idea that programming is all about math. They tend to think that “being good at math” is a prerequisite condition for programming, and they lack the confidence on math. In order to overcome these problem, the module needs to be redesigned. When redesign their module, their considerations are: 1. This module should engage the students. activities such as graphics and animations.. It should including engaging. 2. This module should make contact with the prior experiences of the students positively. 3. This module should be syntactically forgiving. 4. This module should give immediate feedback so that students can observe and build concrete experience with. 5. This module should introduce the basic object-oriented vocabulary. 6. This module should allow a smooth transition to Java. Item 1 and 2 are both connected to creating the interest of the students with programming, by engaging the students. As a result, they choose Alice as their tool for their module. The result of the new module is generally positive. 1. Transition to Java: Students at the second module did not report greater difficulties than the previous year. However, the difficulties of the at-risk students did improve. 2. Motivation: The participation (measured in terms of attendance and submission of exercises) and engagement (defined both in terms of participation and as a measure of how students of the students would go beyond the minimum needed to fulfill the assessment) increased. 18.

(30) Even the result of transition to Java does not look promising, the result is still overall positive. Students did get interested and enjoyed their programming experiences.. 2.3 Previous Research Greenfoot Greenfoot is very power in creating sounds, animation and object-interaction. Many researches with Greenfoot uses game creation as the learning strategy. The researches on microworlds or microworld frameworks in Taiwan mainly use Scratch and Alice. The only research using Greenfoot is the master thesis by YuTzu, L. (2011). [30] Yu-Tzu, L, in his paper “Effects of Game-oriented Teaching Material on Senior High School Students’ Programming Learning”, uses the quasiexperiment research design to study the difference of performance, attitude and selfefficacy between the top-down and bottom-up learning strategies with game design. The results indicated that students’ performance and attitude using top-down learning strategy were better than student performance using bottom-up learning strategy. However, this research was focused on the comparison of the learning strategies, but not the Greenfoot environment itself. There are more researches with Greenfoot itself outside of Taiwan. Al-Bow et al. in University of Denver held summer game camps in 2007 and 2008. [31] [32] They used Greenfoot as their game development environment. The 2007 camp is for high-school students. The result shows significant increase in the students’ confidence of programming, although students did not show enough increase in their own knowledge. The 2008 camp is for both students and teachers. This time students show increase in both their interest and their level of knowledge in computer programming. The teachers show increase of confidence with this pedagogy, too. They concluded that Greenfoot has positive effect both to students’ and teachers’ motivation and interest. Aedo, Díaz, Díez, and Montero (2010) in Universidad Carlos III de Madrid studied the effect of adding Greenfoot in CS1 in addition to the ordinary curriculum in their research “Dual instructional support materials for introductory object-oriented programming: Classes vs. objects”. [33] They were previously using jGRASP to teach Java programming in CS1. In this study they compare the effect of teaching with both Greenfoot and jGRASP, with the control group that are only taught jGRASP. Both the two groups show advance in scores, but the Greenfoot experimental group show significantly more increase. They conclude that learning with both textual and visual instructional materials can help students’ learning. Murphy and Villaverde (2012) from New Mexico State University took Greenfoot in a higher approach in their paper “Senior project: Game development using Greenfoot”. [34] They choose Greenfoot as their game development environment in their senior project. The reason they choose Greenfoot is because the class has only one semester, and Greenfoot is simple enough so that they don’t have to spend too much time on the development environment itself, that they can focus on the game design and development. They uses content analysis qualitative method on the progress of the class and the resulted work of the students. These students resulted in three great game projects with beautiful graphics, sounds and background music. 19.

(31) Some of them have even made the top projects on the Greenfoot community sharing website. They proved that Greenfoot indeed fit their purpose to be a simple yet extendable system that does not take much time to learn. They consider letting students learn Greenfoot off-class in the next semester. This study support the claim of Greenfoot that “Greenfoot scales well into older age groups. More sophisticated and technically demanding ideas can be implemented” (Kölling, 2010). DiSalvo, Guzdial, and Simmons (2012) from Georgia Institute of Technology uses Greenfoot in their CS workshop in the GLITCH game testers program in their paper “Using game development to reveal programming competency”. [35] GLITCH game testers is a program to engage Africa American students with computer science through game testing. Besides game testing, some of their time are devoted CS workshops. After two years using Alice and Jython, they found that students has a wrong perception with their true programming ability. They often over-estimated their true programming ability. They turn to Greenfoot for three reasons: 1. Greenfoot balances between simple access and larger concepts. 2. Greenfoot uses Java, which is consistent with the programming language that is used in the Advanced Placement program students may attend in the future. 3. Greenfoot is suitable to create games, which matches their daily game testing works. Their research employs a qualitative design, investigating the programming competency of the students but their projects and their learning process. The workshop is project-based. Students are split into six teams, and for some reason only data from three of them are collected. The result shows that students’ self-perceptions are adjusted and aligned to their true ability after these projects, and Greenfoot does help in this process.. 20.

(32) CHAPTER 3: RESEARCH METHOD During this study, an eight-week Greenfoot class was deployed on a class of 10th grade senior high school students. The class was given in the second semester of the school year. This Greenfoot class covered from Chapter 1 to 5 of Kölling’s (2010) textbook. Half of the weeks were dedicated to the practices of the concepts learned. In order for the practices of the students, four additional scenarios were given to the students, with two of them expressly designed for this study. A special Traditional Chinese translated version of Greenfoot was used for this study. The qualitative unobtrusive field observation method was used as the main data collection method. In order to justify the result, three other methods were also used. 1. Analysis of the Uploaded Projects of Students 2. Student survey. 3. Teacher interview.. 3.1 Participants 3.1.1 The Students The students are a class of 10th grade students in Taipei Municipal Nan Gang High School. There are 40 students in this class, with 19 female students and 21 male students. The Greenfoot curriculum was given to them in the second semester of the school year. The students were taught with MIT Scratch in their previous semester. The students have some basic concepts with repeating structures, selection structures (if-else statements), variables and procedural program execution. One of the students was a member of the computer science club and have learned Greenfoot and Java programming in the previous semester. Other students has no experience with text programming before.. 3.1.2 The Teacher The teacher has worked as a computer science teacher in Taipei Municipal Nan Gang High School for eighteen years. She graduated from the Information and Computer Education Department, National Taiwan Normal University at 1995, eighteen years ago, and worked in the school since. She returned to the university and obtained her master degree in the Graduate Institute of Information and Computer 21.

(33) Education, National Taiwan Normal University at 2004, nine years ago. The teacher is also very active in the teachers’ community. She works for the campus free software promotion group for many years. She constantly organizes teachers’ workshops on various topics of computer science education. The teacher knew about Greenfoot from a professor in the Graduate Institute of Information and Computer Education, National Taiwan Normal University since 2010, three years ago. She was trained with the C programing language in the college. She had no experience with the Java programming language at all before Greenfoot, and felt difficult with it. She learned the Java programming language from Greenfoot. She was surprised how easy Java programming can be learned with Greenfoot. She became very enthusiastic, and organized the Greenfoot Taiwan community, in order to promote Greenfoot among the high school teachers. The Greenfoot Taiwan community currently has 76 members, with scheduled one or two seminars each month. The teacher had taught Greenfoot in the computer science club of the school in the previous semester. She tried to bring her teaching experience with the students in the computer science club to the ordinary students in this curriculum. She had also given speeches for Greenfoot in some other events and seminars. Besides Greenfoot, the teacher is also very enthusiastic and experienced with MIT Scratch. During the time of this study, a new Chinese Scratch textbook written by her was published.. 3.2 Research Tools 3.2.1 The Greenfoot Software The version of the Greenfoot software we were using in this class is version 2.1.1. It was released in September 8, 2011. Greenfoot does not have official Traditional Chinese translation yet. The teacher had translated the Greenfoot UI into Traditional Chinese earlier in 2012. The researcher helped to translate the Greenfoot API documents, templates and textbook scenarios in July, 2012. Because of some MS-Windows encoding bug with version less or equal to Greenfoot 2.2.1, the Traditional Chinese translated class templates and textbook scenarios cannot be read with version less or equal to Greenfoot 2.2.1. The researcher had tried to debug, reported this bug and sent the bug fix to the Greenfoot team, and was accepted (with some modification). This bug exists until the release of Greenfoot 2.3.0 in April 29, 2013. But the Greenfoot class had already started at the time of the release of Greenfoot 2.3.0, and we had not verified the translation for Greenfoot 2.3.0 yet. For this reason, Greenfoot 2.3.0 was not deployed in the classroom, and the Traditional Chinese translated class templates and textbook scenarios are not used. As a result, this Greenfoot class used a special Traditional Chinese translated version of Greenfoot 2.1.1.. 22.

(34) 3.2.2 The Questionnaire of the Student Survey A questionnaire was given to the students after the end of the whole class. The contents of the questionnaire was designed with the following goals: 1. To provide the overall attitude of the students toward Greenfoot. 2. To justify the results produced from the analysis of the field observation, as described in 3.5.1. 3. To supply additional information that was not seen in the field observation. Based on these goals, the following questions were presented in the questionnaire: 1. I like to program with Greenfoot. 2. It is easy to program with Greenfoot. 3. I want to design my program with Greenfoot after class. 4. I could find the answers in Greenfoot documents when I ran into problems in Greenfoot. 5. I could find the answers in Java documents when I ran into problems in Greenfoot. 6. I’m more confident with programming than the previous semester after I learned Greenfoot. 7. It is easy to add animations and sounds in Greenfoot. 8. The functions of animations and sounds in Greenfoot help to increase my learning interest. 9. It is easy to add object interaction with Greenfoot. 10. The functions of object interaction in Greenfoot help to increase my learning interest. 11. It is easy to create different effect than others with Greenfoot. 12. Which scenarios are most impressive to me among the Greenfoot scenarios taught in this semester? Why are they most impressive? The first eleven questions were presented as Likert scales. Question 1 was used to scale the general interest with Greenfoot. Question 2 was used to scale the sub-goal 1 (Ease of Use) of Greenfoot. Question 3 was used to scale the engagement effect of Greenfoot, as in Brindley, Eccleston, and McDermott’s study (2008). Question 4 and 5 were used to scale the sub-goal 2 (Discoverability) of Greenfoot. Question 6 was used to scale the confidence with programming, also part of the engagement. Question 7, 8, 9, and 10 were used to scale the sub-goal 3 (Support engaging functionality) of Greenfoot. Question 11 was used to scale the exploration behavior. The first half of question 12 was presented with a check list of all the scenarios used in this Greenfoot class. This check list was also used as a reminder of the whole class. The last half of question 12 was presented as free text that participants can input freely. Question 12 was used as an in-depth introspection of the interest of the students 23.

(35) to each class unit, and may be used to support the feature 4 (Flexibility) of Greenfoot. A sample questionnaire is attached in Appendix A.. 3.2.3 The Outlines of the Teacher Interview An in-depth interview was taken with the teacher after the end of the whole class. The outlines of the interview was designed with the following goals: 1. To justify the results produced from the analysis of the field observation, as described in 3.5.1. 2. To supply additional information from the perspective of the teacher. Based on these goals, there are five questions in the interview outline. 1. Can Greenfoot create the learning interest of the students? Please give us examples. 2. Which designs or functions of Greenfoot can create the learning interest of the students? Please give us examples. 3. Can Greenfoot invoke the active learning behaviors of the students? 4. What is the difficulty to teach with Greenfoot? 5. In the seventh class (the Emoticon scenario), you have said that knowledge of the students was locked on the scenarios. Could you please further explain it? Question 1, 3, and 4 were the questions of this research. Question 2 was drew from the sub-goal 2 of the students of Greenfoot. Question 5 was drew from the discussion between the teacher and the observer in the seventh class in the field observation records. The outlines of the teacher interview is attached in Appendix B.. 3.3 Instructional Design The Greenfoot class was designed with the principles of practice. The students need to practice with the same programming concepts for proficiency. The Greenfoot class was based on the Kölling’s (2010) textbook, “Introduction to Programming with Greenfoot.” It covered from Chapter 1 “Getting to know Greenfoot”, to Chapter 5 “Making music: An on-screen piano” (p. 1–77). The following programming concepts were covered: 1. Classes and objects. 2. Methods, parameters and return values. 3. Method inheritance. 4. Constructors. 5.. if-else. conditional statements.. 6.. for-loops.. 24.

(36) 7. Variables. 8. Arrays. The Greenfoot class was given project-based and problem-based. For each class session, one or more designed scenarios (projects) were given to the students. The scenarios covered several different interests, including games, music, sounds, in order to engage the students with contexts that they are already familiar with. When scenarios were given to the students at the start of the class session, they were unfinished with several unsolved problems that covered the topics of the week. Some supporting Java classes and functions were included at the start to simplify the problem and hide the details that are beyond the scope of this class session. The students were then required to build the project and solve the problems with the methods and functions provided by the supporting Java classes. This followed the writing principles in Kölling’s textbook. The Greenfoot textbook scenarios we were using are listed below, with their covered concepts explained: 1. Wombats and leaves, Asteroids (Chapter 1): Greenfoot UI, object, class, method call, parameter, return value. 2. Little crab (Chapter 2, 3, 4): source code, method call, parameter, sequence, ifstatement, dot notation, random numbers, defining methods, comments, constructors, loops, state, instance variables (fields), assignment, new (creating objects programmatically). 3. Piano (Chapter 5): abstraction, loops, arrays. In addition to the above, the class was designed with goal of practice. After the students were taught with each new concept, a couple of practices concerning the newly-learned concept were given to students for proficiency. For the purpose of practice, four additional scenarios were adapted: 1. Fat cat (Week 1): Greenfoot UI, method call. 2. Pac-Man (Week 4, 5): method call, parameter, sequence, if-statement, dot notation, random numbers, defining methods, comments, constructors, state, instance variables (fields), assignment, new (creating objects programmatically). 3. Emoticon (Week 7): for-loops, arrays, if-statement. 4. Tank wars (Week 8): method call, if-statement, random numbers, defining methods, comment, constructor, variables, assignment, new (creating objects programmatically), for-loop. The Pac-Man and tank wars scenarios were expressly designed by the researcher for this Greenfoot class. The fat cat scenario was downloaded from the Greenfoot website, and is an official exercise for Chapter 2. The emoticon scenario was downloaded from Greenroom – the Greenfoot teacher online community – as an exercise of Chapter 5 (the piano scenario). The tank wars scenario in the last week (Week 8) was a comprehensive practice class. Students were asked to use the knowledge they learned so far to finish the tank wars scenario. A PDF document with prompting questions to finish the scenario was given to the students instead of the teacher guidance.. 25.

(37) The content of the Greenfoot class is attached in Appendix C.. 3.4 Procedures The Greenfoot class was deployed in the computer science class on a class of students in Taipei Municipal Nan Gang High School. The class took eight weeks, from April 3, 2013 to May 22, 2013, and was given in the second semester of the school year. The class took two hours each week, from 10:10 to 12:00 in the morning every Wednesday. During the eight-week class period, the observer and the teacher met in the morning every Tuesday, the day before the class, to check the materials to be used in the next day and discuss ideas. In the two hours of the class on Wednesday, the observer stayed at the rear end of the classroom, observed and recorded the teaching events and the behaviors of the students in the classroom. The observer used her smart phone as a recorder to record the sounds in the classroom. The recorded sound files were used as backup data sources for the field observation records. After each class, a short and simple interview with the teacher was conducted, to clarify the problems observed in the class. The observer and teacher might discuss about the class, the materials, and other opinions at this time. Figure 3.1 shows the map of the classroom. The observer stayed at the rear end of the classroom (except for Week 5) to observed and recorded the events. The rear end of the classroom is a small meeting room for teacher preparation. This room is physically separated from the main classroom with a row of iron cabinets. The iron cabinets are at the height of the waist. They acted both as a physical separator to avoid the observer from the students, and also as tables for the observer to write down the records.. 26.

(38) Teacher 1-1. 2-1. 3-1. 4-1. 1-2. 2-2. 3-2. 4-2. 1-3. 2-3. 3-3. 4-3. 1-4. 2-4. 3-4. 4-4. 1-5. 2-5. 3-5. 4-5. 1-6. 2-6. 3-6. 4-6. 1-7. 2-7. 3-7. 4-7. 1-8. 2-8. 3-8. 4-8. 1-9. 2-9. 3-9. 4-9. 1-10. 2-10 3-10. 4-10. Iron Cabinets Observer (Moving left/right) Figure 3.1 The classroom The only exception is the fifth class (May 1), where the observer experimentally stayed at the front of the classroom, in order to transfer her view ports to the students in the front half of the classroom. This did not work well for the following reasons: 1. There was no table-like things to write the records with. The observer could barely write on hands. The speed and quality of the records was seriously decreased, and the recorded text were too sloppy to recognize and transcript afterward. The only thing that the researcher could stably write on was the shoe cabinet, but it stunk and interfered the recording seriously. 2. The front side of the classroom was part of the traffic flow of the students. The students did bump into the observer when they got on or off the class, or went to ask others. It introduced a serious obtrusion to the students. Because of the above problems, the observer returned to the rare end of the classroom from the sixth class (May 8), and stayed there till the end of the classes. However, in order to balance the geographical effect that the students at the rear half of the classroom get more attention from the observer, extra attention was put to the students at the front half of the classroom. The questionnaire was given to the students after the end of the class at Week 10 (5/5) in the same classroom. 27.