Designing and building apps cross-tablet?

Over the next couple of months we will see a variety of tablets showing up in the stores. Ranging from end-consumer overall iPad competitors like the Samsung Galaxy Tab to enterprise-only devices like the Avaya Flare.

These new tablets will mostly have differing sets of specifications packed onto a number of different operating systems.  However, there are a couple of common specifications we can safely expect in these newcomers:

  • They all have a touch screen display with multi-touch support that allows – to some extent – the same type of physical user interaction with gestures etc.
  • They will all be able to play video, almost certainly H.264 (but the level of HD support can differ)
  • They will all have good connectivity support, with WI-FI as the minimum, but most likely also 3G and Bluetooth

The difference will be in the details, like in the level of HD video support (720p or 1080p).  So if you have a use case for a more generic app and you pay attention to a couple of important points, it is possible to design and implement an app to run on as many devices as possible.

So how can you go about building your app cross-tablet?

Start with the screen…

Your base design choices should be made with regard to the screen:

  • What is the screen resolution and screen size?
  • What is the aspect ratio?
  • Device orientation: am I going to use portrait or landscape mode, or both?

The size of the screen is important.  If you have a high resolution but a small screen, you need to design your interface so images don’t end up being too small.  When you look at resolution, the majority of new tablets support a minimum resolution of 1024x768 so using one of these values as base width/height when designing your app will get you safe.

The aspect ratio matters as well.  The iPad is one of the few that holds to a 4:3 aspect ratio, most tablets announced will favor 16:9.

Sticking to either portrait or landscape mode could simplify your app design greatly… unfortunately that can be a very tough decision to make.  Some users might use their tablet in portrait all the time, others in landscape.  The size and aspect ratio of the device also makes a difference. A 16:9 in portrait has more of a “stretched” feeling, which makes me favor it more in landscape for example.

The best way to go here is with flexible layout designs.  Design your interface in such a way that it adapts automatically to either portrait or landscape, and avoid creating different designs for the different orientations.

 To make a comparison: the iPad has a 9,7” screen with a 4:3 ratio and a resolution of 1024x768, the Blackberry Playbook and Samsung Galaxy Tab favor a 7” screen, 16:9 aspect ratio and consequently 1024x600 as resolution.

Operating system and development platform

The development platform is mostly determined by the operation system.  Apart from iOS that currently dominates the market because of the iPad, it looks like Android will have most chances to catch up since a lot of Android 2.x powered tablets have been announced.  But then there is still the new Blackberry Tablet OS, HP WebOS and of course Windows 7.

When building your app you will need to follow-up all operating systems (and preferably even devices) you want to run on.  Even if you focus on only one operating system, you’ll still need to test and possibly modify your app to make it compatible with every new version of that OS.

Native app and HTML-5

All devices sport the ability to run native apps, but the development cost for native apps is quite high and code sharing is not easy.  However, the support for HTML-5 is rising very quickly, and with HTML-5 and javascript you can bridge part of the compatibility gap between traditional xhtml and the full flexibility of a native app.

Although HTML-5 does not offer the same user experience, you can still go quite a long way.  A good example of this is Treesaver: it provides app-like behavior on the iPad when it comes to reading an article/magazine, but it is entirely built on web standards, see the example of ICIJ.

Native app

HTML-5/Javascript web app

PRO

  • access to all hardware options
  • apps usually have better performance

 

CON

  • no shared codebase

PRO

  • portable and more straight-forward to develop

CON

  • still dependent on browser compatibility
  • not all hardware may be accessible using Javascript

 

 

But there is a middle way too: most platforms make it easy to combine HTML-5 pages in your native code and doing so can offer you a good balance of functionality, code sharing and maintenance cost.

Cross-platform development frameworks

One step further are cross-platform development frameworks like PhoneGap.  These tools allow you to design your app in a single framework (in case of PhoneGap this is HTML, CSS, Javascript) and then automatically take care of all the platform specific conversion.  You get unified access to things like the geo location and accelerometer in your device, but because it unifies different platforms there will always be functional limitations.  And of course you are required to use the specific framework to do your development in, which can make it more difficult to branch off device specific versions later on.

Flash and Adobe AIR market

Another special case to mention is Flash support.  Flash is still not officially supported on iPad and this is unlikely to change, making Flash support one of the biggest claims of other tablet manufacturers. 

Adobe – owner of Flash - recently went one step further by announcing the Adobe AIR market and extending the AIR runtime support to Android and BlackBerry Tablet OS.  AIR enables you to build  apps by means of html, javascript, Flash and ActionScript.  This makes Adobe AIR a platform worth considering.  The idea behind AIR is comparable to the PhoneGap approach, but AIR is backed by a large player, has direct support of manufacturers and is becoming more and more a standard of its own.

When it comes to distributing your app, the new Adobe InMarket can help you there as well… again… just not when it comes to the iPad and Apple AppStore.

Multitasking

Multitasking support is also important when it comes to designing your app.  The iOS 4 operating system that runs on iPhone has support for multitasking, at time of writing the iPad has not (but should have with the new version of its iOS).  Android devices all have support for multitasking.

But… there is ‘true multitasking’, where an app continues running in the background, and there is what we can call ‘pseudo multitasking’: it looks as if the app continued running but in fact it was paused by the operating system. 

If you want tasks to execute in the background while the user is not having the app open, you will need to know the specifics of your operating system and design and develop accordingly.  And even if you don’t use multitasking features, you should still design for an environment where your app gets paused or keeps running in the background instead of starting up anew every time. 

Extra features and functionality

If you need functionality like gyroscope, accelerometer, light sensor, video camera… you obviously need to check the availability on your target devices.  Even when it comes to integrating with Google add-ons like Google Maps, be aware they might not always be there (unsupported Android devices might not have them for example).

Approach

Designing and building your app cross-tablet is quite an undertaking, a careful approach can save you a lot of development and maintenance costs later on. 

  1. Determine the devices you want to target, for example: iPad and Android devices with a multi-touch screen of at least 7”.
  2. Draw out the user experience that will be consistent across devices (screen size, resolution, orientation are major deciding factors here). 
  3. Divide your app in device-specific parts and those parts that can be reused across platforms.
  4. Sit together with the platform experts to decide on the development and support process for the implementation of both parts.
  5. Coordinate top-down based on the generic parts: have the application architects design an architecture and a review process that the different teams must uphold.
  6. Keep a functionality, behavior and technical map that gives you an overview of the similarities and differences between platforms, so you can keep track of them in the long run.
  7. Test, test and test.  Do it early, do it a lot.  It’s the only way to find out whether the user experience really works and to see device specific issues pop up.

Category: Touch & Tablets

November 16, 2010 by Arne Vandamme

Comments

News Archive

Latest Blog Entries

    loading...