Readers of this blog know that we spend the bulk of our time discussing ways to improve the process by which mobile applications are tested. Today, however, I want to direct your attention to one method for improving the process by which they are developed.
In this case, the method is a product, or rather a platform: Pyxis Mobile. Unlike the vast majority of app development platforms, Pyxis Mobile lets developers create applications simultaneously across multiple operating systems. Not only does this drastically reduce development time, but it also compresses the testing and QA phases of the SDLC. What’s not to like?
It’s not particularly surprising, but the rate of growth is remarkable. Mobile use increased by 39% year-over-year by Comscore’s measure, but access via apps doubled. This suggests a nice halo effect from local-knowledge apps like Foursquare and Urban Spoon. Mobile browser use also increased, but I suspect that the gap will only widen, or the two will become difficult to separate; do web apps count as web or app?
At this point I think it’s a relatively safe assumption, given the still-primitive state of many mobile web browsers, that this mobile-browser map use is actually web-based, for example accessing the web interface via an embedded map on a restaurant’s website after Googling (or Binging) them. As this behavior is damaging to the standard “division of labor” on smartphones, it will likely only decrease due to more forceful redirection of web maps to the native mapping app (if compatible, which is another issue altogether). Mustn’t sent a browser to do an app’s job, or vice versa.
Earlier this year, Apple’s App Store reached its 10 billionth web application download goal. What is amazing is that they did this in about 30 months’ time. Apple’s first iPhone was released to the US market at the end of June in 2007. At the time, the smartphone was seen as a huge leap forward in innovation. Users were able to interact with this new device in ways that they never could using just a cell phone on a wireless carrier. This was more than a phone – this was the beginning of the mobile web.
When the iPhone was released, Apple announced that the iPhone would support third-party web applications written in Ajax (asynchronous Javascript and XML) so long as the apps maintained the look and feel of the iPhone interface. In March 2008, Apple released a software development kit to third-party developers and a slough of developers set out to create native applications for Apple mobile devices.
Apple’s App Store opened for business on July 11, 2008. The apps that were offered in the beginning were primarily Apple developed educational programs, mobile commerce and business productivity tools. There was no Angry Birds, Bejeweled, or my personal favorite, Flick Fishing. Games hadn’t really come along yet – they came along later and have proved to be “crazy popular” with users–dominating all app store categories over the last two years.
The past two years, New York City has hosted contests for mobile apps that use city data. Now New York State’s Metropolitan Transportation Authority (MTA) is launching a similar contest of its own.
A number of cities, including Washington, D.C., and San Francisco, have made their data publicly available. It makes sense: Apps that improve parking situations or make public transportation easier to navigate benefit the city without sucking its resources.
But New York City, and now New York State, are some of the first governments to add a contest to the process in order to incentivize developers to make such apps.
To be eligible for “MTA App Quest” and its $15,000 in cash prizes, the biggest requirement is that apps need to use at least one of the MTA’s data sets.
The MTA first posted databases online for developer use in January 2010, and 40 or so apps have been created using the data. But many of these, like NYC Way [iTunes link], were entries in New York City’s BigApps contest, which borrowed several MTA databases.
As a tester, have you ever noticed that some apps drain your battery faster than others, even when the apps are almost completely identical? Until very recently, there was no clear answer to this question, let alone a proposed solution.
But the other day, a reader informed me of a study conducted by AT&T Labs Research, titled “A Call For More Energy-Efficient Apps“, which sheds some light on this problem. Here’s an excerpt of their mission:
AT&T researchers working with colleagues from the University of Michigan undertook an in-depth, comprehensive investigation of the end-to-end data transmission paths, ultimately discovering the source of the problems to be in the complex interactions between the device and the cellular network, interactions that are especially hard to see, given the layered nature of the network architecture that intentionally hides lower-level protocols from developers working in the application layer. (emphasis added)
This article summarizes how researchers were finally able to understand the nature of the interactions and build an entirely new technology that makes them visible, allowing researchers to diagnose specific inefficiencies of individual apps. One popular app was found to be using 40% of its power consumption to transmit 0.2% of its data.
What follows is an in-depth, technical explanation of the super inefficiencies of modern mobile applications, with statistics, case studies and more evidence to back it up. It’s well worth the read. I’ve posted a few more excerpts below (along with some useful screenshots), but first I wanted to paraphrase the “layman’s” explanation I received via email. This will be especially critical for developers, so listen up:
Someday, a really smart person is going to figure out the optimal developer/tester ratio. Today is not that day.
Case in point: The tech media is largely aware of the shortage of mobile app developers, but remains oblivious to the shortage of mobile app testers.
ComputerWorld.com just posted a long (but terrific) article on the under supply of mobile app developers. Below are a few choice excerpts. Just for fun, I want you to replace the word “developer” with “tester” and see if the article still makes sense.
As market demand surges for apps to run on iOS, Android and whatever operating system will power the next wave of smart devices, companies are facing a dearth of mobile development talent. For IT professionals with programming skills, that gap represents a fresh opportunity to embark on a career makeover.
Just who is developing all of those apps? In its recent “America’s Tech Talent Crunch” study, IT job site Dice.com found that job postings for Android developers soared 302% in the first quarter of this year compared to the first quarter of 2010; ads for iPhone-related positions rose 220% in the same time frame.
Elance.com, a website for freelancers, reports comparable demand: In the first quarter of 2011, there were 4,500 mobile developer jobs posted on the site — an increase of 101% over the number of similar job postings in the same quarter last year.
Developers and designers who fully understand the constraints and the opportunities afforded by the smaller real estate and touch interfaces of the smart device platform are in high demand.
With all the time we spend on tools and techniques designed to catch mobile bugs post-dev, we should point out that many of these defects – especially usability ones – can be prevented by following some key steps pre-dev.
The bloggers at 53days.com seem to grasp this concept. In an article titled “Best practices for Mobile Application development”, they outline a bunch of simple steps developers can take to minimize bugs,maximize usability, and launch apps that their users will love.
Here’s a few:
Context is critical for mobile applications. A thorough understanding of the user’s context and objectives is a must requirement.
Display minimum number of options possible on any single screen.
Conduct ongoing usability testing throughout the design and development process, including testing on real devices.
The less text input, the better.
Use simple navigation structures pointing to one specific task at a time.
Reducing the number of objects, define proper data structures and carefully manage object handles. These features will help to conserve memory.
Store data on the device selectively and archive less frequently accessed data on the server.
Do as much processing as possible on the server.
Effectively use multi-threading wherever possible to improve performance.
Use high contrast text color and select typefaces for maximum readability.
Provide clear status and feedback based on progress of task completion.
Manage content in a wise manner. Wherever possible, try to crop large images and reduce the size of data files.
Use a consistent User Interface design that helps users maintain a familiarity with the application.
Get involved in real-time interaction via social media. This could include live Facebook or Twitter streams.
