DCWeek: 5 Lessons for Mobile App Development

November 11th, 2011 - by John E. Jones

Despite the generally heartbreaking rain that would not surrender on Thursday, all was not lost thanks to the 2011 Digital Capital Week. DCWeek is a nerd extravaganza that draws some of the DC metro area’s best tech minds together to discuss innovation in the mobile and web realm. Thursday featured an all-day conference in Arlington with speakers and panelists from AT&T, LivingSocial, AOL, and other major industry players. Experts brought advice on anything from in-the-weeds experience implementing mobile APIs all the way up to battlefield-tested, strategic advice for the aspiring entrepreneur in us all. While I tried to avail myself of everything the conference offered, I’d like to share some things I learned regarding mobile development:

 

Let Analytics Determine the Platform

 

For too long in the current platform war, developers chose their mobile platform and defended it with passion. Guilty of this crime myself, I often neglect the other platforms when developing a new app on my own, but it is an unsustainable behavior that I am hereby shedding. Rather, in order to gain adoption of an app in a specific community, one must develop based on the usage statistics of that community – and the way to do that is by using web analytics. By looking at a website’s user-agent statistics, it is easy to discover which mobile platforms visitors in that space prefer. With informed data in hand, choosing a first platform to develop on is no longer an exercise in the platform pride debate.

 

Respect Users’ Desire for Privacy

 

Integrating social-sharing tools such as ShareKit into a mobile app is often a necessity, but be careful of overzealous usage of the single-sign-on tools offered by the major players in social networking. According to a discussion panel consisting of Keith Casey of Twilio, Eric Johnson of el-studio.com, Mike Panchenko of SimpleGeo, Zvi Band of Contactually and Hemang Gadhia of Condaptive at DCWeek regarding mobile APIs, statistics show that users are extremely wary of using Facebook’s and Twitter’s in-app sign-on APIs out of privacy fears, and users prefer to complete a registration form separately for each app. One cannot blame users for being too cautious as the mobile privacy and social network privacy debates are very much unsettled.

 

Microsoft is Back in the Mobile and Tablet Arena

 

On Wednesday night, I played with Windows Phone Mango at a Microsoft event and was wowed. A year ago, no one would have given the OS a second glance when considering a new smartphone. That, however, has changed, and many of Thursday’s DCWeek presenters agreed. The OS’s interface, dubbed ‘Metro’ is visually stimulating, intuitive and fast. Plus, Microsoft’s hearty embrace of HTML5 is putting the tech giant back on the cutting edge. Windows Phone and the upcoming Windows 8 hybrid that operates on both desktops and modern tablets are all waves we need to be catching.

 

Understand the Nuances of User Feedback

 

According to another set of DCWeek panelists consisting of Nick O’Neil of Holler, Sol Lipman of AOL, Brett Battjer of LivingSocial, Jody Thomas of EightShapes and Geno Yoham of Winamp, it is important to solicit feedback from users while the app is still running to get higher volumes of feedback and honest feedback, but that isn’t for the purpose of interpreting the literal meanings of each and every piece of feedback. A famous Steve Jobs quote regarding market research was cited to summarize the point: “… It’s not the consumers’ jobs  to know what they want.”  Playing to type, this unaffected statement by Jobs lends truth to topic because implementing every feature users request is – besides simply impossible – a derailment from the vision guiding the app. Assuming an app is based on a thorough vision and plan, feedback must be used to see what users don’t understand about that vision. Building app features should be left to app builders.

 

Make Sure an API is Trustworthy

 

If tomorrow morning, ShareThis, the tool Adfero uses for social-sharing on its website, decides to change their terms or service or how their web API works, swapping out the tool on our site would take about five minutes. If an API provider used in a mobile app decides to pull that trick, it could mean days of headaches for developers and end users. When building a mobile app, there is the usual plethora of APIs and public datasets available at seemingly low risk, but do not be fooled. To choose a good mobile API, there are three key things to look for. The first is technical documentation. Is each remote-procedure-call documented well? Is there example code? That is most important. The second thing is to look for is terms of service and privacy policy documentation. 80 percent of mobile APIs do not offer either of these. Last, does the provider boast of any major apps using their API? If these criteria are met, it is reasonably safe to trust that API will not simply change on a developer’s whim and leave you to pick up the pieces.

 

I could go on discussing what I learned even beyond the mobile and purely technical space yesterday, but I feel this is a good sample of what the day had to offer. If anyone would like to discuss this further, please tweet me @johnjones4.

Recent Posts By John E. Jones