Tuesday, November 30, 2010

Design thinking graphic

Design thinking.

I needed this image for a proposal I am writing. I can't tell you how many times I've sketched this. It's not quite as pretty as the one I had been using, but it saves me space in the attributions, and it should be reproducible in greyscale without trouble.

Creative Commons License
Design Thinking by Paul Gestwicki is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.

Tuesday, November 9, 2010

Future of Education: Challenge Statements

About two weeks ago, I wrote about my six-hour meeting with the BSU Future of Education Task Force. One of the primary outputs of this meeting was a list of ten challenge statements. There's no secret recipe involved, so here they are, in no particular order:

  1. How might Ball State University foster learning in college?
  2. How might BSU help students embrace serendipity and uncertainty?
  3. How might BSU assist/encourage faculty to modernize their teaching?
  4. How might BSU provide more opportunities for experiential or immersive learning?
  5. How might Ball State University make the educational experience more relevant and interesting for students?
  6. How might BSU increase classroom engagement and interaction?
  7. How might BSU give students more choice so they can personalize their education?
  8. How might Ball State University get faculty to accept the opportunity costs of change?
  9. How might BSU align awards and incentives to change teaching and assessment?
  10. How might BSU increase awareness of resources to help faculty improve their teaching?

So, dear reader, how might we?

Thursday, November 4, 2010

Safe Fail

Regular readers will remember that in Spring 2010, I taught a Human-Computer Interaction class (CS345/545) in which students worked in teams to develop Android applications. The inspirational goal—stated at the start of the semester and mentioned many times during—was to release novel applications on the Android Market. Out of seven teams, none actually released their applications on the Market during the semester, and in fact, many did not exhibit core functionality by the end of the 15 weeks of development. One team did add some spit-and-polish over the Summer and has since published theirs: it's called Elemental: Periodic Table, and it has 1/2 star more than my own Connect the Dots. (I think there's a good reason for that, and it has to do with expectations management, but I'll write about it another day.)

There is a significant contrast between CS345/545 and the current CS315 course (game programming, a.k.a. 3:15 Studio). This has been kicking around the back of my head for a while, but I have not done any real rigorous reflection about it. However, this is all just set-up for the story, so let me carry on.

I was in the lab the other day with some of 3:15 Studio, and things were going well. I turned to one of my students who was also in CS345/545, and I mentioned that I wished that the Android development had been as productive. This particular fellow is a good student, but it's fair to say that his project tanked last Spring. His response to me was not one of regret or criticism, but rather, he observed that it was better to fail at a big team-based semester project last Spring than to fail at the Morgan's Raid project or his senior capstone.

What phenomenal wisdom! In my own idealistic and individual analysis, I had been thinking about the failure as being a problem that needed to be solved. This student recognized that the learning still happened. Specifically, it was learning from failure, which might be the only kind of learning that matters.

Wednesday, November 3, 2010

Students owning space

Let me tell you why this sign makes me happy.

A few weeks ago, we had a ScrumMasters Community of Practice meeting in 3:15 Studio (which consists of the students in my CS315 class). There are four teams within the studio, each with its own ScrumMaster. The goals of this CoP meeting were to facilitate the ScrumMastering process and identify any inter-team issues.

The student ScrumMasters mentioned that, especially towards the end of the sprint, the lab gets quite crowded. The University scheduled CS315 for 2–3PM MWF, and so this is the time that everyone in the studio is working on the project. About 1/4 work in the classroom where the course is official scheduled, and 3/4 move up to the lab, which is much more conducive to small-group work. At the CoP meeting, the students suggested putting up some signs claiming the priority is given to CS315 students at 2–3PM MWF. However, this is technically what some might call "unauthorized use of the lab as a teaching space," and so the students don't really have preference during this time slot, not in the letter of the law anyway. I recommended that the students come up with signs that convey what they want, and then work with the department chair to have them approved.

When I first brought up official signage with the department administration, they were not too keen on it, mostly because we don't really have an official lab usage policy. The machines are configured so that only our majors can sign on, but otherwise, there is no real regulation of the space. However, when I informed the administration that it was the students who wanted to put up signs—not me—they became more interested in the process.

One of the student ScrumMasters drafted a reasonable poster on Monday, and I gave him some feedback from my perspective as a faculty member. He made some edits and sent it to the chair, who made some further changes and then approved its posting. Today, the student posted the notice. Perhaps to him and the other students, it was a mundane occurence, but to me it was significant. It was a sign that the students took ownership of this collaborative work space, that they felt they are stakeholders in departmental resources, and that they can define how these resources are used for the betterment of their education.

Kudos to you, 3:15 Studio, for being exemplars of learning in the campus community!

Tuesday, November 2, 2010

A growing dissatisfaction with 222

There are plenty of things to keep me busy, but I find myself drawn mostly to the need to reflect on some recent activities in my CS222: Advanced Programming class. I have written a little about the course design previously, but as a refresher, it's a brand new course in the curriculum, designed as a bridge from the foundations courses to the project-oriented upper-division courses.

I have a growing dissatisfaction with the execution of CS222, and I think this is in stark contrast to my other course, CS315: Game Programming. 315 is based entirely on studio-based learning: it is project-oriented learning to the nth degree, with all 25 students collaborating with me and external stakeholders on a real project. Perhaps the best way for me to express the difference between these two courses is to show what I did in the last meetings of these two courses.

In CS315, where students are in their 10th week of the project:

  • Worked on research for 5-10 minutes while the students had their "daily" stand-up meetings.
  • Got new markers for the lab where many of the students work.
  • Found paper for the printer in the lab so that students could print up some signs on lab usage, which they proposed to the department chair as official statements.
  • Helped a student in the lab, who is in my other class, with his project and talked about D&D a little with him and some 315-ers.
  • Gave some tips on how to deal with in-game dialog box images and text, facilitating conversation between members of different teams.
  • Looked over a group's shoulders and recommended a refactoring to a monstrous method.

In CS222. where students are in the second week of a six-week project:
  • Talked for 5-10 minutes about the importance of voting, the history of public education and its role in forming an educated electorate, and the difference between indoctrinating patriotism and respecting freedom. (It is election day.)
  • Showed past and current examples of an MSF-style risk matrix and Scrum backlog, explaining that the teams may use either one--or something else--as long as they are deliberate in their decision and reflect on it, and they can write a reflection on it later. (5-10 minutes)
  • Gave a walkthrough of how I use Google's guava library. This took about 10-15 minutes, partially due to unexpected system problems with Eclipse, probably related to the distro change and multiple Eclipse installs I currently have on my netbook.
  • The remaining 35 minutes was used by teams to evaluate each others' physical prototypes. As teams evaluated each others' interface designs, I posted some links to the course Web site. Only one group asked me for feedback on their design, and then others came to ask about other things. The best of these was the question of whether I thought a specific project was even worth pursuing, and I explained (to the student's satisfaction) that it wasn't me they should ask, but their prospective users.
315 is a joy. It is by and large an amazing experience to watch students learn to work together and learn from each other in a wholly legitimate way, a sort of organized chaos.

In 222, by contrast, I keep finding myself talking much more than I want to. It's not usually until I'm done that I realize how long I have been talking. We can take the guava libraries as an example: when I first learned about them, I was floored, and I wished that someone had shown them to me ages ago. In my mind, it would have only taken someone's showing a minimal example for me to see why I should be using this in all my Java projects. Yet, when I showed the students what I do with it, I got very little excitement from them. Was it because they do not have the perspective I have to realize what a useful library it is, or was it a failure of my presentation? These two are hard for me to disassociate, but the fact remains that maybe the whole thing would have been better organized as a workshop than a lecture. This is not without its own complications, not the least of which is the amount of planning that's required for minimal payoff.

Since day one in 222, we've had assignments due twice a week, at each meeting. This idea was gleaned from the SIGCSE mailing list as a way of ensuring students are doing the reading and keeping up. I will be teaching the course next semester, and I need to re-evaluate this structure in light of the students' lack of programming prowess: I'm not sure they're seeing the forest for the trees on issues of design, since many still struggle with basic program structure. Be that as it may, right now, the students are working on a six week project, delivered in two three-week increments. I am continuing to have them read items from Effective Java, but now instead of relating them to old projects or other experiences, they are relating these to their current project. For example, they are currently reading about minimizing the scope of variables (Item 45), and I asked them to evaluate their current project--in its current state--in light of this design idea. It's too early to know if this is positively impacting student learning, but my fear is that I might be giving them too many diverse ideas for them to deeply learn from their project experience. As soon as a student sees the homework as busywork rather than a learning experience, it loses almost all value to the student.

Maybe writing this, then, has helped me to see the problem: some students are not seeing the tips in Effective Java as the brilliant ideas they are, and so the well-intentioned assignments become busywork instead of learning experiences, and so both the assignment and the project suffer, rather than the synergy I try to promote. If that's true, then it becomes a problem of motivation management, the perennial problem of education. I think that I will scheduled time in class, perhaps next Tuesday, in which to engage students in a discussion of this whole process. I get the feeling that many of them do not feel like they can give me an honest evaluation of the class in person, so I may have to find a way to get them brainstorming, maybe a SWOT analysis, and come up with communal ideas.

As always, no answers, but this blog is not a place for answers: it's a place to try to hunt down the questions, and the questions within questions. As always, I'm open to ideas from the community. My plan for now is to maximize the learning in the time we have left this semester (about four weeks), and then use Winter Break to do a more significant analysis of the structure, goals, and delivery of 222.