New tech in the classroom – an adventure.

In a fit of techie twitching I decided to try some fancy technology in my classroom teaching.  I wanted to do a test review.  The test is a Word document.  I wanted to be able to highlight, underline and circle things and work problems free hand on the Word document.  The classroom I use has a computer and a projector, that is it.  I have an iPad app called Air Direct.  It puts my Windows screen on the iPad which allows me to control the computer remotely so I do not have to sit at my desk to run the computer/projector.  The app works once you figure out what order to do things and remember to set the app to mirror.  Details, details.  The iPad is a bit small to use to run Windows but a fine tipped stylus helps.  Getting that set up was the easy part.  Getting the ability to draw free hand on a Word document is another story.  Word used to come with a feature called Inking under the Review tab that did this task.  Guess what is not built in to Office 2007.  So I went on a search for a solution.  There are several apps out there that do this but are not free.  I live for free.  I kept searching.  No justice.  Think Flint, think!  The school owns some Smartboards so maybe if in install the SMART software I can use it to draw on the Word document.  After installing the SMART software the Start Inking icon magically appears under the Review tab.  Who knew!  So after about three hours of research, trial and error, tinkering and colorful thoughts regarding technology in the classroom I have everything up and running.

It is not a perfect solution, the iPad is simply too small and lag time is a bit of a pain, but it is better than nothing.  It also sort of justifies the iPad the school bought me which I normally use once in a blue moon.  I have got to find $1000 so I can get a Surface Pro.  It seems like the Surface is the tool for a task like this.

There are some lessons learned with all this.

1. Classroom tech is not always easy.  It seems like the simple tasks are not really simple.
2. When the Good Idea Fairy sits down in front of you, be afraid.
3. There is always an issue when trying new classroom tech.  Be prepared.
4. Actual improvement in instruction using this technology is debatable.
5. Technology is much more fun than the whiteboard.
6. I still dislike iPads but there are some nifty apps out there for it.
7. Do not plan to use new tech tomorrow.  Plan to use it next week after you try it out for a couple of days.
8. Make sure it is all working when your principal comes into the room for your annual observation.  It was and I was impressive.
9. Too bad Interwrite/Smartboards are so expensive.
10. New tech takes TIME!!

Poor Tutorial Kills GameSalad

In my usual desire to find greener grass on the other side of the fence I started tinkering with GameSalad.  GameSalad is game authoring software for mobile devices, sort of like Corona but more drag-and-droppish like GameMaker.  The obvious place to start is with the manual that is a tutorial.  So I start working through the Windows manual.  The manual does not match the latest version of GameSalad.  After an hour or so of “huh”, and “where is the thing the manual referring to been moved to this time”, and “that tab does not exist so where do I look now?” I am about ready to give up.  As a semi-experienced programmer that has a stubborn streak I can fiddle, tinker, search and cobble through the manual/tutorial and slowly get somewhere.  As a high school teacher with very little extra time to waste on out-of-date documentation I will no longer bother to look at this software a viable greener grass.  Tutorials make such a significant first impression that a crappy one will eliminate the very large educational programming population for a product. Why is it so difficult for companies to hire a competent individual or team to keep the documentation up-to-date and legible?  This seems to be a persistent problem industry wide.  I gave up on GameMaker because the tutorials were written by someone who assumed the reader knew how to use the software already.  I will give up on GameSalad because I do not have time to rewrite the documentation to fit the software.  The companies will not lose big bucks if I do not use their software.  They could lose big bucks in that I do not introduce their software to 20 aspiring game writers every year.

Actually, I do sort of understand the documentation problem.  My one short (six month) professional experience working for a software company showed me the issues involved.  This company wrote 911 call-in software.  One of my friends worked in the documentation department of the company.  She literally had to walk around and ask the programmers what changes they had made in the latest version of the software.  If she was not quick enough the department that handled updates would send out the updates without any documentation.  The next couple of days were always interesting for the customer support people.  And of course they blamed the docs people who blamed the programmers who were oblivious to the whole issue.  Read Dilbert and watch Office Space.  Exact fits for this company.  I cannot image the company is unique.

Here is a solution.  Hire a bunch of high school programming teachers to write the tutorials and pay them in free licenses for their classrooms.  (OK, many be squeeze in some $$ there somewhere.)  Wow, good education based documentation AND a bunch of kids that know how to use your software.

Why Programming is so Hard to Teach

OK, so maybe not hard for other programming teachers but for my sample of two it is by far the most time consuming and can be the most confusing course we teach.  The difficulty is there is always something new and interesting to teach.  In my usual lifelong rebellion against status quo I am always looking for something new and fun.  Yes, we could make a very secure and consistent Java or VB curriculum that we could teach the same way every year.  The kids would learn some programming skills and probably, except for the few and far between uber-geeks, never to take another programming course again.  Instead we have to make programming interesting and fun.  What a couple of idiots.

We already are using Corona (Lua) as our second semester teaching language so the kids can learn a little game writing.  So what if we have no real lesson plans, not a lot of experience with the language and a horrible debugger.  It is free and it is fun.  Kids take a second and third semester of programming because they like programming in this language and making little games.  Amazingly enough, along the way they learn some programming!

I have eight Mindstorms robot kits sitting on the shelf.  I have not used them in a couple of years because I hate the NXT-G programming environment and I cannot afford enough licenses for RobotC, which I do like.  Then last month I stumbled on Enchanting, a Scratch based language for controlling the NXT robot.  So why not try this?  I only have to learn how to make it work with the NXTs, learn the idiosyncrasies of a new controller language and build a robot.  Oh, I also have to figure out a direction to take the students.  Details, always details.

A thought comes to mind, there is a Kinect/Scratch interface and there is now a NXT/Scratch interface.  Now can I get the Kinect to command the NXT through Scratch?  Can I use this to get kids interested in programming?  Dang, programming is hard to teach.

Using Corona Crash Course video tutorials in a programming classroom

In an earlier blog I mentioned I was going to try to use some video tutorials with my Programming II/III class.  These tutorials, Corona Crash Course, are very good compared to many tutorials I have tried to watch.  They are short (most are about 6 minutes), and fairly to the point. Since they covered material in a different way than the text I am using and they directly built a little game I thought it would be a good direction for my class.  I have had less than stellar experiences with video tutorial previously but I thought I would give it one more try.  The class I tried these in consists of nine sophomore and junior boys.  A couple enjoy programming and are considering it as a possible future.  The others are there because they did not want to take the other elective offered that period.  They are capable, just not enthusiastic.  I thought the game making scenario in the tutorials would entice them enough to keep them focused and on track.  It worked for a while.

The problem as I see it is not the tutorials themselves, but the inconvenience videos present.  My programming class meets every other day.  Between each class there is some loss of “what did I see last time”.  So the kids would have to go back and refresh themselves.  There was also the problem “which video did I see that in?”  The kids might have to look through a couple of videos to find what they were looking for.  This is a bit of a pain.  The quality of the videos seems to not be the issue.  The video format is the problem.  The solution would be if each video had a series of notes to go with it.  Something in the direction of what each video covers and the important points it makes.  It is so much easier to look back a few pages in a book than trying to find the place in the video you want to see again.  The author of the video strongly suggests typing along with the video.  This is great if the goal is to make the exact same project as in the video.  I want the kids to take what they are learning and tweak it to make their own but similar game with modifications.  Videos just do not lend themselves to this tweaking.  A textbook with videos would seem to be the best teaching approach, the text for reference and the videos to show how the code/project should look.  The videos definitely help in understanding the progress of a game project but a text is needed to help with explanations by filling in gaps and to speed up reference searching.

If I had time I would love to build a text to accompany these videos.  I think with that add-on this series of videos would be great for a high school classroom.