A Collaborative Project to Improve Teaching and Learning in First Year Programming
Dianne Hagan
Faculty of Information Technology
Monash University
Ian Macdonald
Faculty of Education,
Monash University
Abstract
In 1995, at Monash University, first year computer programming students in the Faculty of Computing and Information Technology were perceived as having an unacceptably high failure rate and a comparatively low retention rate. A collaborative project between the faculties of computing and education, beginning with a study to identify the problems experienced by students and staff, has resulted in a series of modifications to the structure and delivery of the subjects, and the development of a tutor training course. Responses of staff members and students have been mostly positive, and the subjects are still being improved each year. The transition from high school to university life, in which students were expected to adjust immediately to a different style of teaching and learning, was part of the problem. This paper describes the approach that has been adopted and which has resulted in improved learning behaviours. It also demonstrates the way in which a collaborative, cross-discipline approach to educational change can affect the teaching and learning process.
Introduction
In 1995, concerned at the percentage of first year students who were failing or discontinuing their computing studies, the Dean of the Faculty of Computing and Information Technology at Monash University asked the Faculty of Education for help in improving the level of teaching expertise within the Computing faculty. Most of the Computing staff have no formal teaching qualifications or training, having been employed for their computing expertise. They tend to base their teaching style on memories of lecturers or tutors that they considered effective during their own undergraduate years. Their teaching methods are therefore those that worked well for them, but that may not work well for most of their students. Many environmental changes have taken place in the last ten years or so, giving rise to a need for new techniques. These changes include increases in class sizes, number of students per staff member, and number of international students. Staff have had to develop expertise in producing high-quality computer presentations, maintaining subject websites and mastering other technological tools, all of which add to the workload of running a subject.
The initial request by the Dean of Computing was for a series of seminars on the latest teaching research and techniques. However, the Education faculty declined to provide these, recognising that they alone were unlikely to produce any real or lasting change in teaching behaviour. Faculty were also concerned that the high failure rates may be part of a more complex, integrated problem that was influenced by more than the teaching knowledge of academic staff.
The Education faculty suggested instead a research project to determine the source and nature of the problems in learning computing before any solutions could be applied. Introductory programming was chosen as the focus of the initial effort, as it is a subject taught in every course offered by the computing faculty, although in very different ways for different courses, and using different programming languages. Two Departments volunteered to take part in the project: Software Development and Computer Science. The Education faculty members were very unwilling to perform this research as "outside experts", and so a collaborative team (the "Edproj") was established to study the existing first year programming subjects in the two Departments and to suggest improvements that could be made.
The Edproj team consisted of the Associate Dean (Teaching) of the Computing faculty, two academics from the Education faculty, two lecturers in first year programming from the Software Development department, and the assistant lecturer in charge of coordinating and supporting the first year programming subjects in the Computer Science department. A few other computing faculty staff were also involved from time to time.
The two computing departments involved were on different campuses and had different philosophies: Computer Science was part of the traditional university with a primary interest in research, and Software Development was part of a former College of Advanced Education which had been merged into Monash University in 1990, and thus had many more staff members whose primary interest was teaching. The focus of the Computer Science course was leading-edge computing research, whereas the focus of the course taught by the Software Development Department was best-practice in commercial applications of computing. The responses of the two departments to the research project were different.
This paper focuses on the response of the Software Development department. The Computer Science experience has been well documented in conference papers such as Macdonald, Mitchell, Gunn & Carbone [1], and Carbone, Mitchell & Macdonald [2].
The Students
The composition of the student body has changed since most academics completed their undergraduate degrees, consisting now of many more students than before, a large number of whom are international students with their own cultural backgrounds and learning approaches. As more local students are also accepted now, a wider range of abilities is found among them. There are full-time and part-time students, day and evening classes, and large variations in age, prior knowledge and experience, motivation, and expectations.
In the subjects run by the Software Development department, the number of students enrolled at the beginning of a year was typically about 400. In 1995, about a third of these would have had no experience of computing at all, and almost all would have had no experience of programming. These proportions have become lower each year since then.
In all computing courses in the Faculty of Information Technology, first year programming is compulsory and is seen by most students as the most difficult, least interesting and most time-consuming of their subjects. This is partly because the kinds of programs now required, and the programming languages in which they are written, are more complicated than those used ten or twenty years ago. It is also because learning to program involves research, experimentation, and problem solving, and many students lack these skills and must learn them as well as the programming language itself.
Typically, students find the subject interesting at the beginning, but by about week 5 find it becoming very challenging and requiring a great deal of time. Some students begin to lose motivation and interest. Programming is a particularly cumulative subject, as each concept and technique builds on all the previous ones, and students cannot related it to anything they have done before. It is not possible to ignore one topic if it proves difficult, as that will block understanding of later concepts. Learning programming requires great attention to detail, perseverance and a willingness to ask for help when necessary: attributes not characteristic of first year students grappling with a much broader transition to university.
The Teaching Staff
At the time of Edproj academics were promoted exclusively on the basis of research, not on teaching performance. Teaching was therefore seen by some as comparatively unimportant and some lecturers devoted as little time as possible to it, concentrating their efforts on their research. Research related to computing education was not considered worthwhile in the Computing faculty. Staff who were interested in improving their teaching were not rewarded for doing so, and were given very little support. Never-the-less there were some staff who enjoyed the teaching role, and deliberately chose to take on high load first year subjects. There were also a large number of post graduate students, who depended on money earned by tutoring or demonstrating in laboratories, who had an interest (albeit sometimes only pecuniary) in teaching.
In the Software Development department, there was a tradition that the lecturer taught at least two tutorials in his or her own subject, to keep in touch with how the students were coping with the material. All administrative work related to the subject (e.g. handling tutorial timetabling and changes to enrolments, liaising with the computer centre about computer laboratories, writing and marking tests and examination papers, recording and collating results, organising and coordinating tutors) was also done by the academic staff. Many academic staff took tutorials in other subjects, to keep in touch with what was happening in the rest of the degree program. Financial constraints within the Department over the last 5 years had resulted in reduced numbers of academics, an increased number of students, a consequential increase in workload for staff, and hence increased pressure on them to perform better with less support. Staff were also required to demonstrate research productivity and perform administrative tasks not directly related to their teaching (e.g. committee memberships).
Most of the tutors in the undergraduate subjects were postgraduate students. In the Software Development Department, they were paid at a comparatively high hourly rate for the two hours per class per week, but were expected to contribute generously of their time to provide individual consultation for their students outside class time, a minimum of one hour per week for each scheduled hour of class time. They were also expected to help with the administration of the subject as requested. Most were keen on teaching and very willing to do all that was asked of them.
In the Department, the number of tutors engaged in teaching first year programming was typically about 18, with some permanent lecturing staff also tutoring - including the lecturers for the subject.
The Initial Study
The initial stage of the Edproj involved extensive observations by Education staff of first year programming lectures and tutorials, interviews of all lecturers and many tutors, and some interviews with students. A random selection of students were invited to be case studies, and were interviewed each month during the second half of 1995, to obtain in-depth qualitative data about the students’ experience and perceptions. All members of the research team were assigned students from a different campus to interview, so that their interviews were not affected by the students' fears of possible repercussions. Edproj guaranteed that staff members would not be disadvantaged by participating in the surveys, observations and interviews, whatever results emerged. The internal Edproj team members were also assured by the Computing faculty that this research would be considered legitimate research activity, and therefore worth the amount of time they needed to devote to it. An attempt was made to collect data from larger numbers of students by surveying them via email during the semester, but this was not very effective.
At the end of the semester, a report was presented to the Dean. This report covered both departments that had been investigated and, although written in a non-specific way, contained some observations that could have been damaging to certain members of staff, so it was not made available to the rest of the faculty. This engendered some resentment among tutors who had participated in the interviews on the understanding that they would see the final report, even though a summary of the recommendations was prepared for them. It did, however, reflect the great sensitivity that exists in any faculty area when academics feel that their teaching is under any sort of review, and the conflict between transparency and confidentiality in any research on teaching.
The primary finding reported was that the students were struggling to learn well, and that the major learning vehicle for students was not the lectures but the small group situations such as the tutorials in Computer Science and the laboratories in both departments. Teaching quality varied widely in that context, exacerbating some general problems students had in adjusting to university both academically and socially. As the small group sessions were important opportunities to meet other students and forge vital friendships and study partnerships, the students experiencing didactic monologues that discouraged or entirely prevented any student-to-student interaction were being significantly disadvantaged in ways beyond the academic.
There were also recommendations about restructuring and redesigning the content of the lectures, and providing discussion classes for students to complement the existing closed laboratories. As the payment schemes for tutors in the two departments were quite different, a recommendation was made regarding this, too.
At this early stage the problems were seen as primarily teaching and learning related, and the recommendations were made in that light. Subsequently, as the recommendations were implemented and data recorded, it became apparent that this issue was only a subset of the broader transition problem first year students faced, and changes to the teaching and learning environment could have far broader reaching affects than simply improving academic grades. The data collected in the context of programming was remarkably consistent to the Australia wide data of McInnes and James [3] when they looked at the experiences of first year students, and a follow up DEETYA funded investigation of the problem [4], suggesting that the problem was more than simply a difficulty with teaching the challenging subject of programming.
Implementation of the recommendations
It was left up to the two departments to decide how they would respond to the recommendations. As stated earlier, this paper is concerned with the Department of Software Development response.
Students in a first year programming subject attended one two-hour lecture and one two hour tutorial/laboratory per week. One recommendation was that an additional type of class be provided for students, i.e. a one-hour discussion class to be held in a room without computers. This class was to allow students to talk about their understanding of programming concepts, as this is seen as crucial to their learning. Small group activities would be used to stimulate discussion and to encourage shy students to participate. Another reason for introducing this type of class was that students would very quickly get to know each other and begin to feel part of a group. One of the major reasons for students dropping out of university in their first year is that they feel isolated and not part of a community based around the institutions [5]. The entire class of about 400 was broken into tutorial groups with a maximum size of 16, and the same tutor took each tutorial group for both discussion class and lab session to assist in building a "learning community".
The two-hour lecture was changed to two one-hour lectures, with the discussion class between them and a lab session after the second lecture. Observations had shown that students tended to disengage with the lecture in less than one hour, and two hour lectures were likely to be ineffective. At the lectures, copies of all the PowerPoint slides were handed out to the students, so that they did not have to worry about copying down what is being displayed, and can instead think about what the lecturer is saying. This was considered more effective than just making the slides available on the World Wide Web, as students need to have the notes during the lecture, and it is much easier, and ultimately cheaper, to print them en masse than to have 400 students trying to find available computers in the labs to download and print the notes before the lecture.
A three-day tutor training program, focused on teaching introductory programming, was developed by the Edproj team. The program was to be run separately for the two departments because of the numbers of tutors involved, and was to be presented jointly by staff members from Education and the appropriate Computing department. The structure and content of this tutor training scheme are described in detail in Gunn & Macdonald [6]. It focused largely on how to run the discussion classes in ways that would promote quality learning. Emphasis was placed on how to get students to talk and help each other to solve their own problems with some guidance from the tutor, rather than tutors supplying answers and solutions. Training was targetted to specific needs of the tutors in the subject of programming, rather than giving "generic" teaching tips that have are hard to translate into daily practice.
The Software Development Department took the initial report to the Dean very seriously, and decided that not only would all first year tutors be required to do the tutor training course, but also that all permanent staff members should be involved in tutoring these subjects, in order to upgrade their teaching skills. An advantage of this was seen to be that the most experienced academic staff would be teaching the first year students, and would provide the highest quality teaching experience. In fact, it became evident that it was much easier to train a new tutor to use the modern, student-focussed techniques espoused by the training course than to change the ingrained habits of a staff member who had been tutoring for a long time in a different way [1].
The tutor training program was followed up by a weekly staff meeting of the tutors in the first year programming subject. The purpose of this meeting was to reinforce the training program by reminding tutors of the techniques taught in the training course, discussing attempts that had been made to use them in the previous week with any successes, failures and possible improvements, and ways that they might be implemented in the following week's classes. At the beginning of semester, the lecturer asked for two student volunteers (one male, one female) to attend these staff meetings and represent the students’ point of view. These students were asked to talk to as many other students as possible to learn of any problems. Their input to the meetings was very valuable. If there was a problem with the workload or understanding a particular concept, action would be taken to rectify the situation.
A "Teaching Community" [7] approach to the subject was adopted, whereby the Lecturers in Charge were seen as being just part of the team teaching a subject rather than as authorities handing down the work to be done to subordinates. Tutors were expected to attend all meetings and contribute ideas, suggestions, anecdotes, teaching materials, examination questions, etc. Discussions took place each week about the "Big Ideas" to be taught in the following week, and how they could best be taught in lectures, discussion classes and lab sessions. The "Big Ideas" are the concepts and underlying principles that students were intended to learn, rather than the implementation details. For example, the lecture might be about functions and parameter passing with examples using the syntax of a particular programming language, but the Big Ideas might be abstraction and modularisation. Often there was animated discussion in the tutors’ meetings about the meaning of a particular concept in computing, as different tutors would have different understandings of its meaning. Computing is a comparatively young discipline, and many of its terms and concepts are still new. It is also changing constantly. It is important that the view presented by the tutors matches the view of the lecturers, otherwise students become confused. Tutors were also encouraged to attend the lectures so that they were familiar with the approach that the lecturer was taking.
The most important part of the Teaching Community meetings was the opportunity for the tutors to discuss likely student misconceptions and to develop specific teaching strategies that would give opportunities for the students to interact with each other, build relationships, and construct meaningful understanding of the key concepts. With so many committed individuals contributing, the range of ideas and innovations generated each week was remarkable.
For the first two years, the tutor training course was presented jointly by Computing and Education staff, and an Education staff member attended the weekly tutors’ meetings. This lent a voice of authority to discussions about teaching and learning, and assisted the process of interpreting the experiences of the tutors in terms of the training course concepts. Since then, the Education involvement has ceased, and Computing staff are running the training program and the tutors’ meetings alone. This has made it more difficult to convince some new tutors of the validity of the teaching philosophy, but also reflects the development of educational expertise in the ongoing staff.
Helping students with programming problems
As it is at about week 5 of the first semester that many students start to fall behind and lose interest in the subject, at this point a test worth about 10% of the total marks is given. It is intended to be reasonably easy, so that it builds up students’ confidence, however, anyone who fails it sees that he or she has serious problems and needs to address them immediately. Tutors advise anyone who has failed the test to seek individual help, but most such students do not do so.
To make it easy for students to get help almost immediately with programming problems, several kinds of assistance are provided. Tutors are rostered onto a helpdesk for one hour per week for each tutorial they take. The helpdesk is a well advertised room, that is open for much of the week, equipped with computers and other resources where students can seek help about any aspect of the programming subject. This helpdesk replaced the system of each tutor being required to specify consultation times for his or her own students. Because there are about 24 tutorials in the subject, there are about 24 hours scattered throughout the week that this service is available, including some convenient for evening students. Students can bring their programs along and ask for help. Tutors will not simply correct the code, but will prompt the student with questions to help them to find the solution to the problem themselves. Some students find this very frustrating, become angry and resentful, and give up using the helpdesk, but most understand that it is necessary to learn to solve their own problems, and that this is the way to do it.
There is also a website that contains all the documentation for the subject, including the subject handbook, PowerPoint lecture presentations, weekly exercises, assignment specifications, etc. It also has examples of how to do some things that students traditionally find difficult, and a frequently asked question file. Perhaps the most important element is an anonymous feedback page in which students can ask questions or make comments about the subject. The feedback postings are automatically emailed to the lecturers and a few of the tutors, so that someone usually responds to a posting within a couple of hours. This facility is described in detail in Hagan [8], and has become more popular each year since it was introduced, with over 800 postings during semester 1, 1999. It also gives students some sense of ownership of the subject, as they can see that their concerns elicit an immediate response and can produce changes in the way the subject is run. Anonymous feedback has been much more effective than a newsgroup, as many first year students are very reluctant to identify themselves when asking questions or making comments, although this reluctance diminishes as they progress through the course and become more confident [9].
Students are also able to email the lecturer or their tutors directly to ask for help. They are encouraged to read the lecture notes and the textbook first, and to try other sources such as online help and their peers, before turning to staff for help.
Preparing students for the subject
One of the problems with transition seems to be that students have unrealistic expectations of university life. They imagine either that it will be just like school, or that it will be a harsh, uncaring place where they will be left to sink or swim on their own.
Students in the Bachelor of Computing degree attend a presentation by the course leader during enrolment time, where she explains that they are expected to spend on average 48 hours per week on their studies, and that undertaking too much outside work is very risky. She also explains that there are many people in the university who are willing and able to help them, and that asking for help when it is needed is a smart thing to do, and not a last resort when they have already failed subjects. Most students either ignore this advice, or are in such cognitive overload, due to the barrage of new information to which they are exposed, that they do not register it.
At the first programming lecture, the lecturer warns the students that this subject will probably require more time and effort than the others, and that 12 hours per week of study is a reasonable estimate for it, not an exaggeration. They are also shown all the avenues of help available to them, and the advantages of getting to know other students and helping each other with work are discussed.
At the first discussion class, an icebreaker activity helps students to get to know one another. Students are then put into small groups to discuss what they see as the role of the tutor and the role of the student. The small groups then report to the entire group. The tutor makes sure that he/she uses the names of the students at all times so that, within a couple of weeks, everyone knows everyone else’s name. If necessary, for the first couple of weeks students have their names printed on cards in front of them. Furniture is rearranged so that students are not sitting in rows, with their backs to other students, facing the tutor at the front of the class. Horseshoe or table groups put emphasis on fellow students as a learning resource, and de-emphasise the centrality of the tutor as a source of all learning.
In the laboratory session each week, students implement some of the techniques they have been shown in the lecture and have considered in the discussion class. A tutor takes the same group of students for both the discussion class and the lab session, both to ensure continuity of concepts, and to foster a sense of belonging among the students and to help them to get to know each other and form a learning community. They are encouraged to work collaboratively on the exercises during the lab sessions. Students are discouraged from changing tutorial groups, although this is impossible to prevent entirely. Depending on how much change has taken place in the membership of the group since the last class, it may be necessary to run more (and different) icebreaker activities in weeks after the first. This progressive engagement of the students in the subject and its requirements has proved the most effective way to induct students to the university.
Monitoring the effect of the changes to the subject
As mentioned earlier, an attempt was made to interview students via email from time to time, but this was not very successful. A far better method was to use the subject website, and ask all students at the beginning of a tutorial in each of several weeks to respond to a radio-button survey. This survey asked questions about how well the students were coping with the subject, which types of classes they found most useful, how useful they found the textbook, the website and handouts given in lectures, etc. The results of the surveys were mostly positive, and were used to progressively "fine tune" the resources.
A survey of tutors after the subject was finished indicated that most enjoyed teaching the subject more after the training course, felt more confidence in their teaching ability, and found the tutors’ meetings of great benefit. For many the sense of belonging within the faculty that was generated by their integration into the teaching community was a significant factor in their enjoyment of their own research agenda, as well as their teaching.
Measuring improvements in performance of students is not a simple matter of comparison of marks from one year to the next. Exam marks are probably one of the least reliable and valid measures of learning, but retain their premier position due to the lack of a universally accepted alternative. Exams are set to be similar each year, but inevitably vary in difficulty and in the weighting of content topics. Particularly in computing the nominated content changes from year to year as the subject evolves or new programming languages assume dominance. Teaching staff change. Cohorts of students vary as fashions in degrees wax and wane.
So many variables were changed by the intervention in all its manifestations that it is difficult to ascribe any particular cause and effect between a variable and exam marks with any mathematical significance, even if the variable could be quantified. Academic performance may have been the driving force of the original Edproj collaboration, but as previously mentioned, the many issues that affect student performance in first year particularly are influenced in many subtle ways by changes to the learning environment that may not be directly driven by teaching. The ability to make friends and build a social and learning community may result in a student being better integrated into the life of the university, with a greater resistance to discouragement and withdrawal. Such a student is likely to do better in formal assessment, but this is hard to directly attribute to icebreakers and group work in tutorials, though they may have played a very important part in initiating the social interactions.
All the above qualifiers may seem like the "softening up" for poor results, but in fact comparisons of tests, exams and assignments before and after the intervention showed strong improvements, improvements that have been sustained for several years. Overall results for the subject have shown a sustained one grade improvement for those students who pass the subject, compared to the performance prior to the intervention. In 1994 28% of students gained a High Distinction, in 1995 31% gained HD, and in 1996 40% gained HD. Performance on the exam was judged by the lecturers in charge to show much greater understanding of the main concepts of the subject, with less dependence on recall of information. However the exam was more weighted for this type of knowledge and it is impossible to generate comparison statistics. The proportion who fail the subject remain at similar levels, however, suggesting that the academic difficulty of the subject is not as important in the overall transition experience of the students as had been assumed.
The increase in grades could be dismissed as a "lowering of standards", but other data suggests that this actually represents an increase in students’ learning outcomes.
The students sat two unit tests during the semester, which contributed to the overall mark. During the second semester of 1996 the average score on the first test rose from 61.21% in 1995 to 70.46% in 1996, while the second unit test showed a less impressive rise of 62.87% to 67.06% average. With around 300 students included in the analysis these results are statistically significant, but for the reasons described above we hesitate to claim them as definitive proof of better learning.
The most compelling data for the Edproj team was the observational data collected by a team of trained research assistants from the education faculty. Two measures were taken, the "good teaching behaviours" or GTBs, and the "good learning behaviours" or GLBs. Ongoing research in education, particularly in secondary schools, has related particular overt behaviours of students to be closely associated with learning outcomes of a "deep" kind [10, 11, 12; also 13 for "deep" learning]. When these are observed to be occurring in the classroom it is a strong indication that quality learning is in progress. Similarly there are teaching behaviours that are closely associated with these GLBs incidence in students. Some of the more fundamental measures were the number of open questions being asked by the teacher, and the time spent by the class in discussion that did not directly focus on the teacher, but involved student-to-student interactions.
Prior to the intervention the GTBs were rarely seen, but after the training course, and with the support of the teaching community, the average number of questions asked in tutorial classes rose from 26 per class in semester one to 49 per class in semester two. Similarly the amount of time spent in class discussion (out of a nominally 60 minute class) rose from 20 minutes in semester one to 27 minutes in semester two.
The GLBs also showed remarkable increases: Student generated questions rose from an average 8.6 per class in semester one to 11.2 per class in semester two; while extended responses to questions (which involved the student explaining a point of view not simply giving an answer) increased from 4.6 per class in semester one to 12.6 per class in semester two – a 174% increase over the intervention’s first year, and a total transformation from the previous year.
Student interviews also gave anecdotal data suggesting an approach to learning that valued understanding as an outcome, and regarded peer learning as a significant contributor, was far more common that prior to the intervention. Students also appeared to be more interested in the subject, better adapted to the university, and more positive about their university experience than the students interviewed during the research phase, though the number involved was too small to be definitive. Similarly, the feedback gained from the anonymous feedback page was also generally positive, though there was no comparison data available from prior to the intervention.
Although each of the data sources taken alone are hard to defend as conclusive, the triangulation of the various data collected suggests that there has been major shift in the learning approach and learning outcomes of the students in first year programming.
Conclusion
The changes made to the structure and delivery of the first year programming subjects have resulted in better learning behaviours in students and an improvement in teaching on the part of lecturers and tutors. There is more of a community approach to the subject among the tutoring staff, rather than an attitude of doing what the lecturer says. Students appreciate the amount of help given to them in this subject, as compared with their other subjects. In general, student results in the first year of the changes showed an upward shift of about one grade in the students who were passing the subject. There are still a number of students who fail or drop out, and more research is being undertaken to address this problem. There are more students taking programming electives in later years of the course, and more choosing to specialize in software development rather than some other aspect of computing. This indicates that the changes made to the subject have had some success, and there is ongoing research to try to improve the subjects still more, and to help students with the transition into university study.
Financial support
The authors gratefully acknowledge the financial support for the Edproj project of the Faculty of Computing and Information Technology and the Department of Software Development of Monash University.
Acknowledgements
The authors acknowledge the work of the rest of the Edproj team, especially Anne MacMillan, Ian Mitchell, Judy Sheard and Angela Carbone; webmaster Jason Lowder; research assistants Freya Gunn and Meaghan Walsh; all the lecturing and tutoring staff of the first year programming subjects in the Bachelor of Computing degree; and the student representatives in those subjects.
References
[1] Macdonald, I.D.H., Mitchell, I.J., Gunn, F., & Carbone, A. (1996). Helpless, isolated and underpaid: Turning computer science demonstrators into teachers Paper presented at ASERA conference, Canberra, Australia, July 1996.
[2] Carbone, A., Mitchell, I., & Macdonald, I. D. H. (1996). Improving teaching and learning in first year computer science tutorials. Paper presented at ASCILITE conference in Adelaide, December 1996.
[3] McInnes, C. & James, R. (1995). First year on campus. A CAUT funded publication. Australian Government Publishing Service. Also available at website: http://uniserve.edu.au/caut/commproject/fye/FYEfront.html#top
[4] Pargetter, R., McInnis, C., James, R., Evans, M., Peel, M., & Dobson, I. (1998). Transition from secondary to tertiary: A performance study. Report to the Department of Employment, Education, Training and Youth Affairs (now DETYA).
[5] Tinto, V. (1993). Leaving college: Rethinking the causes and cures of student attrition. (2nd Ed). Chicago: The University of Chicago Press.
[6] Gunn, F., & Macdonald, I. (1997). Developing a culture of teaching at first year tertiary level: a training course for post graduate students that made a difference, Paper presented at ASERA conference, Adelaide, Australia, July 1997.
[7] Macdonald, I. D. H. & Gunn, F. M. (1997). A model for change in tertiary teaching: Combining education research, tutor training, and reflective practice to create Teaching Communities. Paper presented at ASERA conference in Adelaide, July 1997.
[8] Hagan, D.L. (1997). Student Feedback via the World Wide Web ultiBASE online journal (March 1997) http://ultibase.rmit.edu.au.
[9] Lowder, J., & Hagan, D.L. (1999). Web-based student feedback to improve learning 4th Annual Conference on Integrating Technology into Computer Science Education ITiCSE’99, Krakow, Poland, June 1999.
[10] White, R. T., & Mitchell, I. J. (1994). Metacognition and the Quality of Learning. Studies in Science Education, 23, 21-37.
[11] Baird, J. R. & Mitchell, I. J. (Eds.). (1986). Improving the quality of teaching and learning: an Australian case study - The PEEL project. Melbourne: Monash University.
[12] Baird, J. R. & Northfield, J. R. (Eds.). (1992). Learning from the PEEL experience. Melbourne: Monash University.
[13] Biggs, J. B. (1991). Student learning in the context of school. In Biggs, J. B. (Ed.). Teaching for learning: The view from cognitive psychology. Melbourne: A.C.E.R.
[Home] [IMAC Staff] [Current Research] [Publications] [Student Resources] [Teacher Resources ] [Useful Links]
IMAC Education Pty Ltd.
ACN 069 479 036