What’s happening there is that a DSLR video (and crap audio) I captured around this time last year has been converted into a 3G-cellular-video-appropriate format and is playing under some of my simple Javascript canvas animations.

But the concept is actually kinda sweet (assuming further testing works): it means that I have interactive video up and running, and it was easy. It means anything you can do online you can link to video — like make a [redacted]. It’s not hard to, say, add 3D models to scenes on-the-fly (motion tracking, as always, will be an asspain). Or you could pre-load composites and trigger them in code — like have the characters wait until the viewer Tweeted them a certain go-code (not saying it’s a good idea — just that it’s possible).

If you didn’t try Take This Lollipop then go do it now and you’ll get it.

There’s a legal issue with the design of unsubscribe systems: some allow you to be added to the organization’s “do not contact” list, which in theory penalizes the business if contacts you again, intentionally or not. Keep in mind that local regulations might have something to say about how people unsubscribe from a system you build.

I look at the unsubscribe feature as a point of service failure, like having a dish sent back at a restaurant: the customer is unhappy with something you’ve done. It’s well known that successfully recovering from service failures can help create fierce brand loyalty. Any serious hospitality company and AppleCare are good examples of this.

I’m a fan of design simplicity, so I’m very biased against “preference changing” unsubscribe systems — ones where the link takes you to a page where you have to uncheck boxes and click buttons to continue the unsubscribe process. I wonder what the metrics are on these things: how many people click an unsubscribe link and then don’t change their preferences to unsubscribe from the mailout? How many try, fail, and try again? I bet the answers to those questions are, respectively, “almost none” and “way too many” — and I’m going to assume those going forward.

The one-click unsubscribe avoids these usability (and potential accessibility) issues but adds another — that users might accidentally unsubscribe from your service. I think this fear is what drives the prevalence of the “preferences model” (in my non-statistical sample preferences systems outnumbered one-clicks about 4:1).

Aside from all that, there are two main process design problems with both kinds of unsubscribe systems. First, they don’t try to recover from the service failure — they treat an unsubscription as an end of all communication with the customer. Second, at a wider scope, I think companies should avoid using email to talk to their clients en masse. Obviously you need to provide that kind of access if your customers want it, but email systems weren’t really designed with automatic mass communication in mind — one reason unsubscribe links need to exist in the first place.

My ideal newsletter unsubscription system would, at one click, take the customer to a page saying that they had been successfully unsubcribed from the service. It would have an undo link to handle the false-unsubscribe case. That’s the basic design, right there (plus invisible metrics, always).

To attempt a service failure recovery it could have a “click here to let us know why you unsubscribed” link. It’s possible to make this a text area on that first page with a submit button, but I feel that would over-clutter and confuse the page, given the prevalence of preference pages with submit buttons. An email link (or a link to a comment form page) is cleaner.

I’d also want to get people involved in my corporate community (another thing email is bad at — it’s one-way, not a connected graph) so I’d want people to connect with the community manager on Facebook and Twitter. “Question? Comment? Suggestion? Let us know on Facebook”, etc.

Community manager? Yes. All of this is predicated on having good communication in the first place — I might write more about that later — and, of course, using an unsubscribe page to trick a user into validating an address for resale is unadulterated cancer.

I suppose you need a mix: an architecture that allows expansion, but is sufficient (and non-lethal) at any given point in time.

Here’s a question from a coding test I just wrote:

Question 4: There is a class of 30 students. Each specifies 3 students they would like to sit with and 3 they would not.

Table 1: 5 seats.
Table 2: 7 seats.
Table 3: 6 seats.
Table 4: 5 seats.
Table 5: 7 seats.

Describe how would you go about constructing a seating plan. The data are available in any format you like.

Click through for my answer and then fire away in the comments.

Answer 1: Let the students seat themselves. Record the resulting plan.

Answer 2: The data are arranged in a graph of students, with low edge weights connecting friends and high edge weights connecting enemies. Use A* to find the lowest-cost paths through the graph.

The key to high-performance Javascript is to separate your physics updates from your animation updates and use a requestAnimationFrame call instead of a normal setTimeout for graphics. Essentially the application ends up with a “multithreaded” MVC pattern — and might need “mutexes” in future. In quotes because not really.

One of the basics that every small project should have is version control and until recently I’ve been a Subversion guy. Since I’m getting back into game development I’ve started coding again and, frankly, svn sucks. Its interface is just not intuitive.

“The slogan of Subversion for a while was “CVS done right”, or something like that, and if you start with that kind of slogan, there’s nowhere you can go. There is no way to do CVS right.” -Linus

Several talented coders I know have been raving about git and something I wanted to install recently forced me to clone its repository off github and compile it manually. I decided to give it a spin for local development using this Windows git tutorial as a guide.

It’s amazingly simple. I love it. All my future projects will now be git controlled. It should make it relatively easy to share too — soon if you want code for a game, you’ll be able to clone it. It might also make deployment awesome (how sweet would it be for a request for an HTML5 game page to first trigger a clone of all the latest code).

We could, perhaps, even start versioning MPF themes, which we should have been doing this whole time.

It’s made for desk jockeys who dig their disco as much as they dig Chrome (or maybe more).