Prototyping

We’ve been having a hell of a (great!) time stitching together a new creative process with a new team here in the office. The company is already producing some really great 3d models, and I have been hired to head up the software effort to make those models interactive. Go touchscreen, go!

Something that has struck me lately is generally how bad developers are at PROTOTYPING. Now don’t get me wrong, I don’t mean this in a negative way. Instead I think that our tools have held us back for a while, but our tools are getting really good really fast and I think we have a lot of work to do in order to find a place in the creative process.

I’ve been talking to freelance developers and a few studios trying to find the right people to build a couple of key visual components for our first big job building touchscreen interactives. Meanwhile, we have been working hard to get our conceptual design done in parallel. So I’m having a look at how we are communicating our ideas and finding visual examples to illustrate what our ideas actually MEAN – and the whiteboard is just not cutting it.

Sure we still need the whiteboard, but not for more than a conversational tool. What we really need is to spend a smaller amount of time describing what we need, and more time building real examples in a timely fashion. A picture is worth 1,000 words, and here an animation is worth closer to 10,000 words! The only goal here is to produce a rich touchscreen experience, so this stuff is super important.

I’m getting the idea that most creative companies have their people make a bunch of prototypes, and then they go with the best option (Anyone seen Mad Men? Read a Steve Jobs book?). This means you have to burn time, and you also have to master your tools so that you can spend your time thinking about the big picture and less time thinking about the code. This brings me to my point.

I am looking at where we are as developers and I think that we are juuuuuust almost there – at least in the visual and interactive design realm. We need to take the next step and get even better at our tools so we can do this. If a client comes up with a concept, we shouldn’t need to have them spec out the whole animal for us before we build something. Instead we need to be so good at our tools that we can put all of our effort into interpreting the big picture and the code is nothing more than an after thought. I mean, we can spend all day talking about methodologies and “agile” and waterfall whatever blah blah blah, but at then end of the day we need to be able to quickly write something or a few somethings “for free” to get a tangible illustration of the idea in front of the right people at the right time.

I think this means for a WebGL or CSS3 interactive we need to be able to turn a working example around in a couple of days. Then when someone says we need to rotate the camera around not one but all objects in the scene at once, we need to be able to turn that around in an hour. If we want to turn all the circles into squares and have them rotate around the axis instead of constantly looking at the camera, it should take 20 minutes.

You can see how these ideas would be hard to illustrate since there’s several ways that we can interpret these simple few statements. Seeing it work is everything. Also it’s important for a developer to not take the instructions literally but to interpret them as solutions to the problem, and write prototypes that solve the problem. No one likes a monkey.

On the same note, we eventually narrowed our focus to only hiring guys that have portfolios of prior work to show. We needed to SEE what they’ve put together to get a feel for what they can do. We also gave them a couple of days to put together a prototypical example of how they would approach our problem – off the clock. This seems to be the way of business in other creative industries, and I think it should be the way it works with software as well.

By | 2011-12-01T19:29:00+00:00 December 1st, 2011|Uncategorized|1 Comment

One Comment

  1. Lion Kimbro December 2, 2011 at 8:27 pm - Reply

    I agree with many of your points. I don’t think that “knowing our tools well” will help as much as needed, though, for the purpose of prototyping. The problem (I believe) is that our tools are bad for prototyping. They aren’t even made for prototyping. Rather, most of our tools are made for a long-term dig-in.

    HyperCard is an example of a tool that was good for prototyping. Django is an example of a tool that is conventional, and thus not good for prototyping. Even though Django vastly accelerates so many things, it simply isn’t anywhere near the immediacy of HyperCard.

    I work a lot on making Python environments for rapid prototyping and development. You should also look at Enthought’s work in reactive programming and user interface.

    I invite you to follow my blog’s Python category — http://lion.posterous.com/tag/planetpython.

Leave A Comment

65 − = 63