Amazing Grace: Degradation in Mobile Applications
Submitted by John Boxall on January 21, 2007 - 7:46pm.
Last Monday, Jo Stichbury a Symbian Developer for Nokia spoke at Mobile Monday SFU about a collection of "Best Practices for Mobile Game Development". With the current state of the mobile games industry I hope someone important was listening. The points were valuable for all mobile applications and ranged from the seemingly obvious (applications must be able to suspend themselves to answer an incoming phone call) to the less apparent (remember to turn off the phone's back-light after extended periods of no input to conserve batteries). One lesson in particular struck me because I had not heard it used in the context of mobile development before. Graceful degradation.
Typically used in reference to web development, graceful degradation refers to a form of fault-tolerant built into an application. That is an application which continues to function even when some of its components are either malfunctioning or not present altogether. On the web, the vast disparity between the rendering processes of early web browsers caused many pages to become visibly broken to viewers using particular browsers. The concept of graceful degradation was introduced to ensure that all web pages could be rendered with at least basic functionality by any browser. The 'alt' attribute of an HTML image tag is the perfect example of graceful degradation, allowing an image in a web page to be replaced by a text description if the image cannot be be displayed by the requesting web browser.
In the interest of providing a seamless user experience in mobile applications, graceful degradation plays an important role as more complex mobile apps are deployed to a varied field of devices. With little experience with software faults or sluggish behaviour on cellphones, mobile users are ill prepared for the blue screens of death that plague the desktop experience and they shouldn't have to be.
Imagine an application that extracts information from an image such as a tag or barcode reader. Many tag reading applications today require merely for a cellphone's camera to be focused on a tag, the information is then extracted from the live image and processed on the fly, there is no need to save a traditional 'picture' to get the data. However, the vast majority of mobile devices still do not allow direct access to camera APIs making such fluid operation impossible. Lack of access to the camera should by no means be seen as the end of the application. Instead of simply responding with an 'Unable to access camera.' message or worse, the dreaded 'java.lang.nullpointerexception' why not allow images already in the mobile's file-system to be processed? While the process of taking a picture, opening the tag application and then opening the picture for processing is far less glamorous than point and decode it nonetheless gives users access to basic functionality which in my opinion is infinitely better than a useless application.
Other instances of graceful degradation involve applications operating in imperfect conditions. As more phones introduce the ability to use multiple applications at once the problem of sharing system resources will inevitably come to cellphones. Instead of providing users with the typical desktop experience of increasing unresponsiveness as applications pile up, why not create applications in such a way that they would suspend themselves when available resources drop below required thresholds? In this way unresponsiveness is hidden from the user making the overall mobile experience less painful.
With mobile development cycles already being criticized as too long and costly, taking the care to implement graceful degradation into mobile applications may seem like overkill. That said, when I'm paying by the kilobyte for an over-the-air download an uncaught NullPointerException is not going to cut it.
-jb
Typically used in reference to web development, graceful degradation refers to a form of fault-tolerant built into an application. That is an application which continues to function even when some of its components are either malfunctioning or not present altogether. On the web, the vast disparity between the rendering processes of early web browsers caused many pages to become visibly broken to viewers using particular browsers. The concept of graceful degradation was introduced to ensure that all web pages could be rendered with at least basic functionality by any browser. The 'alt' attribute of an HTML image tag is the perfect example of graceful degradation, allowing an image in a web page to be replaced by a text description if the image cannot be be displayed by the requesting web browser.
In the interest of providing a seamless user experience in mobile applications, graceful degradation plays an important role as more complex mobile apps are deployed to a varied field of devices. With little experience with software faults or sluggish behaviour on cellphones, mobile users are ill prepared for the blue screens of death that plague the desktop experience and they shouldn't have to be.
Imagine an application that extracts information from an image such as a tag or barcode reader. Many tag reading applications today require merely for a cellphone's camera to be focused on a tag, the information is then extracted from the live image and processed on the fly, there is no need to save a traditional 'picture' to get the data. However, the vast majority of mobile devices still do not allow direct access to camera APIs making such fluid operation impossible. Lack of access to the camera should by no means be seen as the end of the application. Instead of simply responding with an 'Unable to access camera.' message or worse, the dreaded 'java.lang.nullpointerexception' why not allow images already in the mobile's file-system to be processed? While the process of taking a picture, opening the tag application and then opening the picture for processing is far less glamorous than point and decode it nonetheless gives users access to basic functionality which in my opinion is infinitely better than a useless application.
Other instances of graceful degradation involve applications operating in imperfect conditions. As more phones introduce the ability to use multiple applications at once the problem of sharing system resources will inevitably come to cellphones. Instead of providing users with the typical desktop experience of increasing unresponsiveness as applications pile up, why not create applications in such a way that they would suspend themselves when available resources drop below required thresholds? In this way unresponsiveness is hidden from the user making the overall mobile experience less painful.
With mobile development cycles already being criticized as too long and costly, taking the care to implement graceful degradation into mobile applications may seem like overkill. That said, when I'm paying by the kilobyte for an over-the-air download an uncaught NullPointerException is not going to cut it.
-jb
- John Boxall's blog
- Login to post comments
