Comments on: Lessons from Big Games for Mobile Web Apps http://urbanhonking.com/ideasfordozens/2010/06/07/lessons_from_big_games_for_mob/ Thu, 19 Jun 2014 09:26:37 +0000 hourly 1 By: Dakota Reese Brown http://urbanhonking.com/ideasfordozens/2010/06/07/lessons_from_big_games_for_mob/#comment-551 Tue, 08 Jun 2010 10:27:08 +0000 http://urbanhonking.com/ideasfordozens/2010/06/07/lessons_from_big_games_for_mob/#comment-551 Again, I’m not disagreeing with you. In fact if you take a look at my track record, you’ll see that I’ve basically written the same words:
B&A Article: http://tinyurl.com/ykjvdl3
GaTech Masters Thesis: http://tinyurl.com/35cxs5f
What I guess I am taken back by is the fervor by which you wish to apply a technical criticism to a prototype esp. since I am fairly certain that IPT shares a similar outlook on prototyping as Georgia Tech (where I did my Masters) does. I feel bad that you didn’t have the same enjoyable experience as some of the other groups did, but that happens.
We did paper prototype earlier in the process, but that obviously doesn’t allow us to test things like what to expect in terms of Dilution of Precision for the area we were targeting and whether or not the way we were thinking of organizing games made sense in terms of menu interactions (which it didn’t, and is super good to know prior to doing UX on the go-to-market product).

]]>
By: Greg Borenstein http://urbanhonking.com/ideasfordozens/2010/06/07/lessons_from_big_games_for_mob/#comment-550 Tue, 08 Jun 2010 09:44:06 +0000 http://urbanhonking.com/ideasfordozens/2010/06/07/lessons_from_big_games_for_mob/#comment-550 Dakota —
I appreciate your comments and, like I said in the post, none of my criticisms were aimed at you guys in particular. I could tell from the design polish on the app that it was part of a well-considered professional development process. And I can definitely appreciate the value of rapid prototyping and user testing.
However, the point I was trying to make was that the techncal limitations imposed by the use of a web app in this particular environment meant that, at least for my group, we ended up testing the technology more than the gameplay. The experience for us ended up being about waiting for page loads and wrestling with map UI rather than racing.
If you wanted to build a really simple and cheap prototype I might have used paper maps and envelopes or some other non-technical solution that would have been even easier to fabricate and would have kept the focus entirely on the game.
I hope that you don’t take my criticism too personally as that’s not the way it was intended. In regards to me using your game as a “soapbox” for an argument I’ve been long formulating, I’ll just tell you a little about myself (this being my blog many other readers might know this already, but you don’t seem to have clicked around much). I was a web developer for years building my own startups as well as applications for other people in PHP and then Ruby on Rails for five or six years before leaving that world to do more art- and physical computing-driven work at NYU ITP last year.
In other words I was a web evangelist (zealot, even) for a long time but have gradually, over the last year, come to realize that when it comes to some of the really weird interesting creative applications that we want to build for mobile devices, applications that treat mobile devices more as programmable pieces of mobile hardware than as generic user agents, native apps have a lot of advantages. To the degree to which your application is user agent independent, web tehnologies are superior. The more hardware requirements you have in mind, the more you need a native app. When you begin treating the device like a package of sensors and outputs rather than a generic user agent the web app approach stops being viable as a prototypin tehnique and starts being simply the wrong paradigm.

]]>
By: Dakota Reese Brown http://urbanhonking.com/ideasfordozens/2010/06/07/lessons_from_big_games_for_mob/#comment-549 Tue, 08 Jun 2010 08:12:28 +0000 http://urbanhonking.com/ideasfordozens/2010/06/07/lessons_from_big_games_for_mob/#comment-549 Hi Greg,
Once again I really can’t disagree with your technical observations (other than where you claim that a native app would remove the need for a game server), but the reason I feel compelled to comment now is that you seemed to have missed a word that I’ve consistently been using throughout our conversations- “prototype.” The version of the game you played was a prototype for the forthcoming native experiences.
Why did we bring a prototype to Come Out & Play?
We did this because we’re planning to build a bigger platform, but we needed user validation w/ a focused audience sample to give us an idea of what to keep as is, what to build on, and what to leave behind. We had six teams complete the course (1 didn’t check-in to the final check point), and we had great conversations with each of them about what they liked and what needed work. Based on those conversations and a few other observations, we were able to refine our Feature Roadmap and have begun work on the native experience you say that we so desperately need.
Why did we prototype in HTML, Javascript, & CSS?
The first rule of prototyping is build it quickly. The second rule of prototyping is that once you learn what you need to learn from the prototype, throw it away. Had we prototyped in Ruby or as a native app, the temptation would have been to recycle some code. Sometimes recycling code goes alright, but I’ve found the best results for a product come when you force yourself to trash the prototype and start over.
…a few other things I’ll add is that the game’s description & sign-up form clearly stated that this was an iPhone experience. It was playable on Android devices with browser geo-location, but it wasn’t the experience’s intended context.
Furthermore, and keeping in mind that I do respect and value your obviously informed opinion, I’d ask you to examine your own bias behind the statement of “it ruin the experience.” 5 teams finished ahead of you. 4 of those teams were placed squarely in the “would play again without modification” category and the 5th was a “would play again with slight modification.” I realize and acknowledge that more than 6 teams started the game, but user abandonment is bound to happen and it was likely do to the experience of playing a prototype as opposed to any of the foundation tenants of the gameplay.
My final point is that what you have labeled as “naive belief in the hype around web apps” is actually part of a disciplined and iterative design process. However I am happy to have provided you with a soapbox upon which to broadcast an argument you seem to have been formulating for some time now.

]]>