A place to track my several small projects
One quick-and-dirty way to build a GRM (Gamer Relationship Manager) is by connecting Gmail to spreadsheet and vice-versa via a Google App Script. The idea here is that simple tools like Gmail filters and Google spreadsheet formulas become your automation tools. Of course, though, you’ll be limited to routing everything through you Gmail, which may add time to automated pushing, calling, and tracking data.
About time for an update!
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.
Lots of developments, and a new to do list for the rest of the year!
- Apply to
sixfive places by the end of the year, including but not limited to: TechStars(done!), Y-C, fi.co, 500.co, AngelPad.org, Steam/Valve
- Write fiction for NaNoWriMo
- Finish a site redesign side project
- Get started on responsive design project for my full-time, grown-up job
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.
I wanted to have a full Agents App wire-frame up by now, but I’ll have to settle for showing an editted-down prototype of a previous version of the project.
To create this self-updating list, I used XSLT to query the user’s personal account XML feed, which was added to from a custom PHP form and the foursquare oAuth.
As for the design, I still plan on including some kind of visual cue of progression (such as percentages or the progress bar I mentioned earlier).
Next up: I’ll get into some hardcore information architecture (IA) to show how the Agents App will receive, respond to and track puzzle solutions.
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.
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.