Posts Tagged ‘345/545’

Elemental

June 2, 2010

One of the teams (or, I think, one of the members of one of the teams) from my Android-HCI class cleaned up the class project and has released it on the Android Market. If you have an Android device, open the market and do a search for “Elemental”, and you’ll find a nifty little periodic table application by Team Phosphoric. Well done, gentlemen! I found posting an Android app on the Market to be a fulfilling personal experience and a great learning experience as well.

The good folks at Google have promised that we should get a Web-searchable version of the Market soon, as well as cloud-to-device messaging, which will allow me to give you a link directly to the app installation. Until then, you’ll have to do it the conventional way.

Advertisements

Reflection on 345/545

May 6, 2010

It’s the end of the semester, and today were the final presentations in the HCI class. I am taking this opportunity to reflect upon this teaching experience, an attempt to articulate some of the joys and frustrations of this semester.

  • I am disappointed that none of the projects have been released on the Market. I suppose it’s a good thing for the students that I didn’t make this a requirement to get an A. I do not think that any of the teams even seriously looked into the distribution requirements, which makes me sad, because there are many interesting elements here, including application permissions, application signing, certificate management, and dealing with feedback from unknown and unexpected users.
  • I knew going into the semester that the vast majority of the students would not be able to adequately scope their projects, and so agility was built into the expectations. However, I did not fully account for the negative relationship between estimation inexperience and team size.
  • I suspect the results would have been better overall with smaller team sizes: this would have increased both accountability as well as motivation, since individuals would be needed. I tried to keep the number of teams relatively small so that I could keep track of each team and provide directed feedback. In retrospect, seven teams were too many for me keep track of anyway, and so having more teams would not have been a significant drain on my time. It would have complicated in-class presentations, but I suspect this would not have brought as much difficulty as benefit. (Many wise students suggested smaller team sizes in their reflections.)
  • The risk matrices were generally useful, but the MSF Team Model was not. From personal experience and the stories told in students’ reflections, it is clear that most students did not understand the meaning of the roles, and I suspect the “role” system caused more difficulty than was necessary. Students with no prior experience in significant team development projects have no useful mental framework for roles, and so, in retrospect, I should have predicted that they wouldn’t appreciate what the roles meant. Point in case: “testing” doesn’t mean anything to a student who has never tested anything. (The fact that students can go through the foundations courses and never discuss testing is a problem, and it’s being addressed by the introduction of 222.)
  • The teams suffered from communication breakdowns and uncertainty about tasks at a fine grain. The risks of the risk matrices were slightly too abstract for the students with no prior team or large-scale development experience to handle. I suspect one of the following would be preferable: (1) more rigorous management of the risk matrices, including more directed feedback from me about the appropriateness of risk articulation; or (2) a more quantitative, task-oriented project management technique such as the product backlogs of Scrum or the use of issue tracking software.
  • Having community partners was important, especially to the best students. Many of the students clearly learned important lessons from these interactions. Some of them were lessons I was also trying to convey, but it was much more effective to work with the ignore-the-professor-in-favor-of-outsiders phenomenon than it was to fight against it!
  • The reflections were worthwhile except that I needed to set stricter deadlines. I am not a fan of deadlines for such work, but they are needed for my own sanity, not for the students. Because I did not set explicit deadlines, I have been inundated by “reflections” the last two days. The astute reader can guess the quality of reflections that are being sent in right before the end of the semester. Hint: they’re not the ones I really enjoy reading, and I think they primarily why I have been so blue today.
  • Expanding on the previous point, it was very rewarding to read the reflections of the responsible students. By responding to their metacognitive essays, I felt like I was having a direct and positive impact on their individual learning, a great win for a constructivist. I realize that there are two potential complications in this: (1) there is a chance that better rhetoric is being rewarded over authentic-but-inarticulate reflections, and (2) a student who is savvy with emotional intelligence could manipulate me through these essays. I think either are acceptable costs. Regarding the first, writing is an extremely important skill that students should have anyway, and regarding the second, I think the best of the students are more honest than that.
  • Expanding on this point again, it was frustrating that some students still did not get the point of the reflections, or perhaps what metacognition is about. I am concerned that perhaps I did not articulate the requirements clearly enough, but with targeted individual responses, I’m not sure what else I could do aside from assigning them to do exercises out of Pragmatic Thinking & Learning.

There are some things I would change if I could do this course again, but mostly, I wish I could take all of my “A” students and with me and do some really great things. Unfortunately, the curriculum doesn’t work this way: this is a terminal class, and I have to let go. (Another reason I’m a little blue today.)

For any of the negative aspects of the course, I do believe that the students really did meet the learning objectives of the course. By and large, I think they understand better the role of humans in software development, both as users and as collaborators. For those who are not graduating (who are most), I look forward to watching them move through the curriculum and seeing if the course really had a measurable effect, especially as they take the capstone course— projects of which are often characterized by team trouble and bad user-interfaces!

Also, the design of the course met the primary constraint: the students were able to hit the ground running with a mobile application development project of their own design, while I was free to enjoy the birth and first few months with my second son. I wouldn’t want to do this every semester, but this one worked out fine.

Advice to future students from current students

May 6, 2010

It’s the end of the Fall semester, and I am a little bummed. More on that later. For now, I will amuse myself by sharing with you, dear reader, the advice that my students are leaving to future students. Specifically, this came from an anonymous survey in my HCI class. The class was project oriented, 15 weeks on a mobile phone application. In the survey, I asked for “Advice to Future Students,” and the students were told that any responses would be shared.

I will be linking my 315 and 222 students here in the Fall.

The only advice that I can give. Any course taken by Dr Gestwicki is very immersive and practical. If you want to fully utilize his course, dont take any other course or atleast dont burden yourself with too many courses other than the required minimum. I personally felt that I had only used 10% of him this semester and still I found it very enjoyable and wonderful. So imagine how I would feel, if I had utilized him to the full. You can make a living out of any of his courses. Attend all of is meeting( I wouldnt say that as classes) and always dont hesitate to ask him any doubts, even if they are silly. Go and knock his office doors often :)

Tackle the bigger problems first, making about pages, and splash screens is trivial compared to the main functionality of your program.


Consider your scope very very carefully. Consider how you are going to meet that scope.┬áConsider what you want to do and make sure you refine that as much as possible. If you have someone that’s taken software engineering before have them help you figure out a development process that will work for your team. Try and do everything you can to involve all the team members.

start your project eariler,
go to developer guide, if you have some problems with andorid coding
communicate your team more than once per week


My advice would be to always get your work done in a timely manner. This, of course, does not pertain to the specific class alone. Nobody likes the person that never does their work. Don’t be that person, is my advice.


Read your documents and any extra material that you think you may need or even peaks your interest. In this field its always good to stay up to date on the latest information as well as branching out and learning new languages, ideas, and methods for accomplishing a goal.

Also, get to know people a bit before you decide to work with them. Just because you are friends with someone doesn’t mean you know their work ethic or their abilities.


Read before start

A good group makes all the difference, and bigger isn’t always better. Having a good tight group of 4 or so people will keep you organized and agile.


Let me begin with an overarching caveat: when you take a class like this, the majority of your work – perhaps 90% or more – will be dealing with other people. You will pick your project, the difficulty level, and almost every aspect of how it should get done. Furthermore, everyone in a 300/500 level CS course should be able to write code and solve problems. Skill is not the problem. Getting people to do the work is.

Take the hiring phase of this course seriously, even though you may have little time/resources to do so. Once you’ve formed a team, get to know the PEOPLE on your team ASAP, not just WHAT they can supposedly do. Find out if they have a lot of other courses this semester. Find out if their other courses are difficult or easy. Find out whether they will consider this a blow-off class or not. If you find yourself among a team of slackers, leave the team or fire those people immediately. Otherwise, you will probably ruin what could have been a fantastic learning experience in this class.

Additionally, find out how your teammates think. This is especially important (in my experience) if your team includes students from other parts of the globe; not everyone thinks like you. The words ‘testing,’ ‘development,’ ‘design,’ etc. can mean slightly/very different things depending on your background. In fact, even if your team consists of just one nationality, your teammates’ past project experiences may foster inconsistent team-wide expectations. Create a terms list for your team ASAP defining project-related terminology. Make sure everyone is on the same page.

Lastly, make sure you adhere to the following three rules when it comes to working as part of a team:
1. Communicate early.
2. Communicate often.
3. See rules 1, 2, and 3.

The internet will lie to you, only incorporate those ideas and algorithms into your project that you understand.
It is best to address the problem of an unproductive team member early rather than late and to do this in as creative and friendly of a way as possible.
Satisfactory results are not always correct results. Test at the margins; the beginning and end of files, the extremes of input – large and small, and test your project with both an expert and a novice.

Reflections on Situated Learning

April 23, 2010

I just finished reading Situated Learning: Legitimate Peripheral Participation by Lave and Wenger. It’s a fascinating piece of scholarship published in 1991 that approaches learning from a situated, social perspective. An overview of Legitimate Peripheral Participation (LPP) can be found on Wikipedia. Many ideas came to mind as I read this book, but before I go any further, I should mention that this is still relatively far afield from my usual research areas, so I welcome correction if I am missing the nuances or even just plain wrong on my interpretations.

Communities of Practice

The authors describe learning as happening in a community of practice. To establish this point, they leverage a variety of examples of apprenticeship. One of the core contradictions the authors use is that of community regeneration, that newcomers become old-timers. Tying this into higher education, it makes me concerned that much of higher education is designed to propogate professorship. This is almost too easy an explanation for why motivation to study is generally low among college students: the intention of the teacher and the perspective of the student (assuming the student is not intending on an career in academia) are completely different.

Masters such as these

A quotation from p85, in the context of discussing how learning occurs in communities of practice despite the absence of didactics:

If masters don’t teach, they embody practice at its fullest in the community of practice. Becoming a “master such as these” is an embodied telos too complex to be discussed in the narrower and simpler language of goals, tasks, and knowledge acquisition.

This captures some of my frustration in teaching. I reference my working with two students on Confluence as one of my most positive learning experiences, and I feel strongly that we all learned substantially from this experience. Borrowing from Lave and Wenger, my students were legitimate peripheral participants, and I was the master—not the “teacher”. This is in stark contrast to my experience with 345/545 this semester. With 33 students spread across seven teams, I am left barely involved in their processes. I am a master in abstentia, but I can see no other way to organize so many people with one course load.

The other course I have this semester is on history education game design, and I am team-teaching it with my esteemed colleague Ronald Morris. We have eleven students who are working on the design for a game that will teach fourth-graders about Indiana’s Civil War history. While the class has some forward momentum now, there have been several points where I have felt that the students were either not putting in the right amount of effort, or that they were not putting effort in the right direction. I have tried to guide this as a mentor, but looking at it from the LPP perspective, not as a master. I cannot help but wonder what would have been different if I had been the game designer, and the students had legitimate peripheral roles: would that have been a better learning experience for them, with less of the frustration that comes from masterless apprenticeship? I am going to need more time to think about this, but I offer it here for consideration and commentary. (EDIT: I should add that I don’t actually consider myself a master game designer, but rather someone who is learning along with the students. However, my “mentoring” actually separates me from being a legitimate peripheral participant. Weird.)

Lave and Wenger do not explore the structural changes that would be necessary in formal education in order to leverage LPP, but I do not blame them for avoiding that minefield in this work.

Teaching a craft

One of the more interesting case studies referenced in the book is that of the apprenticeship of tailors. An apprentice starts by learning to finish a garment: sewing buttons, hems, etc. The apprentice then learns the production process backward, so the last thing the apprentice learns is how to cut the material. This way, while working peripherally yet legitimately in the community of practice, the apprentice is learning not just the feel of the material, the repeating patterns of tailoring, but also the social interaction and the personal identity of tailorship. The authors claim that this outside-in pattern of learning a craft is common across times and cultures.

I agree with Alistair Cockburn that software development is largely a craft. Are we guilty of teaching students inside-out, from cutting to polishing? Given that students rarely ever truly ship anything, I would answer affirmatively. Understanding this model of learning a craft, and the theory of LPP, has given me a new perspective on an old frustration, but again, I’m going to need more time to digest it.

Criticism and Teaching

March 19, 2010

Yesterday, I had an interesting juxtaposition of events. In the early afternoon, my students in 345/545 gave their status reports. Immediately afterwards, I went to a colleague’s class — a graduate course in architecture — to help review status reports there.

In my own class, the students had previously set goals for what they would accomplish before Spring Break. I think the teams had set (mostly) set reasonable goals, although several of them struggled with the concept of measurability. (As in, the goals had to be measurable.) The point of Thursday’s status reports was to briefly address how well the teams had progressed in meeting their goals.

While some of the teams had met their goals, I was overall disappointed with the progress. Some teams clearly misunderstood that there was no expectation in the schedule for work over Spring Break — although it was an opportunity to make up for lost or mismanaged time. Some of the teams have been struggling with the same technological issues since the beginning of the semester, and this is inexcusable. Fighting against the technology, there will be no progression into the deeper topics of HCI that I want students to explore through their projects.

However, I did not tell them this. I was mostly quiet during the status reports, offering little nuggets here and there. My thinking at the time was that the public shame of having missed even rudimentary self-imposed deadlines, and the peer pressure from their colleagues, would be enough to force them to move forward. In retrospect, I’ve been acting this way for weeks, and I’m not sure that this has been the right course.

I moved from this class to a colleague’s, in which I was one of several faculty and staff members who were providing feedback on entrepreneurial innovative ventures. Th best part was the discussion following the presentations. Without naming any names, I’ll say that I was vocally critical of one of the presentations. During the presentation, I recorded a page of criticisms. When we got to Q&A, I tried to gently address the shortcomings of what was presented, though I probably addressed only half of the items I had written down (and none about the dreadful infographics). I was fair, I think, and firm. Yet, perhaps not firm enough: the real problem was that the presenters had an idea but not a plan. Ideas are a dime a dozen: implementation is what defines success. However, I tried to criticize what was presented rather than the process I perceived; I did not want to come across as a jerk with an axe to grind when invited into another’s classroom. However, when the professor himself gave his closing comments to the team, he articulated very clearly what was really the essence of my piecemeal criticism: the problems of the team’s process itself rather than the specifics of their presentation.

As I reflected on this — and discussed it with my wife over dinner — I feel like I was two people yesterday afternoon. In my own class, I was standoffish, not even writing down the many and valid criticisms that could (and probably should) be levied on my students. My wife put it well when she suggested that I should have said, “It goes without saying that your work is unacceptable.” The problem is, I don’t know if it actually went without saying, or if my students are blissfully ignorance of their impending doom should they fail to pick up the pace.

Conversely, in the afternoon, I was diving into specifics, leveraging the critical power of the unknown professor to try to pry the best ideas out of these students who I don’t even know.

And this makes me wonder if this is the essence of the problem. I have gotten to like my 345/545 students, and I want them to succeed. I don’t really know how much criticism I can hit them with and have them still be inspired, rather than becoming disenchanted. I am reminded of a story that Hal Abelson told me about his mobile application development class: when one of the students listed “lack of time” as a risk, one of the professors suggested he either drop the course or deal with it. That’s tough love — I respect that, but sometimes I have a hard time doing it. I wonder if maybe I have coddled my students too much, given them a false sense of accomplishment where, in fact, I complain to my wife almost every night that I am concerned about their lack of progress in their projects.

From this cogitation, I have come up with two actionable ideas. First, the teams should be smaller. My initial vision for the course was that students would be inspired to take the initiative to explore the rich landscape of HCI, and that each would bring unique talents to bear on the success of the project. This has not happened, and I can’t help but blame The System: my students are being asked to do too many things in one semester for them to be able to focus on learning. (Learning in higher education?! No time for that. (That’s the topic of another post.)) As it turns out, some of the teams are just too big, and it opens up the possibility for miscommuncation, mismanagement, and blamesmanship in completely unproductive ways. If I cannot change the system, I can mitigate the problem with smaller teams, I suspect. The confounding corollary is that then I would have about twice as many projects and teams to keep track of, which would be very difficult for me, and again I can’t help but blame The System.

The second action item is to specify milestones for the second half of the semester. Some of the teams are doing an exemplary job of managing themselves, but many still have not seemed to hit stride in this respect. By giving some concrete milestones, I am wedging myself in as a manager in a way I was hoping to avoid, but it seems to be the lesser of two evils. Figuring out where these milestones should go will be a topic for this weekend’s consideration and Monday’s work.

A third idea, on which I may or may not take action, is that I may need to create more explicit rubrics for my students to let them know what I think about how they are doing. They are right now conducting peer evaluations, using a painstakingly-designed rubric. I could adapt this to let them know how I see their team work, presentation skills, technical progress, and understanding of key HCI concepts. I suppose I should first set up their milestones, and then figure out how to best give them the feedback I think they need.

Moving forward, I am going to try to be more cognizant of my own feelings with respect to the critical feedback I give my students. If I’m not giving them the criticism they need, then I’m not doing my best job for them. I will try keeping some notes about my feelings and fears as I observe these status reports, and hopefully that will guide me.

EDIT

As always, my wife is a font of wisdom. How she does so with the chaos of two young boys, I cannot fathom. In any case, in conversation with her I realized that I was probably trying a little bit too hard to try to undo the effects of years of brainwashing from our culture and ridiculous industrial educational system, and accomplishing this in half a semester may have been a little optimistic. This forces me to acknowledge my own fears, that if I comply with the system — as my students (potentially subconsciously) want — I will forget what it is that is so fundamentally broken about the system itself.

345/545 and Dreyfus

January 27, 2010

Two posts in an hour — lots on my mind.

I want to briefly outline the connection between 345/545 and Dreyfus.

Assumption: all students coming into 345/545 are at least novices at HCI by virtue of their having used computers and thought about them.

Assumption: many students are already Advanced Beginners at HCI. They have done some elementary GUI programming, read at least a few chapters or tutorials on the topic. They can already follow simple instructions. Those students who are only novices will become advanced beginners during the semester by going through the Android Development tutorials and documentation. (NB: if a student doesn’t do this, they may stay a novice—certainly the squandering of a unique learning experience).

Observation: the biggest hurdle is getting over the second-order ignorance of the advanced beginner, making the transcendent leap into competent, which is my target for all students. I’m hoping some may actually hop up to Proficient, if they put in the effort, but Competent is my target. For what it’s worth, Andy Hunt told me in private email that Competent is his target for undergraduates and Proficient for those with masters degrees.

Conclusion: design a learning experience that forces students to confront their second-order ignorance. I do not think this can effectively be done by lectures and assignments. Rather, get students intrinsically motivated by allowing them to define their own goals and metrics of success, forcing them into a metacognitive situation. I need to provide the scaffolding for this, of course.

A few students have told me that they are loving the class. I suspect they love it because they “get it”, and it’s not just the novelty of Android and mobile apps. As the Shmenge brothers say, how do you get the little baby to take the aspirin?