After wrapping up my preliminary planning for my Game Programming course before the holiday, I turned my attention to the necessary revisions for my Human-Computer Interaction course. I had a few ideas swimming around my mind, but I decided it would be best to go back to my notes from last time I taught the course, which was Fall 2019. I re-read my end-of-semester blog post, and this reminded me of how terrible that semester was. I had sort of forgotten how painful that course was, but it was good to be reminded.
I decided not to include a community partner for the Fall. I have been disappointed with what my students have been able to provide in this course. While the pandemic makes it easier to work with partners who are distant, it also removes the crucial ability to sit in a circle and have an honest chat. The risks are just too high right now to ask an external partner to donate their time to the students. Of course, if I get good learning outcomes from the students, I would love to have them engage with a community partner in subsequent experiences (such as the game studio course). The topics are just too hard for the students to grasp to ask them to be able to learn them and apply them to a partner's benefit in one semester, given all the other constraints.
The course plan that I just put online lays out the first several weeks of the course in good detail. During these weeks, students will be reading Don Norman's The Design of Everyday Things and completing weekly exercises to help them build their understanding. I have used this book in the past several semesters, and I like that the students can both learn from it and practice learning from expert writings (rather than conventional “textbooks”). The weekly exercises are all in a format that involves individual reading and work from Thursday to Tuesday followed by a period of online peer review from Tuesday to Thursday. In this way, I hope to simulate some of the discussions and ad hoc peer reviews that I would normally do face-to-face in the classroom.
I have been disappointed in the past with students' ability to bring knowledge from DOET into their future work in the semester, and so I added a new culminating assignment that asks them to apply the book's principles to their CS222 projects. In part, this copies the inspiration I use in CS222 when I have them look at their CS121 projects: having them look back on their work, after they have had a chance to step away from it, should give them more objectivity while also reminding them that, despite imperfections, that work was important to their journey. This report is currently designed as a two-week writing assignment with an explicit, graded check-in point halfway through. This will give me and the students' peers an opportunity to give them feedback on which parts of the report are working and which are unclear before the students complete their final submissions.
The course plan as of this writing only goes through the DOET readings and analyses, but my planning notes go several weeks farther. My plan is to get them into Flutter, specifically the Web support that is currently in the beta channel. The thing I like about Flutter is the “code as design” approach, in which the code clearly reflects the application structure. I have seen many students in this course and CS222 get hooked on a drag-and-drop UI builder such as scene builder, leading to two dangerous outcomes: they lose the insights and power about software structures that are gained through programming, and they still design bad-looking interfaces. I'm hopeful that Flutter will give us the right level of abstraction to avoid these two pitfalls.
What I would like to do is have them learn Flutter by creating a simple project, which at this point will likely be a grade calculator. It's simple and familiar, but there is still plenty of room for students to go in different design directions. Then, I would like to use this simple example to introduce readings and techniques of usability evaluation, Gestalt vision, and accessibility. That last point is a new one for the course despite its importance: it has frequently been one of the topics I have cut when doing community-engaged projects because, inevitably with community projects, there are problems that the teams need to put their heads down on and fix.
I would like to wrap up the semester by having them make a larger project that they can use to bring together all the analytical tools and techniques that they have learned. I am still a little uncertain about the context for this project. I may just open it up to them, as I do in CS222, but this runs the risk of students falling into a quagmire of code and not appropriately deploying the other cognitive tools we are learning. I may just give them a canned project for that reason. Two that have come up recently in my own practice are a tool to judge student showcase entries, as in the CCSC Midwest Conference, or a tool to help students manage checklist-based specifications grading, as in my Game Programming course plan.
I think I will return to the CS445 course plan in the next few days and add details for those other assignments. Looking at it now, I realize that I forgot to add the due dates to the Web site; since I cannot yet even access the Canvas page for the course, I may as well trick out my lit-html templates to include the deadlines online. In any case, I had a productive morning of planning, and it seemed like a good time to write this blog post in the gap before lunch.
As always, thanks for reading, and feel free to share any feedback or questions you have about the plans.
No comments:
Post a Comment