Mobile Development: Many Platforms, Many Different Implementations

Android, iPhone, iPad, desktop… there are many plaforms to consider when developing an application. The question has to be raised, do we implement for each one? As users deviate away from the traditional desktop interactions to embrace mobile, the importance of mobile development strategies that target  cost of maintaining the existing user base and attracting new users increases.

Mobile platforms… who needs them?

The growth of the iPhone has led to an unpredecidented intrusion of mobile development technologies into our day-to-day habits. From the days of keeping in touch verbally, to maintaining communcations texual and pictorially, the mobile has evolved as much ergonomically than the technology it sits upon.

Web 2.0 aims to “encourage users to add value to the application as they user it” [OReil05]. Apple provided an architecture of participation by creating an open-in architecture to the iPhone. Allowing external developers the ability to create applications for this platform provided the capability of user driven content to mould the future of the iPhone. Never again should devices be targeting just one feature to the user. They should facilitate the ability to evolve with society.

The success seen by the iPhone has spread through all manufacturers. They all seek to shorten the feedback loops with their end users’ constantly changing requirements. Each manufacturer now respects that their domain experts are the end user, and it is they that know what they want when they want. They do not want to be held by constraints by the product owners of when they should release new features.

When to invest in Mobile Development

The mobile web should never be forgotten when developing a solution to a business problem.  It is to be expected that a growing proportion of users will visit your business using a handheld device.  There is a growing fascination with the new development platforms being released by the various manufacturing vendors.  Each one will require different skills and increases the costs of developing a solution across your targeted market.  The question has to be asked, is it really worth it?

Developing for each platform, is it worth it?

The world wide web grew on open standards of communicating across TCP and delivering content to clients using HTTP and displaying the output in HMTL.  These standards are fundamental to the success of the web.  Mobile technologies are a collection of hetereogeneous platforms that each require insight and execution.  .Net aimed at generating a homogeneous development platform that hooked into existing technologies such as VB, C++ and c#.  Apart from Microsoft, all other vendors has generated their own platform.

The rise of the social network has been driven by Web 2.0.  Social networks are driven by data.  Users provide this data and it is distributed in real-time across the online communities by AJAX.  No longer are users waiting for a page to reload after posting data as a combination of Javascript and XML provide the backbone to AJAX in providing a rich client experience.  The question with the mobile web is how this rich client experience migrates across.  Let’s take Facebook as an example.  It is integral to modern day life; people use it all the time.  The home page is rich with data, but it is far too much to be displayed on the screen resolution that mobile platforms provide, and text sizes are too small to view and hamper the touch screen functionality.

The creators of facebook have developed a mobile friendly site in addition to separate applications for each mobile platform.  The mobile site is a version of the application that removes the excessive meta data and AJAX but includes all the available functionality.  The application provides all the client rich technology but alters the work flow to include many intermediate steps to dilute the information held on pages designed for larger screen resolution.  The BBC also operate a similar strategy towards mobile technology by operating all three approaches.  Both applications are data centric.  This data has helped both applications to be fundamental to modern everyday living.  Not ever application to be developed will be fundamental to everyday living but businesses will not want to create an opportunity for others to take advantage of.

Is Web the solution to Mobile?

Web fits the one size fits all solution.  Built on open standards there are no technology barriers blocking a web application from being displayed on all platforms.  The only stumbling block is how to manage the constraints placed by the usability of the device.  There are number of issues to consider: –

• Screen Resolution
• Touch screen Technology
• Caching
• Limited download speed.

Screen Resolution

<link media="only screen and (max-device-width: 480px)"
    href="iPhone.css" type="text/css" rel="stylesheet" />

Screen resolution limits what the user can see at one time.  Often website are built with 960px width.  The iPhone is developed with 640px.  There are two methods held in CSS; these are media queries and viewports.  The media query is often seen dealing with different outputs that are required for printing.  In CSS 2.1 the option Handheld was also added.  This allowed developers to style layout according to the mobile device.  In CSS 3, this was extended to allow for different devices because not all mobile devices operated at the same resolution.

<meta name="viewport" content="width = 320" />
<meta name="viewport" content="initial-scale=2.3, user-scalable=no" />

Also introduced in CSS 3 is the viewport attribute.  A viewport is the visible area of the page displayed by the browser.  For each device, meta data can be added to pre-zoom the page to the width of the browser.  This allows users to develop one stylesheet for all mobile devices and adjust the zoom scale to the appropriate dimensions.

Touch-screen technology

Hyperlinks need to be larger enough to deal with the width of a finger.  Also hover-overs should be avoided  (in addition to being bad for accessibility) due to the inability for touchscreen technology to deal with this interaction.

Caching

Mobile devices have strict memory constraints (for the iPhone this is approximately 25KB).  This limit expires cached objects at a rate that puts caching as being unreliable.

Limited Download Speed

Currently devices have limited download bandwidth; therefore optimisation techniques should be enforced on any web application that could be targeted for the mobile platform.  The following steps should be taken: –

• PNGCrush should be used to compress all images.
• All components should be compressed by GZIP for data transmission.
• CSS scripts and JS scripts should be minifed and combined to reduced the number of bytes transmitted and reduce the number of requests.
• CSS sprites should be used to reduced the number of requests made for images.

Let’s create a mobile website

Creating separating a website to deal with mobile technology is an investment and will administer additional costs to any business to maintain.  When should it be applied?  The mobile context is different to the web context.  Primarily, mobile devices are used to request textual information such as emails, social networks, news sites, and not for obtaining your annual car insurance quote.  If the current web application is media rich then a new solution would be required that strips down the application to the data and essential media.  This helps reduce the sites payload on data transmission; thus helping page load speeds and data costs.

Often sites reduce not just media, but also functionality on mobile websites.  Assumptions are made that areas of the site will never be required by those users; however, there will always be times when it is required.  To allow for this, users should be provided with a link back to the normal site to offer them this functionality.

Each browser provides a user agent to the web server when requesting a page.  From this agent, the web server can tell what device, operating system, browser…. the list of data goes on.  To enable a mobile version of the website to be delivered to the client a process of browser sniffing is required.  This requires analysis of the user agent to identify the device.  The only problem with this is that the list of mobile devices grow.  If the list becomes out of date, the wrong site will be delivered to the device.

A final conclusion…

Do nothing to embrace mobile technology is a valid approach.  It will not look pretty, take a while to download, and each area of the page may require the user to zoom in, but it will do the job.  On the downside it will give a competitors an advantage over you.

Developing for separate mobile devices is expensive, and can only become feasible if your application is aimed at becoming integral to users daily needs.  Does your application fit into Adam Maslow’s architecture of human needs?[Maslo43]  For example, does it provide the belonging, friendship, and love of a social networking site?  If your application doesn’t, then it is not worth developing an application for each device.

Providing a web application specifically for mobile devices is cheaper than developing applications for each device and allow applications to target the mobile context.  The only problem is the costs attributed to maintenance.  There are two sites to maintain and a list of users agents to keep up-to-date to provide the browser sniffing functionality.

As web technologies advance, the possibilities of producing Adaptive Sites [patrick.lauke@opera.com] that cater for both desktop and mobile devices grows.  This will reduce the overheads attributed with maintaining sites that see the growing market from mobile devices as an opportunity to exploit, but do not offer the daily needs of users e.g. social networking sites, news sites.

References

[Maslo43] Maslow, A. H.; “Psychological Review”, 50, 370-396.

[OReil05]  O’Reilly, T.; “What Is Web 2.0”. O’Reilly Network.http://www.oreillynet.com/pub/a/oreilly/tim/news/2005/09/30/what-is-web-20.html.  Viewed on 22/11/2010