ARGH!!! Best Practices HTML5 Canvas

I'm adding a lot of web development to the Comp Sci curriculum this year.  One thing I've been working on is getting the basics down solid for the new frameworks we'll be using.

Easier said than done.  Case in point: the many HTML5 Canvas books and their suggestions for creating a basic game/animation framework.

Without going into detail (I have a headache), let me just summarize:

Of the many books I have purchased on the HTML5 Canvas element, no two books agree on what should be considered "best practices" with programming the Canvas.  What makes it worse is that most of them speak with conviction as to why their approach makes the most sense.  In another world where I only bought one HTML5 Canvas book, I would simply see it all from one viewpoint.  Instead, I live in this world, and my current headache is mostly from going back and forth over the last several hours on various topics like:

How to best ensure the page has loaded before your script runs

Don't even get me started on this one.  In the end I just said %$&k this!--I'm using JQuery!

How to best erase the canvas between frames

Well, this one isn't really a problem of the various books suggesting different approaches.  This one is just a headache by nature.

How to control the timing of your game or animation

Oh boy.  This one really has changed a lot in the last year.  It appears the best practice now is to NOT use "setTimeout()" or "setInterval()" but to use "requestAnimationFrame()" instead--which is not even mentioned in half the books available on Canvas programming.  Sheesh.

New GIT Project for various Generative Art frameworks

Sometimes I feel like I'm all over the place, sampling all sorts of new stuff and being overwhelmed with the task of weeding out the options to include in my Computer Science classes.  My only advice would be to carefully consider what Comp Sci topics you want to cover, and then look for interesting contexts in which to embed them.  For me lately, the context has been Generative Art.

I started a wiki on all the applications that I have tried for making Gen Art, but the thing quickly grew too big for me to manage, and too ... ugly ... for anyone else to seriously consider joining in on the work.  A wiki done by one person is not really a wiki.

The mistake I made, was starting too early.  Of course I was all excited from trying about a bunch of new applications, so I started putting all sorts of stuff on the wiki, including a huge table of the pros and cons of each application.  What I should have done instead was to put the whole thing off for a month while I worked in more depth on each application.  So that's what I did.  I have been working with my co-teacher in the CS department on updating our CS curriculum, so it was the perfect time to think deep about how these new apps could be used, and where they would fit into our CS curriculum.

Now things are much clearer.  I have had time to play around with all the apps and have narrowed down my list to the ones that find myself using the most.

You Can't Go Home Again

So ... I was ready to go back to my wiki and clean it up a bit and make it better.  And yet ... I didn't want to go back.  I'd look at it and think, "what a big mess--there's good stuff here, but my ADHD hates the intimidating way it's all plastered on the wiki!"  So I decided to make another change in our CS program, and I'm so glad I did.

In the past, our student developers team would use SVN and TRAC on our own server to host our projects.  We also have a private phpbb forum that we use for discussions on current projects.  But I have increasingly found myself interested in two very popular alternatives to the above approach: GIT and GitHub.

Rather than go back and redo the wiki I had already started, I created the Helping Hands project on GitHub, and I'm glad I did.  Of course I had the usual feelings of "...but this is just a simple project of my own, why put it up on a public repo and let anyone at all see it?"  And of course there was the usual guilt I have when something like GitHub is free (as long as the project is open source).  But then I spent some time reading research on the lack of women in open source projects.  I realized that my fears of putting my work out there for everyone to see was, well, normal.

Browsing GitHub, I entered some search terms like "education" to see what projects were out there that could possibly be similar to what I wanted Helping Hands to accomplish.  What I found was pretty surprising.  Of the projects I found, almost all of them were little tiny "hello world" type projects that had only one contributor.  Some only had a README file.  Others had one file of code titled "chapter01problem01.js" and no README file at all.  By "education," most were referring to the fact that the project creator was learning something and wanted to keep their work on GitHub. It was pretty clear to me that these were little experiments that someone tried and then totally abandoned. But there they are--doing nothing and not being read by anyone except ... me. Somehow that made me even more inspired to launch Helping Hands on GitHub.

Take the Chance and Share Your Work

The power of a site like GitHub is that they embrace the new business model that is totally killing off big corporations like MicroSoft. They realize that you don't have to nickel and dime users to death to be profitable. The writing is on the wall ( and it's in Chinese , btw).

One of the best ways to get batter is practice.  But practice can be an escape environment where you feel all safe and isolated and no one will make fun of your skills.  I just want to encourage you to take your work and open it up to others.  When I saw a few typical GitHub projects, I got a perspective that GitHub (and open source projects in general) are just as varied as we are as people.  If you only see GitHub from an occasional blog post linking to a successful and large project hosted there, well, you tend to think that anything you could create would be laughable.  Truth is, laughable is the norm, and on all those flimsy "education" projects there was not one troll on there saying, "this is a bunch of crap, just give up!"  The trolls are in our heads, for the most part (or posting comments on CNN.com).  The majority of people you will meet on open source projects are willing to help you get started into the exciting world of open source development.

It's not the real world, it's nicer.

Okay, I'll admit: I'm a blow-bag and can talk for a long time once I get going on something I am interested in.  When I was asked recently to define "computational thinking", I told the interviewer that I would get back to her on that one, as we had less than 15 minutes left to talk.  Here's what I ended up sending to her:

Q: What is Computational Thinking?

I would say that CT is the act of applying computational approaches to solve problems and to further understand how things work.  I don't want to say it's ONLY about problem solving, as it can also be a recreational activity, like when I play around with Structure Synth and Processing (and Nodebox and Context Free Art).  Certainly observing patterns is involved.  

I used to wimp out and say, "well, I recognize it when I see it."  That, however, seems to have some validity, and it led to me wanting to create a CS class that involved no text editors and no coding.  Education misses out terribly on the one thing that really helps get people thinking computationally: capturing that feeling you get when you start playing a game and you're not really sure how the game works.  The process of interacting with the game environment is very similar to how people best ACQUIRE languages (as opposed to LEARNing languages).  It's involves trial and error, and mistakes are not a big deal.  If mistakes are a big deal (like on a high pressure test, or when someone is uncomfortable during language immersion), learning almost completely stops.  

Think of a good puzzle.  Or here's something I witnessed once at a youth leadership-type conference:  after we had finished most of the activities from the day and were just relaxing in a cabin (in northern WI), one student asked another to "play a tricky game" with him.  Those two students discussed what they would do for a while and then they worked as a pair to show us a game.  Student A left the room and student B explained the game to us.  We were to select some object in the room and see if student A would be able to identify our "secret" object.  We discussed it and chose something like a light-switch.  Student A came back into the room and student B began asking questions like "is it that lamp?", to which A said, "nope."  This went on for a while, through many seemingly random objects, until student B asked "it it that light-switch?"  "Yes!" said A.  

Alright, we had to figure out how that happened.  For the next 40 minutes or so we worked together to impose constraints on A and B to rule out different ways they could be accomplishing their trick.  We had A turn and face the wall.  We made A not talk at all--instead he could only point at objects.  They always got it right.  But we figured it out eventually.

Why bring up that example?  Because those 40 minutes are still clear in my mind and that was 25 years ago.  I have no clue at all what the activities were that day, nor what the lessons were supposed to be.  But I remember that game, because it had all the makings for a successful lesson.  Players A and B did not lecture us for 30 minutes before we played the game.  They did not give us hints.  They also made it clear that they were willing to keep up the game, but we would have to figure it out--they weren't going to TELL US.  

Was it computational thinking?  Well, it certainly was logical thinking that got us the answer.  I have played similar games with students that WERE more overtly numerical in nature, but computational thinking embraces discrete mathematics, and discrete math is simply ignored at the secondary level (except for a little bit of probability, but that's only to pass a "there are 4 colored balls in a sack" type questions on standardized tests.

What's more important to take from that example, though, is the HUGE difference in that activity and a typical class for a student.  Students are much more likely to remember the "Bejeweled" game they were playing under the table on their smart phone than they are to remember the lesson.  

Case Study in Wed Design (1: Plan the site)

The first step in making a website is to develop a plan.  That's what we'll do here, looking at what we want to accomplish, what our constraints are, and so on.

Disclaimer:  I'm no pro!  I also have the advantage that most hobbyist coders have: I don't have to work for anyone under a contract.  If you are reading this and want to be a freelance web designer, realize that it becomes much more complicated when you are hired by a client to make their site.  This cartoon should serve as a warning....  If, however, you want to experiment and try to make your own site or want to help someone make a site, this case study shouldn't teach you too many bad habits.  :-)

Our Goals

Let's begin by looking at what we want to accomplish.  We're designing a site to promote a volunteer group's trail system that they maintain.  Because they have zero web presence at this time, almost anything we produce will be an improvement, even a simple site that merely has some static info on it.  On the other hand, I can think of some really cool things that we could try to include for supporting portable devices that would enhance the experience of using the trails.  Users could mark events or wildlife sightings on a shared map, we could utilize geolocation, and so on.  But, let's keep this simple and more traditional.

Here are some goals we can consider:

1. The site should be relatively simple but with a consistent theme.
2. The site should have a clear navigation scheme--not something "cutting edge"
3. The site should have a web address that makes sense for the site.
4. The site should work reasonable well on older browsers.

Here are some things we can consider including on the site:

1. An attractive home page that gets the user's attention
2. A gallery of photos that were taken on the trail system
3. Information about the trail system during the 4 seasons
4. Information about the EATS group itself
5. A page that gives info on upcoming events
6. A contact page
7. Clear directions on how to find the trails
8. An interactive trail map--almost a "virtual tour"
9. Historical information about the trails
10. Information on the "Woodland Waddle" horseshoe event.

There are several things here that make this much easier than a typical commercial site you could be hired to design.  Most of this can be done with HTML and CSS.  Unless we include a guestbook or a system for receiving donations, we can probably do without using much PHP or a database.  Maybe some JavaScript for the gallery, but for the most part this is a simple site to create.  We can think of things we can add almost like modules, but the base site is just HTML and CSS.

So let's get started!  The first thing to keep in mind is the "separation of powers" between the languages we'll be using:

The Three Layers of the Web

1. HTML for content.
2. CSS for style.
3. JavaScript for behavior.

For a small site, it is very feasible to make the main page first and then alter copies of that page for the other parts of the site.

The first big decision we have to make is deciding on WHAT the main page is about.  Is this site primarily for the EATS group, or for the Scotch Creek Woodland Preserve?  I'm going to go with the Preserve itself as the focus, but we can change that later, if necessary.

Here's a preliminary sketch of the site arrangement:

Main Page: Scotch Creek Woodland Preserve

  |

  |--Events

  |--Four Seasons on the Trails

  |--Gallery

  |--Interactive Map

  |--The EATS Group

  |--Get Involved!

  

Since the amount of actual content is relatively small for this site, I think the history of the trails and the information on where they are should go right on the front page, along with an attractive picture.  So the front page serves a few purposes:

1. Show a nice image to grab attention
2. Explain what the trails are, and how they came to be
3. Show where the trails are located
4. Contain a menu or navigation area to link to the other pages on the site

With that in mind, we can start sketching up ideas for the main page.  And that, is the subject of part two!

Case Study in Web Design Introduction

From an E.A.T.S pamphlet

I'm going to use this blog to document a project I am working on.  I have decided to help make a website for the Edgar Area Trails Supporters group to showcase their trail system, including the Scotch Creek Woodland Preserve.  Edgar is a small town near Wausau in Wisconsin, and the Scotch Creek Woodland Preserve is open to the public year throughout the year and is maintained by EATS, a volunteer civic organization.  Since I have visited the trails in the past and always have enjoyed them, I thought this was a great example to use as a case study in web design that can serve as a reference for my students.

This is a great example of a win-win situation, really.  Since web development has suddenly become a lot less annoying (IE, you know who you are--pun intended), I, for the first time, feel comfortable enough to make it a major inclusion into the Computer Science Curriculum at Skyline.  And for the EATS group?  Well, right now they have ZERO web presence.  All they really wanted was a page on the Edgar Village site, but, as you can see, the Edgar site looks a little behind the times on a modern browser (left margin or some padding would be nice).  The site itself, though, is (and I don't mean to be rude) in a state of decay.  The main page uses frames for layout (ouch), and many of the pages a declared as "html 2.0" for their doctype.  I mean, even Internet Explorer left html 2.0 behind a looooong time ago.  But, if you happen to have some old computer running Windows 95, at least the site will work for you.  :-)

So having a page on the village site is probably NOT going to happen any time soon, seeing as the "upcoming events" on the site are still listing things from early 2011.  So why not just get your own site, right?  Well, I understand the difficulties involved in that.  I live on the Front Range of Colorado, a place that has a pretty "techy" reputation.  Even Google has a major office within 15 minutes from my backyard.  Even here, though, you would have trouble finding someone who knows web design and development to the point where they could develop a functional site for you.  Face it--not many people know how to program computers.  If anything, we are getting dumber as time goes on, when it comes to MAKING applications.  We are passive users who want to just click on stuff and hopefully the right things will happen on the computer or smart phone we are using to access the internet.

Of course that's my job now--teaching the younger generation how to really understand and use computers--making computers do what YOU want them to do, not the other way around.   Why are we in such a sad state?  Well, lots of reasons, really, but all my evidence comes just from my observations over time, so it is hardly scientific.  I put the blame on people not being able to know themselves.  Metacognition is a lost art, and few people seem to really know what they know.  Few are aware of what they are aware of.  In that culture, you can make an easy sale by dumbing stuff down and making it seem like there is an easy way out.  Don't like writing code?  Just use a click and drag block interface!  Don't know where your music files are?  Just let iTunes synch it all up for you!  Don't know the differences between HTML, CSS and JavaScript (not to mention PHP)?  Just let Microsoft FrontPage or Adobe Dreamweaver (or the Mac equivalent that I can never remember) do all the work for you!  Yay!  Life is easy!  We're saved by technology!

Not really.  How many people do you know that have lost their music collection because they plugged in their iPod and iTunes wiped it clean?  How many people have plenty of great pdf files but have no clue how to have their Kindle or iPad display them?  In all these cases the Apples and Amazons of the world are all to happy to step in and offer their solution: just buy all your stuff from our store and we'll keep track of it for you!

So we end up at our present state, where few people know what to do when something goes wrong.  Just check out the forums for things like fixing a system crash.  Your typical Windows user will look for some free little executable program that they can click on to make everything better.  That's one way to spread malware--make it look like something that will help Window's users remove malware.  Mac users are a little different, but not any better, as a whole.  Your typical help forum for technical issues on a Mac has someone describing something bad that their Mac is doing.  Then you get 5 to 8 responses from "helpful" users who say, basically, "...gosh, I'd take it to the Mac store.  I did that and they just gave me a new one."  Great.  I'm sure that business model encourages affordable hardware.

But there is another entire world out there that is very different: free and open source software communities.  Go to the Ubuntu forums and ask for help.  Within hours (often within minutes) you will either get someone willing to help you, or at least point you to an older thread in the forums where the same problem was stated and solved.  Really, there's nothing like the support you get for Ubuntu.

And therein lies my motivation to 1) teach REAL computer science at a public high school, and 2) help the EATS group get a good website up and running.  I get to combine both of these into one, and my students will benefit from the process, along with the EATS group.

This isn't just a problem in the USA, by the way.  Here's a quote I came across recently:

Your IT curriculum focuses on teaching how to use software, but gives no insight into how it's made.  That is just throwing away your great computing heritage.

--Eric Schmidt, Chairman of Google, MacTaggart Lecture at the Edinburgh Television Festival, August 2011, on the state of CS Education in England.


Guess what?  They're teaching programming in China and India.  Real programming, not just how to create a tri-fold pamphlet in Microsoft Word.

So that's my introduction to this case study, and in the rest of the installments I will try to focus on the development process, the decisions made, and the current state of web standards.  If you made it this far, you must be awesome!