Monthly Archives: July 2014
I have been working diligently on my code windows while I was away at my conference so in the next few days I will be showing you some of my updates and findings. Today’s post focuses on how I broke down some of my calculations by part of the lesson simply by adding text labels into large groups of codes. I also show you have to undo this action if you make an error.
To recap: If you added a text label into coded instances that you need to remove, go to “label mode” and highlight all of the instances from which you want to remove your label. Hold SHIFT and OPTION while you click on the label button and Studiocode will remove it from all highlighted instances. 🙂
This is just a short video about my ever-evolving code window. As I was looking at my “heat map” matrix of 2-way label interactions, I realized I needed to make some changes. This video reviews the use of find and replace and the digital color meter to make quick changes to over 400 buttons.
I am currently at the Office of Special Education Programing (OSEP) Project Director’s conference where I will be presenting some of my Studiocode code windows I am using for my current research project. I will try to make another post this week, but I may not get to it until I return at the end of the week. If you have any questions or comments, I would still love to hear from you!
In this screencast I demonstrate how I created my own matrix within my code window to visualize the two-way interactions between text labels within a single code. I have to be honest with you, I am not entirely sure if the Matrix window could have done this for me, but even if it could, I really like having the real-time visualization within the code window. If there is an easier way to accomplish this, as always, I am wide open to suggestions. I am only familiar with basic analysis functions within Studiocode, so I tend to go for creative solutions. I look forward to your feedback 🙂
This is another short video about how the layered coding approach has lead to the development of new codes and much richer data.
This is just a quick post about making use of the lead time feature when coding. I have saved HOURS of my time by setting some of my codes for which I only need frequency counts (as opposed to duration counts) with custom lead and lag times. I used this for initial coding of teacher questioning and feedback because I could wait until after the feedback/question was given to press the code button and it still captures the seconds leading up to that moment. This saves me from having to pause and rewind my video for each instance.
I have spent many hours coding this weekend, and have been developing an interesting way to visualize my data. Stay tuned in the next few days for these posts. 🙂
I used my own advice and had a much more successful coding session. I sorted my initial codes and decided to focus on just three of them for the first layer of coding. In this video I give you a few tips for what this initial process of coding might look like and how I can use the “create new row” and scripting features of Studiocode to gather a little more information to use and explore during my second layer of coding this video. By doing these calculations, I already have very specific data to add to my research. For example, instead of noting a trend of many interruptions to the teacher’s lesson, I can be much more specific and say the teacher was interrupted for 9 minutes and 36 seconds out of the 18 minute and 47 second lesson. “Many interruptions” becomes “the teacher was interrupted about half of the time during concept development”. Calculating this by hand would be completely unreasonable, which is why having software like this is so great. We get a much more accurate picture of our data. Quantifying this qualitative data helps reduce the likeliness of our qualitative research becoming more like glorified story telling than like research.
As I mentioned in the video, if you are not already fluent with quick and easy techniques to adjust your previously coded instances, I highly recommend you view two of my posts from early/mid March where I show you how to trim, merge, and split instances.
- March 7th Post – “Adjusting Coded Instances” (I showed ways to adjust instances, but I also posed questions to the folks at Studiocode)
- March 9th Post – “Problems Solved” (I demonstrated the feedback given from the folks at Studiocode)
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 🙂