Designing with touchscreens and mobile in mind

We’ve had touch screens in our pockets going on six years, but even now games seem to be forever plagued by on-screen joysticks and buttons that make mobile game controls feel clunky and imprecise. Of the thousands of games in the Play Store (not even counting the emulator applications, which allow for some serious retrogaming) most don’t feel designed for touchscreens. Dead Trigger is a prime example of developers shoehorning a genre that relies on precise synchronized controls onto a platform that struggles to emulate them. Touchscreens provide an inherently different experience than the tactile feedback of controllers and keyboards. Developers need to start designing games to take advantage of the touchscreen’s unique strengths. There are new and interesting gameplay mechanics waiting to be unlocked in new and established genres. Some developers like Capybara Games understand this and have created an amazing touchscreen gaming experience with their game Sword and Sorcery EP.  Ingress by Niantic Labs @ Google has other great mechanics like GPS, and competitive AR (augmented reality) gameplay only available on mobile devices. Android phones and tablets are packed with sensors that (save for a few gems) go woefully unused. By developing games designed for the touchscreen and mobile experience, serious gamers will begin to consider Android as a viable platform. However this isn’t necessarily too big of a problem because…

Android isn’t just for your phone anymore

With new Android powered consoles like Nvidia’s Project Shield, Google Chromecast or the recently Kickstarted Ouya, developers have more options with the controls and scope of their game. They could use the Ouya’s controller, a mouse and keyboard, controllers from old consoles for their emulator or motion tracking hardware like the Kinect. Developers could have a game that requires intensive console play for some levels and more immersive, out-in-the-world exploration for others. Mobile devices with touchscreens are more suited to games that deliver quick bursts of fun (think WarioWare) that can be played for a few minutes while you take the bus. Long, story-driven games or competitive, high-action games are best enjoyed at home over the course of a few hours. The benefit of an Android console such as OUYA is that developers have access to the huge open (and free) ecosystem that is Android. Developers should have no issues bringing games to an Android console if it means no more paid Dev kits and NDAs through Sony and Microsoft. Perhaps in the future serious console games will be “Available on the PlayStation, Xbox, and Android”. But for that to happen we’d need to see…

Established developers/distributors in Android

Right now there’s a stigma that Android isn’t for “serious gamers”, and for good reason: with established systems like Steam and Xbox Live, hardcore gamers already have a place to call home. That could all change if Valve, or someone like them, started working with Google to integrate products like Steam or PSN with the Play Store. Imagine being able to show off all your achievements and game progress displayed in your Steam account for all your friends to see. Valve, who offers Steam as a digital distribution software (which includes features such as social networking, DRM, cloud saving, in-game voice chat, and more) caters to both casual and hardcore gamers. A company such as Valve could pave the way for bringing both of these worlds together on a single, open source platform. Considering Gabe Newell’s worries with Windows 8 and Valve’s intention of making their own gaming console Linux based, there’s quite the opportunity for a team up. Even if Google took a page out of Steam’s handbook and offered widely publicized sales, it would create an opportunity for people to purchase games they may not have otherwise considered due to price. They’re already taking steps toward this with the new features like cloud saving, leaderboards, and achievements that we saw at this year’s Google I/O. Thankfully, the ever popular Humble Bundle has been offering it’s package deals that have drawn some PC gamers to pick up a few games for their phone (all in the name of charity, no less). Speaking of Humble Bundles’ charitable donations, games should no longer be ruined by…

Free to play (pay to win)

Companies like Zynga have been pushing this destructive model into mobile and browser games for a while now, and it’s poisoning the water of in-app purchases and turning the Play Store into a minefield. It’s important that developers make money off of their work, but there’s a right way and a wrong way to do it (and a request to plunder your wallet for in-game currency is not the right way). There is nothing wrong with in-app purchases if done correctly. A prime example of this is in Radiant Defense. In the game, you can play for free through the entire game without purchasing anything. However, you can purchase three modules for a dollar each that unlock a few different helpful turrets. The League of Legends model is also an acceptable solution, where you can purchase additions to the game which aren’t required to complete the game (such as skins for your existing characters, or the ability to unlock additional characters early). Neither of these examples require additional (or worse, repeated) payments to remain competitive.

There’s a long and uncertain road ahead for gaming in Android, and we’ve only scratched the surface of the challenges it faces. But look how far we’ve come from playing Tetris on our flip-phones to playing games with rich 3D graphics and innovative gameplay. And who knows, before long we could see game companies completely forgo producing games for Playstation or Xbox in favor of the flexible and ubiquitous OS in everyone’s pocket and in every living room.

Back in June 2012 we launched Developer Economics 2012, the third in our series of reports that focused on app ecosystems, developer segmentation, platform economics and global app trade routes.

Today we are embarking on the evolution of our developer research: Developer Economics 2013 focuses on the best practices for the tools, services and APIs that developers use to build, market and monetise their apps. Take the survey, have your say on your favourite tools and win prizes; including an iPhone 5, a Samsung Galaxy SIII, a Galaxy Tab 2, 2 x Nokia Lumia 920, Blackberry Dev Alpha and a 4G LTE Blackberry PlayBook. The survey will soon be available in Chinese, Russian, German, French, Spanish, Korean. Developer Economics 2013 is sponsored by AT&T, Mozilla, Nokia, BrightCove, BlackBerry and Telefonica.

A service economy develops around app ecosystems

The mobile development landscape has undergone a massive transformation since the early days of the iOS and Android platforms. In the early stages developers faced a limited supply of tools and services to assist them with crossing platforms, beautifying the UI, bridging fragmentation, integrating with ad networks or analysing user behaviour. They had to create most of the building blocks from scratch using their own means.

As mobile application development continues its growth from 100,000s to millions of apps, the rush for gold has sparked a rush for spades. Across the developer journey, there is now a tool for (almost) every developer need, from app testing to ratings management. The app economy is evolving towards a service economy where developers can pick from a range of tools and services to assist them along the plan – develop – market journey. But best practices are yet far from clear.

Third-party developer services, ranging from user analytics, location APIs, bug-tracking tools, app-store optimisation services, and cross-promotion networks are, today, vying for mindshare among developers. Developer Economics 2013 aims to identify the most popular developer services among these and measure their Developer Mindshare. Furthermore we aim to understand the reasons developers choose the services they do and how they rate them across range of key performance indicators (KPIs), such as reliability, availability across platforms and ease of integration within an app.

The right tools for building an app business

Developer Economics 2013 is benchmarking best practices in a variety of developer tools sectors:

Which tool should you use and which one should you trust?

These sectors are becoming increasingly crowded with new entrants while merger & acquisition activity is changing the landscape almost on a monthly basis. The tools and services benchmarked in this survey are becoming the building blocks of modern apps and Developer Economics 2013 aims to establish best practices for the key developer tools sectors across the developer journey.

Developers are often at a loss when it comes to selecting the right tool or partner among the hundreds of services available to them. Cost is just one variable in the selection process but quite often, it is not the most crucial. The reliability of a service, the regional reach, key metrics (such as eCPM or fill rates), as well as the flexibility to adapt to the developer’s needs are sometimes more important than cost, particularly when developers invest time, money and resources to integrate a third-party service with their apps.

Developer Economics 2013 aims to assist developers with the selection process by benchmarking a number of third-party tools and services across a range of KPIs.

We are also helping third-party tool and service providers receive valuable information on how developer rate their services and their key decision criteria when selecting a service. If you’re a tools vendor being benchmarked, now is the time to spread the word to your developers.

If you are a developer your input into this research is very valuable to us and we’d like to invite you to take the survey.

Feedback welcome, as always
– Andreas

Everyone agrees that testing software (and device testing too) is necessary and valuable. Everyone looks to testing to endow software and handsets with quality and reliability. But test engineering is often pure misery – in the quest for bugs and faults and other failures, developers are damned if they find bugs and more damned if they don’t.

Testing is a numbers game. There are probably graduate theses and tortured theorems that testify in detail as to why you can never totally test a piece of software. Similarly, there are ample handy heuristics for deciding how much testing for both software and devices is “enough”.

The mobile domain is not as unique in the testing universe – it shares much with sister disciplines on the desktop and other embedded verticals. But testing Android apps and hardware does present its own set of challenges, including:

• New Android platform releases every 3-4 months
• A vast array of published APIs
• Multiple implementation paths (high level and low, Dalvik-based and native, framework and extension)
• Platform fragmentation with behavior and performance difference across Android devices

It is the last two that are wreaking havoc with software quality and inducing the highest device return rates in the industry, especially for performance and user-experience of games and media-intensive apps on so-called “mass-market smartphones”.

In most software development scenarios, testers worry about coverage, focusing on the proportion of source or binary exercised by test suites and tools. Certification regimes aim high, target 80% or even 90% coverage, or wishfully even more. Real-world testers are usually happy to cover 50% of deployed code, and many code bases never get past 25% coverage.

Android apps are no exception.

The Android Device Jungle

But Android apps and devices also face different coverage challenges – wholesale device and application coverage. Keeping track of new Android device introduction, of handsets and tablets and other devices in volume shipment, and of legacy devices is a wicked paper chase. My friends at Apkudo invest heavily in tracking devices in the wild, and they reckon that as many as 300 different Android-based devices grace the pockets and purses and premises of the consuming public.

As with code under test, device test coverage is an 80:20 affair (or 70:30 or 60:40) – that is, 80% of the benefit comes from testing 20% of deployed kit, with the implication that 80% of bugs will surface through testing just 20% of the actual deployed device portfolio.

Do the math. If you are an application developer, in theory you will realize maximum return on your testing investment by exercising your app on 20% of deployed kit – 60 devices (gulp!). Given the dominance of a few models of current handsets from leading OEMs – HTC, Motorola and Samsung in particular – that number is realistically a more attainable dozen.

But the Android application developer community is as varied as they apps they produce. There are large ISVs, for whom incremental platform testing can be expensive, but within budget. There are smaller development houses and mobile enablement groups inside corporate IT departments, for whom test on a dozen hardware platforms is a burden, but not an unbearable one. Then there’s the population of individual developers, mythically laboring alone in attics and garages and basements, whose personal budgets are stretched by having to buy handsets and tablets they don’t actually use on a daily basis.

It turns out that developers of all types report that they test on about a half-dozen actual device models (stay tuned for a revealing survey by Apkudo on this very topic). Bare bones efforts beg and borrow kit from friends and family, but more substantial organizations also rely on 80:20 statistics.

The Long Tail of Testing

Quality of software and of devices is governed by rational statistics. Perception of this quality is anything but rational. Testing apps on the top dozen shipping devices and testing devices with the top 20 apps will yield statistically relevant results and deliver a quality user experience to a numerical majority of users.

But what about those unfortunate outliers? Unhappy apps purchasers and device owners may constitute a grumpy minority population – a mangy long tail of dissatisfaction – but they can exert a grossly disproportionate influence on the success of apps and devices. When those grumbling gamers and disillusioned down-loaders make their feelings known in widely read reviews and weigh-down rankings, developers and device OEMs can regret their reliance on majority platform rules.

The whip snap of this long tail is why I find Apkudo interesting. Their platform for Android app testing and services for device qualification give small developers, regional operators and upstart OEMs a fighting chance. Their goal of testing apps on EVERY Android device and of hammering devices with thousands of apps will reduce the incidence of nasty market surprises for these individuals and organizations. And even better, it will greatly improve the Android user experience for the rest of us.

-Bill Weinberg
Senior Executive, Mobile Practice Partner – The Olliance Group
Principal Consultant and Independent Analyst – Linux Pundit
@linuxpundit