Quick Prototyping of Ideasby Kyle
Part of Carrot Creative's business advantage is our ability to move quickly through the online process, from idea all the way to product. Whether client work or side project, prototyping is a central part of this and we are constantly prototyping new ideas and technologies. If you can imagine an environment where creatives and strategists generate unique and often challenging development problems for our production team, each and every day, you'll understand why functional models are so important.
Crawl Before You Can Parkour
Committing time to these simplified prototypes may appear like a waste of time, especially as ideas are constantly evolving and even being scrapped completely. Yet it's often not the execution but the experiment that truly proves its worth. By spending time reducing problems to their most basic forms, you can achieve great insights into what is at the core of those ideas. This not only holds true to creative marketing campaigns, but to the tools used during the process. Both the tools used when prototyping as well as prototyped ideas themselves are often more simplified versions of the final product. By experimenting with both of these things at a minimalist level, you better equip yourself with the knowledge or insights needed for success at the proceeding levels. This is part of many time-tested methods across many disciplines—not only software development, but also things like philosophy and athletics.
The Tools We Use
From Moleskines to web apps: our prototyping takes on many forms, but the concept of modeling holds true throughout. Since my role pertains more to the execution of software, my prototypes translate much clearer through code. By using tools I consider swift, un-complex, and fun to use, the prototyping process is often the first, second, and third step in my creative process.
Some examples, you say? Well, my favorite stack for whipping up these models shouldn't come to a surprise to many, but I love using MongoDB + Sinatra to work through these problems. I find Ruby is clear and declarative, as is the elegant Sinatra framework that is built atop Ruby. The reason I use MongoDB is that I find it maps to "concepts" much better than traditional Data Stores that map more closely to database "tables". For example, I can abstract the idea of a Book object that has many Chapters into embedded Mongo objects, rather than through Book and Chapter database tables fused with a MySQL JOIN.
Facebook is a very fun platform to develop on because it gives the developer access to so much great context about its users like Profile Info and Friend associations—so prototyping in the Facebook environment is never rare. Here's a code example that will give a quick way to interact with FB's iFrame tab interface (which is a bit nontraditional due to their use of the POST method to load in pages).