Alleviating Frustration

There is no video for this post because when I tried to make a screencast, I found myself just rambling.  I think it’s easier to read these bullet points than to listen to them.   Last night I spent hours trying to get a solid first layer of coding for a video and I ran into one frustration after the next.  This is of no fault to Studiocode software, but rather to my own approach to grounded theory.  As it turns out, I am much better with single case design where I am measuring specific behaviors with an operational definition than I am with grounded theory.  Once I finally stepped back and remembered my end goal, I came up with these pieces of advice:

1.  Don’t try to code EVERYTHING

I watch my videos and can’t help but see the endless amounts of data ready for me to collect, organize, and analyze.  I understand that we start with a “clean slate” with grounded theory, but if I truly tagged every detail of each 2 hour math lesson, I would never be done…

2.  Don’t lose sight of your RESEARCH QUESTION

This type of research is a delicate balance between being open to develop theory and using common sense.  My research question aims to uncover potential barriers and affordances to students use of my eWorkbook during independent practice.  I need to begin with broad codes that directly relate to barriers and affordances.  Sure, I could code every action the students and teachers make, but I have to use some common sense, my initial observations, and my review of literature to hypothesize the most likely culprits first.  It doesn’t mean I am closed to other options, but at least I’m not grasping at straws.

3. Observe and Paper Prototype FIRST

I don’t generally like using paper, but I got some great advice while attending a workshop with CAST at the Learning Analytics Summer Institute this past week.  Sometimes when we dive right into software (or in this case code window) development, we pay too much attention to the details first and don’t get a sense of the whole, and don’t give enough time to brainstorming.  Yesterday, I abandoned my code window for a paper tablet as I watched the video.  I just wrote down everything about the lesson that I saw as a potential barrier or affordance to the student’s success during independent practice (because that’s my research question).  I then took that sheet of paper and started grouping those things very broadly until I came up with 4-5 broad codes to add to my code window.  When I compared these codes to my original two codes, they were definitely not the same.  I would have completely missed the boat (or at least required a swim to reach the boat) had I stuck with my original codes.

4. Don’t wait until you code the full video to make changes to the code window

Make sure when you code something, it is not a stretch.  As you are coding, If you spot something in the video that doesn’t quite match one of your codes, don’t just find one that is kind of close.  You don’t want to misrepresent data and you don’t want to generate muddy theories.  If you get stuck and you find important information that doesn’t fit your current codes, you should either re-define/re-name your current codes, or add a new one.  I am hoping that by paper prototyping first, I can avoid this as much as possible.  I already wrote down all the “important” things I found and grouped them under broad terms, so I can use my paper prototype as a quick reference when coding.

---

 

I am certainly not saying that this advice is a fix-all for your frustrations; however, I am hoping at the very least, if you are feeling overwhelmed or frustrated, it might give you an approach to step back and regroup so you can move forward 🙂