Design, develop and implement learner-centered teaching resources that engage students in the learning process

Like many lecturers, I am guilty at times (perhaps most of the time) of the chalk and talk approach. I know it is far from the best way to do it, but taking a student-centred approach takes a lot of work and it can be a “bumpy road” for both student and lecturer (Felder & Brent, 1996). I agree that most student learning should be inductive (problem solving, discovery, and so on) as per (Felder, & Silverman, 1988), though it is difficult to completely avoid some deductive teaching (fundamentals, theorems, patterns, and so on). It’s getting the right mix that is important, I feel, and it requires a certain amount of pre-planning and effort in terms of instructional design. I like to think that a polyglot approach is the best, choosing the best tools or methods for each particular learning requirement; however, it all comes back to the issue of time in terms of planning, design and production. In an ideal world we would all engage in at least an iterative ADDIE-style approach to analyse student needs and design the best instructional tools or learning objects, evaluating as we go (formative and summative), at best we would engage students and other stakeholders throughout the stages of analysis and design using SAM (Allen, 2012) or similar agile approaches. Even better than that, the process of instructional design would be team based, as suggested by Gagné et al. (1992) when they describe long-term instructional design.

Having said all that, and despite my busy schedule (work, PhD, family – the usual stuff), I do take time to be as student-centred as possible and to design, develop and implement engaging resources. I could list many, but I have picked out four that I feel show range and differing objectives, such as individual and group work, imparting my experience from years as a practitioner, offering student choice / multiple ways of learning, and flipping the classroom to some extent to allow more time to discuss at a more abstract level in class without getting bogged down in specifics that are best left to the lab or the student’s directed or undirected research.

The concept of student-centred learning (SCL) represents a shift from a teacher-centred or content-oriented approach to a learner-centred or learning-oriented one; the lecturer becomes more of a facilitator of learning and allows for students to construct their knowledge rather than a didactic approach where the lecturer merely transmits information (Kember, 1997). What links the two, according to Kember, is student-teacher interaction. This facilitation by the lecturer could be in person, or with the aid of modern technology, for example by engaging via social media channels or through digital content that the lecturer has either sourced (the idea of the lecturer as a curator of digital artefacts) or created (such as with tutorial documents, recorded videos or developing a serious game). Rogers (1983) suggests that a lecturer or teacher would be an authority figure that is confident in the ability of others to learn for themselves and inspires confidence in others to learn. The lecturer is there to allow as much independent learning as possible and is there to nudge back on track where students lose their way. These ideas are prominent in the seven tenets of SCL in Lea et al. (2003), such as a mutual respect within the learner-teacher relationship, increased autonomy in the learner and increased responsibility and accountability on the part of the learner.

Tutorials featuring before and after code

Kolb and Fry (1974) suggests that learning through concrete experience, reflecting on the experience and taking on board the abstract nature of the experience to reapply in new contexts is a continuous learning cycle (commonly referred to as Kolb’s experiential learning cycle). Students can be given concrete experience through tutorial work in a lab environment and the tutorial work can be relevant to an assessed project where the general ideas taught and learned through the tutorials are applied in the project. This would suit the accommodating learning style according to Kolb’s learning style index, and complements other styles like the assimilating learning style that might prefer in-class diagrams and discussions. It is not just the active learning nature of tutorial work that is student-centred, but also the notion of choice and trying to suit as many learning styles as possible.

I have step-by-step tutorial documents that guide the student through the creation of a small project. This is accompanied by a finished version of the project that I have developed. These are available to the students in a number of ways: I provide a link to the code repository on GitHub within the tutorial document, I put the link within the relevant weekly folder or under the resources folder in Blackboard, and I notify students about the existence of these materials via email announcement. The tutorials are optional and some students will opt to forego them and go straight into assignment work (I have no issue with this – part of my teaching philosophy is trusting students to manage their own learning and to be as strategic as they want or otherwise). Feedback has shown me that some students really benefit from them and complete them all because they are more action learners than the ones who forego them. In the world of software development, however, things change very quickly and they need to be refreshed every year as new approaches emerge and features are first deprecated and then removed. There have been occasions where students have encountered issues because of this and for online students this can cost them hours of frustration, versus the on-campus students in a lab environment where I can very quickly put them right.

An example tutorial document is linked to under Resources below. It features a mix of step by step instructions, explanations about the relevance of each step, how one step might illustrate an improvement on a previous step, plus an exercise, a link to the completed project source code and a signpost to what is contained in the next tutorial. The tutorial deals with coding a database application for storing artists. In a later project they will reuse the skills to store different data, but reapply the general concepts and patterns.

In some ways, the approach of doing a step-by-step tutorial with sample solution code is closely related to the idea of formative feedback – prompt feedback features in a number of theories of learning, such as the Chickering and Gamson (1987) seven principles of learning, where giving prompt feedback is principle number four.

Live exercises and collaboration

The best way to illustrate something like collaborative software development is through doing rather than talking. In doing, what I mean is practiced in a realistic environment, one that represents how the knowledge being learned is applied in the real world, i.e. in industry as a professional software engineer. This approach is rooted in what Brown et al. (1989) call a cognitive apprenticeship – rather than abstracting out knowledge to be transmitted from the context, the knowledge and learning is situated. Where the lecturer takes part alongside the students acting as a guide and a bit of a shepherd, this is what Rogoff (1990) would term guided participation. In one activity, I set up a code repository in with pieces of the code missing and asked students to fork the repository (make a copy of the code under their own GitHub account) and fix a piece of code (any of their choice), and then create a “pull request” that requested that I merge their change into my master repository. This allowed them to troubleshoot where there were conflicts (students making changes to the same lines of code), and allowed me to illustrate how team members could communicate more effectively using GitHub. There were 7 students online at the time and about as many offline. Offline students had the ability to take part also and I responded to their pull requests outside of the normal class hours. There were a number of benefits to how this exercise was designed: it was realistic in the sense that this is exactly the type of scenario that occurs in industry; students could see first-hand how several developers could come together on a project and each contribute something small to a whole, communicating where there were misunderstandings, offering opportunities for feedback and growth as a practitioner.


I have created numerous videos over the years where I go quickly through a concept, but then put it into practice (e.g. develop a small project from scratch, or build on one weekly) and explain my thought process as I go; I had 15 years of industry experience when I joined CIT and I try to get across my inner mental processes in a think aloud way – this again is in the tradition of Brown et al.‘s cognitive apprenticeship where newcomers are brought into a culture of practice (this is also similar to Lave and Wenger’s, 1998, idea of a community of practice). This year, for example, I created a video (See “Spring Legacy DB Project Video” resource at end of page) after the first two weeks had gone by where I revisited everything covered and hinted at what was coming up soon. This is a reusable resource that I can use next year, and I was also able to use it for an on-campus module. It is particularly useful for online part-time students who have commitments that make them miss classes; increasingly, I find full-time students are finding it more difficult to manage their time (they have part-time work, ever increasing assessment workloads, etc.) and videos allow them to catch up later or gain a better understanding when they might have been mentally tired in class. But students learn in different ways and where time allows, I like to give students 2 or 3 ways of learning a key concept or technology, e.g. slides, plus video, plus tutorial document, plus sample code from third-party sources. Inevitably, by “doing” myself, I find additional little topics to cover that wouldn’t have occurred to me during a lecture, such as “watch out for this issue you might encounter” or “this is another way of doing what I showed in class”. It means I don’t have to get too bogged down in detail during lectures, I can focus on higher levels of abstraction and spend more time discussing ideas and can direct students to videos or tutorials – an example of the flipped classroom.

Creative group work / prototyping

Vygotsky (1978) and Bruner (1985) both write about the improved quality of learning that can occur in group versus individual learning with Bruner emphasizing the benefit of a diverse range of a knowledge and experience that different learners can bring to a group – the idea that groups foster cross-polination of ideas and problem solving strategies. Smith and MacGregor (1992) also discuss the idea of a learning community which tackles the problem of fragmentation of learning; and the desire that students can build connections between what they learn across multiple modules of a course.

I feature collaborative group exercises in a module I wrote, SOFT8009 – Game development, which I delivered in both semesters last year (2016/17) to third year students. When delivering the module, I got students to get into groups on 2 separate occasions to produce 2 outputs (see the slides SOFT8009 04 – Game Design under resources below):

(as per slide 14) In 6 minutes a box cover for a game (to address things like USP, competitors, audience, platform, story, character, main dynamic and aesthetic). Before the exercise we looked at and discussed 2 example box covers (Bioshock and Frenzy). Then I suggested picking one of Mario Bros, Double Dragon and Portal. We also watched videos of gameplay on all 3 as the activity progressed so that they students could capture the essence of the chosen game on a boxcover (similar to a one-sheet).

(as per slide 28) In 15 minutes a paper-based game prototype. The students were asked to illustrate the mechanics and dynamics of a game. I suggested they brainstorm ideas for their final game development project. I had asked to students beforehand to bring in card, coloured markers, dice, etc. Not many complied with that, but they still managed with pen and paper. When they got to work I did a quick prototype of my own, cutting out characters and projectiles and drawing a scene on paper. I used my laptop camera to project it on screen. Then I circulated around the groups and enquired as to the game genre, mechanics, etc. After the activity, I demoed my own game and got the students to demo their paper-based games too. It definitely got the students out of their comfort zones. I find computer science students are too used to being handed specifications and getting right into code. They struggle not just with creative activities, but planning their work before getting into detailed design and development (usually poor at brainstorming, mind mapping, etc.). However, they needed a jolt to get them thinking about their final group projects, brainstorming ideas and testing them out. Paper prototyping is a valuable exercise that improves communication in the early stages of a project, yet students all too frequently head straight for an IDE (integrated development environment) to write code. Paper prototyping and brainstorming are also activities widely used in industry (not just game development, but any software or product) and I explained the relevance of the activity to students. This relates back to Smith and McGregor‘s idea of the learning community – students will have learned prototyping in other modules, e.g. Human Computer Interaction (though this has sadly been removed in the recent programmatic review), and now they get to apply it in another context.

As part of the activity, students were able to apply general principles of game design, as well as using their imagination and their “repetoire” (games they have played before in various genres).


Allen, M., 2012. Leaving ADDIE for SAM: An agile model for developing the best learning experiences. American Society for Training and Development.

Brown, J.S., Collins, A., Duguid, P., 1989. Situated Cognition and the Culture of Learning. Educational Researcher 18, 32–42.

Chickering, A.W., Gamson, Z.F., 1987. Seven Principles for Good Practice in Undergraduate Education. AAHE Bulletin.

Bruner , J., 1985. Vygotsky: An historical and conceptual perspective. Culture, communication, and cognition: Vygotskian perspectives , 21-34. London: Cambridge University Press.

Felder, R.M., Brent, R., 1996. Navigating the Bumpy Road to Student-Centered Instruction. College Teaching 44, 43–47.

Felder, R.M., Silverman, L.K., 1988. Learning and teaching styles in engineering education. Engineering education 78, 674–681.

Gagné, R.M., Briggs, L.J., Wager, W.W., 1992. Principles of Instructional Design. Harcourt Brace Jovanovich College Publishers.

Kember, D., 1997. A reconceptualisation of the research into university academics’ conceptions of teaching. Learning and Instruction 7, 255–275.

Kolb, D. A., & Fry, R. E. (1974). Toward an applied theory of experiential learning . MIT Alfred P. Sloan School of Management.

Lave, J., & Wenger, E. (1998). Communities of practice: Learning, meaning, and identity.

Lea, S.J., Stephenson, D., Troy, J., 2003. Higher Education Students’ Attitudes to Student-centred Learning: Beyond “educational bulimia”? Studies in Higher Education 28, 321–334.

Rogoff, B., 1990. Apprenticeship in thinking: cognitive development in social context. Oxford University Press.

Smith, B.L., MacGregor, J.T., 1992. What is collaborative learning?

Vygotsky , L. (1978). Mind in society: The development of higher psychological processes . Cambridge: Harvard University Press.

Resources referred to:

SOFT8027 – Tutorial Doc 1 – JdbcTemplate

SOFT8009 04 – Game Design