One of my goals for this semester here at the University of Georgia in my role as Director of Innovation in Teaching and Technology is to introduce LiveCode to the College of Education community. My plan is to conduct a short (about an hour) seminar that demonstrates LiveCode in the context of learning to code. That is, I want to clearly and immediately make the connection between learning LiveCode and learning to code (i.e. program). A typical first project that one usually finds within most tutorials of computer languages is the "Hello world" example where one simply learns how to program the computer to display "Hello World" on the screen. However, I hope to do something much more interesting, so I've come up with a few example projects. I'm calling these "first projects."
Part of my motivation for doing this was inspired by the recent "Hour of Code" promotion which sought to have every K-12 student in American spend one hour learning to program. I also think learning to code is very relevant to supporting STEM (science, technology, engineering, and mathematics) education. In fact, I would argue that computer programming has not been emphasized nearly enough by STEM educators. Plus, I feel that learning to code also brings the arts into the discussion almost immediately given the ease and importance of integrating graphics, sound, music, and video within most programming projects. And what programming project would be complete without attention to technical, narrative, and creative writing? So I consider the language arts a critical part of a STEM education. Adding the arts turns STEM into STEAM, and I like the sound of that. (Here are two good articles about the need to learn to code from Wired and the Pittsburgh Post-Gazette.)
My objective for this first seminar is less about learning and more about motivation, particularly triggering a sense of confidence and competence. That is, I want people at the end of this seminar to go beyond just saying to themselves "Wow, that's cool!" to also quickly say "I think I can do that!" So, what examples I show are critical. So far, I've come up with three that I think are pretty good.
The first project is a simple mad lib program where four fields are created, one for adjectives, nouns, verbs, and adverbs. Clicking a button chooses one word from each field at random and puts them together in a sentence.
The second is a countdown program that counts from 3 to 0, then triggers the display of "Go!" after 0 is reached. I couch this one in the context of imagining that you have created some sort of race game and you need a counter to let the player know when the race is about to begin.
I also created a second version of this to show a stop light that goes from red to yellow to green, but without changing the program's algorithm (which I like to refer to as the program's "engine").
The third is a simple guessing game. The computer picks a random number from 1 to 3 and it is the player's job to guess what number it is. Not a very fun game, I know, but it does contain at least the seeds of a good guessing game with initial code that is easy to understand.
I'm also considering to use my "Colorful Addendum" that I wrote about back in May as a fourth example. It's a lot of fun to watch and I think the script is easy to understand. But, the script is a little long, so that might be a little "put-offish" to some people.
Here is my "Lesson Plan" for this one hour seminar:
I decided I will create a YouTube video for each project that a group selects each time I offer the seminar. My YouTube video for creating the Mad Libs project is about 30 minutes in length, which is longer than I would have anticipated. But, I don't think there is any "fat" in the demo, especially because I felt it was important to spend a little extra attention on some of the fundamentals of LiveCode and programming in a few places.
Part of my motivation for doing this was inspired by the recent "Hour of Code" promotion which sought to have every K-12 student in American spend one hour learning to program. I also think learning to code is very relevant to supporting STEM (science, technology, engineering, and mathematics) education. In fact, I would argue that computer programming has not been emphasized nearly enough by STEM educators. Plus, I feel that learning to code also brings the arts into the discussion almost immediately given the ease and importance of integrating graphics, sound, music, and video within most programming projects. And what programming project would be complete without attention to technical, narrative, and creative writing? So I consider the language arts a critical part of a STEM education. Adding the arts turns STEM into STEAM, and I like the sound of that. (Here are two good articles about the need to learn to code from Wired and the Pittsburgh Post-Gazette.)
My objective for this first seminar is less about learning and more about motivation, particularly triggering a sense of confidence and competence. That is, I want people at the end of this seminar to go beyond just saying to themselves "Wow, that's cool!" to also quickly say "I think I can do that!" So, what examples I show are critical. So far, I've come up with three that I think are pretty good.
The first project is a simple mad lib program where four fields are created, one for adjectives, nouns, verbs, and adverbs. Clicking a button chooses one word from each field at random and puts them together in a sentence.
[ Get the free LiveCode Community version. ]
The second is a countdown program that counts from 3 to 0, then triggers the display of "Go!" after 0 is reached. I couch this one in the context of imagining that you have created some sort of race game and you need a counter to let the player know when the race is about to begin.
[ Get the free LiveCode Community version. ]
I also created a second version of this to show a stop light that goes from red to yellow to green, but without changing the program's algorithm (which I like to refer to as the program's "engine").
[ Get the free LiveCode Community version. ]
The third is a simple guessing game. The computer picks a random number from 1 to 3 and it is the player's job to guess what number it is. Not a very fun game, I know, but it does contain at least the seeds of a good guessing game with initial code that is easy to understand.
[ Get the free LiveCode Community version. ]
I'm also considering to use my "Colorful Addendum" that I wrote about back in May as a fourth example. It's a lot of fun to watch and I think the script is easy to understand. But, the script is a little long, so that might be a little "put-offish" to some people.
Here is my "Lesson Plan" for this one hour seminar:
- (2 min.) Welcome everyone to the session. The goal is to demonstrate the computer programming environment of LiveCode. Give enough information to describe LiveCode and its history, but keep this very brief as people really won't care too much at this stuff at this point.
- (1 min.) Emphasize that LiveCode involves computer programming, also known simply as coding. Mention the "Hour of Code" promotion (and perhaps show the Web site). Make the point that there is much emphasis on STEM (science, technology, engineering, and math; and some add "arts" to turn STEM into STEAM). It is not enough just to use existing software, one must learn how to build software. To do so, one must learn programming. (Perhaps make the point that learning to programming is far too underemphasized in STEM circles, perhaps because there are not enough teachers who are able to teach it.)
- (1 min.) Emphasize that one of my reasons for learning LiveCode was because of its strengths in creating native mobile applications (apps) on both iOS (iPhone, iPad) and Android.
- (3 min.) Show "Lunar Hotel Shuttle" as an example that I've created.
- (3 min.) Consider also showing one or more other examples quickly. My Classroom Observation Research Data Collection (see blog posting from October, 2013) example might be a good one given the academic context of these session. The air traffic controller example found on the LiveCode web site is another good one.
- (10 min.) Show briefly all three "first projects" mentioned above, taking care to show each very, very fast. Then, pass out a ballot where people vote for the the project they wish to learn how to make during this session. (Let people vote for more than one if they have more than one favorite.) Collect the ballots and ask someone to tally them up.
- (30 min.) Build the "winning" project from scratch.
- (10 min.) End with some discussion and Q&A.
I decided I will create a YouTube video for each project that a group selects each time I offer the seminar. My YouTube video for creating the Mad Libs project is about 30 minutes in length, which is longer than I would have anticipated. But, I don't think there is any "fat" in the demo, especially because I felt it was important to spend a little extra attention on some of the fundamentals of LiveCode and programming in a few places.
No comments:
Post a Comment