Louise Dennis: Teaching Portfolio

Home The Six Areas of Competence Support of Learning Design and Planning of Learning Activities Assessment and Giving Feedback Developing Learning Environments Evaluating Practice Using Research to Inform Teaching Role as a Professional Access Disability Diversity Accountability and Quality Critical Appraisals Group Project Individual Project Other Teaching Philosophy Mapping Document Reflective Statement Reference (Word) Statement of Intent Evidence	Teaching and/or the Support of Learning My teaching activities can be fairly easily divided up into lecturing, lab demonstrating, running tutorials and supervision. A lot of the preparation and presentation of material involved in running modules is also generally undertaken with the intent to support learning. Lecturing I divide my lectures into two categories. The first I think of as "traditional" lectures aimed primarily at the dissemination of information. In these lectures I use slides usually containing bullet points which I use as the framework of the lecture and then talk around each of the items raised. Academic work has shown both that lectures are a poor mechanism for the retention of information (summarised in [Horgan, 99] and [Ramsden, 92]) but yet are popular with students [Ramsden, 92]. I work on the hypothesis that the lectures serve to provide a framework for understanding the module content - in fact possibly that they are a better vehicle for deep learning (ie. they communicate general high-level ideas) than surface learning (ie. retention of basic facts). This is the assumption behind much of my lecture design in this category, although I also present and attempt to sign-post the basic facts that I feel the students need to have at their finger tips. The second style of lecture I think of as "example-driven". In these lectures I work through exercises (either of my own devising or from the textbook). I started constructing these for programming lectures since I observed that the presentation of the syntax of a programming language did not appear to particular help students with actual programming. I was also observing a general lack of skill in identifying program errors and fixing them. I recalled a comment by Prof. Tom Melham (then at Glasgow) for whom I worked as an RA. I had asked him what the purpose of a lecture was in the age of the photocopier and he replied that it was for students to see an expert tackling a problem. Obviously these lectures are only made possible by the ability to connect to the computer science programming environments from the Jubilee Campus lecture theatres. Following general advice on lecturing (e.g. [Horgan, 99]) I have also experimented with breaks in lectures in which students can engage in some student-centred activity (either attempting a short quiz or discussing a sample exam question). In both cases I judged the class sizes too large to get feedback in the lecture from students and instead opted to post answers to the module website afterwards. While initially the students made good use of these this rapidly tailed off and the break became an opportunity for general conversation and other activities. In the second year of lecturing, I felt that this practice was beginning to create discipline problems - a level of background conversation was become a constant in lectures and some students complained that when my back was turned to write on the whiteboard paper-dart throwing etc. was occurring unnoticed. Since the break in the middle has been scrapped these problems have ceased although it is difficult to be sure that they were a contributory factor since there were other problems with the lectures I gave in my second year but I feel that until I can find a satisfactory mechanism to allow the students to immediately give responses to exercises (without making individual students feel exposed in a large lecture) they are not really worth the effort and potential problems involved. A more detailed discussion of my lecturing activities in individual modules can be found in my discussion of the modules G53DDB, G51SWT and G51MC2. An example of my slides for a "traditional" lecture are here, an example of a handout for an example driven lecture is here. Lab Demonstrating Programming laboratories are fairly specialised to computer science. In them a, potentially large, group of students work individually on exercises while "lab demonstrators" are present to respond to queries and requests for help. The programming lab is a typical learning environment in computer science, though unusual in other disciplines. The students are generally set exercises to work through in their own time and the lab acts as a support mechanism where they can access help. This is based on a deeply held assumption within the discipline that the skill of programming is only effectively learned by actually doing and practising programming. The main skill involved in this style of teaching is gauging the level of response to student queries in order to help guide them out of difficulties without spoon-feeding them the answers. It is a fine line to tread and one at which I am not always successful sometimes clearly giving answers which do not get the student much further and sometimes clearly telling them too much so they do not have to think sufficiently about the problem in hand. A more detailed discussion of lab demonstrating and the materials provided for it can be found in my discussion of G51SWT Tutorials Tutorials are small group teaching situations with usually between 10 and 15 students and usually focused around working through some technical exercises. I have been taking tutorials since I was a postgraduate and have experimented with a number of formats. The one I find most successful is where I divide the students into small groups of 2 or 3 and set each group one of the exercises. In the second half of the tutorial the group then presents their answer to that exercise. I find this format prevents individual students feeling they can escape doing any work through anonymity while at the same time making them less exposed if there is some error or problem in the group answer. By this means I find I can get the majority of the students to actually engage with the material - once again this is based around an assumption that students learn through the practice of appropriate skills. A more detailed discussion of tutorials can be found in my discussion of G51MC2. I also take First Year Tutorials which are slightly different in nature. Supervision Supervision activities take place for both the 2nd year group project and 3rd year individual project modules. In the second year this involves attending a group meeting a week in the capacity of an "observer" while in the 3rd year it takes the form of direct guidance and advice in meetings arranged at the convenience of supervisor and student. A more detailed discussion of second year supervision is covered in G52GRP and of third year supervision in G53IDS/J Responding to Student Queries Throughout the year I receive a number of queries from students in all categories, tutees, project students and students taking my modules. These generally arrive via email. In general I attempt to respond to queries from tutees and project students individually but experience has shown me that I frequently end up getting the same query from several students on any module. As a result I now no longer respond to these directly but post answers to a module noticeboard where all can see them. I use a noticeboard in favour to an email list since I have observed that students tend to "accidentally" delete important emails unread whereas they remain permanently available to any student who chooses to look on the module noticeboard. You can see an example of a module noticeboard in the example e-Learning environment I have provided. This is discussed more fully with instructions in Developing Learning Environments. Module Materials As well as activities which involve direct student contact I try to devise all module materials and assessments to have a role in student learning as well as in pure assessment. This sometimes creates tensions between, for instance, the desire for all students to grasp the relevant concepts and the necessity of creating a marks spread or, in the case of an exam, that the attempt to introduce new thoughts and ideas conflicts with the attention of the student in a stressful situation. You can find more detailed discussion of the design of learning outcomes for assessments in Assessment and Giving Feedback. References [Horgan, 99] J. Horgan, Lecturing for Learning, chapter 7 in H. Fry, S. Ketteridge and S. Marshall (eds), A Handbook for Teaching & Learning in Higher Education: Enhancing Academic Practice, Kogan Page, 1999. [Ramsden, 92] P. Ramsden, Learning to Teach in Higher Eduction, Routledge/Falmer, 1992.

Teaching and/or the Support of Learning

My teaching activities can be fairly easily divided up into lecturing, lab demonstrating, running tutorials and supervision. A lot of the preparation and presentation of material involved in running modules is also generally undertaken with the intent to support learning.

Lecturing

I divide my lectures into two categories. The first I think of as "traditional" lectures aimed primarily at the dissemination of information. In these lectures I use slides usually containing bullet points which I use as the framework of the lecture and then talk around each of the items raised. Academic work has shown both that lectures are a poor mechanism for the retention of information (summarised in [Horgan, 99] and [Ramsden, 92]) but yet are popular with students [Ramsden, 92]. I work on the hypothesis that the lectures serve to provide a framework for understanding the module content - in fact possibly that they are a better vehicle for deep learning (ie. they communicate general high-level ideas) than surface learning (ie. retention of basic facts). This is the assumption behind much of my lecture design in this category, although I also present and attempt to sign-post the basic facts that I feel the students need to have at their finger tips.

The second style of lecture I think of as "example-driven". In these lectures I work through exercises (either of my own devising or from the textbook). I started constructing these for programming lectures since I observed that the presentation of the syntax of a programming language did not appear to particular help students with actual programming. I was also observing a general lack of skill in identifying program errors and fixing them. I recalled a comment by Prof. Tom Melham (then at Glasgow) for whom I worked as an RA. I had asked him what the purpose of a lecture was in the age of the photocopier and he replied that it was for students to see an expert tackling a problem. Obviously these lectures are only made possible by the ability to connect to the computer science programming environments from the Jubilee Campus lecture theatres.

Following general advice on lecturing (e.g. [Horgan, 99]) I have also experimented with breaks in lectures in which students can engage in some student-centred activity (either attempting a short quiz or discussing a sample exam question). In both cases I judged the class sizes too large to get feedback in the lecture from students and instead opted to post answers to the module website afterwards. While initially the students made good use of these this rapidly tailed off and the break became an opportunity for general conversation and other activities. In the second year of lecturing, I felt that this practice was beginning to create discipline problems - a level of background conversation was become a constant in lectures and some students complained that when my back was turned to write on the whiteboard paper-dart throwing etc. was occurring unnoticed. Since the break in the middle has been scrapped these problems have ceased although it is difficult to be sure that they were a contributory factor since there were other problems with the lectures I gave in my second year but I feel that until I can find a satisfactory mechanism to allow the students to immediately give responses to exercises (without making individual students feel exposed in a large lecture) they are not really worth the effort and potential problems involved.

A more detailed discussion of my lecturing activities in individual modules can be found in my discussion of the modules G53DDB, G51SWT and G51MC2.

An example of my slides for a "traditional" lecture are here, an example of a handout for an example driven lecture is here.

Lab Demonstrating

Programming laboratories are fairly specialised to computer science. In them a, potentially large, group of students work individually on exercises while "lab demonstrators" are present to respond to queries and requests for help. The programming lab is a typical learning environment in computer science, though unusual in other disciplines. The students are generally set exercises to work through in their own time and the lab acts as a support mechanism where they can access help. This is based on a deeply held assumption within the discipline that the skill of programming is only effectively learned by actually doing and practising programming. The main skill involved in this style of teaching is gauging the level of response to student queries in order to help guide them out of difficulties without spoon-feeding them the answers. It is a fine line to tread and one at which I am not always successful sometimes clearly giving answers which do not get the student much further and sometimes clearly telling them too much so they do not have to think sufficiently about the problem in hand.

A more detailed discussion of lab demonstrating and the materials provided for it can be found in my discussion of G51SWT

Tutorials

Tutorials are small group teaching situations with usually between 10 and 15 students and usually focused around working through some technical exercises. I have been taking tutorials since I was a postgraduate and have experimented with a number of formats. The one I find most successful is where I divide the students into small groups of 2 or 3 and set each group one of the exercises. In the second half of the tutorial the group then presents their answer to that exercise. I find this format prevents individual students feeling they can escape doing any work through anonymity while at the same time making them less exposed if there is some error or problem in the group answer. By this means I find I can get the majority of the students to actually engage with the material - once again this is based around an assumption that students learn through the practice of appropriate skills.

A more detailed discussion of tutorials can be found in my discussion of G51MC2. I also take First Year Tutorials which are slightly different in nature.

Supervision

Supervision activities take place for both the 2nd year group project and 3rd year individual project modules. In the second year this involves attending a group meeting a week in the capacity of an "observer" while in the 3rd year it takes the form of direct guidance and advice in meetings arranged at the convenience of supervisor and student.

A more detailed discussion of second year supervision is covered in G52GRP and of third year supervision in G53IDS/J

Responding to Student Queries

Throughout the year I receive a number of queries from students in all categories, tutees, project students and students taking my modules. These generally arrive via email. In general I attempt to respond to queries from tutees and project students individually but experience has shown me that I frequently end up getting the same query from several students on any module. As a result I now no longer respond to these directly but post answers to a module noticeboard where all can see them. I use a noticeboard in favour to an email list since I have observed that students tend to "accidentally" delete important emails unread whereas they remain permanently available to any student who chooses to look on the module noticeboard.

You can see an example of a module noticeboard in the example e-Learning environment I have provided. This is discussed more fully with instructions in Developing Learning Environments.

Module Materials

As well as activities which involve direct student contact I try to devise all module materials and assessments to have a role in student learning as well as in pure assessment. This sometimes creates tensions between, for instance, the desire for all students to grasp the relevant concepts and the necessity of creating a marks spread or, in the case of an exam, that the attempt to introduce new thoughts and ideas conflicts with the attention of the student in a stressful situation.

You can find more detailed discussion of the design of learning outcomes for assessments in Assessment and Giving Feedback.

References

[Horgan, 99] J. Horgan, Lecturing for Learning, chapter 7 in H. Fry, S. Ketteridge and S. Marshall (eds), A Handbook for Teaching & Learning in Higher Education: Enhancing Academic Practice, Kogan Page, 1999.

[Ramsden, 92] P. Ramsden, Learning to Teach in Higher Eduction, Routledge/Falmer, 1992.

Louise Dennis: Teaching Portfolio

The Six Areas of Competence

Role as a Professional

Critical Appraisals

Other