Thoughts on Popcorn.js hackathon in San Francisco

Last week I brought my JavaScript knowledge and experience to an event that put JavaScript developers and filmmakers in the same room for two days. The idea was to produce something. There were six JavaScript developers, and six films with 2-4 filmmakers per film. There were also designers patrolling the grounds, helping out. I cannot stress enough how important they were. Design really does help bring out the essence of a project, like spice in food. Flavour enhancers. Doesn’t matter how good, right, or fast a program is, if it looks bad, it will, by definition, still look bad. Not only was each group was able to produce something cool, but each produced something unique.

Wired has an article about the event, so check it out.

The actual event went down like this. Breakfast and mingling for about an hour, while everyone arrives. Then we all had a meet and greet. By 10:00 (if my memory serves me) we broke off into groups. So there I was with a group of people I never met, a film I have never seen, and a clock ticking. By lunch we had specced out what we were going to do. This is always an interesting process. You have a developer that knows nothing about the project or how things should be done, and you have designers and filmmakers that don’t know what can and cannot be done or how to measure how long something will take to develop. The problem for developers is “the easiest thing isn’t always the coolest” and for filmmakers and designers “the time it takes to develop something has nothing to do with how cool it is”. The developers don’t know what should be solved, and the fimmakers don’t know what can be solved. I think the solution is for the filmmaker and designer is to start with a big vision, then to have a back and forth discussion. It really is about communication and an open mind. Developers don’t be scared if filmmakers want it all. Filmmakers, don’t be scared to want it all. Developers don’t be scared to say no. Filmmakers don’t be scared to be told no :P. Eventually you will come to something that is “quick to cool”. Then it is lunch time.

After lunch you have to start developing. At this point huge changes to the spec can be frustrating, but still, no harm in asking. You never know, that thing you want changed might actually be easier! so keep up the communication. The rest of the day I struggled with getting Facebook’s API to work, but I did. It was an unstyled, nonsensical, boring piece of what I do best :D.

The next day we got to putting in the design and data. These are two things you need to figure out in the first half of the first day, and if possible have the data ready before the end of the first day. I kept the design pretty clean, empty, but clean, so it was quite easy to plug in some css and add some images. This is where you need the designer again. So, designer during spec phase, not after, and designer during pull it all together phase, not before. Then it’s just a matter of testing and debugging, and it’s still ok to request changes, just understand it might not happen.

Communication was key. Filmmakers teaching developers, and developers teaching filmmakers. I feel like designers have already crossed this bridge.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: