‘Pure Android’ – Adapting an iPad design to Android tablets

Introduction

For the past 3 months I have been working closely with the digital agency Involved to bring their iPad app ‘Accor Hotels & Resorts Asia Pacific’ to Android.  The Accor hotels iPad app works as an interactive catalog, allowing users to browse through the thousands of hotels that Accor Asia Pacific manage.  Users can view hotel details, browse a map and view galleries containing photos of each hotel.

Because it is primarily a marketing tool, the look and feel of the app is very important.  The iPad app has smooth animations, beautiful images and a premium, dark ‘navy blue’ theme.  It is obvious that Involved had put a lot of thought into its design and appearance.  While planning the project it became clear early on that successfully adapting the app’s appearance to Android would be one of the key tasks in the project.

Overview of the iPad app

The iPad app has the following design features:

annotated ipad in frame

1 – Tabs at the bottom, for switching views in the left pane

Large square tabs, with an icon and text are a common iOS design element.  In this case they switch between different views of the hotel list in the left pane.

2 – Left pane navigation bar

Inside the left pane users can drill down through various hierarchical lists of hotels.  To navigate back up the hierarchy a navigation bar, with a back button is displayed.  The navigation bar title shows the current country or state the user is viewing.

The navigation bar also contains a button which allows users to launch a map where they can browse through hotels.

3 – Premium blue theme

A key component of the iPad apps branding is the dark blue theme.  The app makes use of navy blue palette along with customised icons.  There is also heavy use of gradients throughout the ui.

4 – Custom buttons, including ‘more’ button

The Accor directory app features shiny silver buttons, with blue text.  In this case the more button displays a menu where the user can access additional information about the hotel, including business facilities, links to book online, etc.

5 – Accor branding, settings button

The Accor logo is featured throughout the app.  In this case clicking on the button displays an about screen.  Selecting the settings icon displays a dialog which allows users to download all the hotel galleries and perform an update of hotel data.

6 – Updates

The application downloads the list of hotels from a restful webservice and stores them in a database on the device.  This allows the app to be used offline.  Due to iOS restrictions with running background processes the app can only download hotel updates while it is being used.

An aside – What not to do

Before talking about what we did, it’s worth talking about what we didn’t do, namely this:

framed_IMG_3060

Yes, that is the original iPad ui stretched out and pasted into a Nexus 10.  There are a number of reasons not to do this, which I have explored in an earlier blog post, but the two most important ones when I discussed the issue with Involved were:

  • Users of the Android app would probably never see the iPad app.  They wouldn’t care if the two apps were exactly the same or different.  They would however care a lot if the Android version of Accor directory was totally different to the other apps they used daily.
  • Replicating the iOS ui exactly would cost a lot – it would be significantly cheaper to build using the standard controls that google provide, using the holo theme.

1 – Introducing the action bar

The first step in adapting the Accor Directory apps design to Android was to introduce the action bar to replace the iOS navigation bars.  In Android the navigation bar provides a dedicated area for app navigation and actions to live.  The settings button, map button and about button were all moved into the action bar.  Android’s stock icons were used instead of the iOS versions.

This only left the navigation tabs.  There were three different options for adapting them to Android:

tabs mockup 2

  1. Place them in the action bar
  2. Place them below the action bar at the top of the left pane
  3. Place them at the bottom of the left pane

Each approach had its own pros and cons, but in the end we decided to place them in the action bar using text with no icons.  Android users typically expect navigation tabs to live in the action bar.  This is the approach featured in the android design guidelines.  Android devices commonly have a wider aspect ratio than iOS (16:10 on the nexus 10  vs 4:3 on the iPad).  This means vertical screen space can get scarse.  Approach 2 and 3 would have used up a larger amount of it, while leaving a big empty area in the action bar.  Finally under Android it is rare to see icons and text combined on tabs.  It was felt that the icons used on the Accor directory tabs would be too obscure for the user to guess at their meaning.

The last action bar tweak was to the apps icon.  Android will by default place the applications icon in the left corner of the action bar.  We decided to instead replace this with a white Accor logo to provide a cleaner feel.

The final result:

action bar

2 – Navigating through hotels

Within the iPad app users can navigate up and down a a hierarchy of hotels, drilling down based on country, state and then city.  Under iOS the current location and back button were placed in a navigation bar at the top of the screen.  In Android this space had been replaced by the action bar and tabs.  After some experimentation it was decided to place the current location in a blue header at the top of the list, followed by a ‘back’ list item leading up the hierarchy.  The blue in the header tied in with the blue underline on the selected tab.  This helped to hint visually that the tab selection was linked to the content of the left pane:

left bar navigation

3 – Navy blue theme

As has already been seen, the dark navy blue theme forms a key part of the apps branding.   Using the Android Action Bar Style Generator and the Android Holo Colors Generator we were easily able to customise Androids ‘holo dark’ look and feel to match the Accor directory colours.

The original version of the theme I produced used a gradient for the action bar which matched the iPad app’s navigation bars:

old theme

After some thought it was decided to replace the gradient with a solid lighter blue colour.  This is because ‘holo’ look and feel apps tends to emphasise flat blocks of colour and makes minimal use of gradients.  Choosing a slightly lighter colour also helped to differentiate the action bar from the rest of the screen:

new theme

The difference is subtle, but important and contributes towards the apps ‘pure Android’ feel.

4 – Custom buttons

The iPad app makes use of custom buttons with a shiny metalic look.  We decided not to use the same look on the Android buttons, as holo apps typically have a very flat style.  Instead it was decided to use the standard Android buttons, but tweaked to follow the apps colour scheme.  The assets for the buttons were generated using the Android Holo Colors Generator.  In their normal state the buttons appear to be standard Android buttons, but in their pressed state the custom colour shows:

book hotel pressed

5 – Updates as a background service

iOS does not allow applications to run in the background.  Therefore the iPad app can only download updates to its hotel database while it is running.  Android has no such restriction, so it was an obvious improvement to add a background service which downloads hotels.  While the download is running a notification is displayed in the system tray:

updating

6 – Portrait view and managing different aspect ratios

The iPad version of Accor Directory only supports landscape view.  Coming into the Android project we knew the the screens would have to be designed in a flexible manner to support different screen sizes and resolutions.  This meant the app would also support both portrait and landscape views unless it was explicitly disabled.  We were unsure how much work would be involved in tweaking the application layout for portrait orientation.  We decided to do the development with only landscape in mind, then at the end of the project make a choice to either apply a few tweaks and make portrait view work better or to lock the app to only landscape orientation.

In the end the app worked remarkably well in both orientations.  We ended up performing two tweaks to enhance portrait orientation:

In portrait orientation the space for the hotels name was very limited.  This meant that the ‘more’ button simply wouldn’t fit.  We decided to replace the ‘more’ text with Android’s ‘three dot’ menu icon.

portrat hotel name

Secondly we adjusted the padding around dialogs to ensure they fit.  In landscape mode the apps dialogs have padding to the left and right.  We simply adjusted this in portrait so that the padding was above and below the dialog:

landscape dialog

Finally we found that the widescreen aspect ratio of Android devices meant some content that would fit in comfortably on the iPad didn’t fit on Android.  In particular the hotel view either had to have a letterbox sized image, or the text would not fix on the nexus 7.  After some playing around with font sizes and image heights we decided to instead introduce a scroll bar and have the user move down to view any additional text:

scroll bar

 

Conclusion

You can try out the end result in the google play store:

Get it on Google Play

I believe one of the key success factors is that Involved came to the Android port with an open mind – they were willing to alter the design of the application where ever necessary to ensure that it worked well on the Android platform.  They also realised early on, that time and effort would need to be invested in producing proper Android UI, rather than just copying everything wholesale from the iOS app.

Another important factor was attention to detail.  The kind of obsessive focus on design that is needed to create a great iOS app is often discussed in blog posts – however just as much attention and effort is required to build a great Android app.

The app has received fantastic feedback both from Involved, and Accor themselves.  By borrowing the most distinctive elements from the iPad version but carefully adapting them, we were able to build an app that is instantly recognisable as ‘Accor Directory’ but also is pure Android.

New App – Accor Directory

A new app that I built with together with the digital agency involved has just been released into the play store:

Get it on Google Play

 

framed_device-2013-04-19-142340framed_device-2013-04-12-171240

The Accor Hotels & Resorts Asia Pacific Directory provides up-to-date information and imagery of over 570 Accor properties across the Asia Pacific region. It is the perfect tool for travel and tourism conferences, for hotel presentations, or for simply exploring the unique network of Accor properties in the region, for business and leisure, from luxury to economy.

– Discover over 570 properties listed by destination or brand
– View property descriptions, contact details, amenities and business events information
– Browse a gallery of multiple full-screen images for every property
– Explore Accor’s Asia Pacific Brands and Loyalty programs
– Add regularly viewed content to your favourites for easy access
– View properties on an interactive map
– Enjoy automatic content updates as properties join the network
– Download image galleries for offline viewing

Accor directory is an Android conversion of an existing iOS app created by involved. Involved have been great to work with and everybody is very pleased with the final result. Paul Prickett the Director of Involved says:

Involved engaged Luke Sleeman to port our existing iOS app for Accor Hotels Group to the Android platform. This was our first collaboration with Luke, and from the very outset it was evident that he was the perfect choice. Some great discussions and workshops upfront to plan the approach were critical; as opposed to quickly smashing together a copycat App that would suffice, Luke took every opportunity to question the user experience on this specific platform, and used his extensive experience to craft an Android variant of the App that we are all proud of. Every decision was inclusive, thoughtful and carefully considered to build the best result possible for the end user.

We’re very happy with the result, our client is over the moon, and Luke made it all so easy. And he’s a super great bloke too! I can’t recommend Luke highly enough, and we’re planning to engage his services and experience again very soon.

 

I have produced a blog post and delivered a presentation to the Melbourne Android Users Group, detailing the design process that we followed adapting the iOS version of Accor Directory to Android.

Building clean RPN part one – Toggling the device and built in keypad

The Clean RPN calculator app allows users to either input formulas with a custom keyboard, or the devices soft keyboard.  This is toggled by pressing the keyboard button in the action bar.  Pressing the button once will hide the custom number input and show the device keyboard.  Pressing it again will hide the keyboard and show the custom number input.  This is a small feature, but it proved incredibly hard to implement.

device-2013-04-06-230322 device-2013-04-06-230407

 

 

 

 

 

 

 

 

Before delving to far into the how, it is worthwhile to dwell briefly on the why.  What is the advantage of allowing the user to toggle between the built in keyboard an the device one?  Why not just use the built in keyboard as it exposes all the functions the user needs?  Under Android users can install their own keyboards to supplement the device default keyboard.  There are a number of 3rd party keyboards which may be of particular intrest to people inputing mathematical functions, such at the math keyboard or the hackers keyboard available in the google play store.  A calculator app should ideally support any of the custom keyboards users with to install.

It turns out that toggling the visibility of the on screen keyboard, with absolute certainty is quite a difficult thing.  Witness the this question on stack overflow about hiding the onscreen keyboard, with 19 different answers.  After working through many of the suggested answers on a number of different devices it became apparent that android apps can reliably:

  1. Temporarily hide the keyboard.  The Keyboard will re-appear again when a user focuses a new text field.
  2. Show the keyboard when an activity starts and set a flag on the activity indicating that they keyboard should always be visible.  This flag can only be set when an activity is initialising.
  3. Mark an activity to never show or allow the use of the keyboard.  This flag can only be set when an activity is initialising.

Temporarily hiding the keyboard is not enough.  On some devices it will re-appear as soon as a new text field is focused.  As clean RPN uses multiple text fields for input, pressing ‘enter’ to move to a new line, will cause the hidden keyboard to pop back up again.

Unfortunately item 2 and 3 on the list only work reliability when an activity is being started.  Once the activity has become visible you cannot permanently hide or show the keyboard.

The trick is to actually restart your activity when the user presses the keyboard toggle button.  In clean RPN when the user presses on the toggle keyboard button, the following code runs:

    private void toggleKeyboard(){

    	if(keypadPager.getVisibility() == View.VISIBLE){
    		Intent i = new Intent(this, MainActivity.class);
    		i.addFlags(Intent.FLAG_ACTIVITY_NO_ANIMATION);
    		Bundle state = new Bundle();
    		onSaveInstanceState(state);
    		state.putBoolean(SHOW_KEYBOARD, true);
    		i.putExtras(state);

    		startActivity(i);
    	}
    	else{
    		Intent i = new Intent(this, MainActivity.class);
    		i.addFlags(Intent.FLAG_ACTIVITY_NO_ANIMATION);
    		Bundle state = new Bundle();
    		onSaveInstanceState(state);
    		state.putBoolean(SHOW_KEYBOARD, false);
    		i.putExtras(state);

    		startActivity(i);
    	}
    }

This causes the current activity to have its state saved into a Bundle, and then the activity is started, passing through an boolean which indicates if the keyboard should be shown or hidden.

Inside the onCreate method the following code is run

if(bundle.getBoolean(SHOW_KEYBOARD)){
	keypadPager.setVisibility(View.GONE);
	indicatorWrapper.setVisibility(View.GONE);
	((InputMethodManager) getSystemService(Context.INPUT_METHOD_SERVICE)).showSoftInput(newEquationText,0);
	getWindow().setSoftInputMode(LayoutParams.SOFT_INPUT_STATE_ALWAYS_VISIBLE);
}
else{
	getWindow().setFlags(WindowManager.LayoutParams.FLAG_ALT_FOCUSABLE_IM,
	        WindowManager.LayoutParams.FLAG_ALT_FOCUSABLE_IM);
}

If the soft keyboard should be shown, then the InputMethodManager is told to show the keyboard and the window is instructed to make the soft input always visible. If the soft keyboard should be hidden then the WindowManager.LayoutParams.FLAG_ALT_FOCUSABLE_IM is set – this flag is used by dialogs to ensure that the soft keyboard never appears when a dialog is shown.

This approach works reliably on all devices I have tested on – from a 4 year old HTC phone running android 2.2 up to a nexus 7 running 4.2.2

New app – Clean RPN

Its time to talk about one of my newest apps: Clean RPN

Get it on Google Play

 

 

 

Clean RPN is a simple and clean RPN calculator for android phones and tablets, supporting a many functions.  Clean RPN support android 2.2+ and runs on both tablets and phones.

Unlike other RPN calculators which try and mimic the appearance 30 year old desk calculators, clean RPN takes advantage of the screen space and rich input that your phone or tablet provides. The results of your calculation appear while you type and a scrollable list of pervious calculations allows you to easily keep track of your history.

Features:

  • Perform calculations using RPN – Reverse Polish notation AKA postfix notation
  • Results appear as you type your calculation – no need to press enter
  • Scroll through a list of history
  • Tap on a result from your history to include it in the current calculation
  • Support for tablets and phones
  •  Share your history via e-mail, etc
  • Use custom number and function key boards to build your calculation – or your devices built in keyboard
  • Wide number of mathematical functions supported

Apart from the wide number of mathematical functions it supports Clean RPN is technically interesting for a number of reasons.  It supports android 2.2+, can make use of either the built in or the onscreen android keyboard and it’s core is implemented as a native library using java JNI.

In a series of later posts I will describe the process of building Clean RPN.

Two good Android design links

I just wanted to point out two good links relating to android design.

The first is a set of slide by Hervé Mischler on the subject of porting your iOS designs to android.  Unfortunately the slides are light on text, and there are no speaker notes or recorded audio.  Never less, they only take a few moments to look through and there is some good information in there:

https://speakerdeck.com/dstroii/quick-tips-for-porting-your-ios-designs-to-android

 

The second link is the recent android design in action episode relating to responsive design.  There are a bunch of good tips and examples in there if you are interested in scaling your app up from phones to tablets:

https://developers.google.com/live/shows/ahNzfmdvb2dsZS1kZXZlbG9wZXJzchkLEgVFdmVudBjT3pMEDAsSBUV2ZW50GAEM/

 

 

 

A minimal PagerAdapter for ViewPager

As part of the android support library google has introduced the ViewPager class. ViewPager allows you to swipe left and right between a number of views. ViewPager is particularly useful for photo gallery style applications. Unfortunately google have not provided an example of of how to to do a minimal implementation of the PagerAdaptor class which provides the contents displayed in the ViewPager.

The following is a minimal implementation of PagerAdaptor which displays a list of Bitmaps in ImageViews:

import java.util.List;

import android.graphics.Bitmap;
import android.support.v4.view.PagerAdapter;
import android.view.View;
import android.view.ViewGroup;
import android.view.ViewGroup.LayoutParams;
import android.widget.ImageView;

public class ImagePagerAdapter extends PagerAdapter {

    private List<Bitmap> bitmaps;

    public ImagePagerAdapter(List<Bitmap> newBitmaps) {
        bitmaps = newBitmaps;
    }

    @Override
    public int getCount() {
        return bitmaps.size();
    }

    @Override
    public Object instantiateItem(ViewGroup container, int position){

    	ImageView imageView = new ImageView(container.getContext());
        imageView.setLayoutParams(new ViewGroup.LayoutParams(
        		LayoutParams.MATCH_PARENT, LayoutParams.MATCH_PARENT));

        Bitmap bitmap = bitmaps.get(position);
        imageView.setImageBitmap(bitmap);

        return imageView;
    }

    @Override
    public void destroyItem(ViewGroup container, int position, Object object){
    	container.removeView((View)object);
    }

    @Override
    public boolean isViewFromObject(View view, Object object){
    	return view == object;
    }
}

Attaching sources to android dependencies in eclipse

The problem

Up until recently is has been impossible to attach source code to any of the jar files contained in the ‘android dependencies’ portion of an android project in eclipse. If you are trying to debug into a third party library or understand how something works then this is very annoying. Fortunately in version 20 of the android development tools, Google have provided a work around of sorts. Its all detailed in the following bug reports:

https://android-review.googlesource.com/#/c/35702/
http://code.google.com/p/android/issues/detail?id=28658

Continue reading

UI Anti-patterns in porting iOS apps to android

If you are considering porting an iOS app to Android one of the key issues that you need to address is how to adapt the ui to Android.  Fortunately Google provide a series of excellent resources around creating Android UIs .  I highly recommend reading:

However there is one particular anti-pattern I wanted to talk about:

Copying the iOS ui pixel for pixel

Unfortunately a number of apps attempt to copy the iOS version using the same ui controls and resources.  An example of this approach is the commonwealth bank app:

Android commonwealth bank app

iOS commonwealth bank app

 

 

 

 

 

 

 

 

 

Google specifically advises against this in their design guide:

As you plan your app for Android, keep in mind that different platforms play by different rules and conventions. Design decisions that make perfect sense on one platform will look and feel misplaced in the context of a different platform. While a “design once, ship anywhere” approach might save you time up-front, you run the very real risk of creating inconsistent apps that alienate users.

Copying the iOS ui of an app comes with a number of significant down sides:

The app will feel out of place

Its true that apps come in all shapes and sizes.  Companies often customise the look and feel of an app to implement their own branding.  However if you just copy the look and feel of your iOS app, users will know what you are up to right away.  Consider the following review of the commonwealth bank app, from the google play store:

 Since Kaching is still not marked as compatible with my phone, I’m forced to use this poorly ported iPhone app. The content doesn’t resize to fit the screen width, leaving an unused border down the right hand side of the screen, and nothing about the design looks like Android. Commonwealth could learn a lot from ANZ here, their GoMoney app is brilliant.

Lack of device independence

The fact that android must support different screen sizes and pixel densities means that the app must gracefully deal with being resized.  This is a constraint that iOS apps don’t have and often no thought as to how they should resize has been put into the design.

Images in the app are stretched

The bottom tab bar doesn’t take advantage of any extra space to the left or right

Fails to take advantage of native android features

Copying the iOS UI means the app cannot take advantage of Android features that are unavailable on iOS.  For example Android includes the excellent share intent, which allows you to share URLs, apps,images etc via any social apps you have installed.  The commonwealth bank app however copies the iOS version all too literally:

I should note that when I took this screenshot I didn’t even have a Twitter client installed!  I guess if I wanted to share over Google+ or app.net then I would be out of luck.

 

What should have been done instead

When considering porting an iOS app to Android, I would recommend the following:

  • Start by reviewing the android design guide.  The first step in building a great looking android app to to understand what the platform provides and how android apps should look and behave.
  • Redesign for android.  When porting an iOS app you need to consider how to provide a UI that feels ‘native’ to android yet still familiar to users of the iOS app.  This is always going to entail some level of redesign.
  • Ensure HTML5 cross platform content is truly platform independent.  The commonwealth bank app makes heavy use of platform independent html5 content.  When using such content you need to ensure the look and feel is appropriate both for iOS and Android.
  • Test, test and test again.  Any android app needs to support a wide number of devices running at different screen resolutions and display densities.  Testing on a number of different devices would have picked up several of the issues with the commonwealth bank app.