On Tuesday last week, my HCI class gave their informal reports for the first iteration of their final projects. I neglected to post any real guidelines about the presentation, and so it was ad hoc. We did have two guests in the room, though, one being an expert user for the projects and the other being a software development professional. There were several points in the students' presentations when I cringed at how they presented their status and ideas. I considered for a while how to address this, and I ended up coming up with a classroom game show called Who would YOU rather work with?
This is a rhetoric game along the lines of The Metagame and CARD-tamen. There are two teams, each of which sends up a player for the round. The two contestant are shown a pair of fictional quotations, and based on these, must argue for who they would rather hire onto a team. We alternated which team went first, and each player had 30 seconds to make their cases. The winner was determined by popular vote. Even though a team could just vote for their own representative, I think the students understood that it should be a fair vote.
The original idea for the game was Is it User-Centered... or Not?, but I realized as I started working on the game systems that user-centeredness was only part of the equation. More of the problems were with students' rhetoric than with their technical or procedural approaches, and hence my choice to make this a rhetoric game.
We played the game last week Thursday. I had the students count off by twos in order to shuffle them around, so they would not be on a team with the person they usually sat with. The two teams named themselves The One Before Two and Los Dos. (Important note: The One Before Two insisted that the short name of their team was TOBT, pronounced "tot" with a silent "B".)
Here are the prompts that I gave them:
1.
"The images take a long time to load, so the user just has to learn to wait."
or
"We will show a spinner to signify to the user that the system is still working."
2.
"JavaFX is a pain. It's really fiddly."
or
"We thought we knew the JavaFX API better than we actually did. We talked about it and identified our main misconceptions, and we are working to overcome them."
3.
"We were all really busy so we did not work on that feature."
or
"We documented that feature as a user story to consider for the next iteration."
[or, in a bonus round, "That feature is out of scope."]
4.
"Git kept on destroying our files. It doesn't do what it is supposed to do."
or
"We had problems managing version control, and one of our impediments is our own understanding. We have prioritized finding the root cause so that it doesn't happen again."
5.
"We are making this application using Java and JavaFX because Dr. Gestwicki provided an example with these."
or
"We have analyzed our target population's needs and have chosen a development platform that allows us to deploy a solution that meets their needs."
6.
"We did a lot of work that you cannot see exposed through the UI right now, but it will be incorporated into the next iteration."
or
"Our source code provides the simplest possible solution for this iteration that maintains our standards of quality."
7.
"We are not sure if this is an SRP [Single Responsibility Principle] violation or not."
or
"We have evaluated our code for compliance with SRP and, where we were unsure, we consulted with the professor to evaluate the structure."
8.
"We know that what we have planned for iteration 2 is going to solve our problem."
or
"We learned from iteration 1 to help us improve our product and processes for iteration 2."
9.
"We based our work on Dr. Gestwicki's example."
or
"We built a solution for this problem based on our users' specific needs."
The last one is quite a bit like #5, but that was in part to handle the case where everyone actually showed up to class and would get a turn. Of course, not everyone showed up to class, so we had enough questions that some people got to answer two.
One of the students hypothesized out loud, in round three or four, that the bottom answers were always "right." I pointed out that this was a rhetoric game: there was no objectively right answer, but rather a challenge to persuasively argue your position. Once the game was over, I explained to them that there was indeed a pattern, of course. The top item was more or less what I heard people say during their presentations, but the bottom is what I would have like to hear instead. This caused a murmur in the crowd as they considered what this means. It gave us a good excuse to talk about how you present yourself when applying for a job or internship: that the applications will be sorted into two piles, and you want to make sure you end up in the "Let's talk to this person" pile.
For the most part, students argued that they would rather work with the second person on each slide, using the kinds of arguments you would expect. The statements on the bottom tend to show capacity for reflection, eagerness to learn from mistakes, honesty, professionalism, accountability, and user-centered rather than developer-centered. However, it was not the case that everyone argued for the bottom. On #3, a student argued that the person on top was simply being honest, not really making excuses, while the person on the bottom was being political to the point of dishonesty.
In the end, it was a close game, with TOBT winning 5 to 4 over Los Dos. I think the students appreciated the interactivity and how everyone got a chance to speak their piece. When it was all over, I walked through the slides again to talk through some of the issues that came up, so I guess they didn't really get a reprieve from hearing me lecture to them. However, I think they felt like they had some skin in the game now, since they had already shared their thoughts about each issue.
No comments:
Post a Comment