IT World

INTRODUCTION

Many software tools have been built and tested with the main goal of improving teaching and learning activities, and the subject of computer programming is no exception. Nevertheless, teachers have continued to seek new ways to overcome difficulties met by novice students when initiating the study of programming concepts. Recent technological developments raise new opportunities in the educational field, such as the three-dimensional (3D) virtual world which provides educators an accessible means of creating a rich and compelling 3D context for situating learning, communicative tools to support discourse and collaboration [1]. However, comprehensive academic research about the use of these environments as a platform for teaching/learning computer programming is lacking. There has been some recognition in the academic literature about the benefits for the learning of programming derived from visualization [2], contextualization the study [3] and the use of games [4] but not the use of 3D virtual environment as platform to support programming learning. Hence, the aim of our study is to develop a framework for the use of a 3D social virtual world - Second Life (SL) - as platform for teaching and learning introductory computer programming in Computer Science (CS) undergraduate courses, based on meticulous academic research [5]. Essentially, we propose teaching introductory computer programming using SL, i.e., replace traditional language-development environments altogether by the SL environment. We have done so using SL's internal scripting language, LSL, albeit the features of the language itself are not a focus of study. For our research we employed an iterative action approach to analyze the teaching and learning process. This paper is divided into four parts. First, our motivation and related work is outlined. Then, the project methodology of focus groups is described. Finally, the findings and implications are discussed and possibilities for further research are identified.

MOTIVATION AND RELATED WORK

Learning how to program a computer is a difficult and demanding task. To become good programmers, students have to acquire several skills far beyond the syntax and semantics of the underlying programming language [6]- [7]. Students need to know how to solve problems and learn to elaborate algorithms, which make the computer programming learning process difficult. In fact, many students experience difficulties which result in high levels of failure in introductory programming courses typically taught in the beginning of computer science studies. Several research studies can be found concerning the causes of this failure [8]-[9]-[7]. One of the reasons mentioned is that many students entering their first programming courses are not prepared to think. In their previous college studies, they were generally exposed to a numeric computation that they didn’t have problem solving abilities [10]-[11]-[12]. Even the students, who have adequate problem-solving skills and are able to construct an algorithm for a given problem, present difficulties in pass that algorithm in an appropriated programming language [10]. Another reason for failure is that students claim that they don’t like programming because they have some difficulties in understanding even the most basic concepts of programming [6]-[10], such as variables, data types or memory addresses because these abstract concepts don’t have an equal representation on real life [10]. In addition to these difficulties, the traditional teaching method, often based on lectures and specific programming language syntaxes, fails a lot of times in what concerns to the students’ motivation in getting involved in meaningful programming activities, as Lethbridge [13] said “In no other discipline is the gulf between best practice and typical practice so wide.”

Visualization has been proposed as a way of reduce students’ difficulties. Several studies have been published trying to evaluate how visualization could help programming learning and which type of visualization and accompanying material are more effective [14]-[15]. Although it is possible to find studies with contradictory conclusions, it is also probable to find interesting suggestions and comments. For example, Hundhausen [14], in his visual feedback study, concluded that, at least in the case of novice imperative programming environments, the benefits of delivering a continuously updated visual representation of a program’s execution may fail to justify the substantial costs of implementing such feedback. Andries van Dam [16] defends that visualization and visual tools in learning help students to understand better the concepts because physical, spatial or visual representations are easier to retain and manipulate. Having an immediate display of the results of an action, students can find out at once if their idea is right or wrong. If it is wrong, in that case they have to correct, rethink their solutions and consequently this will stimulate their critical thinking [4]-[17].

Papert’s LOGO [18] language creates a mathematical world in which principles of geometry are visible. LOGO offers students the opportunity to create a line drawings with an electronic turtle displayed on a screen. In this environment, users can receive an immediate feedback about their programs, easily determine what has happened, quickly spot and repair errors and can experience creative satisfaction. Karel, The Robot [19] uses the same principles, and it is a programmable visualization software robot. The robot executes a sequence of commands that the user has written as part of a program moving about two-dimensional grid. Alice is a 3D interactive graphics programming environment for windows [20]. It is also an object-oriented by writing simple scripts which its users can control object appearance and behaviour. The benefits of using it allows students to be involved and at the same time have the ability to develop an intuitive understanding of basic concepts in a visual feedback environment [21]. These results influenced some of the opinions we have had when we think about using 3D virtual world Second Life (SL) as an environment to teaching / learning a programming language. Before we proposed the utilization of SL to our students and colleges, we felt the need to do a study with the aim to explore the viability of this environment. In the next section we will present the experience that we have been developing.

DESIGN AND METHODS

The main objective of this study is to find out if and how could SL be used as a platform for teaching / learning the imperative programming language paradigm that is commonly taught in college-level computer science courses. For this purpose, we have employed action research (AR) methodology, that is, a cyclical process approach that incorporates the four-step processes of planning, action, observing and reflecting on results generated from a particular project or body of work [22]. This choice was made in view of two main advantages of AR [23]: it allows us to study a problem while introducing controlled changes, with the aim of discovering how to improve the processes of learning and teaching [24]; and it provides the researcher with a large degree of flexibility, something of great importance when acting within an evolving information technology project concerning a problem about which little was known beforehand [23]. The first action research cycle started by planning a model for teaching introductory programming concepts in SL. To that end, it was necessary to make a preexploratory research and pre-observation with the goal of identifying problems and planning actions [25]. Initial plans were formulated, and actions for their prosecution were devised and implemented. While the action (teaching-learning) took place, results were monitored for reflecting later on. The data collected for the reflection step of the action research methodology was based on daily session reports, classroom images and questionnaires. The reports, written down by the teacher-researcher at the end of each session, describe what happened during the class, indicating all the critical incidents and its implications. Classroom images (screenshots) have been taken in order to assist the teacher to review the lesson when necessary, such as when a critical incident had happened. Questionnaires with open questions concerning the learning / teaching method were presented to students at the beginning, middle and end of the process, to provide further information on the learning process. These elements are used as a tool to adjust and improve the learning / teaching approach. The final step in the first research cycle was reflection upon the outcomes and based on them planning the next cycle. This goes on until the reflection of a cycle showed that the problem was then solved or level of knowledge achieved is fixed, the study was concluded and a report prepared [23]. In this study we have made a pre-exploratory research, a first and second cycle. The pre-exploratory research took place during the second semester of the academic year 2006/2007 and the first/second cycle of action-research append in first semester of the current year (2007/2008)

I .Participants

Our participants are computer science students from the University of Trás-os-Montes e Alto Douro (UTAD), in Vila Real, Portugal, and of the Higher School of Engineering and Management (ESTG – Portugueselanguage acronym) of the Polytechnic Institute of Leiria, Portugal, as elective alternative assignments on the compulsory subjects: Laboratório de Informática I of the 1st curricular year (Lab I); Laboratório de Informática II (Lab II) and III (Lab III), of the 2nd curricular year (at UTAD); and Projecto I, (at ESTG). In all cases, these subjects have their main aims to allow students to develop a semester-long project, to improve programming skills. We had three types of students: a group of beginners (group A); a group with some knowledge of programming (group B); and a group experienced in programming concepts (group C).

The A-group students, at the UTAD, were enrolled in the 1st year, 2nd semester, at an initial stage of learning how to program, even though they had been exposed in the previous semester to introductory aspects of the programming, in about 30% of two subjects (vd. table 1). The project made in SL was the first contact with a programming project (not just an exercise) for these students.

The B-group students were more advanced in learning how to program: at the UTAD, they were enrolled in the 2nd year, 1st semester, and had studied in the previous semester introductory aspects of the C programming language and developed a command-line project in C, and while participating in this research they were also taking a course on object-oriented programming in C++. At the ESTG, students were enrolled in a post-secondary technical course (CT) and had previously studied C programming (vd. table 1). The project developed in SL was their first project (i.e., not just an exercise).

The C-group students, at the UTAD, were enrolled in the 2nd year, 2nd semester, and thus at a more advanced stage of learning how to program: they had completed courses in C and C++ programming, and developed a command-line project in C++ (vd. table 1). Although still requiring teacher support often, these students had already some autonomy in using and studying programming.

In the exploratory research participated 5 students from group A and 4 students from group C, in both cases from UTAD. In the first and second action-research cycle, students were only of group B (10 students from UTAD and 6 from ESTG).

II. Materials and tasks

All participants worked on Pentium IV computers running the windows XP operating system, with 1 GB of RAM and

somewhat limited bandwidth. We proposed a project for students to develop, i.e. we specified what kind of object should be devised, including features and behaviour, and students had to construct objects following thisspecification.

II.I Programming environment

The programming environment was SL itself, not any offline editor. SL is a persistent on-line 3D virtual world conceived by Philip Rosedale in 1991 and it is publicly available since 2003 [26]. It allows large numbers of users to connect, interact and collaborate simultaneously at the same time and (virtual) space. Figure 1 shows a typical programming session in this research: we can see 6 avatars on black rugs (students programming) and two other – teachers’ avatars.

SL programming is done with a scripting language named Linden Scripting Language (LSL), which has Cstyle syntax and keywords. 3D objects created in SL can receive several scripts that are executed concurrently. Each script has its own state machine: program flow is sequential, but structured by triggering events and responding to them (through either environment interactions or programmatic components), besides common methods from imperative programming, such as procedures and flow-control primitives. The programmer defines the states of each state-machine and how/when to switch state. The language’s programming libraries include functions for communication with external servers: sending and receiving e-mail, XML remote procedure calls, and HTTP requests and responses. SL enables synchronous collaboration among students because the system permits two or more avatars to edit the same object and share the same code while programming it. Figure 2 presents two avatars editing the same object (a car): left window shows the car’s contents, one being a script that is opened by double-clicking. The script code (figure 3) collects the name of all cars nearby and shows them to the car’s owner (function listProdut ).

III.II Procedure

The project was presented to all students in the first session, after which some students volunteered to participate in this research. From this point on, they formed groups of two elements and developed their projects inside SL, collaborating with each other. Teachers and students met in-world once a week, for about two hours, to keep track of students’ progress, exchange ideas and make suggestions. Face-to-face meeting did not take place, because the teachers-researchers were in Leiria and the students in Vila Real, 270 km apart. Once a month we meet us at Vila Real to talk about the project.

The general procedure for a given virtual world sessions was as follows. Upon arriving at their virtual lab section, students inform the teacher (on-line), what doubts they may had and what they had been done in the project, since last section and then they continued their work. When students had some difficulty about the code they had implemented, they shared it with the teacher, so they could observe and at the same time find out what was wrong and follow the teachers’ indications/instructions. In this way, the students corrected the code and went on. At the beginning of a lab session, the teacher explained the concepts that students had doubts and stimulated them to find out the solution to their problems. At the closing of the session, the teacher said what they have to do during the following week.

PRELIMINARY FINDINGS

In the pre-exploratory research several difficulties were found:

Teacher’s perspective:

1. Managing communication amongst participants – a public chat was used to communicate and when there were more than two people talking at the same time, which turned it difficult to understand who was saying what;

2. Spatial arrangement of student avatars - students were disperse on the lab space, so teacher avatar had to move very often near one group of students to observe and explain the doubts that they might have and then move again around to another group. This way, teacher might lose the notion of the global class.

3. Discovering students’ difficulties during selfstudy - Outside the weekly guidance session, the students kept on developing their work and in the following lesson, they could tell the teachers the difficulties they had faced and present what they had already done. For a better guidance, it would be useful to have a mechanism that could inform the teacher, by email or another outside system, about what the students had done throughout the week, the difficulties they had felt and attempts to overcome them.

Students’ perspective:

1. Difficulties using the SL interface – students felt some difficulties in the use of the SL editor, for instance, how to link, copy or to line up the objects.

2. Understanding compilation errors and LSL semantics - students who were in the beginning level of the study felt some difficulties to understand the LSL semantics and deal with the compilation errors.

3. Selecting adequate library functions for object control- The biggest/greatest difficulty felt by students in advanced level consisted in selecting the functions to use and implement one kind of functionality. By reflecting upon these problems, we devised a first structured approach to prevent, minimize or tackle them, forming the basis for the first cycle of action research. During this cycle, different computer classes (B group from UTAD and ESTG), employed LSL/SL to develop two kinds of projects: programming motions and behaviours, and more traditional text data processing. In the second cycle, we have done some changes on the projects proposed to the students, namely in the introduction of a more traditional text data processing, a graphical component and in the other project a text data processing. In this way, we intend to observe the students’ reaction, i.e. if there is a change on their behaviour and motivation.

The 1st and 2nd problems reported in pre-exploratory research, in teacher’ perspective, were completely solved. To communicate, we made the following procedure: a public chat has been used only by a teacher to explain contents or give advices to all students; a private channel called instant message has been used by the teacher and students to communicate individually among them. Students said they liked this way of communicating because they felt they had a private teacher and could put their doubts without feeling embarrassed to be lagging in relation to the others. In the teacher’s point of view, a deep connection was set up between teacher and pupil and that is not so easy to achieve in traditional classes. Students, in the virtual lab session, were distributed around the teacher in areas of work that were defined by a black rug. In this way, and because of the communication mechanisms that were used, the teacher doesn’t have to move around and doesn’t lose the overview of the class. For the 3^rd problem, we tested a solution but it didn’t work. So,we are still looking for a better answer to it.

The problems found in the students’ perspective were partially solved. To the students from A and B groups, it was decided that they should begin with simple examples that they had to try and modify. Every time they had difficulties in understanding it, some explanations were made in each part of the code. Therefore, students could understand what these small programs could do and the objective of each one. According to the personal experience of the programming teachers and by the literature read in this area [10], it is known that this situation is difficult to reach when students learn to program in traditional environments, as command line for C compilers, where the students generally feel great difficulty in perceiving the programming objective. A particular important aspect in programming learning is the students’ reaction to the compilation errors [7]-[3], which are inevitable in the learning process. In group C, the students corrected the compilation errors whenever they happened without the teachers’ help, whereas the group A and B, the students found themselves without knowing the reason why it occurred and didn’t know how to correct it as well. So, they need the teacher’s help to correct the problems. Through questionnaires review and by the conversation between teacher and students, it has been remarkable that: most students do have a positive or neutral attitude towards graphics richness of SL, but a minority dismisses it as “unserious,” “awkward,” or “complex”. Students learning how to program by programming physical interactions in SL (e.g., making a dog follow you and obey your voice command) are typically motivated. Students, who focused primarily on non-visible techniques such as data structures and string processing, benefiting from the environment just for enhanced context and not a source of feedback for programming behaviour, did not seem to exhibit any motivational advantage over students who employ a traditional console-oriented (text-only) approach.

CONCLUSIONS

This study has not finished yet. We are still working with one more group of students. The current findings from these efforts indicate that 80% of participants had a bad experience in learning a programming language and because of that they want to try a new form of learning. This shows a few dissatisfaction by the way students learn a programming language, Lethbridge [13] refers the number of students in computing disciplines have decreased in U.S. since 2000, and points out some reasons for that such as: young people are so immersed in computers that they do not see the excitement to them any more and the stereotype of the ‘nerd’ coding all night with no social contact, leave the students avoid these areas. With SL, we observed the opposite: the students are not without social contact when programming and they are excited. Two events have impacted students’ engagement that were: we have a student that received a proposal by an avatar in SL to buy his programming assignment, not as a violation of the student’s conduct but as a sanctioned exchange of virtual commodities; another student received a professional proposal to provide SL programming services for a company. Scripting, we learned, is a marketable skill in SL even at an introductory level. By deploying our students in a publicly accessible virtual world, thus, we inadvertently exposed them to the powers of an authentic microeconomy, and these social forces serendipitously contributed to our students’ “on-the-job” engagement in developing the very core skills targeted by our experimental unit.

Throughout our study, we observed that students are more interested and motivated in learning, so we are in tune with Lethbridge [13] when he says it is necessary to improve the education of software engineers. This study is a first step in that direction because the students who are studying in a traditional way feel unmotivated and don’t understand the reason why they have to learn writing code. Morgado [27] points out that SL, a cutting-edge technologically advanced 3D immersive environment, may harbour opportunities for powerful “back to basics” learning of introductory programming, in terms both of content and context: content - SL coding employs simple devices and practices, without complex development environments or complex compiler errors, with immediate perceptual feedback; and context - beginners’ applications are quite similar in look and feel to experts’, as it was the case in the old days before the graphic users’ interfaces. As future work and research to be developed, we point out the need to find out an automatic mechanism that follows the student in the world, answer their questions and clarify their doubts when the teacher is not present, at the same time record all this and send it back to the teacher. So, the teacher could follow the student’s progress / effort and help him / her in a more effective and direct way. We also intend to develop a blackboard inside the world so the teacher can write quickly his / her ideas and share them with the group.