With the new year we have new things to do, and have taken care of the previous year’s list (YAY!)
My collaborator and I have applied to 6 different incubators/accelerators (y-combinator, TechStars Boston, TechStars San Antonio, Betaspring, AngelPad, and Matter.vc) and have trudged, learned, and grown through each application process.
In the end, I’m proud that we pushed the idea out there to so many difficult programs.
We have one more “feedback round” pending with Matter.vc in February and afterwards we’ll figure out what to do next.
We already got some feedback from another program’s interviewer that had to do with project up into digestible bits. I’m in agreement. To some extent, we all have to break up a big project into workable chunks we can get done in, say, a week or so. In fact, this application round has kind of trained me to do just that.
Just 3 years ago, if you were going to build a complex site from scatch, the answer to the question “What kind of database am I going to use?” was obvious: a table-based relational database, most likely MySQL.
This decision was so obvious, in fact, that it didn’t even occur to most web developers as an option, and they chose instead to squabble over what kind of middleware to use (with PHP winning out for most projects).
Ruby and Python were mostly thought of as powerful little tools, more like Swiss Army knives for creating quick (soon to be termed “agile”) development solutions.
Nowadays we have the NoSQL solutions of MongoDB and Couchbase as well as robust “cloud” app-hosting solutions such as Google App Engine and Heroku, all of which support object-oriented requests in the form of JSON, Ruby, Python, et. al.
This rapid sea change over the years has caused me to rethink how I plan to build my own projects from scratch, paralyzing me with its impressive array of options to the point that I get giddy thinking of the different ways a project can go (Yes, I know it’s sad.)
My job is to take on all of the buzzwords that are out there and distill them down to what I and the team really want the project to do.
As product and web developers, we often let tools bog us down, not because we like to be frustrated by changing tides but because it’s so much fun for us to consider all the possibilities.
When it comes to actually making stuff that works, though, we have to put the toys aside *sigh* and just build a working model of what we wish existed.
Thank you everyone for supporting Meagan’s and my project proposal for the Knight Foundation’s NewsChallenge this past month.
The organization passed on our project, but we learned so much from the experience. Most importantly, we have been reaffirmed in our belief that a hardcore audience exists for such a project.
I can relate our goal more clearly now than ever before:
We want to create a platform for diehard fandoms and “cultural extremists” to read about people like themselves, play alternate-reality games, and build conversations/worlds around their obsessions.
In crafting the proposal, we forced ourselves to narrow our vision considerably from its original incarnation as a 108-page print mag with a website, social media site and ARG.
It was tough saying goodbye to a nicely designed print mag product, but the reality is no print magazine has raised money and lasted long enough to make money since before 2009. It may also be true that a sense of doom surrounds any project that calls itself a “magazine” or “publication,” even if it has the word “digital” or “web” in front of it.
Perhaps the terms “SaaS,” “crowdsourcing” and “cloud computing” could have been injected into our proposal to make it sexier, since our content and game engine would encompass some elements from each of these concepts.
However, I don’t think we have solidified the engine or the content production cycle for the project enough, and it seems wrong to slap on labels and throw around terms simply because they could have drawn more attention from the judges.
What we have wrought from this experience is a rubric that allows us to move away from limiting concepts such “magazine” and “publication” while retaining what we love most about those platforms.
And in doing so, I think we’re on the right track.
Always think about how to automate every part of UI and functionality. Responsive Web Design helps you pare down a web or site to its most basic function and create the most versatile minimalist designs around those functions from scratch. Good read.
A simple way to help people track their status/progress in a mission is with a progress bar. For example, the user has completed 2 out of 3 steps in a mission. In the report about that mission, we could quantify their progress as I did above, with percentages (i.e. 66.66666…%) or with a simpler graphic like this one:
I will prototype this inspiration in more detail later after I work on the account creation and puzzle-submission mechanism.
I’m in the beginning stages of a pet project I’m dubbing the Agents App. This web-based app would be a service that 1) receives solutions to puzzles—via email, text, mobile, and a local form—2) immediately responds with a prompt to the next step of the puzzle and/or a reward based on a points system, and 3) sends out and provides that user’s unique score and status based on the responses in different formats (texts, email, HTML, etc.)
The ARG aspect and the gaming mechanics described above are similar to Foursquare, except that it attempts to match key terms for points rather than only geodata.
Hey everybody! I’m starting this Tumblr to keep up with my projects and discuss all things dev. I’ll catch everybody up on my latest project to create a web app-based alternate reality game (ARG) with a simple Posterious-like sign-up. The idea there is to allow for several points of entry into this spy world-type game. Stay Tuned!