Many faculty I know who maintain a public digital identity reflect frequently and thoughtfully on their teaching with regular blogging. I don't tend to do that, unless there's some specific technology or unique pedagogy that I've been tried out in a semester, like when I wrote about using Slack instead of Canvas, or when I described an assignment built around Kumu.io, or way back when I was first trying out UMW Domains in my classes. Those posts are fine, and I'm happy I wrote them, but because they're focused on novelty, they don't address the core, day-to-day pedagogy that I feel like I'm still learning how to do, little by little. I've found it helpful to encourage or require my students to record their learning in a journal or narrative, so I think I should embrace this too.
Therefore, this post is going to be a reflection on my Fall 2018 teaching, class-by-class, where I document what worked and think about what I should do differently next time I teach each of these three courses: DGST 301A: Creative Coding, ENGL 253: Games and Culture, and DGST 395: Applied Digital Studies. I'm posting this on my blog, clearly, because you're reading it, but you're really not the primary audience I'm writing to. This is, instead, directed at the future version of myself that will need to reference this in the fuure, or perhaps just the future self that I become by hardening some of my vague ideas in the light of having to type them all out.
I'll take it one at a time.
I loved this class so much. This is the class I was most excited to teach, that was the most fun to prepare for every day, and that I was the most eager to talk about in casual social settings when people would ask, "So, how's your semester going?" I think some of that enthusiasm transferred to my students as well, because I got to see them start taking pride in their creative digital work, when in some cases they came into the class with very little prior experience or some real anxieties about coding. One of my favorite moments came when a student was working on her final portfolio where I asked students to revise or improve four of the projects from earlier in the semester. The student messaged me just to say how much fun she was having because now that she felt like she knew what she was doing instead of just feeling stupid because she couldn't get the code from the tutorial to work.
I think students also really took pride in seeing their glitch art projects up on the media wall at the HCC, which also became a nice talking point for Digital Studies generally. I'd like to try and put together another compilation like that, perhaps as a sample of the Digital Showcase?
In Creative Coding, I really enjoyed the readings from Virtual Muse, which helped me at least think through the underlying assumptions of each project. I also had a blast with P5.js once I got the hang of it.
As a teacher, I've been trying to pay more attention to what moments are potential pivotal points for an individual student or for the whole class. In doing this, I noticed how excited I get when a student approaches me with a project idea and starts with something like, "I have no idea if this is possible, but ...." This usually indicates a student who has an idea and a problem worth solving, and I love helping students solve problems that they've come up with, as opposed to working through the "problem" of how to adequately complete what I've set out for them in an assignment.
This kind of moment might be more common in code-oriented class, but maybe all teaching is or should be about showing students what's possible and helping them solve the problems that stand in the way of achieving that possibility.
All that said, this class wasn't all exciting problems and glorioius epiphanies. I liked most of the projects conceptually, but I think there were some unecessary barriers baked into how I organized the class, that I think could definitely be streamlined.
For this class, I went with a "minimal" grading schema such that students received a check, check minus, or check plus for all of their work. As I approached, a check minus was very easy to get if, basically, a student completed at least the bare minimum requirements of a project. Like for a twitter bot, it posts tweets, or for a P5.js screensaver, it actually runs and you can see it.
I like this because the simplicity of the system meant that I actually was more up to date on these grades than I normally am, and beause of that, these grades could serve their purpose of communicating with students what areas they need to work on. I gave feedback informally in person and over Slack, for the most part, which I think was fine. I'll be interested to see if the course evals have anything to say about that. I might adjust the balance of the projects somewhat, but I think I'll keep the basic grade schema.
I had some real beginners and a few more who were already more comfortable with code in general. This made it hard to find projects that were the right balance for those different skill levels, but I think that basically worked. Because some were such beginners, though, much of my time in class fell to helping those students debug their projects or get something basically working. Inevitably, the most vocally needy students got the most help from me, and while I did build in time for that troubleshooting, and I'm happy to help them solve those or any problems, I think we could get more done with some more options for that kind of help besides taking time in class or going back and forth over Slack.
One student had a good suggestion: since students naturally fell into cohorts by sitting at the same table every day, and since those casual cohorts became peer tech support as they talked about and helped each other with their projects, perhaps I could embrace that structure more deliberately and schedule out of class workshops with each of those cohorts. I suppose I could organize those by grouping students with similar ability levels, but I'm always worried about making students feel bad if they're in what they perceive as a lower level group. Instead, it seemed like students naturally organized into similar skill levels or interests, and even when there were wide differences within a group at one table, because those students knew each other, they weren't shy about asking each other for help and working through things together.
In terms of teaching code, one thing I do want to make sure and talk about next time is the right and wrong ways to work with other people's code. I didn't realize until it was essentially too late how many projects, especially those with P5.js, were basically just the code from one of the examples on p5js.org or a Coding Train tutorial, with just one line or value changed like the color of the background or the size of the snowflakes. This is an OK way to learn, but I really do need to teach how to properly credit those tutorials and how to use them to build into your own knowledge. Those tutorials, or even my examples and videos, can be a good starting point, but it's better to move on to something else once you've established that starting point, and in any case you always have to acknowledge and give credit to your sources, which can be accomplished with good commenting.
Oh yeah, I made some videos, using a green screen format similar to what Daniel Shiffman has mastered on the Coding Train . Clearly, I'm not as charismastic or as good at explaining things as Daniel, but the videos were surprisingly fun to make and didn't really require much editing. Students all seemed to really appreciate and use them.
That said, I can definitely do better. They're way too long, and I think it works better to do a video explaining how to do something that I know will work as opposed to hopefully figuring it out as I go like I did with the poetry videos.
At least two of my student's projects had to do with generating poetry, and we read Charles Hartmann's Virtual Muse as a way to think about computation, poetics, and the creative projects. I found the book really accessible and relevant, but I think my students had a hard time making much with it. Our discussions sometimes fell flat, partly I think because it was a larger group, but also perhaps because my students didn't see those same connections and relevancy. I think I can work that in better, by asking more of students in discussions, by directing them to explain chapters to each other, and by just adding more poetry in general to the class so they get a sense of what's possible -- some conceptual poetry, certainly, but also some more conventional imagist and lyrical stuff. We don't have to analyze it, just get in the habit of knowing poetry. If I have enough time, I can get together a big list or database of poetry, and start each class asking students to read out loud.
To work Hartmann in more, I suppose I can prompt them to reflect on specific insights from the book and whether they apply to their creative work. Or maybe there's a less forced way to do that.
I'll try and keep these notes short:
avidemux.All told, a great class. I learned a lot about coding and a few important things about myself as a teacher. I'm grateful to my students for being the pioneers in this new class, and of course I'm indebted to Allison Parrish whose publicly-available syllabi, lucid documentation, and personal advice influenced and enabled nearly every part of this class.
This was not a new class to me, but since it's been about two years since I last taught it, it sort of felt like one. In some cases, the parts of the class that worked well felt like a familiar groove to fall into -- the unit on videogame history and some of the theory things -- but I also really enjoyed some of the new things I got to try out, especially the "make a commercial" assignment, the "close playing," and the Metagaming assignment.
The blogging and the videogame criticism were both a bit off -- the blogging because I didn't follow through with grading those on time or really do anything to make those a community, and the videogame criticism because I don't think I expressed clearly what I was looking for in those, and as a result I couldn't really figure out how to assess them except by trying to grade them with respect to what each student was trying to do with them.
Discord was a big help in this class, and in a lot of ways I think I preferred it to Slack for an always-on discussion board supplementing class discussions. Between Slack and Discord, one big difference that I like is the way that identities persist across servers, unlike in Slack where you have a separate account for each workspace.
In terms of assignments for this class, I really think I'm done with blogging, at least in the way that I did it for this class. The metagaming assignment was, overall, the most successful and the most interesting, in part because the associated reading from Metagaming by Patrick Lemieux and Stephanie Boluk was so compelling and challenging to my students.
I had a good group of highly motivated students in this class, so generally speaking I didn't have to push them that hard in keeping up with the reading. Still, I generally don't do enough, I think, to help students see the connections between the readings and between the readings and their projects. The Metagaming book became a good moment for both of those because their central claims in the book are just abstract enough that my students had to do a bit of work to really get at them, and even then, those central claims actually got some of my students pushing back.
One central premise of the book is that games are really platforms for metagames, and the correllary argument (brillianted stated in a few different ways throughout the book) that "the greatest trick the videogame industry ever pulled was convincing the world that videogames are games in the first place". This quote actually rustled some jimmies in the class, which was great because the claim here really gets to the exigent "so what" of the book: to talk about games as platforms for metagames isn't just an interesting formal exercise in ludosemiotics; it's a way of answering the question, "why are there games?" in a way that recognizes the economic realities of videogames as commodities. I think it got a reaction because it perhaps deflated some students sense of gaming expertise by exposing it instead as ardent fealty to a particular videogame brand, publisher, developer or platform.
The other thing that really worked in this assignment is that when I asked students to describe a hypothetical metagame, I insisted that in their reflection or artist's statements, they should identify which metagame of the ones mentioned or included in the book was the most similar to the metagame they were imagining. This moment of comparison helped some students connect the dots a little better, and it also helped me see when students weren't quite understanding their work well enough to make those connections.
I think this is a good example where asking students to work deeply with one source works better than asking for bibliography, as I often do, of "5 - 7 scholarly sources." For the student who doesn't really know how to work with sources yet, they're not going to get better at by floundering their way toward "5 - 7," but if they do it well with just one source, that may be a foundation to build on later. This is an insight I think I can apply across many of my classes.
I had two sections of this course that's required for all CDS majors, and while I'm too much of an optimist to call it a "failure," there really were a lot of things in this class that didn't go as well as I'd hoped, so much so that I've already started a detailed "Aims and Tasks" document for this class with my colleague Brenta Blevins who will be teaching it this Spring. I want to figure how to improve the things that didn't go well, which also means it's a valuable opportunity to make sure that this course does what we think it needs to do for the CDS program.
Since I already wrote that document, I won't go into as much detail here, other than two or three general points of reflection: ungrading, scale, and structure, all of which are closely linked.
This semester was the farthest I've pushed into the "ungrading" territory, and the ways in which this approach failed to challenge some of my students is probably a result of coupling this ungrading philosophy with an alternative approach to communicating with my students solely via Slack, a class website, and multiple AirTable forms. Like it or not, students have come to expect that at least the logistics of a class (assignment descriptions and due dates) will be available to them via Canvas, so I think in many cases the feeling that the class lacked a sequential structure (something that a few of my students expressed) is due mainly to the absence of that reliable system of reminders in Canvas. That said, many of my students kept up with the work just fine, but I had to work extra hard to remind students in class, over Slack, and occasionaly mass emails to get that information out there regularly. Similarly, most of my students did do OK in getting their work to the right Airtable form, but I had to do a lot of reminding and sending people the right URL. Despite it's faults, Canvas already does this kind of day-to-day logistics, so it really isn't necessary to reinvent this particular wheel.
In the future, I'll definitely go back to Canvas for this class, but those other structures will probably have a role as well.
I'm all for ungrading. I understand and believe all of the problems with grades that many people have pointed to, and I have seen in my own classes how the minutiae of grading can suck the life out of a semester very quickly. Since I'm not very good at grading things quickly, I also associate grading with a lot of anxiety and self-criticism. That said, I also believe that you can't just take the grades out of a class: you have to replace it with some other form of informal feedback for students. As they work on various projects, even projects where they've designed the goals and outcomes, they need some insight from me, their instructor, to help them see which parts of their work they should celebrate and which parts they need to work on some more.
In other words, if I want students to develop their inner critical sense of their own work, it helps if I model that for them some way externally. Relying solely on self-evaluation in a class doesn't quite get there, but not because students try and get away with doing as little work as possible and giving themselves an A (though that definitely has happened in this class). I don't really care if a student gets an A they "don't deserve," but I do think it matters if a student believes that something they've created is good enough without appreciating the context or the craft of whatever is they're creating. There's a risk of something like a Dunning-Kruger effect with student self-evaluations where I see some of my brightest and most energetically self-motivated students (that is, the students best-suited to the open-ended structure of DGST 395) writing the most critical self-evaluations. Conversely, some students who don't seem as engaged confidently award themselves an A because they "did what I asked them to" in the class.
I don't want to say that it's inappropriate for students to be confident, and especially in the context of learning things like programming, a boost to self-confidence makes a big difference, as it did in Creative Coding and in the programming parts of DGST 395. But I think the tricky thing is finding the appropriate balance for each student, and that can only come into a good working relationship based on mutual trust. That relationship can be built through routine assignments, or through frequent conversation, but it takes time and it doesn't scale well. Standardize grading is, in a way, a replacement for those relationships, and that efficiency is a compelling factor when I'm working with about 45 students. It's not the solution, though, and doing things efficiently can't be the only factor to consider if I want to rise above "just good enough" for myself. I certainly feel like I owe my students more than that in my classes.
When I first taught DGST 395, I had one section of 15 students, and with that small group, I didn't really have to think about designing the class much at all, other than setting the basic goals for the class. I knew each of them and their Big Projects well enough that I could help along the way -- acknowledging their successes and challenging them where necessary. That's a lot harder to do with 45 students, and I at least really haven't succeeded at it at that scale, despite my efforts.
As I think now and over the next few months about re-engaging the design of the class, I need to think in terms of building in assignments and structures that will help students be better readers of their own work, and at the same time, I need to make sure that the systems I use to support the logistics of the class really do help me spend my time where it's more valuable, in forming those relationships with my students.
I'll close this section with some of the specific suggestions I've documented for the Aims and Tasks. These are more along the lines of "fixing what went wrong" instead of truly redesigning the class, but still helpful as a starting point:
| Learning Outcome | Analyze, critique, and respond to contemporary digital culture. |
|---|---|
| Developed By | Reading a book (The Peripheral or Autonomous). Peer teaching in small groups, chapter-by-chapter. |
| How it went this year | Pretty well. The book was just OK, but students found relevant connections. Sometimes I had to work to push them to find the things I thought were relevant. Some aimed pretty low in preparing their teaching. It was obvious who had read and who hadn’t, and most were keeping up with the reading. |
| Suggested revisions | Keep this same pattern, but find other books or short stories. Add some kind of project or assignment with this. Ban youtube videos from teaching, strongly encourage discussions. Maybe even call this “discussion leader” instead of “teacher.” Several finished the book early, so maybe add more to it. |
| Learning Outcome | Work with computer programming in order to express ideas, explore questions, and investigate problems. |
|---|---|
| Developed By | Working through Exploratory Programming and peer teaching exercises in small groups. Students choose an "essential topic" they feel they’ve mastered and teach that to peers. |
| How it went this year | Pretty well, but I fear students aimed too low when I assured them they could choose the difficulty level appropriate for them. This led to redundant teaching, and because that entry level stuff is pretty basic, it wasn’t very compelling to some students. |
| Suggested revisions | Keep this book or something similar but... Instead of "pick any starting point and end point" offer different tiers of suggestions Create some kind or project or endpoint for this unit, with suggested projects tied to students’ self-identified tier. OR have students come up with that at the outset of the unit, then hold them accountable to that. Possibly do something with HTML or web development instead of exploratory programming as such, to build off of the HTML assignment in DGST 101. |
| Learning Outcome | Plan, manage, and evaluate a long-term digital project. |
|---|---|
| Developed By | Creating a proposal for a big project, completing several progress reports as you work on it, and writing a final self-evaluation. |
| How it went this year | This was all over the place. Some projects were ambitious and amazing, some were just not very good or well thought-out. At the first progress report, many students were reporting that they essentially hadn’t started yet. The ["project idea generator"](http://applied.dgst101.net/bigprojectgenerator.html) was fun as a brainstorming exercise, but I fear some students latched on to a project from that generator, thinking that the generator was somehow endorsing it as a viable idea. |
| Suggested revisions | This project probably needs to continue being a core of the class, but I think several things could improve it:Reference the DGST101.net modules to help people find topicsOrganize students similar projects into cohorts for accountability and support. Direct them to share progress reports with cohorts, for example.Show previous projects (archive.dgst101.net)Show them “real” projects like NEH grant proposals to get a sense of a higher bar to shoot for, as well as a better “so what” when describing their deliverable.Direct them to create a “budget” in terms of time. Like how many hours it will take to complete each subtask, along with a suggestion for how long a big project “should” take. [50 hours? 100?]Teach how to log hours.Find some way to assess that project directly myself. |
| Learning Outcome | Share your work and make it meaningful beyond the audience of this class and this University. |
|---|---|
| Developed By | Encouraging students to post their work publicly on their domains |
| How it went this year | This really wasn't an emphasis in this year's class, but it should be. |
| Suggested revisions | This could be built into the digital fluency self-assessment where students might be asked at the outset of the semester to really think about what their digital identity is from other people's point of view, with the idea that by the time they write their digital fluency self-assessment at the end of the semester, they've made their domains into whatever they need to be in order to support that identity. |
Wow, this is a lot of words here. I don't really expect anyone to read this, but as I said at the outset of this post, my true audience is my future self. And not the self of a few years from now who will look back on the notes from this semester as a reference, but moreso the future self I will have become by writing this all out so that hopefully I can become a better teacher. This is writing for realization, not documentation, and I think this has been useful.
[Cover photo by Oliver Hihn on [Unsplash]](https://unsplash.com/search/photos/reflection?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)
Word Count: 4615