Two-Week Project Showcase

The focus of my sophomore-level Advanced Programming course (CS222) is a large project at the end of the semester. In the past, this has been a six-week project, delivered in two three-week iterations. It is a project of the students' own invention: they have to pitch a project to satisfy a set of constraints I provide. This semester, I decided to expand the project to nine weeks with three iterations. This goes hand-in-glove with the revised, achievement-oriented assessment model that I am using this semester.

Most students have never worked in a programming team prior to CS222, much less defined their own projects. To warm them up, I give a two-week programming project before starting the big project. The two-week project is done in pairs, and I provide the requirements analysis as user stories. This provides a model for them to follow when they pitch their own projects using user stories.

This semester, I gave a new two-week project that was inspired by my 2013 Global Game Jam project. The students were challenged to write an application that takes a word from the user and then hits Wikipedia's API to determine the last modified date of the corresponding page. The curriculum provides no prior exposure to Web programming or networking, and so I provided a very short sample program that demonstrated how to open a URL in Java and read the stream. This project touches on some very important ideas, including Web services and structured data.

In the past, I have evaluated the two-week project in a rather conventional way: I provide a grading rubric at the start of the project, then I check out students' projects from the department's Mercurial server and give each pair a grade. I wanted to do it differently this semester, in part because of the achievement-oriented assessment. The two-week project provides a vehicle for students to earn achievements and write reflections: I'm not evaluating the project itself but rather how students use it to explore course concepts as articulated through the achievements and essential questions.

I decided to devote a class day at the end of the two-week project to a showcase. Each pair had to have a machine running a demo alongside a summary poster. We rearranged the classroom, moving all the tables to the perimeter and clustering the extras in the center. In order to foster peer interaction, I printed some sheets whereby students could vote on which team had the best UI, the best poster design, the cleanest code, and the most robust input handling.

The students enjoyed this format. There was an energy in the room as the students explored each others' solutions, talking about implementation strategies and UI decisions. A few students had trouble getting their projects working at all, and I heard one student say how disappointed he was, because it left his team unable to fully participate in the activity. This represents positive peer pressure and project orientation, which can be starkly contrasted against instructor pressure and grading-orientation.

I had recommended two strategies in class: using Joda Time to handle time formatting and using Java's DOM parser to deal with Wikipedia's output. I was surprised to see that almost every team used Joda Time (and used it to earn the Third Party Librarian achievement) but only one team used DOM. Every other team read the output stream as a single string and then searched it using Java's String class. This provided an excellent opportunity to teach about input validation. My sample Wikipedia URL queried the "soup" page for its last modified time, and the result looks like this:

<?xml version="1.0"?>
<api>
  <query-continue>
    <revisions rvcontinue="574699285" />
  </query-continue>
  <warnings>
    <revisions xml:space="preserve">Action 'rollback' is not allowed for the current user</revisions>
  </warnings>
  <query>
    <normalized>
      <n from="soup" to="Soup" />
    </normalized>
    <pages>
      <page pageid="19651298" ns="0" title="Soup">
    <revisions>
      <rev timestamp="2013-09-27T05:20:10Z" />
    </revisions>
      </page>
    </pages>
  </query>
</api>

Keep in mind that this is coming in as one continuous stream without linebreaks. Aside from the one group that did an appropriate and simple DOM lookup, students used String#indexOf(String) to search for "timestamp=", and then did manual string parsing using that reference point. This approach works for most cases, but it opens the application up to an attack that I'll explain in the next paragraph, giving the reflective reader a moment to consider it.

If you ask the application for the last modified info of the Wikipedia page "timestamp=", you get a phenomenon similar to an SQL injection attack: the indexOf operation picks up an unintended location, and the manual string manipulations fail. I had seen this when meeting with a pair the previous week who were working on their Advice Seeker achievement. They had thought their solution to be rock solid, and they were appropriately excited when I showed them how to crash it. They became my covert hitmen during the showcase, crashing solution after solution by finding holes in string parsing logic. So, while few students took the opportunity to learn XML parsing in the two-week project, maybe they learned something even better: the embarrassment of doing it the lazy way and seeing your system go down in public!

When I explained to the students what were doing at the showcase, I had expected teams to show up at their stations when I came by. However, it seems they were so excited to see each others' work that they didn't think about this. Since not every team had a person at their station when I came around, I was not able to give my expert evaluation to each group, nor was I able to model for the students how to give critical feedback. On the other hand, the students got a lot of peer feedback and I was able to meld into the group, becoming just one of many people interested in seeing demonstrations and code. I am not yet sure if I would do this part differently next time or not.

One aspect that is still unclear to me is the extent to which students were working for intrinsic motivation versus extrinsic reward. I was approached after class by a student from one of the teams whose solution was not working. During the hour, they had talked to other students and realized what they did wrong, which is an activity I certainly want to foster. The student asked, clearly in a state of agitation, if his group could fix their application even though it was due to be completed the previous night. I confirmed that this would be fine, and the student went away expressing joy and thanksgiving. I suspect his perspective was that he had just been given an opportunity to save his grade. What I really gave him was an opportunity to make his project work and feel good about getting it done, even if a bit late. I don't think he realized that there's no entry in the course grading policy for the two-week project, that the whole thing was just a fun context for us all to play and learn together. I hope that when he figures this out, he sees this as a reflective learning opportunity and not simply smoke and mirrors.

In conclusion, I am very happy with the showcase format. It was definitely worth using a class meeting for this event. I think this two-week project was particularly well-suited to the showcase format since it's fairly small, permits multiple solutions, helps students build better understandings of the modern computing ecosystem, and can have interesting failure states. Perhaps next time around I need to add an achievement related to XML parsing, since this seemed to promote students' use of Joda Time quite well.

(I have some nice pictures of the showcase that I took while standing on top of the teaching station, but I feel like I can't post them here without my students' permission. Sorry.)

Photos and Stories from the Project Showcase

Last Monday was the Project Showcase for my seminar at the Virginia B. Ball Center for Creative Inquiry. It was held in Cardinal Hall at the L. A. Pittenger Student Center at Ball State University. We had three partitioned areas for the showcase. Guests arrived on the Terrace, where we had ample refreshments including cheese, crackers, crudités, meatballs, iced tea, and root beer floats. The sunlight streaming in through the windows was wonderful, although it also made the photos not come out so well.

In the next room, we had ten stations set up for people to play the beta of Museum Assistant: Design an Exhibit. Eight laptops were arranged on tables along the wall, and on either end, workstations were attached to the very large televisions on the side walls.

The plan was that this room would also hold six displays of physical artifacts that were created during the course of the semester. These artifacts include sketches, prototypes, posters, and other miscellany. However, as we set up this space, we realized that there would not be enough room for the demo stations and the displays, and so we moved them into the presentation area.

This presentation area had about 150 chairs facing a stage, and flanking the stage were two projection screens. The artifact displays ran along the sides of the two seating areas.

Stage left

Stage right

Here are close-ups of the six display boards.

Logos, hand-drawn room art, and screenshots of finished art

Room and character sketches

Concept art, screenshots, and excerpts from our design document

Mostly physical prototypes of our game, along with some storyboards.

At the top is the poster that was presented at the Computer Science Spring Banquet and the Butler University Undergraduate Research Conference. Below, concept art, storyboards, and bagged prototypes.

At the top is the poster created for the Ball State University Student Symposium. Below is the final physical prototype for Build a Museum, the primary contender to Mystery at the Museum. The latter was chosen and evolved into Museum Assistant: Design an Exhibit.

Posted along the right side of the room was a replica Scrum board along with a brief description of how it would be used. Our actual Scrum board was much larger.

I did not get any shots of the whole room, but here's one taken from the edge of the seats during set up. Immediately to my left is another projection screen.

Five of the twelve team members spoke during the presentation. We rehearsed several times at the VBC, and they rehearsed once in this space as well. I walked in during this rehearsal and caused a bit of a ruckus, partially to help them realize that distractions are unpredictable and partly just to mess with them. During the actual presentation, as soon as Josh started, every baby in the room started crying. He was well prepared!

There were about a hundred people in attendance, and the presentation was very well received. There were just a few questions at the end, and then we encouraged attendees to enjoy the food, drinks, displays, and the game.

One of the best parts of the evening was being able to meet the friends and family of my students. We have become an intimate group: spending fifteen weeks in close quarters with twelve other people inevitably results in many shared stories about family and friends. It was great to be able to shake some hands and especially to thank parents for their part in grooming this great team.

In case you missed the announcement or any of the links above, the game went live yesterday, and you can check it out at https://sites.google.com/site/designanexhibit. Enjoy!