I have been thinking a lot lately about the design of a proposed project to address a real problem for the pre-service teachers I currently serve: how can I best help prepare them for the challenges of technology integration? In crafting my design, I have conducted what I think is a thorough review of the literature. Honestly, at least half of the reading I have been doing in my doctoral program for the past three years has been focused on this topic, so while I have certainly read new things this semester, I find I have been revisiting things I’ve read previously, and I find that I am synthesizing from many sources, seeing how the pieces fit together, and designing a way to address this problem.
 |
| Image by US Department of Education [CC BY 2.0] |
One of the readings from our major text for the semester noted that, “designing solutions to educational problems fundamentally involves change” (McKenney & Reeves, 2012, p. 112). That is what I am really thinking a lot about right now: what might have to change about our teacher preparation program to better prepare students for technology integration? This is not a simple question, but through conversation with my colleagues, and even a sort of informal focus group of some of my students, I am devising a plan to help boost pre-service teachers’ self-efficacy for teaching with technology. I am focusing my attention on self-efficacy because I have come to realize that there is no way I can teach students every different piece of technology they might possibly have access to in their future classrooms. Add to this the fact that technologies are ever-changing, and it becomes even more important to foster that sense of learning-to-learn when it comes to technology.
At the same time, I have been thinking a lot about the evaluation-reflection process, and how this project might actually be implemented. McKenney and Reeves (2012) describe this process akin to the way software developers might think about the iterations of a particular tool, in terms of alpha testing (basic logical tests of soundness of design and feasibility of usefulness), beta testing (use in context, though perhaps not with full functionality), gamma testing (just before final release, the highly-stable version that is evaluated for effectiveness and impact), and then the “final” release. This analogy is helpful for me as I think about the different iterations a particular intervention might pass through in the development and design process, and it rings true with me for my own work as an educator: I generally try to approach my teaching practice as a continuous learner, always looking to improve in the next iteration, and reflecting at every point along the way. However, I think my teaching practice might currently be better described as “continuously in beta,” and this is why I find the approach McKenney and Reeves (2012) advocate helpful: how can my work begin to generalize into other situations, be implemented beyond just my own classroom, and be a positive influence on others? I worry that I sound a little arrogant when I say things like that, as if I have things all figured out and that everyone should want to do what I am doing in my own teaching practice. I recognize that I am a work in progress, and that my teaching practice, and even this design project is a work in progress!
However, I hope that the project I have been working on for this course--a project aimed at improving my students’ abilities to integrate technology in their own teaching practices--would, in fact be something that would spread and be implemented more widely than in my own teaching practice. I say this not out of arrogance, but out of a hope that the work I am doing would be valuable to others, and that when they read about the development work I have been doing for this project, they might see it as relevant for their own situations, and that they might apply or adapt the things I am doing and discovering in their own contexts. Because that seems to be the most helpful part of EDR: seeking not only to develop theoretical understandings, but also practical solutions to real problems!
Reference:
McKenney S., & Reeves, T. C. (2012). Conducting educational design research. London: Routledge.
It isn't arrogance, but rather service. If you were working on something for yourself and your practice without a thought or care that it may help someone else's practice and benefit a wide range of students; what would you call it? Selfish? Or perhaps, thoughtless or self-serving--maybe even arrogant if your practice is the only one worth considering.
ReplyDeleteYou are thoughtful, humble, and reflective. It is in your character to be concerned about avoiding arrogance, but from my distant corner of your community, you are nowhere near arrogant. Thank you for your servant leadership that expresses itself in your generous sharing, the strength of your vulnerability and transparency, your investment in your vocation, and abundant energy and enthusiasm. (Abundant but not bottomless. Rest, too, my friend. ;-)
Blessings on you and your work.
You are very kind, my friend. Thanks for the encouragement! (And...yes...I do need to rest!) :-)
Delete