After an entire semester in EDRS 8000 researching and creating a quantitative research project that encompassed a four-week unit plan and was meant to analyze the impact of collaborative technology usage on students' attitudes and performance, this semester was my first time implementing real, long-term research, and it was not easy. In fact, although I was able to hit each curve ball, they gave me significant pause and caused me significant stress. Each curve ball also, however, revealed a truism. Upon these I will now expound:
(1) Never trust the county timeline for research approval. There will be snowstorms. There will be "other responsibilities". There will be applications lost in stacks. I'd say, take the county approval timeline, multiply it by three, then add a few days. Submit your research a month before that date, just to be sure.
(2) Choose collaborators carefully. Chances are, unless they are deeply involved in the creation of the research project and deeply affected by the outcome, they will not give it the energy you think they should. It's not a fault in their persons; it is simply a matter of perspective. You see your research as top priority; they don't. Trouble ensues.
(3) Don't expect 14-year-olds to jump on an idea just because technology is involved, no matter how creative the usage. You have to sell it. Hard. Ceaselessly.
(4) Think small first, and build from there. Don't try to prove everything all at once. Small hypotheses can build to the answer to big questions, or at least a significant discussion of those questions. There's no need to build a castle on your first go with a hammer.
(1) Never trust the county timeline for research approval. There will be snowstorms. There will be "other responsibilities". There will be applications lost in stacks. I'd say, take the county approval timeline, multiply it by three, then add a few days. Submit your research a month before that date, just to be sure.
(2) Choose collaborators carefully. Chances are, unless they are deeply involved in the creation of the research project and deeply affected by the outcome, they will not give it the energy you think they should. It's not a fault in their persons; it is simply a matter of perspective. You see your research as top priority; they don't. Trouble ensues.
(3) Don't expect 14-year-olds to jump on an idea just because technology is involved, no matter how creative the usage. You have to sell it. Hard. Ceaselessly.
(4) Think small first, and build from there. Don't try to prove everything all at once. Small hypotheses can build to the answer to big questions, or at least a significant discussion of those questions. There's no need to build a castle on your first go with a hammer.
Ultimately, this course taught me some hard lessons about true research, and though my success in it was hard-won and required some significant tap dancing on my initial research design, those hard lessons will be important to my future educational goals and to action research I decide to deploy to gauge strategy effectiveness and adjust accordingly. This course also taught me that teaching teachers and students what technology does is not sufficient training if the goal is for them to actually use the technology. Teachers and students alike need to develop ownership through exploration and through creativity with the tool before they will use it in any meaningful way without being forced to do so. Ongoing, engaging training that gradually releases the responsibility to the teachers and students and convinces them to create their own version or usage of the tool would engender more implementation.