Interface Mockups: Balsamiq

Balsamiq is the first tool I use when trying to design a UI flow for an application. It’s is a simple layout tool that lets you drag sketches of widgets, controls, and other UI elements on a canvas to quickly build mockups of interface screens.

The best thing about Balsamiq is that the end result looks like a hand drawn sketch. This way it’s clear to the UI artist that the design is just for layout and flow, not for the actual look and style. I’ve seen horrible GUI designs delivered as a result of prototyping tools that use actual widget images for mockup layouts. This can confuse artists and clients, making them think the mockup is how the interface is actually supposed to look.

Brick Buddies as mocked up in Balsamiq

Icons: iconfinder.com

If you need interface graphics or even a simple app icon for a prototype, just use this search engine. It contains a large amount of royalty-free icons you can use right away or massage in Photoshop to your liking. Iconfinder is invaluable for delivering professional looking interfaces with no graphic designers in a hackathon crunch. I wish I knew about it before doing NTheMiddle!

Sounds: freesound.org

Freesound.org is a great resource for free sounds and much easier to use than professional sound libraries you pay thousands of dollars for. The sounds here vary in quality greatly, but most have pretty loose terms that allow you to use them commercially or otherwise. If I can’t find what I’m looking for here, then I drop a few bucks on Soundsnap for more professional sound effects.

Server Back End: Parse

It seems you end up writing the same back-end code over and over for most mobile apps. In recognition of this pain point, a bunch of cloud APIs for common mobile back-end functions have popped up this year. I’m still evaluating them, but from a cursory glance I think Parse is the best.

Parse has the clearest billing terms, the easiest to use API regardless of platform (including a Unity3D plug-in!), and a solid feature set. If you need to make a user account system, send out push notifications, or store and query geolocation data, Parse is pretty easy to use. For anything real-time, you’ll need another solution.

The first thing you learn in improv is “No Blocking.” This means you can’t contradict what anyone says in a scene. If someone says, “There’s a purple alligator on the floor!” and you say, “What are you talking about? I don’t see anything.” rhythm is lost and the entire scene collapses. To maintain the flow you have to say something like, “Yeah, and it looks like it wants a donut!” The scene smoothly rolls along. This is also why improv comedy isn’t funny.

No Blocking isn’t just useful for improv. It works in real conversations. Especially if you are an engineer trying to raise money. A skilled engineer is a master of saying “no.” Say “no” enough and you’ll whittle an idea down to the core functionality that can be polished and perfected.*

This why investors and engineers don’t get along–engineers are generally too practical. They lack the ability to power up the reality distortion field essential for raising a round. This is where the principle of No Blocking comes in handy.

Let’s say a cokehead asks if your software can be used with some esoteric piece of hardware one of his portfolio companies is producing. You know this is a complete waste of time and a distraction to your core business. Also, there are loads of technical issues that would make such an endeavour impossible. However, this extremely rich person can write you a huge check.

You may be tempted to explain why it can’t be done, as you would when planning a schedule or product roadmap. Perhaps you think the investor would appreciate your candor and intelligent analysis in an effort to save him from wasting millions of dollars on a futile task. Not so.

As we’ve discussed before, this sort of “resistance” can sour the entire conversation and turn your investor cold. The most successful pitchers don’t block. They skillfully craft a “yes” and then use the art of conversational jujitsu to throw the conversation’s momentum back into pitching.

The most mesmerizing and successful pitchers I’ve ever encountered never acknowledge any disagreement. They relentlessly stay on message while still somehow making it appear as if you’ve been listened to. It’s almost as if they can disagree with you while leaving you feeling as if you are in agreement. This is a Jedi Mind Trick you might consider practicing at ACME.

* Of course, if you say “no” too much, you’re going to miss out on true innovation. Success belongs to those too stupid to know they can’t do something. You’ve got to learn when to let it go.

Our 2nd place app at the CityGrid hackathon: NTheMiddle

Since this was the first hackathon I ever attended, I figured I’d post some survival tips.

Figure out compensation at the start.

If there are prizes involved, plan out how you’ll cut up the rewards first. Especially if you just met at the event. I’m not sure on what the best method is to split the pie with complete strangers, considering you may find that some do absolutely no work and will still expect their ‘fair’ share. We just divided it based on how much work we thought everyone was going to do.

Check your ego at the door.

It’s more important to complete something than to have your brilliant vision materialize by the end of the weekend. If you see another pitch that you like, ditch your project and join the other team! In my case, I abandoned my idea and became the sole developer on another because I really liked the concept and it seemed possible to do in a weekend.

Stick with it.

The most interesting thing about a hackathon is you go through the entire Paul Graham Startup Curve in 48 hours. Some teams seemed to fall apart during the mini Trough of Sorrow which hits around the second day. Seriously–it’s only 48 hours, get it together. It might not come out the way you wanted, but there’s absolutely no reason to give up on such a short project. Cross the finish line, even if it’s a spectacular failure.

Focus.

I pretty much ignored my other team members and forged ahead developing the project as it was originally envisioned on the first day. This was easy for me to do since I didn’t have another programmer to debate with. There’s no feature creep allowed in a 48 hour cycle. The most valuable skill in life is to know what to work on and what is a distraction. A hackathon can be a good training exercise to develop this ability.

Don’t be selfish.

Although it’s a competition, there’s no reason to not help others out. Offering a quick bug fix, feature suggestions, or even QA on another team’s project is a good way to meet future collaborators.

You don’t have to win to get value out of it.

Winning is nice, but that’s not the only objective of a hackathon. Hackathons are great places to find developers for other projects or seek new opportunities. It’s also a good way to network with the sponsors. They are usually underwriting the event to scout for talent or new uses for their APIs.

You don’t need to be a hacker to attend a hackathon.

I think only one-third of the attendees at this hackathon were programmers. The rest were, uh, “business” people and other mundanes. However, there are a lot of talents necessary for a successful hackathon project. I know I could have used a decent graphic designer on my team. Some developers were great engineers, but desperately needed an additional member to do the final presentation.

Hack!

Hackathons are held all over the world. They usually have themes–some are based on a specific technology, others on a type of app. There are resources out there to find hackathons near you if you’re interested in doing one.

In the wake of Farmville’s massive success in 2009, investment in social gaming hit a fever pitch. The Facebook audience grew to 500 million with the rising tide floating all boats. We went from “RIP Good Times” to a veritable all-you-can-snort coke buffet in the little over a year.

During this period, Facebook shut down viral channels making it more difficult to acquire ‘free’ customers and instituted a 30% tax on social gaming revenue in the form of Facebook Credits. By 2011, user growth flattened out and user acquisition costs skyrocketed as social gaming companies blew their war chests fighting over the same group of casual social gaming customers.

Apple, on the other hand, introduced In-App-Payments for free apps and created an entirely new genre of tablet games with the introduction of the iPad. News of new social gaming startups declined, but mobile gaming investments became white hot. The mobile social gaming gold rush was on.

Recent filings from Facebook show that Zynga, one of Facebook’s single biggest contributors of revenue, is now responsible for a shrinking portion of Facebook’s income. This may be due to a change of focus. New game releases on Facebook from Zynga have slowed to a trickle. Meanwhile, Zynga has been feverishly acquiring mobile startups and barking up their stock price with social gambling chatter. While some companies stubbornly cling to the Facebook platform, in most cases social gaming companies are evacuating Facebook for mobile.

Facebook can’t earn a dime off of mobile social games despite their usage of the Facebook API because mobile billing is all controlled by Apple or Google (and now Amazon). There is no place for Facebook credits in the mobile ecosystem. If you try to use any alternative payment system in an iOS app, Apple won’t approve it.

This is why Facebook is making carrier billing agreements and beefing up their HTML5 platform. They can’t get a cut of native app revenue, but can position themselves as a premier destination for HTML5 mobile browser games with Facebook Credits as the billing system.

Even if buying Facebook Credits can be made as seamless as iTunes billing, Facebook still has to fix the fact that HTML5 sucks. This is a problem that is somewhat out of their control, as HTML5 performance is affected by features in mobile browsers developed by Apple and Google.

Facebook is desperately trying to figure out mobile–spending $1 billion on Instagram is an example of this. The unstoppable shift to mobile media consumption threatens Facebook’s core revenue streams from all angles. Facebook Credits have no use in native mobile games and Facebook can’t generate much ad revenue as ads are largely non-existent in their own mobile apps. Facebook’s walled garden is under attack from another walled garden of closed mobile devices. I guess it’s karma.

The top line: Brick Buddies on iOS gets 10X the downloads of the Android version. I got more iOS downloads in the first day than I did in 3 weeks on Google Play. Although both versions have earned a pittance, iOS users spend more money too.

Brick Buddies’ iOS release got picked up as a news story on at least 3 websites, including The Guardian, with no PR. I saw far more Facebook likes, shares, and retweets about Brick Buddies on iOS through my social graph than the Android release.

But wait, isn’t Android beating iOS in market share?

Pondering this, I thought about everyone I know that has an Android phone. They are my friends least into mobile tech. When I get a peek at their home screen, they hardly have any apps installed. They are seemingly content to have a slick-looking phone with a giant screen that makes calls and sends messages. iPhone users (myself included) appear to be platform zealots and voracious consumers of apps.

I had a hunch that most Android users just aren’t into their phones–which makes sense. If you aren’t into mobile tech, you’d probably settle for an Android device. Let’s face it–Aside from the Google ‘pure’ handsets, most really aren’t so great.

I put a survey up on Mechanical Turk to unscientifically poll the public about the habits of iPhone and Android users. I wanted to see how they like their phones and how excited they are about apps. I only got about 200 responses, so this really isn’t statistically significant.

Hey–it’s good fodder for an inflammatory linkbait post about Android users! Here are some results:

WHO ARE ANDROID USERS?

Both Android and iOS had the same ratio of men to women users.

My results supported what I’ve heard from other studies–Android users trend younger than on the iPhone. 60.6% of Android users polled were under 29 as opposed to 47.3% of iPhone users.

Android users trend younger than iPhone

Android users also reported lower incomes and education levels than iPhone users. Not that this is relevant information–Unless you are an Instagram snob.

ANDROID USERS SEEM LESS SATISFIED WITH THEIR PHONE

When asked if they would buy the same kind of phone again, 89.3% of iPhone users said yes, while 78.9% of Android users did. Android owners also seem a little less satisfied with their phone when asked–89.2% of iPhone users were satisfied or extremely satisfied with their devices versus 81.7% for Android.

ANDROID USERS DON’T CARE ABOUT APPS

Android users seem less likely to blab about apps to their friends.

Android users seem slightly less likely to recommend apps to friends, with 37.5% of iPhone users recommending apps to friends often or extremely often and only 19.7% for Android. Hey, Android users just aren’t into apps–why talk about them?

Nearly 43% of iPhone users reported using apps extremely often, compared to 31% of Android owners.

ANDROID USERS ARE CHEAPSKATES

iPhone users pay for apps, Android users don't.

Although the vast majority of Android and iPhone users have downloaded free apps, only 47.5% of Android users have ever paid to download an app vs. 80.4% of iPhone users. Also, 77.5% of Android users reported never having made an in app purchase in a freemium game versus 58.9% of iPhone owners. Hey, it’s been said before.

CONCLUSION

This data is based on too small a sample to really make a conclusion. I still think it’s decent data to expand on my hunch–Android users just aren’t into apps. This presents a marketing challenge. Android users are out there, but how do you get them excited about your content?

According to this final chart, users of both platforms look for information about apps in similar places.

Android and iPhone users have similar tastes as far as info sources for new apps.

The audience exists. Perhaps you have to address them differently in the same channels.

Some developers seemed to have cracked this code. For most, monetizing apathetic Android users remains a challenge.

Application.CaptureScreenshot

CaptureScreenshot is a method in the Application class that does exactly what it says; it saves the screenshot as a PNG file. On iOS devices, this screenshot will be put in the Documents folder. On other platforms you can specify an absolute path to put the file anywhere.

What the documentation doesn’t tell you is CaptureScreenshot is asynchronous. This is because capturing and saving the screen can take awhile. The API call itself isn’t a coroutine, so there’s no easy way to monitor its progress. One hack is to write your own method which checks for the existence of the screenshot file. Once the screenshot has completed saving, the file will be there.

Also note that it’s good practice to put CaptureScreenshot calls in the LateUpdate method. This way you capture the contents of the frame as it will look at the end of that update. If you have made any objects active or inactive during that frame, the results of those operations will be seen in LateUpdate.

RenderTexture

One convoluted way to take a screenshot is to use the RenderTexture feature in Unity Pro. You can create a RenderTexture object and tell any camera to write to it. You can then access the color buffer of the RenderTexture if you want to write out the pixels to a PNG.

CaptureScreenshot was just way too slow for my needs (I needed immediate access to the frame buffer) so I started writing a RenderTexture solution, until I found an easier way. If you want to check out this technique, I suggest this example.

Texture2D.ReadPixels

ReadPixels will read the pixel data from a specified rectangle on the screen and copy it to the source texture. It’s fairly fast and works with a few lines of code. Much like CaptureScreenshot, it’s a good idea to queue up the action somehow and then actually call ReadPixels in LateUpdate. Works like a charm:

Texture2D tex = new Texture2D(Screen.width, Screen.height);
tex.ReadPixels(new Rect(0,0,Screen.width,Screen.height),0,0);
tex.Apply();

ReadPixels still introduces some delay, so in the end I might try to see if RenderTexture is faster. If you are using the screenshots as a real-time texture effect, then RenderTexture is your best bet.

One Month with the Sony Vita

George Broussard famously stated the Vita seems like the last dinosaur at a mammal convention, and sales figures may be confirming this. Still–as a die-hard gamer from the monochrome era, I got one at launch. I’m the earliest adopter there is.

Regardless of the market reality, there is one game that proves the Vita is a serious piece of gaming hardware–Uncharted: Golden Abyss. This is a PS3-sized game of AAA amazingness that you hold in your hand. It’s doubtful the Vita ecosystem can support many games of Uncharted’s scope, but it really is an incredible experience for a handheld.

Oh, and the Near network is cool. It’s strikingly similar to a location-based mobile games ad network I built in 2010. So, yeah–this kind of tech is dear to my heart. What’s up with only being able to refresh every hour?

Adobe Cries For Help

Is Adobe trying to kill itself, or is hurting Flash just a cry for help? Maybe Adobe is just a cutter. Anyway, adding a 9% tax on all content built using Flash’s new Alchemy opcodes is another desperate attempt to create a Flash ecosystem.

This is obviously a move to make UDK and Unity3D’s Flash exporters prohibitively expensive. If you develop Stage3D apps in ActionScript using Adobe’s own tools (or deploy on AIR or mobile), you apparently can release content royalty-free. Too bad. I was really looking forward to using Flash as a low friction web platform for Unity3D content.

GDC 2012 Impressions

My GDC impressions are over a month old and pretty stale. So I’ll keep it quick. Facebook games = dead. Mobile social games = tail end of cokehead frenzy. Social gambling = the fuse has just been lit. The crab cioppino at Sotto Mare = greatest meal of all time.

I built the iOS version first, and then spit out the Android build shortly after my submission to Apple. It took only a few days to finish the conversion, but I initially got Brick Buddies running on Android with a few commented out lines of iOS specific code and a button click. It was that easy.

What manner of sorcery did I use to make an Android port in a matter of days? Unity3D, of course. I figured I’d discuss a few loosely organized details of cross-platform mobile development here as a thinly veiled excuse to promote my app.

Plug-ins

I developed Brick Buddies with Unity 3.5. I used a lot of plug-ins and Asset Store goodies to get it out the door with as little work for me as possible. This list includes: NGUI, Localytics (Android/iOS), MoPub (Android/iOS), Social Networking (Android/iOS), iOS StoreKit, and the Android In App Billing plug-in. I didn’t have to touch a line of native code, as the plug-ins did all the work. Although, I would like to have made some small changes to some of the plug-ins. I didn’t because I don’t want to have to merge the source in every time there’s an update from the vendor.

Platform Specific Code

Brick Buddies is a very simple app that took a few days to prepare an Android build for. More complicated apps may require a little more retooling per platform. In my case the day or two I spent porting consisted largely of swapping out the iOS specific plug-ins for Android equivalents.

One weird thing I noticed was that some of Prime31’s plug-ins have different interfaces for Android and iOS even though they do pretty much the same thing. As an ugly hack, I used preprocessor directives to disable platform specific code when calling unique methods in plug-in classes. A better solution is to write a wrapper class around the plug-ins and use different classes on each platform.

Screen Sizes

Most Android devices have 16:9 aspect ratios versus the 4:3 aspect ratio of the iPad and 3:2 aspect ratio of the iTouch/iPhone. This was something I realized when I got Brick Buddies up and running on my Nexus One and saw the HUD cut off on the sides.

Luckily, NGUI uses 3D geometry for all of its widgets. When running on Android, I simply apply a .9 scale to the X axis on the interface screens that don’t fit. Alternatively, NGUI provides features for anchoring widgets to parts of the screen when dealing with disparate resolutions.

Performance

Brick Buddies doesn’t stress the capabilities of even the most modest smart phone hardware. I mean, it’s just a brick. Still, to test for performance and weird fragmentation bugs, it’s good practice to have test coverage over the most common Android hardware types.

I’ve been building up a collection of Android devices to make sure I test apps on common chipsets. A proper collection should include the Nexus S at the low-end, a Nexus S II as the most popular mid-range, and a Galaxy Nexus as the high-end handset. I also use one Tegra 2 tablet, even though nobody seems to care about Android tablets.

For iOS, I only support devices that can run 5.X. That means 3GS and above. I had some weird rendering problems that showed up on my 4S but not my 3GS. Otherwise, I targeted the low-end with this app, so I didn’t do any other per platform tweaks.

If you’re making a real game, you will probably have to deal with some drastic performance differences between the 3GS/iPad and higher end iOS platforms. You can use Unity 3.5′s new Level-of-detail system to restrict older platforms to low-res models, as well as turn off lighting and other expensive features at run-time with a platform check.

Submitting To Apple’s App Store

It took me about 3 weeks of submission drama to get Brick Buddies on the App Store. Apple initially rejected it because it uses Game Center but they claimed it was not actually game. At first, I argued that this game had gameplay that is basically the same as Puppy World, and yet that game uses Game Center. Along with this argument, I submitted a new build with more achievements.

That was a mistake. A resubmit takes a full test cycle to evaluate. This currently stands at about 5 business days. Apple rejected it again for the original reason plus another claim that it used the GPS with no actual GPS features. This time I submitted an appeal that included my Puppy World defense and a screenshot of the GPS travel feature in action. After a few days, I was approved. When dealing with Apple rejections, appeal first and resubmit as a last resort.

All was great until Apple rejected me the same day for not submitting the achievements for approval. After submitting the achievements, it took another 3 days. This whole saga took about 3 weeks.

Submitting to Google Play

Google Play was a much simpler process. I uploaded my APK, set my description text, uploaded screenshots, and that was it. It was instantly in the store. I published an app on Android a few years back and was disgusted at the lack of metrics in the panel. Now, Google gives you all kinds of interesting stats including active installs, daily downloads, etc. You can also chop up these stats by OS, device, region, etc.

Discovery

Since the Android release I’ve been messing around with advertising to buy users. AdMob and Android is a great mix because it automatically tracks conversion rates in AdMob’s control panel. I experimented with a $50 AdMob campaign at 10 cents a click and found users were costing me a little over $1.50. In line with expectations.

A big discovery issue when publishing the same app on Android and iOS making a URL that will redirect the browser to the App Store or Google Play depending on which device you are browsing on. I was going to write my own redirect code until I discovered omniqrcode.com. This service generates a QR code that links to a URL that redirects your phone to different addresses based on the platform.

I can’t think of too many instances where I’d use a QR code to promote an app. So, I’m actually using it just for the URL itself. If only they spent the money on a short URL instead of omniqrcode.com.

Conclusion

Building an app that runs on both iOS and Android with Unity3D is painless. I was shocked when I clicked a button and had my iPhone app up and running on Android within seconds. For more demanding apps you will have to deal with performance differences between chipsets and platforms as well as the dreaded Android 50 meg limit. Minor quibbles. Despite a lot of my pet peeves, you really can’t beat Unity3D for cross-platform development.

You can’t protect an idea. That’s intellectual property 101. Although, it is true that you can protect the expression of an idea: level layouts, art, perhaps even scoring. I’m not a lawyer, but as far as I can tell Zynga is in the clear here.

You have to know the culture that produced social gaming to understand why cloning is the new business model for games. The social gaming industry was created by MBAs, not game developers. To an MBA, there is no difference between a game and any other web service. Both Orbitz and Travelocity sell plane tickets online–but nobody complains that Orbitz ripped off Travelocity. They are simply two competitors in the web airline reservation space.

To a company like Zynga, Tiny Tower is merely a pioneering entry in the Mobile Virtual Tower Simulation space. Zynga is simply producing another entrant and attempting to carve out their slice of the total addressable market for this type of service. There’s no creative soul to Dream Heights, perhaps, but neither is there one for airline ticketing websites.

This is abhorrent to a lot of developers who have been creating games since before the social gaming revolution. Yet, I meet a lot of young gaming entrepreneurs for whom this is the way of things. They speak in terms of attracting another game’s customers with cloned mechanics and a few changes–perhaps in platform, delivery, or other business model differences. Never in terms of creative twists.

Social gaming giants usually clone games from smaller developers and buy larger companies who produce games they’d like to be cloning. This is probably because well-funded startups often have the same cokeheads backing or advising them, and thus a cloning controversy will ruffle some valuable feathers. Smaller developers should be already well into the development of the next hit-to-be-cloned by the time the VC backed cookie cutters arrive.

This usually is a trap that technical CEOs fall into. To a technical (or even just perfectly rational) person a functional prototype is impressive. It proves the ability to execute. To most investors, a prototype is an application with no traction. As we’ve discussed before, traction is a key element of social proof investors look for when evaluating opportunities. Plus, it’s usually not immediately obvious that your ability to acquire a small user base scales with investment.

When pitching cokeheads, it’s important to create a reality distortion field. A gifted pitcher can pump up everyone in the room about how game changing his company will be accompanied by lots of hockey sticks and absurd 3-year projections. With rare exceptions, seeing your product in action shatters this illusion.

If you show a prototype, investors are confronted with reality. Reality is usually not as impressive as the grandiose mental images inspired by a slick PowerPoint delivered with some effective table dynamics. “Oh wait–that’s what it is?” “Why don’t you add this feature and come back to us later?” This rabbit hole leads nowhere.

Even worse–If you’ve soft-launched your service, you further deflate this bubble. Where are your users? Why is your growth so low? It’s not proof that you can execute. After all, investors think developers are cattle. Execution is a given. What’s more important is making sure that hockey stick is real.

When raising money, you may find it much easier if you haven’t written a line of code but have your pitching strategy down. Only build something that you know you can launch and monetize without outside investment. If you need to raise money early–stop building and start talking.