Studio DH: Mixing Classroom Time and Meetings

Schedule Most of my DayOfDH has been devoted to meeting with student groups for their final projects due next week.

The course is entitled Digital Studies / Citizenry, but this year’s edition is really a course on data visualization in the humanities. I’ve always wanted to teach a course in Processing as a way to have students create interactive digital works and learn some programming basics (most students in the course have done little or no coding). Learning to code in Processing could be a course on its own, but there’s also a whole set of parallel conceptual topics that I wanted to visit (ethics, aesthetics, legal issues, etc.). I often seem to be overly optimistic about how much we can cover in one term, and this course has been no exception.

I find teaching programming to be a real challenge because I think it’s difficult to strike a good balance between reusable coding concepts (data types, functions, classes, etc.) and a more pragmatic perspective of just getting something rewarding done. Moreover, students certainly want to learn programming, but they’re not always prepared for the time and perseverance required (no matter how often I repeat it in the first weeks). My core objective in recent years has been to do everything I can to help students learn strategies for figuring things out on their own (though I can’t claim to always succeed at this). In any case, it seems to me that technical pedagogy in DH merits a lot more attention.

As often happens in my courses, I’ve had to revise the structure as we’ve been going along. I’d originally planned to continue with parallel streams of Processing and conceptual issues and have students start group projects in the second half of term. In practice, we’ve dropped the Processing units (conducted as a workshop where I would introduce new programming material and we’d work through some examples and exercises together) and instead I have student groups (typically 3-4 students) book 30 minute meetings with me where they come to work on coding problems that are specific to their projects.

One of the things I love about the project meetings is the just-in-time nature of the material: students are keenly interested in what they’re learning because it’s immediately relevant to their project. I tell them that I’m there to help them tear down obstacles to realizing their vision of the project, and that’s generally what happens. Sometimes I ask them questions that help them figure things out on their own, sometimes I show them strategies for finding techniques and tricks of the trade, sometimes I code for them and ask them to add comments to what I’ve done – I take this to be a variety of forms of apprenticeship. (And very often they show me new stuff as well.) The projects are diverse enough that there’s rarely duplication between meetings in a given week. We all tend to find the meetings immensely rewarding because we get real things done. (Having said that, they also very much value our discussions about conceptual issues on Wednesdays – it’s the mix that works well.)

One of the disadvantages of the meetings format is that it’s time-consuming for me: instead of a 1.5 hour block of teaching Monday mornings, I have at least 4 hours of meetings. This might be closer to what happens in studio art. In any case, I recognize that it’s not especially scalable for larger classes.

Students will be presenting their projects next week during the final class – I can’t wait to see the final product.

BTW, next time I run this course I probably won’t use Processing, but instead focus on existing GUIs for producing data visualizations. While I remain convinced that programming should be more widely integrated into teaching in all disciplines (and all levels, including K-12), I think a more practical introduction to available tools for producing data visualizations would probably be more useful for the kinds of students who register for this course.

As an appendix, in case anyone’s interested, here’s a tentative description of the project submission:

The final project is the culmination of this course. It is intended as an opportunity to apply and develop the concepts and technical skills that you have acquired throughout the term (through readings, discussion, presentations, and mini-assignments, etc.). The final project is composed of an interactive digital work (or works) and of accompanying documentation, including a project write-up. Both the digital work and the documentation are subject to the same high academic standards as what you may be more accustomed to with term papers. Your work should demonstrate a critical understanding of concepts, a mastery of relevant technical skills, a self-aware thoughtfulness, and creativity.

The emphasis of the project is on producing a coherent and compelling data visualization, an expression of what has been explored in class (it may be worth revisiting the course outline and some of the readings as you’re refining your project before submission).

Project submissions should include the following:

  1. A fairly brief (300-500 words) project profile, that includes at least one image that somehow represents the project, a brief introduction, and some highlights of the work (the profile should be autonomous and written for a large audience – the kind of thing that could be included in an electronic portfolio). This document may contain segments that are repeated in the next section.
  2. A PDF document that includes the following sections:
    • Introduction. A paragraph or two introducing the project (what is it? what are the motivations? what were the objectives? what are the arguments?). In this section make it very clear where the project is located and how to launch it.
    • Statement of Collaboration. A paragraph introducing the team members and describing the roles and responsibilities of each team member. You can also use this section to summarize any additional help you received, including online tutorials, discussion groups, manuals, blog posts, articles, etc.
    • Mini-Essay. This is the closest section to a conventional essay, but it’s not an essay. You should narrate your project by intertwining motivations, methodologies, observations, and interpretations. As I read this section I should have a very clear idea of what you did and why (including what you didn’t do and why). You may want to use appendices (in section 3: additional materials) for longer code snippets or procedural explanations. Remember that visuals can be very effective in helping to explain your work. You should take all the normal care you would in writing clearly and smoothly (especially for stitching together parts of your work) while also recognizing the unusual nature of this mini-essay (that has a strong technical component). Be sure to showcase any insights you may have had.
    • Reflections. A final paragraph summarizing the student’s reflections on the project. For instance, what worked well? what was frustrating? what wasn’t anticipated? what would you do differently next time? what potential (if any) does the project have to contribute to society?
  3. Electronic versions of your individual task sheets (that should follow the same template I provide in class). These can take the form of a word processing or spreadsheet document or they can be a scan of a piece of paper. Either combine all task sheets into a single document or use indicative file names like TaskSheet-Sinclair
  4. a list of additional materials appended to the project, as applicable (source documents, executable files, raw data, etc.)

The full project should be uploaded as a zip file to this assignment page. The zip file should include all of the sections above (including the one-page profile).

Projects will be assessed primarily on the quality of the write-up, and particularly the clarity, usefulness and appropriateness of the mini-essay section as well as the interest of the apparent effort put into the project. A portion of the grade will also come from the in-class electronic poster session on April 15th.