Archive for January, 2010

Great Presentations

January 28, 2010

Yesterday, I posted on a course Wave that it’s possible for a student to go through an entire undergraduate education without ever seeing a great presentation*. However, you don’t have to, thanks to the power of the Internet. Here are some of my very favorites (which I’m sharing with my students directly, too):

For further discussion of what makes a great presentation, I will refer you to Presentation Zen.

*Actually, I think it’s even worse than that. People see so many bad presentations that they never learn to distinguish between bad and good. The fact that so many students want a passive spoon-feeding education is a symptom of a wider illness.

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?

Don’t Trust Your Professors

January 27, 2010

In every course, I always make the opportunity to remind students, “Don’t trust your professors.” Students always respond as if it’s a joke, so I usually have to explain.

  • A major goal of higher education is the development of critical thinking skills. If a student passively listens to a professor’s lecture, absorbs bits of it, and spits them back out — whether on tests or in practice — there is no evidence of critical thinking. Unfortunately, much of our educational infrastructure and culture enforces the fallacy that teachers are fonts of knowledge and students are empty vessels. Great for obedience, poor for meaningful learning experiences.
  • Professors are biased. We are specialists, and so we see the world through our specializations. The self-governance model of higher education enforces an organizational fallacy: that folks with deep specialization are good at anything besides that thing. University governance models are by and large developed so that professors rule themselves, but what know we of business, of marketing— or for that matter, of education? Professors, by virtue of advanced degrees, are neither inherently good nor inherently bad at any of these. We are as subject to second-order ignorance as anyone else is. However, I believe that the situation is exacerbated by the fact that we have built up an ivory tower for ourselves in which we pat ourselves on the back and reward each other for things we know very little about. An example close to my heart is the science of teaching and learning: there’s no reason to believe that because I am a specialist at interactive visualization of Java program execution that I am also good at teaching it. For more discussion, see the Dreyfus Model of Skill Acquisition and the distinction some make between Experts and Masters (also called Proficient Experts on Wikipedia).
  • Finally, the knowledge we have is gathered from a wide variety of sources. In internalizing this knowledge, we have judged it (according to our biases, as mentioned above). What we share in class is not definition but interpretation. One of my favorite examples from Computer Science is the Model-View-Controller architecture. There is a sense in which “MVC” means something, but delve beyond a very naive “separation of concerns” interpretation, and you find a wealth of disagreement and different interpretations of this pattern. There is not a single right answer to the question, “How do I implement MVC?” The truth of MVC’s meaning is much richer than any definition or example I can give in class. I believe, therefore, that my job is to help students understand that there is a path to enlightenment, not to try to give them my lamp.

Who am I, anyway?

January 20, 2010

When I first started as a teaching assistant at UB, I started my first class by saying something like, “You can call me Paul, you can call me Mr. Gestwicki, you can call me Mr. G — it doesn’t matter to me.” At the end of recitation, a memorable student came up to me and said, “I’m gonna call you ‘P.G.’!” And he did, for his four years as an undergraduate. (Steve, I would love to know where you ended up!)

My surname is not that complicated, and yet it scares some people. At Ball State, I adopted the moniker “Dr. G.”, which is designed to be simple and easy to remember. It’s part homage to my high school physics teacher (“Mr. G.”) and part homage to Coach Z.

This semester, I am team-teaching with a very talented History professor who is my senior both in years and rank. He is “Ron” in class. This makes it very awkward for me to be “Dr. G.” Going by two names does not solve the problem since several students in this team-taught class are also in my other CS class.

One of my undergraduate professors who I admire goes by his first name, “Ziya“. Although it’s a first name, it has an otherworldly (or at least other-continently) ring to it that “Paul” just doesn’t have. I never felt like I was calling Ziya by his first name: I felt like it was a title. My theory professor in grad school solved the problem by calling all of his students by their last names. He was Dr. Regan, and I was Mr. Gestwicki — very formal, very symmetric.

From a teaching philosophy point of view, I do want to be the guide on the side.  I don’t want students to think of me as having some arcane and unattainable knowledge. Does a title like “Professor” or “Doctor” engender such perception? I don’t want to imply familiarity where mutual respect is the goal. What is the role of a name or title here?

I have no answers yet.

Orders of Magnitude

January 19, 2010

As loyal readers know, I published an application on the Android market on January 3 called “Connect the Dots” (blog, project page). Today, January 18, I just checked the stats on the Developer Console: there have been 7489 installations of Connect the Dots, and it has 3.5 of 5 stars.

This means that more people have used Connect the Dots than have used any other software I have written by two orders of magnitude. When I first noticed this, it absolutely floored me. For all of my work on JIVE, in education, and on information visualization, it’s this silly one-week project that most people have used. It’s very hard to measure my impact on students in higher education in any kind of quantitative terms, but here, I can see that Connect the Dots has brought happiness to thousands of people. It may be fleeting happiness, but it’s happiness nonetheless.

Part of the inspiration may be the classic Powers of Ten video. Watch it if you haven’t. All my other work is a picnic blanket: Connect the Dots is a park. It borders on ludicrous.

Reflections on “What should we teach new software developers? Why?”

January 17, 2010

Reading the latest CACM, I came across an opinion piece by Bjarne Stoustrup entitled “What should we teach new software developers? Why?” The topic of the article fits right into my blog-on-teaching-reflection. There are a few interesting and controversial things in the article, some overt and some implicit.

The tension between “computer science” and “software development” is not adequately addressed, in my opinion. It is true that right now, academic study of computer science often leads directly to employment in software development. I wish Stoustrup had spent some time on whether this was necessary and mutable. I don’t blame him, in such a short article, to simply take the world-as-it-is position.

The natural extension of this article is “How?”, since he has already addressed “What”? and “Why?”. Stoustrup dips into potentially blasphemous territory when he calls for more group projects, but more and more, I fall into that camp. I wish this idea, and much of what Stroustrup preaches, were easier to package for the opposition. It is unfortunate that the same establishment that wants us to teach C++ at the same time won’t listen to Stroustrup’s calls for fundamental change in how we teach!

His comment on “smokestack” courses is especially interesting to me.  Integration is an important part of learning, but by and large, professors don’t want to let go of their territory. To actually teach integration of knowledge requires significant overhaul not only in curriculum and course design, but potentially in the entire reward mechanism for faculty. I have seen this topic arise at the departmental, college, and university levels, and in an age of tight budgets, I am not hopeful for innovation any time soon. Borrowing from Christensen, it’s not clear that the entrenched structures of higher education can disrupt themselves.

Stoustrup’s notion that the lowest degree offered for software development is a Masters is intriguing. I am not sure that I have much else to say about that for now, but I do love for my own students to deeply study practically anything from outside of CS.

These thoughts are incomplete, and I’m not perfectly following Merlin Mann’s suggestion to edit all writing, but at least this is some food for thought. Perhaps I will come back to it later, but as seems to be my modus operandi recently, I feel like I have more topics I’d like to write about than I have time to write at all, so editing gets short-shrifted.

User-Centered Design

January 12, 2010

Here’s an image I created for my introductory presentation in CS345/545. I quite like it.

Child using Android phone with the caption "User Centered Design"
Creative Commons License
User Centered Design by Paul Gestwicki is licensed under a Creative Commons Attribution-No Derivative Works 3.0 United States License.

Hypocrites, or signs of changing times?

January 9, 2010

Back in November, I attended the International Digital Media and Arts Association conference, conveniently hosted at Ball State University. It was for this conference that my Confluence project was developed. I did not attend many talks, spending most of my time babysitting the Surface. (Turns out the system was perfectly stable, by the way.)

One of the events I attended was a panel discussion of “digital media and arts” folks. I’m leaving their names out for now—maybe I’ll edit later—but suffice it to say that they are successful in the field. Two related questions were raised: how did they become successful, and how should modern college students be educated to succeed in digital media. I should acknowledge here that I don’t ever call myself a “digital media” person. They seem to mean something different by it, even though all of my scholarship is digital and expressed in various media. That’s a topic for another discussion, perhaps.

Three of the four panelists explicitly credited a liberal arts education with their success. Only one of the four had a “pre-professional” higher educational experience in media studies. However, when asked about what students should learn, all four immediately jumped on skills training. I noticed this contradiction immediately and wrote it as a question in my pocket notebook, but perhaps for fear of being branded an apostate, I did not take the opportunity to ask the question. The panel also ran out of time, incidentally, so maybe more time would have given me more courage.

What I am left with then is this question: Why did the majority of these experts recommend paths to success that were substantially different than their own paths?

I have three hypotheses. One is that times now are simply different. Graduates are expected to be more productive much sooner, and the literacies of digital media are significantly more advanced than they were 20 years ago. This is not unreasonable. The media and higher education intelligencia make a big deal about digital natives, but I’ve seen it myself: these students are not technically literate. They know a few clicks, but their digital literacy skills are pretty much on par with their reading & writing skills, which is to say, lacking. There are always diamonds in the rough, but I’m frankly disappointed with the critical thinking, analysis, and literacy skills of  college students, but that’s another topic for another post. My point here is that maybe the bar of digital literacy is too high for the majority of students to get in K-12, and so we have to do training in college for students in digital media. (NB: I doubt it. Civilization has not yet collapsed because college students are not perfect.)

Another hypothesis is that it’s a sinister—albeit potentially subconscious—desire for these experts to stay on top. If they tell the rest of the world to go learn Photoshop, and meanwhile they have knowledge of history, literature, arts, etc., they will always be the boss and the rest will always be amazed by their intelligence. (NB: I doubt it.)

That leaves my third hypothesis: these experts haven’t really thought about it. They have spent too much time with HR trying to hire people with specific skills to serve the company’s purpose. They have not thought about how to actually make a better company — kind of like Christensen’s observation that companies cannot disrupt themselves. Although they know their own success, they are blind to the key factor: critical thinking and lifetime learning skills development fostered by a liberal education. (NB: Yes.)

It’s Saturday before the new semester, and this has been on-and-off of my mind for weeks. I wanted to put it somewhere, so here it is. Is it proper to apologize, on a blog that almost no one reads, that I have no grand conclusions and am still looking for answers? I do think that this is a deep and wide issue, and that most of us are just skating on the frozen surface, impressed by how very graceful we are.

Connect the Dots

January 4, 2010

As we get ready to start the Spring 2010 semester, I should get working on my resolution to write more reflective pieces! This is inspired by a desire to “practice what I preach”—specifically, being a reflective practitioner. In my case, I see that as being relevant to higher education and software development, among other things.

Yesterday, I published an application on the Android Market called “Connect The Dots”. It’s a simple dot-to-dot application that is briefly explained over at http://sites.google.com/site/androiddots/. (By the way, you are encouraged to add the “La la la la!” after singing the title of the application.)

One reason for making the application is that my son, who is nearly three, seems to enjoy dot-to-dot puzzles, as I remember enjoying when I was young. This application was a way to make something that I could share with him. My wife is quite crafty and does all kinds of neat artsy things with him, but it’s harder to share my love of software creation. This was a personally fulfilling use of my time.

More to the point of this blog, by developing and publishing a mobile phone application, I have gained experience in the processes that I will expect my students in CS345/545 to follow next semester. One of the most important parts of this process is reflection. We’re studying human-computer interaction, after all: this cannot be done without adopting some qualitative research methods, at least stopping to think about what we’ve observed.

I feel like I should mention that I’m happy with the Android documentation. I appreciate that it goes beyond the engineering-technical into the design-technical, dealing with best practices of application design from both the performance and UI points of view. I think this will make it a valuable teaching tool, and I found it quite readable. I am eager to see how students with much less programming and UI experience take it, but I suspect most will enjoy it more than a traditional textbook.

The evolution of the “dot” design is interesting. From the beginning, I knew that the dots had to be large so that they could be easily touched. Also, the area that is sensitive to touch is actually larger than the dot, since fingers are not very accurate on touchscreens. The initial design looked like a conventional dot-to-dot, with the numbers outside of the dots.

early prototype showing numbers to the right and slightly below each dot

Connect the Dots: An Early Prototype

It’s connect-the-dots, right? How hard can it be? (Incidentally, I did not originally take screenshots during development, but through the magic of version control software and intelligent commit comments, I was easily able to roll back to this version and grab a screen capture. Subversion for the win!)

As I continued development and my team (i.e. wife) started making puzzles, I realized that I needed to move the numbers around. In a conventional dot-to-dot, the numbers are manually placed so that lines don’t cross over them. Even in the silly test image above, you can see that the line between 3 and 4 crosses over the “4” slightly. I started sketching some ideas of either computationally guessing where to put the numbers or incorporating another field into the puzzle description language (more on that later).

Then, after discussions with my wife and watching my son play the game, I realized that I had failed to question my assumptions. Context matters. In a conventional dot-to-dot, one uses a pencil with a very small tip to connect the points, so the points can be very small. The numbers go outside the dots, because the pencil marks through the dots, not the numbers. On a touch screen, if I need bigger dots, then I should just put the numbers inside the dots. It’s hardly genius, and in retrospect it seems obvious. However, I think it’s a great example of failure to question assumptions. Initially, I was just thinking “take paper dot-to-dot and make it electronic”. With this mindset, I had missed an obvious place for positive adaptation to a different environment. Now, in the version on the Market, we have two-state (pre-click and post-click) dots with numbers within, as shown below.

screenshot of Connect the Dots showing numbers in the dots

Better Dots

It was very exciting to me when I first gave Alex this puzzle. He went through it patiently, and as soon as the image drew, he smiled and shouted “a car!” Aside from being glad that my son was pleased, it meant that this actually is fun. It’s easy to lose sight of that when knee-deep in an API.

Later posts will address some other aspects of the application design and development process that I found interesting. Thanks for reading!