Social Studies Teachers using Programming for Data Visualization: An FIE 2020 Paper Preview
October 19, 2020 at 7:00 am 4 comments
The Frontiers in Education (FIE) 2020 conference starts Wednesday October 21 in Uppsala, Sweden — see program here. My student Bahare Naimipour will be presenting our paper “Engaging Pre-Service Teachers in Front-End Design: Developing Technology for a Social Studies Classroom” (see preprint here) by Bahare, me, and Tammy Shreiner. This work came long before the NSF work that we just got funded for (see blog post here), but it’s in the same line of research.
The paper is about two of our participatory design sessions with pre-service social studies teachers in Tammy’s class on data literacy. In both of these sessions, we asked teachers to program in JavaScript or Vega-Lite to build a visualization, and in the second one, we also introduce CODAP, a visualization tool explicitly designed for middle and high school students. The paper is less about the technology and more about what the teachers told us about what they thought about tools for visualization in their class.
Social studies teachers are such an interesting group to study. They’re not particularly interested in STEM, data, or computers. They want to teach social studies. Very few of our participants had ever seen any code. (One told us, “This looks a lot like setting up my MySpace page in middle school!”)They’re only interested if we can help them teach what they want to teach. It’s a hard audience to engage, in all the right ways.
I’m going to highlight just two lessons we learned here:
First: The results from the two participatory design sessions were remarkably different. Participatory design isn’t a “okay, we did that — check off the box” methodology. Each group of participants can be remarkably different. There’s no generalization here. Each session is useful, but I don’t know how many sessions we’d have to do to get anywhere near saturation. That’s okay — we learned design lessons from each session.
Second: There is no one answer to how teachers think about programming. I have heard from many people that teachers find programming hard (see this CACM Blog post about that discussion), and I’ve hypothesized that to be true in this blog (see this post). So, now I’ve been in the room as social studies teachers have their first programming experiences and interviewing them afterwards, and….it’s complicated.
Teachers tell us often in our sessions that programming is overwhelming, but several teachers also told us that CODAP (explicitly designed for their use, and not a programming tool) was overwhelming. The question is whether it’s worth the complexity — and for whom. We get contradictory responses from the teachers, which we report in this paper. One told us that she wanted a simpler tool for herself and JavaScript for her students: “I don’t mind keeping life simple for me, but I wanted to challenge my students and give them useful, new skills.” Another teacher told us the opposite: “I would like Java[script] because it would let me do more to the visualization. Vega-lite would be better for students because it seems far more simple.”
We couldn’t fit in all the great stories and insights from these two participatory design sessions. Like the teacher who wants JavaScript in her class because, “That’s similar to what they use in math and science, right? I don’t want history to be the ‘dumbed-down’ programming.” I found that surprising, and wondered what the teachers would think of a block-based language. Another teacher told us that she wants to use programming in her history class, “Because maybe that would make history ‘cool.’” One of the tensions I found most interesting in these sessions was between the desire to know the tools and be comfortable in front of the class, and the desire to push their students to learn more. Some teachers told us that they preferred CODAP to any programming tool because they would be embarrassed to get a syntax error in front of their kids, which they realized would always be possible when programming. Other teachers told us that they were more concerned with going beyond basic tools — (paraphrasing one comment we received), “My students will already know Excel and Google Sheets. I want them to do more in my class.”
Our work is ramping up now. We had another PD session with pre-service teachers in March, just before pandemic lockdown, which was our first one with our data visualization tool in the mix. We’ve just held our first workshop in August for in-service (practicing) teachers. We’ve got more workshops planned over the next year. You’ll likely be hearing more from these studies in future posts.
Entry filed under: Uncategorized. Tags: computing education research, computing for all, computing for everyone, history, participatory design, social studies.
1.
Brett Becker | October 20, 2020 at 8:22 am
This highlights an issue with error messages that goes beyond error messages being unhelpful, etc. If the act of programming with anyone watching could lead to “embarrassment” it may represent a barrier to motivation, uptake, and more – not to mention learning. What are other effects of this potential embarrassment? If teachers won’t program in front of students, will they do it with other teachers? What about future effects? I’d argue that most future computing teachers are today, computing students. If their teachers avoid programming due to potential embarrassment, what would motivate them to program in front of their students when they become teachers? I wonder if today’s teachers feel differently about live programming in blocks in this regard. Is having blocks not fit/snap together less embarrassing than getting more standard error messages?
2.
gmh | October 21, 2020 at 1:31 pm
Mark, I’m curious…
How did the JavaScript programming go, particularly
debugging? In my experience with introducing JavaScript
programming is that programs with errors produce error
messages that non-programmers can’t understand or
(worse) don’t work but there are no error messages.
This really complicates debugging. Isn’t this a problem
for social studies teachers?
3.
Mark Guzdial | October 21, 2020 at 4:14 pm
Great question! They did get bugs, and they came up with a really interesting strategy for dealing with them. We paired them up, mostly to get more discussion that we might capture for our data. But they used each other for backtracking. One teacher made a change to the code, while the other did not. If the change didn’t work, the other teacher helped them get back to safety. They mostly didn’t read error messages — just “it worked” or “let’s see if we can figure it out, or just give up and try something else.”
4.
From Guided Exploration to Possible Adoption: Patterns of Pre-Service Social Studies Teacher Engagement with Programming and Non-Programming Based Learning Technology Tools | Computing Education Research Blog | April 19, 2021 at 7:00 am
[…] have blogged about our participatory design sessions before (see Bahare’s FIE paper from last Fall). Basically, we set up a group of social studies teachers in pairs, then ask them to try out […]