Motion tracking with Javascript, HTML5 and a webcam

Why would you use the web for motion tracking? Simple. HTML5 Canvas is exciting. Javascript is (pretty) cool. Combined with a lazy afternoon, we can create an ultra simple hand motion tracking and colour recognition system.

This isn’t entirely true. It doesn’t track the hand, it tracks a bright blue bottle cap I found on the floor. Even more truthful is to say that it tracks anything bright blue. But enough chat, here’s a demonstration. Just click the small button with the dash in it to get started, grab something blueish and wave it in front of your camera. It won’t be as good as we got it since we adjusted it for specific lighting conditions, but it’s enough as a proof of concept.

We’ve also got pretty pictures to show. Here’s one of the quick n’ dirty strap we used to embed the bottle cap in.


And here is one of it in action.


You can see the (bad, hackish, thrown together) code for it in my playground repository on GitHub.


The web as an art medium

Almost three months ago, I had a course which got me thinking: what if the web was seen as yet another medium for artists? I’m referring specifically to artists, those who create without purpose and just for kicks to add life’s flavour, rather thanĀ designers, who have an objective or a problem they are trying to solve. This means I’m not talking about webdesign – I’m talking about Web Art.

I’m also not talking about plugins or embeddable content like Flash or 3D – I’m talking about pure HTML DOM and things which manipulate it.

This isn’t a new idea. Ever since Chrome reminded the market about the importance of script execution and rendering optimisation, there have been a lot of experiments out there. It’s probably unsurprising, then, that now is the perfect time for artists to invade and create a layer of class and “meaning” behind this eyecandy.

My feelings about stuck-up artists aside, I made a series of web toys. Two of these were appropriate for public viewing, and so here they are.


Named after its inspiration, Trauma is an experimental point and click environment. Nothing special scriptwise.


Also named after its inspiration, vector is a box that does stuff (click on it). Animation in Blender, exported as a single image of all the frames, and jQuery scrolls through it.

Note that these have not been optimised, cleaned, or browser tested in any way. It works in Firefox, but be sure to give it time to load fully as there is no preloader.

Enjoy! (or not – apparently you can’t tell people what to think with art)


SLUG Feb monthly meeting

Being completely new to Australia and since Malaysia doesn’t have any sort of open-source community whatsoever I searched around for a linux/blender/open-source group when arriving. I found SLUG, or the Sydney Linux User Group. They hold monthly meetings, and though I was unavailable to join their January meeting, I did manage to join the February meeting on Friday. It was my first meeting of this nature so I must say it was very interesting regardless of the actual content of the meeting.

The meeting was kindly hosted by the folks over at the Google Sydney office, which was an experience in itself. It was certainly the most open and personalised set of offices that I had ever seen. I’ll let a picture speak for itself. (Why yes, that is a tire swing there)

The talk was given by Dr Silvia Pfeiffer about HTML 5’s video and audio capabilities – which are, needless to say, extremely powerful. The talk inspired me to implement HTML 5 video support in WIPUP, and for those that are interested in the talk, she gave at LCA too and is available here.

But what was more interesting was the people. They were your usual ragtag group of geeks.

How unexciting to meet such regular people.


How to Make a Website Part 1 – The Environment

Creating a new website from scratch into the next killer web-app is always tough, but the journey there can always be a fun one, given that your workflow is right, you know what you aim to achieve, and you’ve got the right tools for the job. I’ve decided to document the creation of The E2 Project, which is basically the re-creation of E2.

During the documentation, I will also teach you the do’s and don’ts of website creation. These are often overlooked, and you’d definitely pick up a lot of tricks that normally take years of experience to develop.

Understanding the resources around you.

Here’s a list of useful resources for the impatient: HTML, CSS, PHP, MySQL, Javascript, Ajax, Free scripts (yes, really), stock images, SVN, Git, Mercurial, Image editing applications (The GIMP), text editors (Vim).

OK, firstly I’m going to talk about setting up your mental and physical environment before you start a project. A lot of people who don’t develop with computer more than often disregard this vital step, and end up rushing or making a mess of things. The first step is to make sure you know what you want your site to do. Will it be a blog? Will it be your online portfolio? Will it be yet another youtube clone? If you know what it does, you should also know what type of person will use it, and what features it should have. You need to be clear on what features it should have, as that’s the bulk of any web-app.

Assuming that you now know what your site is about and what features it will offer, it’s time to make sure you really know what’s going on. Has it be done before? If it has, what can you offer that other sites don’t? What can you learn from existing websites? Are there useful javascript or ajax snippets that can give your webpage that extra zing that makes it stand out? For example, people developing a personal portfolio website might be interested in Lightbox, as that’ll improve continuity on the site and remove layout restrictions. It also makes things look cooler in general. (yes, I really said that)

The next step is to know your limits. You will need to know HTML back to front. Sure, you can forget tags, but as long as you know they exist, that’s fine. As the saying goes, the great programmer doesn’t need to remember it all. There’s really nothing wrong with using cheatsheets. If you do know HTML, make sure you know how to validate it. If you’re epically extreme about this, make sure you can get XHTML 1.0 Strict validation on all your pages. It’s all about discipline, and in the end it helps with cross-browser functionality and compatibility with newer devices like mobile phones. Just take the extra step, and please, oh please, validate your code.

Do you know CSS? Do you use CSS? Any site nowadays should only contain semantic markup and use CSS to effectively seperate design from layout. No matter what you do, do not use tables for layouting. It’s bad. It’s evil. It causes the folks in the #css IRC channel to condemn you to heck. It’s good practice. If you’re unsure what I’m talking about, read this handy guide. Of course, also don’t forget to validate your CSS code.

Do you know PHP and MySQL? True, this isn’t the only way to make sites, but it sure is popular, and hell powerful. How good are you at it? Do you know OOP, do you know MVC (or other framework styles)? If you answered no to either one, take your time to go and re-learn PHP. You’ll might find you’ve been doing it all wrong. Don’t disregard that warning, really, take your time and re-learn what it is.

How big is the project? Do you need version control for it? It’s quite comon for people to dump version control for web projects, even individual ones, as it really makes the developing stage less confusing. If you don’t know what version control is, try search it up, then search up CVS, SVN, git, and Mercurial. You should try it out on your system, get familiar with it and perhaps use it in your next project.

Are you good at design? This does not necessarily mean you have to be a wiz at something like Photoshop (ewww) or The GIMP, there are some really simple designs that look amazing. If you do follow the “Create graphic image” -> “Slice” -> “Create web-app” workflow like most do, do you know how to use CSS in the slicing stage? Do you know how to create a design that won’t break in flexible layouts? Do you know how to solve the never-ending battles with CSS and IE? (Yes, all those dirty coding hacks that are so troublesome)? Do you have good stock graphics? Most disregard stock graphics, but they really add shine to the page. Have you considered web load-times and optimisation when designing? There are hundreds of things to consider, and over time all these things become natural.

Don’t underestimate planning and protoypes.

Don’t underestimate the importance of this step either due to the shortness of this section. User Interface is almost the most important thing that exists on a webpage. Don’t get me wrong, I’m not saying that your backends and server-side scripts aren’t going to do the trick too, it’s just that your site is going to be used. To be honest, change the splash image of any application, and even if you don’t add any new features, it already looks as though it’s had a bunch of action packed updates over the last version. You want to have a clear idea of several things:

  1. The homepage of the site. This is the very first page people see, and the most important of all. This is what gives them their first impression, this is the page that should explain what you do, why you exist, and how you can benefit the user in less than a minute. This will be the central template design (especially for large scale sites) that defines the organisational structure and navigation style used throughout. Do not ever be inconsistent with design.
  2. Your databases. Yes, that’s right. You want to know what’ll be stored, where it’ll be stored, what’s the best way to store it so it can be used efficiently. The word that must be drilled into your head is modularisation. (Not a real word, but we aren’t learning English here, are we?) Basically, you want to use it one way, and any way you might think of in the future. I’ll cover this in more detail when I talk about setting up databases later.
  3. The system and framework. Yes, I stress frameworks again. Too many a PHP script kiddy has spewed out nothing but spaghettic logic. It’s not a fate you deserve. What framework are you going to use? Build your own? Use a preexisting one? Any needed libraries? How should you divide the logic framework into modules?

Work, flow. Work!

The third and last topic I will cover in Part 1 of this series is workflow. This is VITAL. Read that again. That’s the acronym for Very Important Topic Aids Learning. I won’t go into much detail, because all my next parts will focus on workflow too. Some thing you might have noticed here. I did not mention servers or domains. That is NOT your concern. Too much worrying about servers and domains will leave you with a crappy system that’s up 100% of the time. Which nobody wants. You need to make your site? Need a server? Install Apache on your localhost and build it there. Don’t waste money on a

Workflow is amazingly flexible, but there are some one-size-fits-all that works. The first thing you want to get out of your way is the environment stuff I talked about in the first topic I covered. Know back to front what’s going on and how it’s going to go on. Assuming you have that all worked out, you’d want to create a design using an image editing program. Even if your site is something like Google or Yahoo that has a high text:image ratio, you want to visualise it first. No point playing around with CSS if you haven’t got a clear image in your head. Once you’ve got your visualisation done (good for the home page), create a valid HTML and CSS slice of the page. Split it up into template files and start organising and creating dummy filesystem structures in your framework. Create a couple static non-dynamic pages just to check the flexibility of the layout (stretches, different tags: forms, inputs, divs, headers), check cross-browser compatibility, and then when you’re done, make the home page and fill it with placeholders as necessary.

Now you can start working on the actual logic and system of the website (excluding previous framework setup). The first step is to create all your needed database tables, and choose the appropriate field types and set values. After this, since I use an MVC framework for most of my sites, I like to work pretty much … in that order. I build the models first, build the views, then just connect everything beautifully with the controllers. I generally like to start with building the user system, which is often the key and wire system of a website. This covers easy stuff like database input, form building, error and message templates, and general usability of the site. It’s the perfect “mini-system” to test the effectiveness of your framework, templating system, and helper libraries.

It all pretty much spins off from there, before venturing to code debugging, stress and user testing, hacking preventation, and advertising. Website creation is a huge topic, and unfortunately a text-heavy one too. Hopefully I’ll write part 2 soon!