DESIGNING MOBILE APPLICATION FOR ANDROID AND IOS

For any of the apps I’ve worked on, the deadline has been tight enough for designing one app, let alone dividing the project fully into two, which

are Android and iOS

Quite often you’re designing one app, on this case is CNN Indonesia with tweaks being made before handing it over to two development teams.

If you are designing an app in this way, it’s important to understand the difference between the two platforms early on, and the quick ways that you can make the experience feel native to each.

Before You Begin: Choose Your Approach

1. Keep your enemy closer

2. Choose a lead

3. Know the rules

Designing Your App

1. General styleSince iOS7, Apple has shifted to a flatter design style, and ditched the shadows, textures and effects which defined the iPhone’s early years. Android, having been more systematic in style in the beginning, has gone slightly the other way. Google’s new Material Design guidelines create more subtle references to the real world, with a layered “paper” approach providing more hierarchy.

2. Real buttonsAndroid phones have a back button, which can be used to return to previous screens in the app. iPhones don’t have this button, so there needs to be a way to travel back to the previous screen. This is usually done by a “back” chevron in the top left of the screen, but needs to be considered throughout the various journeys in your app.

Button Back

3. Global elementsThere are global elements (like a status bar and header) which appear on all the pages of your design. You shouldn’t be changing the height or style of these bars at all if you want the app to feel native, so I would recommend defining them once in your first page design for each platform.

4. NavigationThe primary navigation pattern on Android is a drawer menu. Android users naturally go to this for menu items, and it tends to be omnipresent throughout the experience. Apple’s guidelines are more in favour of a tab bar, which is located at the bottom of the screen, and allows easy access to the top level areas of the app. When you’re deciding the top level architecture of your app, you can plan out two separate menus for the two platforms.

Android

iOS

5. Cards, or not?Visually, cards fit in very well with Android’s material design (it being inspired by paper). On iOS, using cards needs more care and consideration. iOS guidelines suggest using depth in transparencies and overlays, but the basic view is usually more flat.

Android iOS

6. TypographyThe system font family on iOS is Helvetica Neue. On Android it is Roboto. Although the style of the typefaces are noticeably different, the metrics of the fonts are quite similar.

Android iOS

7. Grids and touch targetsiOS (44px @1x) and Android (48dp - 48px at 1:1 ratio) have slightly differing guidelines for touch targets. Material Design guidelines also suggest aligning all elements to an 8dp square baseline grid.

8. Button stylesFloating action buttons: the most traditionally shaped buttons. The drop shadows are quite heavy and lift them off the page. These should only be used on backgrounds, or sparingly on cards. They shouldn’t be used at all on alerts or popups, as doing so creates too many layers of depth. The primary action takes your accent colour, while the secondary versions are usually a less prominent colour.

Flat buttons: essentially text in your accent colour, without any bounding elements. They use padding and all caps case to give them structure.

Android iOS

9. Action SheetsAction sheets allow users to choose from a multitude of actions from one UI item. With Action sheets, overlays, and alerts, iOS and Android use different details to indicate depth in layers:

Android overlays have a solid colour with a slight drop shadow to indicate that it is a “paper” layer above. iOS overlays have no drop shadow, but have a slight transparency on the background.

Android iOS

10. Segmented controlsOn iOS there are three tabs, styled similarly to the line buttons discussed previously. On Android, they are denoted by a simple underline, and given a lot more white space to signify their interaction.

Android iOS

11. AlertsThe Android alerts use the flat button styles that were shown earlier, dimensions for which can be found in the material design guidelines. The actions sit on the bottom right of the alert. The “buttons” are actually entirely text based. They use all caps to give them more structure, and they carry the primary action colour of your app.

On iOS, the actions are separated by dividers. They are usually in sentence or title case, as they gain their structure from the separate blocks. They are centred in the field, and again they will inherit your active colour.

Android iOS

12. IconsiOS popularised line icons, with very thin strokes. The Android system icons have thicker strokes, or are entirely solid icons.

13. Snackbars, toasts, loading imagesCommon ones like alerts and loading icons are often left to developers. You may have experienced rogue spinners and strange alerts which have felt out of tune with the rest of the app. There tend to be native solutions for these, but they can be tuned to the style of your app. This is definitely an area where collaboration with developers is the best way to decide on which way yours should work.

14. Common UI ControlsRadio buttons, check boxes, fields and switches are functional components that should be given a native feel. Use the native components as much as possible for these. Use your UI kit as much as possible for these components, and again communicate with developers early on in the process.

Summary

It isn’t an impossible task to create a native feel for your app on both iOS and Android with one design. Try to keep on top of these tweaks from the beginning,

keep an eye out for components that feel out of sync on one platform, and always work as closely as you can with developers.

THANK YOUby CAHYANTO ARIE WIBOWOsource : Tutsplus 2016