Channels ▼
RSS

Web Development

Traditional Development Fails Mobile Apps


Let us be clear, the Dr. Dobb's news stream doesn't make a habit of running too many Gartner analyst press releases; the firm's seemingly interminable ability to pump out (arguably) over-commercialized, (arguably) simplified and contrived Magic Quadrants often serves to put many readers off.

Regardless, the firm has commented on the state of mobile versus desktop software application development and said that "traditional methods" used to define and develop desktop applications will not work with mobile application development.

"Enterprise application development teams use traditional practices to define and develop desktop applications; however, most don't work with mobile app development, due to device diversity, network connectivity, and other mobile-specific considerations," said Van Baker, research vice president at Gartner. "Instead, [developer team leaders] should use functional, performance, load, and user experience testing, as well as agile development practices."

Baker said that users find it challenging to effectively describe what a mobile app needs to do. As a result, the traditional practice of having a business analyst sit down with the mobile app end users — employees for business-to-employee (B2E) apps and consumer focus groups for business-to-consumer (B2C) apps — to define requirements for a new mobile application normally fails.

"There are several reasons these efforts don't succeed for mobile applications, even though they've worked historically. Firstly, mobile apps are a new category for most users and secondly, mobile apps are constrained by the nature of the platform and the size of the screen, so porting the workflow of a mature desktop app is not viable," said Baker. "Finally, the experience associated with mobile devices is significantly different from that of desktop devices, including shorter session lengths and limited presentation, due to screen size constraints that affect how mobile apps need to function."

Testing mobile applications also differs greatly from testing traditional desktop applications, says Gartner.

For a mobile app, each device OS can behave differently, depending on the actual device on which it is being used and the wireless network to which the device connects. Therefore, testing of mobile apps must be conducted across a combination of device types and OSs. It should employ, at a minimum, a two-tier approach of testing on device simulators and on a subset of the latest or most popular devices, because simulators don't always produce the real-world user experience of physical devices. This can be supplemented by in-the-wild user experience and device testing, which is recommended for B2C apps.

"The important thing for organizations to realize at this point in the mobile app maturity cycle is that there is still much to learn about how to design, build, and deploy great mobile apps," explained Baker.

Once the app is deployed, it is important to understand how it is actually used, because behaviors may change. This suggests that in-app instrumentation and the analytics that are associated with it are critically important, as developers can use them to learn what makes a mobile app successful or unsuccessful. In-app analytics, offered by specialist vendors (such as Flurry) or available with MADP solutions such as Appcelerator, Kony, IBM, and Pega Software, can tell developers and the business sponsors of the app what users are doing inside the applications they're using.

Mobile apps are different. They need to be frequently revised to meet end-user expectations, and this agile development process especially requires operations to be on top of infrastructure and systems to support frequent mobile app deployments and pushed updates," said Mr Baker. "The number of mobile device types further complicates mobile app development and operations efforts, because the range of device screen sizes, resolutions, hardware API access, and performance is fragmented and changes rapidly. The pace of change in the mobile market presents challenges in particular to the operations team, and this pace is unlikely to slow down."


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 
Dr. Dobb's TV