tiff. teardown

The trailer for Paul Thomas Anderson’s new film The Master is enticing. I wanted to see if I could pick up tickets for one it’s screenings at tiff. That’s how I discovered the mangled interface for their public ticket sales.

Tiff.net is aesthically, well, nice enough. It’s what you might expect as the output of a reasonably executed design process. It does have the hallmarks of concessions and deadlines. The menu type is too small, and the hover states have very poor contrast. But these aren’t fatal flaws, they’re just the reality of the vast majority of creative work at this scale. The casualties of committees.

That said, the ticket checkout is simply awful.

A flow chart and poorly written instructional text. Great. Fine, I just want to find the tickets for the Master. My eyes dart towards the bottom of the screen, looking for the next or continue button whose text and position has been ubiquitous for a decade. Nothing.

Let’s see, the orange rectangle says home, so that must indicate my current state in the process. Alright, what does this text say?

"Click CHOOSE film to begin."

I glance up at the flow chart again. It occurs to me that navigation flow charts aren’t good answers to design problems, they’re symptoms of weak concepts. If the process of purchasing was clear and well defined, then why would arrows and imperatives to click this and that even be necessary?

After clicking choose film and not knowing the date of any of the Master screenings, I swapped over to the select film by title view.

Why is there no letter spacing? FILMSBEGINNINGWITH”A”? Really? Why is the text set in all caps? These aren’t petty matters of taste. It’s simply a great deal more difficult to read.

I make my selection, but the film is marked as Off Sale. What does Off sale mean? Why not “sold out”? What’s the difference? Why favour the ambigious phrase over the clear one?

Ultimately, I am met with frustration. Luckily, tiff has the resources to improve their experience - and I hope that they do.

jQuery Haversine Plugin 0.1

I am happy to announce the version 0.1 release of my first jQuery plugin: jQuery Haversine. The plugin is a JavaScript implemention of the haversine formula - an equation to generate the circular distance between two points on a sphere.

Use Case

jQuery Haversine is useful if you need to determine the distance between two points on a map. There are lots of obvious use cases for location-based data where you need to calculate the distance between a user’s current location and a number of search results. For example, a restaurant search in a particular neighourhood.

Instructions

jQuery Haversine is called with:

This will return the distance (in km) between the two lat/long values. Future versions will allow you to specify a custom sphere radius (with the Earth’s radius set as a default), and the unit of measurement to output.

You can pass the arguments as an integer (floating point included) or numeric string - the plugin uses parseFloat() to extract whatever gets passed.

Source

jQuery Haversine is hosted at github.com/jdjkelly/jquery-haversine and Apache 2.0 licensed.

Backbone.js with WordPress for Music Blogs

I’ve been spending a lot of time with Backbone.js - first on a small marketing-site demo and more recently on a rebuild of Mixcastr.com. I think there’s a real practical application for Backbone in providing rich, application behaviour to WordPress-backed music blogs. Generally, they have lots of playable rich media - but it lives inside the DOM. So once you start playing a song, you can’t continue to explore the blog without interrupting the playback.

It’s broken.

Backbone has an attractive set of tools to build a persistent-player along the lines of what Pitchfork.com has produced. A track is a model that belongs to a post, a playlist is a collection of tracks, and the audio player is a view that renders the playlist collection.

This approach has some challenges:

• Search-engine indexability is extremely important to a blog. So all internal URLs on the site have to actually render the page server-side when Javascript is unavailable.
• All internal links have to load asynchronously.
• Playable MP3s have to be bound-to, and rendered inside of a player that does not get re-rendered during playback.

I think the solution to these challenges is to develop a complete server-side WordPress theme that’s capable of rendering all regular requests. So when a user requests a resource at your domain, WordPress parses a set of theme files and renders a full HTML response for that page back to the browser - just the way it normally functions. But when the DOM is ready, Backbone is initialized and all subsequent requests are handled through a Backbone router.

To make this work you’d have to reproduce the following inside of Backbone:

• The entire WordPress theme - or at least the parts that would be bound to Backbone views
• URL routing for all page types/URLs
• Models for posts, pages, categories, comments, and all other data to be rendered by Backbone

It would work something like this: once Backbone is initialized, a request hits Backbone’s internal router and gets passed to a method. That method might need to request new data from the server as part of a Collection. Luckily, WordPress has a RESTful JSON API plugin which could be used. The JSON response gets passed into a Backbone collection and then rendered in a view.

There are distinct benefits to this approach. First of all, the site would remain indexable by Google because any given request could be served with a full HTML response. Secondly, because subsequent page loads would route through Backbone as a JSON response, the server wouldn’t have to actually render anything but the JSON itself for each request (assuming JavaScript is enabled). Finally, because each request would only need to re-render part of the user interface, song playback wouldn’t be interrupted by new requests.

Weekend Hack Idea: Learning to Tie a Tie 2.0

On Friday, I watched my roommate fumble through YouTube videos trying to figure out just how his bowtie was supposed to be assembled. He did what I’ve done myself in the past: glance at the video, look down at his hands, curse loudly, and glance back at YouTube. This process repeated itself for fifteen minutes before he loudly pronounced failure.

But not five minutes he later he returned and booted PhotoBooth open. That way, he could see himself while watching YouTube. This is ingenious because it’s really difficult to develop fine muscle memory without actually watching yourself perform the action. That’s why even after learning to tie a knot, people continue to watch themselves in the mirror.

So I stumbled upon this weekend hack idea: develop a web app that displays input from a local webcam on the left side of a browser window, and a user-selected video from YouTube on the right. That way, the user can see their own hands as they watch the instructional video.

I’ve thought of some implementation details too:

• A database would not be required, as no user-specific information would need to be saved. Instead, the system would just need to be able to support a high concurrency of requests. This would probably be a good time to play with Node.JS
• YouTube has a search API
• There’s a new HTML5 API for grabbing user media input like webcam video called getUserMedia. It’s not widely supported yet though, so a Flash shim of some kind would likely be necessary.

This isn’t a business idea by any means, but it could be used as a one-off, relatively inexpensive marketing tool for an online men’s retailer (hint, hint @diolpah).

There's This Lake in Bolivia

Salar de Uyuni isn’t really a lake. Not any more at least. Today it would be hard to mistake it for anything but a desert. At over 10,000 square kilometers, and mostly empty, it’s a lonely place.

I imagine that it’s the kind of place that engenders visions of a post-apocalyptic future. A place and time just completely and utterly devoid of the features of the modern world. No buildings nor bridges. Just desert and salt.

Salar de Uyuni is a particularly good metaphor for the kind of mental atmosphere you have to be in to do great work. You know, the kind of creative work that’s just beyond what seemed possible to your past self just three or four months ago. Great work requires a certain kind of mental acuity that only seems to be possible in the absence of all distraction. When you’re free from those distractions, everything just flows with complete clarity. Your mental horizon just sort of folds in on itself.

Hackers call this being in the zone. To me, it’s being in the middle of Salar de Uyuni.

I Wish That I Had Known

I’m still young, but I often wish that I had known that computer science is a big tent. I believed that software engineering - the applied kind of computer science - was only the mundane application of bigger ideas. I figured that if I couldn’t grapple with this academic narrative about the mathematics of information, then I certainly wouldn’t make much of a software engineer.

So I didn’t invest as early as I could have. I knew that I had a passion from a very early age, but I didn’t seriously pursue it until Plan A (being a lawyer) no longer seemed realistic after a few semesters at the University of Toronto. I wish I could look at my younger self and say, “No you idiot! I mean, yes, of course computer science is very much all about the mathematics but you’re missing the point! All that is just a medium, a tool for the craftsman to create. Go and do that.”

I took a different path, but I’m glad that I made it here in the end. Fuck, I could’ve been a lawyer. I’m glad I’m not.

As far as early life lessons go, that’s a pretty good one I suppose.

The Tao of Craftsmanship

If a man is called to be a street sweeper, he should sweep streets even as Michelangelo painted or Beethoven composed music or Shakespeare wrote poetry. He should sweep streets so well that all the hosts of heaven and earth will pause to say, ‘Here lived a great street sweeper who did his job well.’

Developing software is a kind of craft. It’s a practiced art.

I’ve thought this way for three years, but I’ve only recently begun to believe it. This is the consequence of the transition I’ve made from nerd/enthusiast to professional developer.

It is at the heart of what I hope my career will be; a career filled with deliberately focussed creative and intellectual energy. Not for fame or fortune, but for the sake of craftsmanship.

For the sake of itself.