Comments on: Going with the flOw http://UnhinderedByTalent.com/Phi/archives/2007/02/25/go-with-the-flow/ Not all battles are fought with a sword Fri, 21 Nov 2008 15:06:58 +0000 http://wordpress.org/?v=2.5.1 By: Andy Korth http://UnhinderedByTalent.com/Phi/archives/2007/02/25/go-with-the-flow/#comment-12790 Andy Korth Mon, 26 Feb 2007 05:00:28 +0000 http://UnhinderedByTalent.com/Phi/?p=489#comment-12790 Some of these ideas are pretty similar to Ralph Koster's ideas in his book, The Theory of Fun. He discusses how games are all a sort of pattern matching. If a game is too hard, too complex, we give up and are frustrated. Likewise for an lab assignment in software design. Or if a game is too simple, it's boring and nothing is gained. Game players seek the best way to play or beat the game, always. In the context of games, this pretty clearly relates to the "Anxiety" and "Boredom" sections of the flow diagram presented here: http://www.jenovachen.com/flowingames/missionstatement.htm In the context of coursework, you're probably more concerned with not overwhelming students while keeping as many as possible from being bored- that is then penalty for too difficult assignments is greater than too easy ones- at least where the student's grade is concerned (and probably most students). The more I think about it, the more I suspect there isn't much beyond a mix of challenge and abilities to create flow. I'm not quite sure how the ideas of clear goals work in... The game Flow seems to have no goals and few instructions. However, there is a natural drive to explore. Players quickly notice they can increase the size of their creature, which seems to be an acceptable and interesting goal to play towards. There's also a drive to explore the next level. What about for coursework? Without a clear definition of the assignment, the aspect of a challenge is simply missing. Other games, particularly A Tale in the Desert and Eve Online do tend to suffer from the lack of goals. There's so much that could be done, but the band of flow seems very narrow. Anyway, thinking back to my coursework, I've had enjoyable projects of the appropriate challenge level, and boring projects that were a drag, but eventually completed. Portions of an assignment can be frustratingly hard, but it's hard to say how often these challenges defeat students. Usually they are addressed in the next lecture or perhaps dropped. 1) We are up to the activity. 2) We are able to concentrate on the activity. 3) The activity has clear goals. 4) The activity has direct feedback. When I look at these prerequisites from the standpoint of classes like Software Design I think each one can stand in the way of students being in the flow. 1) Simply being up for an activity is having a reason to do the assignment, understanding it and its purpose. 2) Concentrating on an activity means having the personal motivation to sit down and do it. I think this is mostly a personal thing although that doesn't mean that the professor does not have an important role to play here. I could expound on this, but it is beyond the scope of my response :P 3) Clear goals (long term and short term). This is why we have stories. 4) Direct feedback is about seeing results and seeing how what was learned in a lecture applies to programming. I write unit tests for their direct feedback. As I look at learning the observer pattern, I suspect it's fairly abstract for students. They might not see the immediate need for the added complexity, but give the professor the benefit of the doubt (unless the professor's major is in marine biology). But given some example code and the goal to add listeners to a large and incomplete project could be understandably difficult. They might not be up to something of this size, and furthermore, the're not a lot of direct feedback, since they can't see it in action. . A small mini-lab, or even assignment is probably the best way to demonstrate this. Even a small lab has a sense of completion. It's done and over with in a reasonable amount of time. The goals for a small assignment are more clear and seem more attainable. Some of these ideas are pretty similar to Ralph Koster’s ideas in his book, The Theory of Fun. He discusses how games are all a sort of pattern matching. If a game is too hard, too complex, we give up and are frustrated. Likewise for an lab assignment in software design. Or if a game is too simple, it’s boring and nothing is gained. Game players seek the best way to play or beat the game, always.

In the context of games, this pretty clearly relates to the “Anxiety” and “Boredom” sections of the flow diagram presented here: http://www.jenovachen.com/flowingames/missionstatement.htm

In the context of coursework, you’re probably more concerned with not overwhelming students while keeping as many as possible from being bored- that is then penalty for too difficult assignments is greater than too easy ones- at least where the student’s grade is concerned (and probably most students).

The more I think about it, the more I suspect there isn’t much beyond a mix of challenge and abilities to create flow. I’m not quite sure how the ideas of clear goals work in… The game Flow seems to have no goals and few instructions. However, there is a natural drive to explore. Players quickly notice they can increase the size of their creature, which seems to be an acceptable and interesting goal to play towards. There’s also a drive to explore the next level.
What about for coursework? Without a clear definition of the assignment, the aspect of a challenge is simply missing. Other games, particularly A Tale in the Desert and Eve Online do tend to suffer from the lack of goals. There’s so much that could be done, but the band of flow seems very narrow.

Anyway, thinking back to my coursework, I’ve had enjoyable projects of the appropriate challenge level, and boring projects that were a drag, but eventually completed. Portions of an assignment can be frustratingly hard, but it’s hard to say how often these challenges defeat students. Usually they are addressed in the next lecture or perhaps dropped.

1) We are up to the activity.
2) We are able to concentrate on the activity.
3) The activity has clear goals.
4) The activity has direct feedback.

When I look at these prerequisites from the standpoint of classes like Software Design I think each one can stand in the way of students being in the flow.
1) Simply being up for an activity is having a reason to do the assignment, understanding it and its purpose.
2) Concentrating on an activity means having the personal motivation to sit down and do it. I think this is mostly a personal thing although that doesn’t mean that the professor does not have an important role to play here. I could expound on this, but it is beyond the scope of my response :P
3) Clear goals (long term and short term). This is why we have stories.
4) Direct feedback is about seeing results and seeing how what was learned in a lecture applies to programming. I write unit tests for their direct feedback.

As I look at learning the observer pattern, I suspect it’s fairly abstract for students. They might not see the immediate need for the added complexity, but give the professor the benefit of the doubt (unless the professor’s major is in marine biology). But given some example code and the goal to add listeners to a large and incomplete project could be understandably difficult. They might not be up to something of this size, and furthermore, the’re not a lot of direct feedback, since they can’t see it in action. .

A small mini-lab, or even assignment is probably the best way to demonstrate this. Even a small lab has a sense of completion. It’s done and over with in a reasonable amount of time. The goals for a small assignment are more clear and seem more attainable.

]]>